[llvm-dev] ICE in release/9.x when using LLVM_ENABLE_MODULES

[Brian Gesiak via llvm-dev]

Thank you for the link and the suggestion to try master! I did so and
discovered that it reproduces on master for me as well. The repro
script I used (unchanged from before) and the output can be found
here: https://gist.github.com/modocache/d9700166067f4a155820bc57d9bee1f3

(Note that the output looks nearly identical, but it's using clang-10
from the master branch of llvm-project.)

I wonder why the buildbots would begin passing again, whereas locally
the issue reproduces... very strange. Looking at the CMake invocation
in the build logs that Akira linked to, I can see that
'-DLLVM_ENABLE_MODULES=On' is being used. Could it be one of the other
options is masking the error I'm seeing on master?

- Brian Gesiak

On Mon, Jul 29, 2019 at 1:51 PM Akira Hatanaka <ahatanak at gmail.com> wrote:
>
> This is probably the same failure we've been seeing here:
>
> http://green.lab.llvm.org/green/job/clang-stage2-coverage-R/4124/console
>
> But it looks like the bot has turned green since July 19th, so I'm wondering whether you are still seeing the same failure if you use trunk?
>
> If I remember correctly, there was a MemberExpr node in the AST that was referencing the anonymous union in class Expected, but the parent class (class Expected) didn't contain the AST node for the anonymous union.
>
> On Mon, Jul 29, 2019 at 6:41 AM Brian Gesiak via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>>
>> I ran into an LLVM/Clang crash when attempting to do the following:
>>
>> 1. Build Clang from the release/9.x branch source.
>> 2. Use the Clang from (1) to build clangd on the release/9.x branch,
>> with LLVM_ENABLE_MODULES=On.
>>
>> I wrote a script to reproduce the crash:
>> https://gist.github.com/modocache/ac366ca9673b93bb21e75d3e72162608
>>
>> At the above URL, you'll find a script `repro.sh` that reproduces the
>> crash, and a file `out.txt` that contains the build output and the
>> stack trace.
>>
>> I used the script to bisect, and bisect determined the first "bad" commit was:
>> https://github.com/llvm/llvm-project/commit/baae41ff76f662987f31447686ba819dcd748b3f
>>
>> The stack trace appears to crash when generating code for an
>> `llvm::Expected` declaration, and the commit above seems to add a few
>> of them, so that seems suspicious. The stack trace is in the GitHub
>> gist URL above, but I'll also paste the relevant portion here:
>>
>> ```
>> Stack dump:
>> 0. Program arguments: ...
>> 1. <eof> parser at end of file
>> 2. Per-file LLVM IR generation
>> 3. /home/modocache/Source/llvm/git/dev/llvm-project/llvm/include/llvm/Support/Error.h:625:17:
>> Generating code for declaration
>> 'llvm::Expected<std::__cxx11::basic_string<char> >::getStorage'
>> /home/modocache/Source/llvm/git/dev/build-s1/bin/clang-9(_ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamE+0x2a)[0x557bc131549a]
>> /home/modocache/Source/llvm/git/dev/build-s1/bin/clang-9(_ZN4llvm3sys17RunSignalHandlersEv+0x34)[0x557bc13131b4]
>> /home/modocache/Source/llvm/git/dev/build-s1/bin/clang-9(+0x1649335)[0x557bc1313335]
>> /lib/x86_64-linux-gnu/libpthread.so.0(+0x13f40)[0x7f3bc780af40]
>> /home/modocache/Source/llvm/git/dev/build-s1/bin/clang-9(_ZN5clang7CodeGen15CodeGenFunction18EmitLValueForFieldENS0_6LValueEPKNS_9FieldDeclE+0x8ad)[0x557bc1749abd]
>> ```
>>
>> I have an immediate workaround -- I can turn off LLVM_ENABLE_MODULES,
>> and the crash goes away. However, I think it might be worth looking
>> into the commit above and determining why it crashes when using
>> `-fmodules`. At first glance, I don't see the problem, but I've cc'ed
>> the author, in case they might know more.
>>
>> Does anyone have any ideas on how to fix the underlying crash?
>>
>> - Brian Gesiak
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev