[llvm-dev] ICE in release/9.x when using LLVM_ENABLE_MODULES
Thomas Preud'homme via llvm-dev
llvm-dev at lists.llvm.org
Tue Jul 30 07:36:12 PDT 2019
I've reduced FileCheck.h (obviously FileCheck.cpp or other users of FileCheck.h won't build with this) to the following while still triggering the bug when building FindSymbols.cpp:
#ifndef LLVM_SUPPORT_FILECHECK_H
#define LLVM_SUPPORT_FILECHECK_H
#include "llvm/Support/Error.h"
#include <string>
llvm::Expected<std::string> getFileCheckResult();
#endif
I do not have any issue if using Optional instead of Expected, nor if using something else than std::string. Moving the header to llvm/include/llvm/Object also allows the compilation to proceed, as well as removing the -fimplicit-module-maps
I'm not sure how to progress further, I believe this hint at the bug being somewhere else instead.
Best regards,
Thomas
________________________________
From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Thomas Preud'homme via llvm-dev <llvm-dev at lists.llvm.org>
Sent: 30 July 2019 09:49
To: Brian Gesiak <modocache at gmail.com>; llvm-dev <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] ICE in release/9.x when using LLVM_ENABLE_MODULES
Hi Brian,
Thanks for letting me know about this. I've been able to reproduce the issue thanks to your reproducer and realized there's some missing include in FileCheck.h, namely for StringRef("llvm/ADT/StringRef.h"), Expected ("llvm/Support/Error.h"), Optional ("llvm/ADT/Optional.h") and std::string (<string>). However that does not solve the problem. Still, this warrants a patch in itself IMO. Unsurprisingly, changing all the Expected<std::string> for Expected<StringRef> in FileCheck.h let the compilation proceed but I can see some other uses of Expected<std::string> in headers so that ought not to be a problem. Please find below the backtrace when building the first stage llvm with debug info:
#0 __GI_raise (sig=sig at entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x00007ffff687b801 in __GI_abort () at abort.c:79
#2 0x00007ffff686b39a in __assert_fail_base (fmt=0x7ffff69f27d8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
assertion=assertion at entry=0x55555f5b0b98 "CachedFieldIndex && \"failed to find field in parent\"",
file=file at entry=0x55555f5afa88 "/home/thomasp/repos/llvm-project-modules-crash/clang/lib/AST/Decl.cpp", line=line at entry=3932,
function=function at entry=0x55555f5c3640 <clang::FieldDecl::getFieldIndex() const::__PRETTY_FUNCTION__> "unsigned int clang::FieldDecl::getFieldIndex() const") at assert.c:92
#3 0x00007ffff686b412 in __GI___assert_fail (assertion=0x55555f5b0b98 "CachedFieldIndex && \"failed to find field in parent\"",
file=0x55555f5afa88 "clang/lib/AST/Decl.cpp", line=3932,
function=0x55555f5c3640 <clang::FieldDecl::getFieldIndex() const::__PRETTY_FUNCTION__> "unsigned int clang::FieldDecl::getFieldIndex() const") at assert.c:101
#4 0x000055555c4e8773 in clang::FieldDecl::getFieldIndex (this=0x55557702a108) at clang/lib/AST/Decl.cpp:3932
#5 0x000055555929e37f in clang::CodeGen::CodeGenFunction::EmitLValueForField (this=0x7fffffff7d70, base=..., field=0x55557702a108)
at clang/lib/CodeGen/CGExpr.cpp:3965
#6 0x000055555929d8cc in clang::CodeGen::CodeGenFunction::EmitMemberExpr (this=0x7fffffff7d70, E=0x555577029f38) at clang/lib/CodeGen/CGExpr.cpp:3853
#7 0x000055555928e20b in clang::CodeGen::CodeGenFunction::EmitLValue (this=0x7fffffff7d70, E=0x555577029f38) at clang/lib/CodeGen/CGExpr.cpp:1346
#8 0x000055555928d636 in clang::CodeGen::CodeGenFunction::EmitCheckedLValue (this=0x7fffffff7d70, E=0x555577029f38, TCK=clang::CodeGen::CodeGenFunction::TCK_MemberAccess)
at clang/lib/CodeGen/CGExpr.cpp:1212
#9 0x000055555929d782 in clang::CodeGen::CodeGenFunction::EmitMemberExpr (this=0x7fffffff7d70, E=0x55557702a2b8) at clang/lib/CodeGen/CGExpr.cpp:3849
#10 0x000055555928e20b in clang::CodeGen::CodeGenFunction::EmitLValue (this=0x7fffffff7d70, E=0x55557702a2b8) at clang/lib/CodeGen/CGExpr.cpp:1346
#11 0x000055555929fb59 in clang::CodeGen::CodeGenFunction::EmitCastLValue (this=0x7fffffff7d70, E=0x55557702a2e8) at clang/lib/CodeGen/CGExpr.cpp:4264
#12 0x000055555928e36b in clang::CodeGen::CodeGenFunction::EmitLValue (this=0x7fffffff7d70, E=0x55557702a2e8) at clang/lib/CodeGen/CGExpr.cpp:1367
#13 0x000055555928d636 in clang::CodeGen::CodeGenFunction::EmitCheckedLValue (this=0x7fffffff7d70, E=0x55557702a2e8, TCK=clang::CodeGen::CodeGenFunction::TCK_MemberAccess)
at clang/lib/CodeGen/CGExpr.cpp:1212
#14 0x000055555929d782 in clang::CodeGen::CodeGenFunction::EmitMemberExpr (this=0x7fffffff7d70, E=0x55557702a380) at clang/lib/CodeGen/CGExpr.cpp:3849
#15 0x000055555928e20b in clang::CodeGen::CodeGenFunction::EmitLValue (this=0x7fffffff7d70, E=0x55557702a380) at clang/lib/CodeGen/CGExpr.cpp:1346
#16 0x00005555592998d5 in clang::CodeGen::CodeGenFunction::EmitArrayToPointerDecay (this=0x7fffffff7d70, E=0x55557702a380, BaseInfo=0x0, TBAAInfo=0x0)
at clang/lib/CodeGen/CGExpr.cpp:3307
#17 0x00005555592de962 in (anonymous namespace)::ScalarExprEmitter::VisitCastExpr (this=0x7fffffff7870, CE=0x55557702a3b0)
at clang/lib/CodeGen/CGExprScalar.cpp:2145
#18 0x00005555592ef299 in clang::StmtVisitorBase<std::add_pointer, (anonymous namespace)::ScalarExprEmitter, llvm::Value*>::VisitImplicitCastExpr (this=0x7fffffff7870, S=0x55557702a3b0)
at tools/clang/include/clang/AST/StmtNodes.inc:859
#19 0x00005555592edb8d in clang::StmtVisitorBase<std::add_pointer, (anonymous namespace)::ScalarExprEmitter, llvm::Value*>::Visit (this=0x7fffffff7870, S=0x55557702a3b0)
at tools/clang/include/clang/AST/StmtNodes.inc:859
#20 0x00005555592d59c9 in (anonymous namespace)::ScalarExprEmitter::Visit (this=0x7fffffff7870, E=0x55557702a3b0) at clang/lib/CodeGen/CGExprScalar.cpp:424
#21 0x00005555592de09e in (anonymous namespace)::ScalarExprEmitter::VisitCastExpr (this=0x7fffffff7870, CE=0x55557702a3c8)
at clang/lib/CodeGen/CGExprScalar.cpp:2040
#22 0x00005555592d6732 in (anonymous namespace)::ScalarExprEmitter::VisitExplicitCastExpr (this=0x7fffffff7870, E=0x55557702a3c8)
at clang/lib/CodeGen/CGExprScalar.cpp:573
#23 0x00005555592ef759 in clang::StmtVisitorBase<std::add_pointer, (anonymous namespace)::ScalarExprEmitter, llvm::Value*>::VisitCXXNamedCastExpr (this=0x7fffffff7870, S=0x55557702a3c8)
at tools/clang/include/clang/AST/StmtNodes.inc:817
#24 0x00005555592ef227 in clang::StmtVisitorBase<std::add_pointer, (anonymous namespace)::ScalarExprEmitter, llvm::Value*>::VisitCXXReinterpretCastExpr (this=0x7fffffff7870, S=0x55557702a3c8)
at tools/clang/include/clang/AST/StmtNodes.inc:833
#25 0x00005555592edb45 in clang::StmtVisitorBase<std::add_pointer, (anonymous namespace)::ScalarExprEmitter, llvm::Value*>::Visit (this=0x7fffffff7870, S=0x55557702a3c8)
at tools/clang/include/clang/AST/StmtNodes.inc:833
#26 0x00005555592d59c9 in (anonymous namespace)::ScalarExprEmitter::Visit (this=0x7fffffff7870, E=0x55557702a3c8) at clang/lib/CodeGen/CGExprScalar.cpp:424
#27 0x00005555592eb469 in clang::CodeGen::CodeGenFunction::EmitScalarExpr (this=0x7fffffff7d70, E=0x55557702a3c8, IgnoreResultAssign=false)
at clang/lib/CodeGen/CGExprScalar.cpp:4488
#28 0x0000555558f48431 in clang::CodeGen::CodeGenFunction::EmitReturnStmt (this=0x7fffffff7d70, S=...) at clang/lib/CodeGen/CGStmt.cpp:1097
#29 0x0000555558f4416e in clang::CodeGen::CodeGenFunction::EmitStmt (this=0x7fffffff7d70, S=0x55557702a408, Attrs=...) at clang/lib/CodeGen/CGStmt.cpp:144
#30 0x0000555558f44ddb in clang::CodeGen::CodeGenFunction::EmitCompoundStmtWithoutScope (this=0x7fffffff7d70, S=..., GetLast=false, AggSlot=...)
at clang/lib/CodeGen/CGStmt.cpp:386
#31 0x0000555558fc8045 in clang::CodeGen::CodeGenFunction::EmitFunctionBody (this=0x7fffffff7d70, Body=0x55557702a498)
at clang/lib/CodeGen/CodeGenFunction.cpp:1023
#32 0x0000555558fc8caf in clang::CodeGen::CodeGenFunction::GenerateCode (this=0x7fffffff7d70, GD=..., Fn=0x555579b00fc8, FnInfo=...)
at clang/lib/CodeGen/CodeGenFunction.cpp:1188
#33 0x0000555558ff07ad in clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition (this=0x555561837460, GD=..., GV=0x555579b00fc8)
at clang/lib/CodeGen/CodeGenModule.cpp:4295
#34 0x0000555558fe9ad4 in clang::CodeGen::CodeGenModule::EmitGlobalDefinition (this=0x555561837460, GD=..., GV=0x555579b00fc8)
at clang/lib/CodeGen/CodeGenModule.cpp:2740
#35 0x0000555558fe6d11 in clang::CodeGen::CodeGenModule::EmitDeferred (this=0x555561837460) at clang/lib/CodeGen/CodeGenModule.cpp:2118
#36 0x0000555558fe6d5f in clang::CodeGen::CodeGenModule::EmitDeferred (this=0x555561837460) at clang/lib/CodeGen/CodeGenModule.cpp:2124
#37 0x0000555558fe6d5f in clang::CodeGen::CodeGenModule::EmitDeferred (this=0x555561837460) at clang/lib/CodeGen/CodeGenModule.cpp:2124
#38 0x0000555558fddfb9 in clang::CodeGen::CodeGenModule::Release (this=0x555561837460) at clang/lib/CodeGen/CodeGenModule.cpp:393
#39 0x0000555559e08f29 in (anonymous namespace)::CodeGeneratorImpl::HandleTranslationUnit (this=0x555561831d40, Ctx=...)
at clang/lib/CodeGen/ModuleBuilder.cpp:256
#40 0x0000555559e024b8 in clang::BackendConsumer::HandleTranslationUnit (this=0x555561831ab0, C=...) at clang/lib/CodeGen/CodeGenAction.cpp:238
#41 0x000055555b3c274c in clang::ParseAST (S=..., PrintStats=false, SkipFunctionBodies=false) at clang/lib/Parse/ParseAST.cpp:171
#42 0x00005555595bb943 in clang::ASTFrontendAction::ExecuteAction (this=0x55556180d440) at clang/lib/Frontend/FrontendAction.cpp:1035
#43 0x0000555559e0067f in clang::CodeGenAction::ExecuteAction (this=0x55556180d440) at clang/lib/CodeGen/CodeGenAction.cpp:1059
#44 0x00005555595bb332 in clang::FrontendAction::Execute (this=0x55556180d440) at clang/lib/Frontend/FrontendAction.cpp:934
#45 0x00005555595576c4 in clang::CompilerInstance::ExecuteAction (this=0x5555617e1a60, Act=...) at clang/lib/Frontend/CompilerInstance.cpp:944
#46 0x0000555559715a87 in clang::ExecuteCompilerInvocation (Clang=0x5555617e1a60) at clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:287
#47 0x000055555762f146 in cc1_main (Argv=..., Argv0=0x7fffffffd6a4 "build-s1/bin/clang-9",
MainAddr=0x555557622e5a <GetExecutablePath[abi:cxx11](char const*, bool)>) at clang/tools/driver/cc1_main.cpp:250
#48 0x00005555576245cb in ExecuteCC1Tool (argv=..., Tool=...) at clang/tools/driver/driver.cpp:309
#49 0x0000555557624cbc in main (argc_=125, argv_=0x7fffffffcf48) at clang/tools/driver/driver.cpp:381
Note that I think this should give an error message rather than an assert but of course that does not change that there is a bug somewhere. I'll keep looking.
Best regards,
Thomas
________________________________
From: Brian Gesiak <modocache at gmail.com>
Sent: 29 July 2019 14:40
To: llvm-dev <llvm-dev at lists.llvm.org>
Cc: Thomas Preud'homme <thomasp at graphcore.ai>
Subject: ICE in release/9.x when using LLVM_ENABLE_MODULES
[This message was sent from somebody outside of your organisation]
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
** We have updated our privacy policy, which contains important information about how we collect and process your personal data. To read the policy, please click here<http://www.graphcore.ai/privacy> **
This email and its attachments are intended solely for the addressed recipients and may contain confidential or legally privileged information.
If you are not the intended recipient you must not copy, distribute or disseminate this email in any way; to do so may be unlawful.
Any personal data/special category personal data herein are processed in accordance with UK data protection legislation.
All associated feasible security measures are in place. Further details are available from the Privacy Notice on the website and/or from the Company.
Graphcore Limited (registered in England and Wales with registration number 10185006) is registered at 107 Cheapside, London, UK, EC2V 6DN.
This message was scanned for viruses upon transmission. However Graphcore accepts no liability for any such transmission.
** We have updated our privacy policy, which contains important information about how we collect and process your personal data. To read the policy, please click here<http://www.graphcore.ai/privacy> **
This email and its attachments are intended solely for the addressed recipients and may contain confidential or legally privileged information.
If you are not the intended recipient you must not copy, distribute or disseminate this email in any way; to do so may be unlawful.
Any personal data/special category personal data herein are processed in accordance with UK data protection legislation.
All associated feasible security measures are in place. Further details are available from the Privacy Notice on the website and/or from the Company.
Graphcore Limited (registered in England and Wales with registration number 10185006) is registered at 107 Cheapside, London, UK, EC2V 6DN.
This message was scanned for viruses upon transmission. However Graphcore accepts no liability for any such transmission.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190730/039918cb/attachment.html>
More information about the llvm-dev
mailing list