Closes https://github.com/llvm/llvm-project/issues/59765.
Currently we will generate the global ctor/dtor for variables in
importing modules. It will cause multiple initialization/destructions.
It makes no sense. This patch tries to not generate global ctor/dtor for
variables which are available externally. Note that the variables in
header units and clang modules won't be available externally by default.
Reviewed By: iains
Differential Revision: https://reviews.llvm.org/D140867
[module.import/6] last sentence:
A header unit shall not contain a definition of a non-inline function or
variable whose name has external linkage.
Differential Revision: https://reviews.llvm.org/D140261
Implement https://cplusplus.github.io/CWG/issues/2631.html.
Immediate calls in default arguments and defaults members
are not evaluated.
Instead, we evaluate them when constructing a
`CXXDefaultArgExpr`/`BuildCXXDefaultInitExpr`.
The immediate calls are executed by doing a
transform on the initializing expression.
Note that lambdas are not considering subexpressions so
we do not need to transform them.
As a result of this patch, unused default member
initializers are not considered odr-used, and
errors about members binding to local variables
in an outer scope only surface at the point
where a constructor is defined.
Reviewed By: aaron.ballman, #clang-language-wg, rupprecht
Differential Revision: https://reviews.llvm.org/D136554
During template instantiation, the instantiator will enter constant
evaluated
context before instantiate a template argument originated from an
expression,
and this impedes the instantiator from creating lambdas with independent
types.
This patch solves the problem via widening the condition that the
instantiator
marks lambdas as never dependent, and fixes the issue #57960
Differential Revision: https://reviews.llvm.org/D140554
This is the default behavior and cuts down on attribute spam.
Probably should also do something to consolidate the option spellings;
printing and parsing it is repeated in at least 3 different places.
In the OpenMP tests, I had to manually delete some metadata check
lines update_cc_test_checks was inserting that included the local
build revision.
This is an alternative way of D139627 suggested by Craig. Creently only X86 backend uses this attribute. Let's just emit for X86 only.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D139701
This reverts commit e43924a75145d2f9e722f74b673145c3e62bfd07.
Reason: Patch broke the MSan buildbots. More information is available on
the original phabricator review: https://reviews.llvm.org/D127812
For the Itanium ABI, we emit an initializer for each module. This is responsible
for handling initialization of global vars. Relates to P1874R1.
The initializer has a known mangling and is automatically called from any TU that
imports a module. Since, at present, the importer has no way to determine that an
imported module does not require an initializer, we generate the initializer for
all cases (even when it is empty).
Initializers must be run once, with the ordering guaranteed by the import graph
and this is ensured in the current code by addition of a guard variable.
In the case that a module has no requirement for global initializers, and also does
not import any other modules, we can elide the guard variable.
Differential Revision: https://reviews.llvm.org/D134589
After this patch, in the following snippet:
```
template <typename T> Foo {};
template <template <typename T> class CT = Foo> Bar {};
Bar<> b;
```
The debug-info entry for the `CT` template parameter will have
a `DW_AT_default_value (true)` attached to it.
Differential Revision: https://reviews.llvm.org/D139989
DWARFv5 added support for labelling template parameters with
DW_AT_default_value to indicate whether the particular instantiation
defaulted parameter. The current implementation only supports a limited
set of possible cases. Namely for non-value-dependent integral template
parameters and simple type template parameters.
Useful cases that don't work are:
1. Type template parameters with defaults that are
themselves templates. E.g.,
```
template<typename T1, typename T2 = Foo<T1>> class C1;
template<typename T = Foo<int>> class C2;
etc.
```
2. Template template parameters
`clang::isSubstitutedDefaultArgument` already implement the required logic
to determine whether a template argument is defaulted. This patch re-uses
this logic for DWARF CodeGen.
Differential Revision: https://reviews.llvm.org/D139988
This reverts commit 731abdfdcc33d813e6c3b4b89eff307aa5c18083.
This commit breaks some tests in libcxx, e.g.
`std/utilities/expected/expected.expected/ctor/ctor.inplace.pass.cpp`
RecordLayoutBuilder assumes the size of a potentially-overlapping field
with non-zero size as the size of the base subobject type corresponding
to the field type.
Make CGRecordLayoutBuilder to acknowledge that in order to avoid incorrect
padding insertion.
Differential Revision: https://reviews.llvm.org/D139741
**Summary**
Starting with DWARFv5, DW_AT_default_value can be used to indicate
that a template argument has a default value. With this patch LLVM
will emit the this attribute earlier versions of DWARF, unless
compiling with -gstrict-dwarf.
Differential Revision: https://reviews.llvm.org/D139953
**Summary**
Starting with DWARFv5, DW_AT_default_value can be used to indicate
that a template argument has a default value. With this patch Clang
will attach the attribute to the debug metadata regardless of version.
In a follow-up patch we will change llvm to emit this attribute in
earlier versions of DWARF, unless compiling with -gstrict-dwarf.
**Details**
* Previously the DwarfVersion check in CGDebugInfo was inconsistent:
For non-type template arguments we attached the attribute to the debug
metadata in DWARFv5 only. Whereas for type template arguments we didn't
have such a version restriction. With this patch we attach the attribute
regardless of DWARF version (and instead offload the check to the AsmPrinter
in a future patch).
This reverts commit f1f1b60c7ba607e9ffe3bc012161d43ef95ac773.
Temporary revert, possibly triggers a new assertion failure on
QualType::getCommonPtr.
We're working on a reproducer, to follow-up on
https://reviews.llvm.org/D136554.
Implement https://cplusplus.github.io/CWG/issues/2631.html.
Immediate calls in default arguments and defaults members
are not evaluated.
Instead, we evaluate them when constructing a
`CXXDefaultArgExpr`/`BuildCXXDefaultInitExpr`.
The immediate calls are executed by doing a
transform on the initializing expression.
Note that lambdas are not considering subexpressions so
we do not need to transform them.
As a result of this patch, unused default member
initializers are not considered odr-used, and
errors about members binding to local variables
in an outer scope only surface at the point
where a constructor is defined.
Reviewed By: aaron.ballman, #clang-language-wg
Differential Revision: https://reviews.llvm.org/D136554
to member naming a weak member to nullptr.
This fixes a miscompile where constant evaluation would incorrectly
determine that a weak member function pointer is never null.
In passing, also improve the diagnostics for constant evaluation of some
nearby cases.
This may be a breaking change for consumers if they're trying to detect
if code is C or C++, since it'll start using new codes that they may not
be ready to recognize, in which case they may fall back to non-C
handling.
This caused regressions due to PS4 having a different default for C
language version than other targets. Those tests were adapted to be
relaxed about which C version is used.
This reapplies commit 3c312e48f325c1b1ee11404ee6cfa08ee00037b0
Which was reverted by commit 6ab6085c77ef9bcdabf842342f63fba4291791a4.
Differential Revision: https://reviews.llvm.org/D138597
Implement https://cplusplus.github.io/CWG/issues/2631.html.
Immediate calls in default arguments and defaults members
are not evaluated.
Instead, we evaluate them when constructing a
`CXXDefaultArgExpr`/`BuildCXXDefaultInitExpr`.
The immediate calls are executed by doing a
transform on the initializing expression.
Note that lambdas are not considering subexpressions so
we do not need to transform them.
As a result of this patch, unused default member
initializers are not considered odr-used, and
errors about members binding to local variables
in an outer scope only surface at the point
where a constructor is defined.
Reviewed By: aaron.ballman, #clang-language-wg
Differential Revision: https://reviews.llvm.org/D136554
Over the past day or so, i've took a large swing at our tests,
and reduced the number of tests that were still using the old syntax
from ~1800 to just 200.
Left to handle: (as it is seen in this patch)
* Transforms/LSR
* Transforms/CGP
* Transforms/TypePromotion
* Transforms/HardwareLoops
* Analysis/*
* some misc.
I think this is the right point to start actively refusing
to honor the old syntax, except for the old tests,
to prevent the old syntax from creeping back in.
Thus, let's add temporary default-off flag,
and if it is not passed refuse to accept old syntax.
The tests that still need porting are annotated with this flag.
Reviewed By: aeubanks
Differential Revision: https://reviews.llvm.org/D139647
Implement https://cplusplus.github.io/CWG/issues/2631.html.
Immediate calls in default arguments and defaults members
are not evaluated.
Instead, we evaluate them when constructing a
`CXXDefaultArgExpr`/`BuildCXXDefaultInitExpr`.
The immediate calls are executed by doing a
transform on the initializing expression.
Note that lambdas are not considering subexpressions so
we do not need to transform them.
As a result of this patch, unused default member
initializers are not considered odr-used, and
errors about members binding to local variables
in an outer scope only surface at the point
where a constructor is defined.
Reviewed By: aaron.ballman, #clang-language-wg
Differential Revision: https://reviews.llvm.org/D136554
Prior to this, metadata pertaining to the size or address point offsets
into a relative vtable were twice the value they should be (treating
component widths as pointer width rather than 4 bytes). This prevented
some vtables from being devirtualized with D134320. This ensures the
correct metadata is written so whole program devirtualization can catch
these remaining devirt targets.
Differential Revision: https://reviews.llvm.org/D134687
The global constant arguments could be in a different address space
than the first argument, so we have to add another overloaded argument.
This patch was originally made for CHERI LLVM (where globals can be in
address space 200), but it also appears to be useful for in-tree targets
as can be seen from the test diffs.
Differential Revision: https://reviews.llvm.org/D138722
Some buildbots are failing in Clang and LLDB tests. (I guess the LLDB
failure is due to the explicit C language tests in DwarfUnit.cpp that
need to be updated - not sure what the Clang failures are about, they
seem to be still emitting C99 when we're expecting C11 and I checked
those tests pass... maybe systems with a different C language version
default?)
This reverts commit 3c312e48f325c1b1ee11404ee6cfa08ee00037b0.
This may be a breaking change for consumers if they're trying to detect
if code is C or C++, since it'll start using new codes that they may not
be ready to recognize, in which case they may fall back to non-C
handling.
Differential Revision: https://reviews.llvm.org/D138597
This reverts commit 26fa17ed2914bd80c066d36b325fd3104e45554c.
This reverts commit 4403c4f9e77e673a2771edfc7ab0ebb234e97485.
There is still an ODR issue causing linker errors, investigating.
Implement https://cplusplus.github.io/CWG/issues/2631.html.
Immediate calls in default arguments and defaults members
are not evaluated.
Instead, we evaluate them when constructing a
`CXXDefaultArgExpr`/`BuildCXXDefaultInitExpr`.
The immediate calls are executed by doing a
transform on the initializing expression.
Note that lambdas are not considering subexpressions so
we do not need to transform them.
As a result of this patch, unused default member
initializers are not considered odr-used, and
errors about members binding to local variables
in an outer scope only surface at the point
where a constructor is defined.
Reviewed By: aaron.ballman, #clang-language-wg
Differential Revision: https://reviews.llvm.org/D136554
When generating __clang_call_terminate use SetLLVMFunctionAttributes
to set the default function attributes, like we do for all the other
functions generated by clang. This fixes a problem where target
features from the command line weren't being applied to this function.
Differential Revision: https://reviews.llvm.org/D138679
After accepted in Kona, update the code to accept static operator[] as well.
No big code changes: accept this operator as static in SemaDeclCXX, update AST call generation in SemaOverload and update feature macros + tests accordingly.
Reviewed By: cor3ntin, erichkeane, #clang-language-wg
Differential Revision: https://reviews.llvm.org/D138387
This used to be required, but the difference between asserts/!asserts
builds no longer exists for %clang_cc1 (only for %clang), so they pass
just fine without this flag.
Initialisation Guard Variables should take their DLL storage class
from the guarded variable. Otherwise, there will be a link error if
the compiler inlines a reference to the guard variable into another
module but that guard variable is not exported from the defining
module.
This is required for platforms such as PlayStation and
windows-itanium, that are aiming for source compatibility with MSVC
w.r.t. dllimport/export annotations, given Clang's existing design
which allows for inlining of a dllimport function as long as all the
variables/functions referenced are also marked dllimport.
A similar change exists for the MSVC ABI:
https://reviews.llvm.org/D4136.
I have added a run test for windows-itanium for this issue to the
build recipe: https://reviews.llvm.org/D88124.
Differential Revision: https://reviews.llvm.org/D138463
