With codegen prior to this patch, truly indirect arguments -- i.e.
those that are not `byval` -- can have their debug information lost even
at O0. Because indirect arguments are passed by pointer, and this
pointer is likely placed in a register as per the function call ABI,
debug information is lost as soon as the register gets clobbered.
This patch solves the issue by storing the address of the parameter on
the stack, using a similar strategy employed when C++ references are
passed. In other words, this patch changes codegen from:
```
define @foo(ptr %arg) {
call void @llvm.dbg.declare(%arg, [...], metadata !DIExpression())
```
To:
```
define @foo(ptr %arg) {
%ptr_storage = alloca ptr
store ptr %arg, ptr %ptr_storage
call void @llvm.dbg.declare(%ptr_storage, [...], metadata !DIExpression(DW_OP_deref))
```
Some common cases where this may happen with C or C++ function calls:
1. "Big enough" trivial structures passed by value under the ARM ABI.
2. Structures that are non-trivial for the purposes of call (as per
the Itanium ABI) when passed by value.
A few tests were matching the wrong alloca (matching against the new
alloca, instead of the old one), so they were updated to either match
both allocas or include a `,` right after the alloca type, to prevent
matching against a pointer type.
Differential Revision: https://reviews.llvm.org/D141381
As the summary explained in https://reviews.llvm.org/D137058,
the design of `-fmodule-output` changes relatively frequently
so I skipped the release notes and docs for -fmodule-output in the
the patches. And the patches get accepted and landed. The patch adds
the related release notes and docs.
This reverts commit 4c37671a7c946ac246b52fa44a6a649b89d6310b,
aka llvmorg-16-init-17246-g4c37671a7c94
This caused many warnings in the current llvm codebase.
Issue #58168 describes the difficulty diagnosing stack size issues
identified by -Wframe-larger-than. For simple code, its easy to
understand the stack layout and where space is being allocated, but in
more complex programs, where code may be heavily inlined, unrolled, and
have duplicated code paths, it is no longer easy to manually inspect the
source program and understand where stack space can be attributed.
This patch implements a machine function pass that emits remarks with a
textual representation of stack slots, and also outputs any available
debug information to map source variables to those slots.
The new behavior can be used by adding `-Rpass-analysis=stack-frame-layout`
to the compiler invocation. Like other remarks the diagnostic
information can be saved to a file in a machine readable format by
adding -fsave-optimzation-record.
Fixes: #58168
Reviewed By: nickdesaulniers, thegameg
Differential Revision: https://reviews.llvm.org/D135488
This change enables implicit conversion warnings (like Wshorten-64-to-32) for compound assignment operator with integral operands.
rdar://10466193
Differential Revision: https://reviews.llvm.org/D139114
RISC-V supports `-march`, `-mtune`, and `-mcpu`: `-march` provides the
architecture extension information, `-mtune` provide the pipeline model, and
`-mcpu` provides both.
What's the priority among those options for now(w/o this patch)?
Pipeline model:
- Take from `-mtune` if present.
- Take from `-mcpu` if present
- Use the default pipeline model: `generic-rv32` or `generic-rv64`
Architecture extension has quite complicated behavior now:
- Take union from `-march` and `-mcpu` if both are present.
- Take from `-march` if present.
- Take from `-mcpu` if present.
- Implied from `-mabi` if present.
- Use the default architecture depending on the target triple
We treat `-mcpu`/`-mtune` and `-mcpu`/`-march` differently, and it's
kind of counterintuitive: -march is explicitly specified but ignored.
This patch adjusts the priority between `-mcpu`/`-march`, letting it use
architecture extension information from `-march` if it's present.
So the priority of architecture extension information becomes:
- Take from `-march` if present.
- Take from `-mcpu` if present.
- Implied from `-mabi` if present.
- Use the default architecture depending on the target triple
And this also match what we implement in RISC-V GCC too.
Reviewed By: craig.topper, MaskRay
Differential Revision: https://reviews.llvm.org/D140693
When using the && operator within a || operator, both Clang and GCC
produce a warning for potentially confusing operator precedence.
However, Clang avoids this warning for certain patterns, such as
a && b || 0 or a || b && 1, where the operator precedence of && and ||
does not change the result.
However, this behavior appears inconsistent when using the const or
constexpr qualifiers. For example:
bool t = true;
bool tt = true || false && t; // Warning: '&&' within '||'
const bool t = true;
bool tt = true || false && t; // No warning
const bool t = false;
bool tt = true || false && t; // Warning: '&&' within '||'
The second example does not produce a warning because
true || false && t matches the a || b && 1 pattern, while the third one
does not match any of them.
This behavior can lead to the lack of warnings for complicated
constexpr expressions. Clang should only suppress this warning when
literal values are placed in the place of t in the examples above.
This patch adds the literal-or-not check to fix the inconsistent
warnings for && within || when using const or constexpr.
This commit relands the patches for implementing P0960R3 and P1975R0,
which describe initializing aggregates via a parenthesized list.
The relanded commits are:
* 40c52159d3ee - P0960R3 and P1975R0: Allow initializing aggregates from
a parenthesized list of values
* c77a91bb7ba7 - Remove overly restrictive aggregate paren init logic
* 32d7aae04fdb - Fix a clang crash on invalid code in C++20 mode
This patch also fixes a crash in the original implementation.
Previously, if the input tried to call an implicitly deleted copy or
move constructor of a union, we would then try to initialize the union
by initializing it's first element with a reference to a union. This
behavior is incorrect (we should fail to initialize) and if the type of
the first element has a constructor with a single template typename
parameter, then Clang will explode. This patch fixes that issue by
checking that constructor overload resolution did not result in a
deleted function before attempting parenthesized aggregate
initialization.
Additionally, this patch also includes D140159, which contains some
minor fixes made in response to code review comments in the original
implementation that were made after that patch was submitted.
Co-authored-by: Sheng <ox59616e@gmail.com>
Fixes#54040, Fixes#59675
Reviewed By: ilya-biryukov
Differential Revision: https://reviews.llvm.org/D141546
Currently we don't diagnose overflow in a constant expression for the case of
compound assignment with remainder as a operand.
In handleIntIntBinOp the arguments LHS and Result can be the same source but in
the check for remainder in this function we assigned to Result before checking
for overflow. In all the other operations the check is done before Result is
assigned to.
Differential Revision: https://reviews.llvm.org/D140455
This reverts commit 879bfe6a979295f834b76df66b19a203b93eed0f.
owenpan@ pointed out on https://reviews.llvm.org/D140956 that this
actually makes the formatting more consistent, so it's not a regression.
> Dependent access checks.
Fixes: https://github.com/llvm/llvm-project/issues/53364
We previously ignored dependent access checks to private members.
These are visible only to the `RequiresExprBodyExpr` (through `PerformDependentDiagnositcs`) and not to the individual requirements.
---
> Non-dependent access checks.
Fixes: https://github.com/llvm/llvm-project/issues/53334
Access to members in a non-dependent context would always yield an
invalid expression. When it appears in a requires-expression, then this
is a hard error as this would always result in a substitution failure.
https://eel.is/c++draft/expr.prim.req#general-note-1
> Note 1: If a requires-expression contains invalid types or expressions in its requirements, and it does not appear within the declaration of a templated entity, then the program is ill-formed. — end note]
> If the substitution of template arguments into a requirement would always result in a substitution failure, the program is ill-formed; no diagnostic required.
The main issue here is the delaying of the diagnostics.
Use a `ParsingDeclRAIIObject` creates a separate diagnostic pool for diagnositcs associated to the `RequiresExprBodyDecl`.
This is important because dependent diagnostics should not be leaked/delayed to higher scopes (Eg. inside a template function or in a trailing requires). These dependent diagnostics must be attached to the `DeclContext` of the parameters of `RequiresExpr` (which is the `RequiresExprBodyDecl` in this case).
Non dependent diagnostics, on the other hand, should not delayed and surfaced as hard errors.
Differential Revision: https://reviews.llvm.org/D140547
This reverts commit a28f0747c2f3728bd8a6f64f7c8ba80b4e0cda9f.
It appears that this regresses some function definitions, added an
example as a comment over at https://reviews.llvm.org/D140956.
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
In C mode, if e1 has __attribute__((noreturn)) but e2 doesn't, `(c ? e1 : e2)`
is incorrectly noreturn and Clang codegen produces `unreachable`
which may lead to miscompiles (see [1] `gawk/support/dfa.c`).
This problem has been known since
8c6b56f39d967347f28dd9c93f1cffddf6d7e4cd (2010) or earlier.
Fix this by making the result type noreturn only if both e1 and e2 are
noreturn, matching GCC.
`_Noreturn` and `[[noreturn]]` do not have the aforementioned problem.
Fix https://github.com/llvm/llvm-project/issues/59792 [1]
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D140868
Previously, if a header file and a source file used different end of line
(EOL) forms, preprocessed output generated with the -frewrite-includes option
would, in some cases, generate line control directives with the wrong line
number due to an error in how source file lines were counted.
Fixes https://github.com/llvm/llvm-project/issues/59736
Reviewed By: cor3ntin
Differential Revision: https://reviews.llvm.org/D140984
This feature causes clang to crash when compiling Chrome - see
https://crbug.com/1405031 and
https://github.com/llvm/llvm-project/issues/59675
Revert "[clang] Fix a clang crash on invalid code in C++20 mode."
This reverts commit 32d7aae04fdb58e65a952f281ff2f2c3f396d98f.
Revert "[clang] Remove overly restrictive aggregate paren init logic"
This reverts commit c77a91bb7ba793ec3a6a5da3743ed55056291658.
Revert "[clang][C++20] P0960R3 and P1975R0: Allow initializing aggregates from a parenthesized list of values"
This reverts commit 40c52159d3ee337dbed14e4c73b5616ea354c337.
This reverts commit d5dd37ac139a74701e16f084eb2609ff58893770.
Apparently there's some ABI difference in the Sony builder that fails a test.
Will hopefully investigate tomorrow. https://lab.llvm.org/buildbot/#/builders/139/builds/33769
This reverts commit 85960043d594fc12d340ccb66a30861b023ab496.
The powerpc64le self-built buildbot had an assertion during self-build,
that seems like it is possibly related here, reverting so the author can
take a look.
As noted in https://github.com/llvm/llvm-project/issues/59624, we sometimes mark implicitly
deleted special member functions as non-trivial. This is unnecessary work and leads to some
weird type traits errors.
This fixes the problem by making the implicitly deleted special member functions always
trivial.
Reviewed By: #clang-language-wg, erichkeane
Differential Revision: https://reviews.llvm.org/D140664
Originally, the code would take a lookup result as a member in the
current scope and build a member expression accordingly, if the lookup
result was not an operand of the address operator, or it was a field
declaration. However, a field declaration may come from another class,
and cause the issue #58674.
Thus, this patch fixes the issue via checking where does the field
declaration comes from, and if it comes from another class, then marks
it as not member in the current scope. The parent scopes of the current
scope are also checked, as the current scope may be associated to a
lambda or friend declaration.
Differential Revision: https://reviews.llvm.org/D137531
Closes https://github.com/llvm/llvm-project/issues/54457.
This removes a FIXME we found previously. But we didn't remove the FIXME
that time due to the lack of the corresponding test. And now we found
the corresponding test so we can remove it.
Previously committed in 46c94e5067b5 which was reverted in f0756e086010
due to a memory bug.
Closes#58949.
Differential Revision: https://reviews.llvm.org/D140543
"__cmpccxadd_epi*" -> "_cmpccxadd_epi*"
This is to align with other intrinsics to follow single leading "_" style. Gcc
and intrinsic guide website will also apply this change.
Reviewed By: LuoYuanke, skan
Differential Revision: https://reviews.llvm.org/D140281
Revert "[clang-format] Disable FixRanges in IntegerLiteralSeparatorTest"
Breaks buildbots, details in https://reviews.llvm.org/D140543
This reverts commit 879bd9146a2c9ea395abd7c1ebd0f76f414a4967.
This reverts commit 46c94e5067b5f396c24bb950505c79bc819bd4b8.
AggExprEmitter::VisitInitListExpr sanity checks that an empty union is really
empty and not a semantic analysis failure. The assert is missing that we allow
anonymous structs as a GNU extension. I have updated the assert to take that into account.
This fixes: https://github.com/llvm/llvm-project/issues/58800
Differential Revision: https://reviews.llvm.org/D139261
Implement the proposed UAX Profile
"Mathematical notation profile for default identifiers".
This implements a not-yet approved Unicode for a vetted
UAX31 identifier profile
https://www.unicode.org/L2/L2022/22230-math-profile.pdf
This change mitigates the reported disruption caused
by the implementation of UAX31 in C++ and C2x,
as these mathematical symbols are commonly used in the
scientific community.
Fixes#54732
Reviewed By: tahonermann, #clang-language-wg
Differential Revision: https://reviews.llvm.org/D137051
MSVC requires that C++23 be available (_HAS_CXX23) else the entire
content is elided. Conditionalise the inclusion properly so that C/C++
code using stdatomic.h for memory_order_* constants are able to do
so without changing the C++ standard. This repairs builds of Swift and
libdispatch after ba49d39b20cc5358da28af2ac82bd336028780bc.
Differential Revision: https://reviews.llvm.org/D139266
Reviewed By: aaron.ballman, Mordante, fsb4000
The main goal of this work is to allow developers to express the need to place instances
of a class or structure in the read-only part of the program memory. Such a placement is
desirable to prevent any further modifications to the instances of a given structure, by
leveraging the read-only run time protection.
To achieve this, we are introducing a new attribute that can be attached to any record
definition or a declaration. The compiler enforces that every instance of this type can
be placed in the read-only segment of the program memory, provided the target triplet
supports such a placement. If an instance of a given type bearing this attribute doesn’t
satisfy such a placement, the compiler attaches an appropriate warning at suitable program
locations. In other words, adding this attribute to a type requires every instance of this
type to be a global const, which are placed in the read-only segments for most target
triplets. However, this is *not a language feature* and it *need not* be true for
*all target triplets*.
The current patch emits a warning at global variable declaration sites of types bearing
the attribute without const qualification and corresponding note attached to the type
definition/declaration.
Differential Revision: https://reviews.llvm.org/D135851
This patch implements P0960R3, which allows initialization of aggregates
via parentheses.
As an example:
```
struct S { int i, j; };
S s1(1, 1);
int arr1[2](1, 2);
```
This patch also implements P1975R0, which fixes the wording of P0960R3
for single-argument parenthesized lists so that statements like the
following are allowed:
```
S s2(1);
S s3 = static_cast<S>(1);
S s4 = (S)1;
int (&&arr2)[] = static_cast<int[]>(1);
int (&&arr3)[2] = static_cast<int[2]>(1);
```
This patch was originally authored by @0x59616e and completed by
@ayzhao.
Fixes#54040, Fixes#54041
Co-authored-by: Sheng <ox59616e@gmail.com>
Full write up : https://discourse.llvm.org/t/c-20-rfc-suggestion-desired-regarding-the-implementation-of-p0960r3/63744
Reviewed By: ilya-biryukov
Differential Revision: https://reviews.llvm.org/D129531
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.
