Per discussion with @ojhunt and @AaronBallman we are moving towards
predefined macros and away from __has_feature and __has_extension
for detecting sanitizers and other similar features. The rationale
is that __has_feature is only really meant for standardized features
(see the comment at the top of clang/include/clang/Basic/Features.def),
and __has_extension has the issues discovered as part of #153104.
Let's start by defining macros for ASan, HWASan and TSan, consistently
with gcc.
Reviewers: vitalybuka, ojhunt, AaronBallman, fmayer
Reviewed By: fmayer, vitalybuka
Pull Request: https://github.com/llvm/llvm-project/pull/153888
This adds ReturnAddrOp and FrameAddrOp that represent
__builtin_return_address and __builtin_frame_address and the respective
lowering to LLVM parts.
---------
Co-authored-by: Andy Kaylor <akaylor@nvidia.com>
This modifies InjectAnonymousStructOrUnionMembers to inject an
IndirectFieldDecl and mark it invalid even if its name conflicts with
another name in the scope.
This resolves a crash on a further diagnostic
diag::err_multiple_mem_union_initialization which via
findDefaultInitializer relies on these declarations being present.
Fixes#149985
Currently, `__attribute__((target("lasx")))` does not automatically
enable LSX support, causing Clang to fail with `-mno-lsx`. Since
LASX depends on LSX, enabling LASX should implicitly enable LSX to
avoid clang error.
Fixes#149512.
Depends on #153541
Pointer auth protection of the block descriptor pointer is only
supported in some constrained environments so we do actually need it to
be configurable.
We had made it non configurable in the first PR to protect block
metadata because we believed that was an option but subsequently
realised it does need to remain configurable.
This PR revives the flags that permit this.
Clang defines the x64 preprocessor macro (`__x86_64__`) when building
Arm64EC, however the tests for x64 built-ins and intrinsics are
currently failing since the relevant functions don't exist, resulting in
errors like:
```
Line 165: invalid conversion between vector type '__v2di' (vector of 2 'long long' values) and integer type 'int' of different size
```
(Clang doesn't know the intrinsics being called, and so treats it like
an undefined function, which makes it assume the return type is `int`)
For now, expect these tests to fail until someone decides to implement
these intrinsics.
The #cir.global_view attribute was initially added without support for
the optional index list. This change adds index list support. This is
used when the address of an array or structure member is used as an
initializer.
This patch does not include support for taking the address of a
structure or class member. That will be added later.
The 'cfi_salt' attribute specifies a string literal that is used as a
"salt" for Control-Flow Integrity (CFI) checks to distinguish between
functions with the same type signature. This attribute can be applied
to function declarations, function definitions, and function pointer
typedefs.
This attribute prevents function pointers from being replaced with
pointers to functions that have a compatible type, which can be a CFI
bypass vector.
The attribute affects type compatibility during compilation and CFI
hash generation during code generation.
Attribute syntax: [[clang::cfi_salt("<salt_string>")]]
GNU-style syntax: __attribute__((cfi_salt("<salt_string>")))
- The attribute takes a single string of non-NULL ASCII characters.
- It only applies to function types; using it on a non-function type
will generate an error.
- All function declarations and the function definition must include
the attribute and use identical salt values.
Example usage:
// Header file:
#define __cfi_salt(S) __attribute__((cfi_salt(S)))
// Convenient typedefs to avoid nested declarator syntax.
typedef int (*fp_unsalted_t)(void);
typedef int (*fp_salted_t)(void) __cfi_salt("pepper");
struct widget_ops {
fp_unsalted_t init; // Regular CFI.
fp_salted_t exec; // Salted CFI.
fp_unsalted_t teardown; // Regular CFI.
};
// bar.c file:
static int bar_init(void) { ... }
static int bar_salted_exec(void) __cfi_salt("pepper") { ... }
static int bar_teardown(void) { ... }
static struct widget_generator _generator = {
.init = bar_init,
.exec = bar_salted_exec,
.teardown = bar_teardown,
};
struct widget_generator *widget_gen = _generator;
// 2nd .c file:
int generate_a_widget(void) {
int ret;
// Called with non-salted CFI.
ret = widget_gen.init();
if (ret)
return ret;
// Called with salted CFI.
ret = widget_gen.exec();
if (ret)
return ret;
// Called with non-salted CFI.
return widget_gen.teardown();
}
Link: https://github.com/ClangBuiltLinux/linux/issues/1736
Link: https://github.com/KSPP/linux/issues/365
---------
Signed-off-by: Bill Wendling <morbo@google.com>
Co-authored-by: Aaron Ballman <aaron@aaronballman.com>
These warnings are reported on a per expression basis, however some
potential misaligned accesses are discarded before that happens. The
problem is when a new expression starts while processing another
expression. The new expression will end first and emit all potential
misaligned accesses collected up to that point. That includes candidates
that were found in the parent expression, even though they might have
gotten discarded later.
Fixed by checking if the candidate is located withing the currently
processed expression.
Fixes#144729
Added constant evaluation support for `__builtin_elementwise_abs` on integer, float and vector type.
fixes#152276
---------
Co-authored-by: Simon Pilgrim <llvm-dev@redking.me.uk>
When stashing the tokens of a parameter of a member function, we would
munch an ellipsis, as the only considered terminal conditions were `,`
and `)`.
Fixes#153445
Close https://github.com/llvm/llvm-project/issues/138558
The compiler failed to understand the redeclaration-relationship when
performing checks when MergeFunctionDecl. This seemed to be a complex
circular problem (how can we know the redeclaration relationship before
performing merging?). But the fix seems to be easy and safe. It is fine
to only perform the check only if the using decl is a local decl.
Introduces the use of pointer authentication to protect the invocation,
copy and dispose, reference, and descriptor pointers in Objective-C
block objects.
Resolves#141176
This updates the array initialization loop to use a do..while loop
rather than a fully serialized initialization. It also allows the
initialization of destructed objects when exception handling is not
enabled.
Array initialization when exception handling is enabled remains
unimplemented, but more precise messages are now emitted.
Summary:
Previously we extracted archives and did special symbol resolution on
them, this was mostly done because the nvlink executable couldn't handle
archives natively. Since I have added a wrapper around it that handles
that, we can now remove a lot of this complexity and just create a new
archive and pass it to the device linker.
The one issue here is that for offloading code, we often have references
to kernels that do not come from the device link job, but from the host
that wishes to call them. Under normal circumstances we would ignore
them because they are not referenced, but we need them. For now I am
just passing `--whole-archive`. In a future patch I will likely add some
logic to create a linker script that will tell the linker which symbols
we want to be extracted. That won't work for NVPTX but it's the most
canonical solution.
Also some ugliness in this patch where I need to juggle whether or not
the input is an archive and throw pairs around, I may merge that into
the `OffloadFile` struct in a later patch.
Unless relevant (which it very seldom is), avoid checking specifically
for the "pc" vendor field; mingw environments often use "w64" as vendor
- but not always.
In this case, this test has been passing in mingw configurations lately;
the previous XFAIL pattern would cause the test to unexpectedly succeed
if running with a triple with a "pc" vendor field.
Instead reinstate the checking for an -msvc environment here; this
essentially reverts 8e029d9e35092d1440dafc8991e73fb8c3b323d7 (and the
related typo fix 301f3da5162499965287338a0cd52309fb28e8b8).
I'm not sure how 8e029d9e35092d1440dafc8991e73fb8c3b323d7 concluded that
this issue affected the gnu ABI (mingw) as well; I rechecked building
that commit, and at that point, this test did pass for an aarch64 mingw
target. (Due to the -pc- triple, the false positive XFAIL match hasn't
been noticed before.)
The goal is to correctly identify diagnostics that are emitted by virtue
of -Wformat-signedness.
Before this change, diagnostic messages triggered by -Wformat-signedness
might look like:
format specifies type 'unsigned int' but the argument has type 'int'
[-Wformat]
signedness of format specifier 'u' is incompatible with 'c' [-Wformat]
With this change:
format specifies type 'unsigned int' but the argument has type 'int',
which differs in signedness [-Wformat-signedness]
signedness of format specifier 'u' is incompatible with 'c'
[-Wformat-signedness]
Fix:
- handleFormatSignedness can now return NoMatchSignedness. Callers
handle this.
- warn_format_conversion_argument_type extends the message it used to
emit by a string that
mentions "signedness".
- warn_format_cmp_specifier_sign_mismatch is now correctly categorized
as a
diagnostic controlled by -Wformat-signedness.
This PR introduces the `LabelOp`, which is required for implementing
`GotoOp` lowering in the future.
Lowering to LLVM IR is **not** included in this patch, since it depends
on the upcoming `GotoSolver`.
The `GotoSolver` traverses the function body, and if it finds a
`LabelOp` without a matching `GotoOp`, it erases the label.
This means our implementation differs from the classic codegen approach,
where labels may be retained even if unused.
Example:
https://godbolt.org/z/37Mvr4MMr
The OpenACC standard is going to change to clarify that init, shutdown,
and set should only have a single architecture in each 'device_type'
clause. This patch implements that restriction.
See: https://github.com/OpenACC/openacc-spec/pull/550
Allow CCEKind::ExplicitBool in BuildConvertedConstantExpression for
pre-C++11 contexts, similar to the existing TempArgStrict exception.
This enables explicit(bool) to work as a C++20 extension in earlier
language modes without triggering assertion failures.
Fixes#152729
---------
Co-authored-by: Jongmyeong Choi <cheesechoi@gmail.com>
