Created attachment 17936 [details] Repro reduced Clang-4.0 (and trunk) are crashing when building Unreal Engine, a PCH can't be read back we hit this assertion. I believe this is a regression from clang-3.9 introduced in r276159: Author: Richard Smith <richard-llvm@metafoo.co.uk> Date: Wed Jul 20 14:10:16 2016 [modules] Don't emit initializers for VarDecls within a module eagerly whenever we first touch any part of that module. Instead, defer them until the first time that module is (transitively) imported. The initializer step for a module then recursively initializes modules that its own headers imported. For example, this avoids running the <iostream> global initializer in programs that don't actually use iostreams, but do use other parts of the standard library. Reduced repro attached. Run with: clang -c -x objective-c++-header pre.h -std=c++14 -o pre.gch clang -c -x objective-c++ /dev/null -std=c++14 -include-pch pre.gch
(In reply to comment #0) > clang -c -x objective-c++-header pre.h -std=c++14 -o pre.gch > clang -c -x objective-c++ /dev/null -std=c++14 -include-pch pre.gch Note: the same repro works with -x c++-header and -x c++.
@rsmith, I've attempted a fix, can you take a look? https://reviews.llvm.org/D29753
A stopgap fix for PCH was committed in r296656. The problem still happens with modules though. Richard triggered the issue with: $ cat test/PCH/empty-def-fwd-struct.modulemap module M { header "empty-def-fwd-struct.h" } $ clang -cc1 -x c++ -std=c++14 -fmodules -emit-module -fmodule-name=M test/PCH/empty-def-fwd-struct.modulemap -o tmp.pcm $ cat use.cpp #include "test/PCH/empty-def-fwd-struct.h" $ clang -cc1 -x c++ -std=c++14 -fmodules -emit-llvm -fmodule-file=tmp.pcm use.cpp -o - clang: [...]/src/tools/clang/lib/AST/RecordLayoutBuilder.cpp:2933: const clang::ASTRecordLayout &clang::ASTContext::getASTRecordLayout(const clang::RecordDecl *) const: Assertion `D && "Cannot get layout of forward declarations!"' failed. Leaving this open until we find a more complete solution.
(In reply to Bruno Cardoso Lopes from comment #3) > A stopgap fix for PCH was committed in r296656. Thanks! I will merge it to the release branch once it's been in tree for a bit.
(In reply to Hans Wennborg from comment #4) > (In reply to Bruno Cardoso Lopes from comment #3) > > A stopgap fix for PCH was committed in r296656. > > Thanks! I will merge it to the release branch once it's been in tree for a > bit. Merged to 4.0 in r296762. If we can fix this properly for 4.0.1 that would be great, so marking it a blocker of that.
*** Bug 32186 has been marked as a duplicate of this bug. ***
PR32186 has a totally unrelated symptom with the same root cause (the call to DeclMustBeEmitted in a context where AST invariants are not met during deserialization).
*** Bug 32144 has been marked as a duplicate of this bug. ***
This was mostly addressed by https://reviews.llvm.org/D30793 / r300110. A follow-up fix is under review in https://reviews.llvm.org/D32499.
Second part of the fix landed in r303432.
Richard, now that the fixes have been merged, are https://reviews.llvm.org/rL300110 and https://reviews.llvm.org/rL303432 OK to merge to the release_40 branch?
r303432 is very new; would you prefer to merge it now and revert it from the branch if people have problems with it on trunk, or wait a few days and merge it if there are no complications? (I'm not anticipating any problems, just cautious about merging a patch that's not really been field-tested.) I'm fine with merging r300110 now.
*** Bug 33313 has been marked as a duplicate of this bug. ***