Closed glaubitz closed 5 months ago
@llvm/issue-subscribers-backend-powerpc
Author: John Paul Adrian Glaubitz (glaubitz)
This regression was introduced by the following commit:
bc73ef0031b50f7443615fef614fb4ecaaa4bd11 is the first bad commit
commit bc73ef0031b50f7443615fef614fb4ecaaa4bd11
Author: Richard Smith <richard@metafoo.co.uk>
Date: Thu Mar 30 14:21:31 2023 -0700
PR60985: Fix merging of lambda closure types across modules.
Previously, distinct lambdas would get merged, and multiple definitions
of the same lambda would not get merged, because we attempted to
identify lambdas by their ordinal position within their lexical
DeclContext. This failed for lambdas within namespace-scope variables
and within variable templates, where the lexical position in the context
containing the variable didn't uniquely identify the lambda.
In this patch, we instead identify lambda closure types by index within
their context declaration, which does uniquely identify them in a way
that's consistent across modules.
This change causes a deserialization cycle between the type of a
variable with deduced type and a lambda appearing as the initializer of
the variable -- reading the variable's type requires reading and merging
the lambda, and reading the lambda requires reading and merging the
variable. This is addressed by deferring loading the deduced type of a
variable until after we finish recursive deserialization.
This also exposes a pre-existing subtle issue where loading a
variable declaration would trigger immediate loading of its initializer,
which could recursively refer back to properties of the variable. This
particularly causes problems if the initializer contains a
lambda-expression, but can be problematic in general. That is addressed
by switching to lazily loading the initializers of variables rather than
always loading them with the variable declaration. As well as fixing a
deserialization cycle, that should improve laziness of deserialization
in general.
LambdaDefinitionData had 63 spare bits in it, presumably caused by an
off-by-one-error in some previous change. This change claims 32 of those bits
as a counter for the lambda within its context. We could probably move the
numbering to separate storage, like we do for the device-side mangling number,
to optimize the likely-common case where all three numbers (host-side mangling
number, device-side mangling number, and index within the context declaration)
are zero, but that's not done in this change.
Fixes #60985.
Reviewed By: #clang-language-wg, aaron.ballman
Differential Revision: https://reviews.llvm.org/D145737
clang/docs/ReleaseNotes.rst | 2 +
clang/include/clang/AST/Decl.h | 2 +-
clang/include/clang/AST/DeclCXX.h | 39 +++--
clang/include/clang/AST/ExternalASTSource.h | 10 +-
clang/include/clang/AST/MangleNumberingContext.h | 8 +
clang/include/clang/AST/Stmt.h | 25 +++
clang/include/clang/Sema/ExternalSemaSource.h | 5 +
.../clang/Sema/MultiplexExternalSemaSource.h | 3 +
clang/include/clang/Sema/Sema.h | 7 +-
clang/include/clang/Serialization/ASTReader.h | 19 ++-
clang/lib/AST/ASTContext.cpp | 9 ++
clang/lib/AST/ASTImporter.cpp | 9 +-
clang/lib/AST/Decl.cpp | 11 +-
clang/lib/AST/DeclCXX.cpp | 11 +-
clang/lib/AST/ODRDiagsEmitter.cpp | 1 +
clang/lib/Sema/MultiplexExternalSemaSource.cpp | 6 +
clang/lib/Sema/SemaExprCXX.cpp | 10 +-
clang/lib/Sema/SemaLambda.cpp | 39 ++---
clang/lib/Sema/TreeTransform.h | 15 +-
clang/lib/Serialization/ASTReader.cpp | 50 ++++--
clang/lib/Serialization/ASTReaderDecl.cpp | 175 +++++++++++++++------
clang/lib/Serialization/ASTReaderStmt.cpp | 8 +-
clang/lib/Serialization/ASTWriter.cpp | 48 +++---
clang/lib/Serialization/ASTWriterDecl.cpp | 71 ++++++---
clang/lib/Serialization/ASTWriterStmt.cpp | 8 +-
clang/test/Modules/lambda-in-variable.cpp | 120 ++++++++++++++
.../parallel_master_taskloop_simd_codegen.cpp | 130 +++++++--------
27 files changed, 593 insertions(+), 248 deletions(-)
create mode 100644 clang/test/Modules/lambda-in-variable.cpp
CC @zygoloid
Has anything been done about this?
Has anything been done about this?
Not that I know of.
Retested today and used LLVM 16 as the bootstrap compiler. Cannot reproduce the issue at the moment.
There seem to be some issues with gcc.
OK, this is definitely not reproducable when using LLVM as the bootstrap compiler. So, I assume this is a GCC bug then.
I will file a bug report in the GCC bug tracker.
If this is not a LLVM issue, should we close this issue? @glaubitz
Feel free to reopen if this should not be closed. As I see from previous comments, this is a GCC's bug instead of LLVM's
I have reported it to GCC [1], but I have not found the time yet to perform more debugging.
Since LLVM 17, the bootstrap fails building stage2 on 32-bit PowerPC with:
Full build log: https://buildd.debian.org/status/fetch.php?pkg=llvm-toolchain-snapshot&arch=powerpc&ver=1%3A18%7E%2B%2B20231102103655%2B18839aec4ed1-1%7Eexp1&stamp=1698940233&raw=0