The ATS community is having trouble with clang. They had been using an older version of clang and upgraded because newer versions give higher quality warning messages. Unfortunately, with 3.5, moving from -O1 to -O2 triggers a crash on startup in the clang-generated executable. I had suggested building with -fsanitize=undefined and -fsanitize=address to weed out any dependencies undefined behavior. All their generated C code came out clean. Here is the workaround Hongwei Xi came up with: https://github.com/githwxi/ATS-Postiats/commit/5e17db4badf58b404598e8b3ae4a666b8b0e889c Looks like a bug on the LLVM side. He says it worked with clang 3.3, but breaks on 3.4 and 3.5. Would someone be interested in investigating this further? It's fallen down to an area I don't think I can debug quickly and if we can squeeze a fix into 3.6, that'd be great. ATS is such an interesting language, I hope we can help. Thanks, Greg
Is there a bug filed with the affected C code, or better, a standalone reproducer? I don't know ATS, so it's hard to diagnose from an ATS diff. On Tue, Jan 27, 2015 at 10:04 AM, Greg Fitzgerald <garious at gmail.com> wrote:> The ATS community is having trouble with clang. They had been using > an older version of clang and upgraded because newer versions give > higher quality warning messages. Unfortunately, with 3.5, moving from > -O1 to -O2 triggers a crash on startup in the clang-generated > executable. I had suggested building with -fsanitize=undefined and > -fsanitize=address to weed out any dependencies undefined behavior. > All their generated C code came out clean. Here is the workaround > Hongwei Xi came up with: > > > https://github.com/githwxi/ATS-Postiats/commit/5e17db4badf58b404598e8b3ae4a666b8b0e889c > > Looks like a bug on the LLVM side. He says it worked with clang 3.3, > but breaks on 3.4 and 3.5. Would someone be interested in > investigating this further? It's fallen down to an area I don't think > I can debug quickly and if we can squeeze a fix into 3.6, that'd be > great. ATS is such an interesting language, I hope we can help. > > Thanks, > Greg > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150127/32aace79/attachment.html>
> Is there a bug filed with the affected C codeI just added: http://llvm.org/bugs/show_bug.cgi?id=22360> or better, a standalone reproducer?I added code sent by Hongwei Xi to the bug report, but it is not minimal or standalone. :-/ A job for bugpoint?> I don't know ATS, so it's hard to diagnose from an ATS diff.The diff just aims to demonstrate that that the bug is likely in Clang and not the ATS-generated C code. He added a level of indirection to prevent the optimizer for kicking in. -Greg On Tue, Jan 27, 2015 at 2:11 PM, Reid Kleckner <rnk at google.com> wrote:> Is there a bug filed with the affected C code, or better, a standalone > reproducer? I don't know ATS, so it's hard to diagnose from an ATS diff. > > On Tue, Jan 27, 2015 at 10:04 AM, Greg Fitzgerald <garious at gmail.com> wrote: >> >> The ATS community is having trouble with clang. They had been using >> an older version of clang and upgraded because newer versions give >> higher quality warning messages. Unfortunately, with 3.5, moving from >> -O1 to -O2 triggers a crash on startup in the clang-generated >> executable. I had suggested building with -fsanitize=undefined and >> -fsanitize=address to weed out any dependencies undefined behavior. >> All their generated C code came out clean. Here is the workaround >> Hongwei Xi came up with: >> >> >> https://github.com/githwxi/ATS-Postiats/commit/5e17db4badf58b404598e8b3ae4a666b8b0e889c >> >> Looks like a bug on the LLVM side. He says it worked with clang 3.3, >> but breaks on 3.4 and 3.5. Would someone be interested in >> investigating this further? It's fallen down to an area I don't think >> I can debug quickly and if we can squeeze a fix into 3.6, that'd be >> great. ATS is such an interesting language, I hope we can help. >> >> Thanks, >> Greg >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >