[llvm-dev] ICE in release/9.x when using LLVM_ENABLE_MODULES
Akira Hatanaka via llvm-dev
llvm-dev at lists.llvm.org
Thu Aug 1 14:23:55 PDT 2019
On Tue, Jul 30, 2019 at 7:53 AM Brian Gesiak <modocache at gmail.com> wrote:
> 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?
Sorry, I didn't notice that someone had disabled modules by passing
'-DLLVM_ENABLE_MODULES=Off' to cmake. I think that's why we haven't seen
the failure since July 19th.
- 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:
> >> 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.
> >> Generating code for declaration
> >> 'llvm::Expected<std::__cxx11::basic_string<char> >::getStorage'
> >> /lib/x86_64-linux-gnu/libpthread.so.0(+0x13f40)[0x7f3bc780af40]
> >> ```
> >> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev