Currently, Clang handles some qualifiers correctly for __auto_type, but
it does not handle the restrict or _Atomic qualifiers in the same way
that GCC does. This patch handles those qualifiers so that they attach
to the deduced type the same as const and volatile already do.
This fixes https://github.com/llvm/llvm-project/issues/53652
This patch extends the support for C/C++ operators for SVE
types to allow one of the arguments to be a scalar, in which
case a vector splat is performed.
Differential Revision: https://reviews.llvm.org/D121829
This reverts commit 56d46b36fc.
The LIT test SemaCXX/attr-trivial-abi.cpp is failing with 32bit build on
Windows. All the lines with the ifdef WIN32 are asserting but they are
not expected to. It looks like the LIT test was not tested on a 32bit
build of the compiler.
GCC supports power-of-2 size structures for the arguments. Clang supports fewer than GCC. But Clang always crashes for the unsupported cases.
This patch adds sema checks to do the diagnosts to solve these crashes.
Reviewed By: jyu2
Differential Revision: https://reviews.llvm.org/D107141
Allow goto, labelled statements as well as `static`, `thread_local`, and
non-literal variables in `constexpr` functions.
As specified. for all of the above (except labelled statements) constant
evaluation of the construct still fails.
For `constexpr` bodies, the proposal is implemented with diagnostics as
a language extension in older language modes. For determination of
whether a lambda body satisfies the requirements for a constexpr
function, the proposal is implemented only in C++2b mode to retain the
semantics of older modes for programs conforming to them.
Reviewed By: aaron.ballman, hubert.reinterpretcast, erichkeane
Differential Revision: https://reviews.llvm.org/D111400
@mgehre-amd pointed out the following post-commit review feedback on
the changes in 8cba72177dcd8de5d37177dbaf2347e5c1f0f1e8:
As an example, the paper says 3wb /* Yields an _BitInt(3); two value
bits, one sign bit */.
So I would expect that 0xFwb gives _BitInt(5); four value bits, one
sign bit, but with this implementation I get _BitInt(2).
This is because ResultVal as 4 bits, and getMinSignedBits() inteprets
it as negative and thus says that 1 bit is enough to represent -1.
This corrects the behavior for calculating the bit-width and adds some
test coverage.
For the following code,
void test() {
volatile int j = 0;
for (int i = 0; i < 1000; i++)
j += 1;
return;
}
If compiled with
clang -g -Wall -Werror -S -emit-llvm test.c
we will see the following error:
test.c:2:6: error: variable 'j' set but not used [-Werror,-Wunused-but-set-variable]
volatile int j = 0;
^
This is not quite right since 'j' is indeed used due to '+=' operator.
gcc doesn't emit error either in this case.
Also if we change 'j += 1' to 'j++', the warning will disappear
with latest clang.
Note that clang will issue the warning if the volatile declaration
involves only simple assignment (var = ...).
To fix the issue, in function MaybeDecrementCount(), if the
operator is a compound assignment (i.e., +=, -=, etc.) and the
variable is volatile, the count for RefsMinusAssignments will be
decremented, similar to 'j++' case.
Differential Revision: https://reviews.llvm.org/D121715
Previously, OpenMP variant declarations for a function declaration that included
the 'cpu_dispatch', 'cpu_specific', or 'target' attributes was diagnosed, but
one with the 'target_clones' attribute was not. Now fixed.
Reviewed By: erichkeane, jdoerfert
Differential Revision: https://reviews.llvm.org/D121963
Previously, an attempt to declare an overload of a multiversion function
in C was not properly diagnosed. In some cases, diagnostics were simply
missing. In other cases the following assertion failure occured...
```
Assertion `(Previous.empty() || llvm::any_of(Previous, [](const NamedDecl *ND) { return ND->hasAttr(); })) && "Non-redecls shouldn't happen without overloadable present"' failed.
```
... or the following diagnostic was spuriously issued.
```
error: at most one overload for a given name may lack the 'overloadable' attribute
```
The diagnostics issued in some cases could be improved. When the function
type of a redeclaration does not match the prior declaration, it would be
preferable to diagnose the type mismatch before diagnosing mismatched
attributes. Diagnostics are also missing for some cases.
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D121959
Checking of multiversion function declarations performed by various functions
in clang/lib/Sema/SemaDecl.cpp previously forced the valus of a passed in
'MergeTypeWithPrevious' reference argument in several scenarios. This was
unnecessary and possibly incorrect in the one case that the value
was forced to 'true' (though seemingly unobservably so).
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D121958
This change removes redundant code in the definition of
CheckTargetCausesMultiVersioning() in SemaDecl.cpp. The removed code checked
for multiversion function support. The code immediately following the removed
code is a call to CheckMultiVersionAdditionalRules(); that function performs
the same check on entry. In both cases, the consequences of missing multiversion
function support results in the same diagnostic message being issued and the
applicable function declaration being marked as invalid.
Reviewed By: erichkeane, aaron.ballman
Differential Revision: https://reviews.llvm.org/D121957
This change removes dead code in the definition of CheckMultiVersionFunction()
in clang/lib/Sema/SemaDecl.cpp. The removed code was made dead by commit
fc53eb69c26cdd7efa6b629c187d04326f0448ca: "Reapply 'Implement target_clones multiversioning'".
See the added code just above the code being deleted; it contains the same
return statement with the previous condition now distributed across an if
statement and a switch statement.
Reviewed By: erichkeane, aaron.ballman
Differential Revision: https://reviews.llvm.org/D121955
Ensure that the TypeExtension of an `ImageType` is also taken into
account when generating `OpenCLBuiltins.inc`.
This aligns the handling of the `write_only image3d_t` type for
`-fdeclare-opencl-builtins` with opencl-c.h with respect to the
`cl_khr_3d_image_writes` extension.
Since the `write_only image3d_t` type is not available when the
extension is disabled, this commit does not add a test to
`SemaOpenCL/fdeclare-opencl-builtins.cl`.
Partially fixes PR24883.
The patch sets Reference bit while instantiating a typedef if it
previously was found referenced.
Reviewed By: thakis
Differential Revision: https://reviews.llvm.org/D114382
__builtin_memcpy_inline doesn't use the usual builtin argument validation code,
so it crashed when receiving wrong number of argument. Add the missing validation
check.
Open issue: https://github.com/llvm/llvm-project/issues/52949
Reviewed By: gchatelet
Differential Revision: https://reviews.llvm.org/D121965
Committed by gchatelet on behalf of "Roy Jacobson <roi.jacobson1@gmail.com>"
FLT_EVAL_METHOD tells the user the precision at which, temporary results
are evaluated but when fast-math is enabled, the numeric values are not
guaranteed to match the source semantics, so the eval-method is
meaningless.
For example, the expression `x + y + z` has as source semantics `(x + y)
+ z`. FLT_EVAL_METHOD is telling the user at which precision `(x + y)`
is evaluated. With fast-math enable the compiler can choose to
evaluate the expression as `(y + z) + x`.
The correct behavior is to set the FLT_EVAL_METHOD to `-1` to tell the
user that the precision of the intermediate values is unknow. This
patch is doing that.
Differential Revision: https://reviews.llvm.org/D121122
If we are equality comparing an FP literal with a value cast from a type
where the literal can't be represented, that's known true or false and
probably a programmer error.
Fixes issue #54222.
https://github.com/llvm/llvm-project/issues/54222
Note - I added the optimizer change with:
9397bdc67e
...and as discussed in the post-commit comments, that transform might be
too dangerous without this warning in place, so it was reverted to allow
this change first.
Differential Revision: https://reviews.llvm.org/D121306
Current ASTContext.getAttributedType() takes attribute kind,
ModifiedType and EquivType as the hash to decide whether an AST node
has been generated or note. But this is not enough for btf_type_tag
as the attribute might have the same ModifiedType and EquivType, but
still have different string associated with attribute.
For example, for a data structure like below,
struct map_value {
int __attribute__((btf_type_tag("tag1"))) __attribute__((btf_type_tag("tag3"))) *a;
int __attribute__((btf_type_tag("tag2"))) __attribute__((btf_type_tag("tag4"))) *b;
};
The current ASTContext.getAttributedType() will produce
an AST similar to below:
struct map_value {
int __attribute__((btf_type_tag("tag1"))) __attribute__((btf_type_tag("tag3"))) *a;
int __attribute__((btf_type_tag("tag1"))) __attribute__((btf_type_tag("tag3"))) *b;
};
and this is incorrect.
It is very difficult to use the current AttributedType as it is hard to
get the tag information. To fix the problem, this patch introduced
BTFTagAttributedType which is similar to AttributedType
in many ways but with an additional BTFTypeTagAttr. The tag itself can
be retrieved with BTFTypeTagAttr.
With the new BTFTagAttributed type, the debuginfo code can be greatly
simplified compared to previous TypeLoc based approach.
Differential Revision: https://reviews.llvm.org/D120296
This is the `ext_vector_type` alternative to D81083.
This patch extends Clang to allow 'bool' as a valid vector element type
(attribute ext_vector_type) in C/C++.
This is intended as the canonical type for SIMD masks and facilitates
clean vector intrinsic declarations. Vectors of i1 are supported on IR
level and below down to many SIMD ISAs, such as AVX512, ARM SVE (fixed
vector length) and the VE target (NEC SX-Aurora TSUBASA).
The RFC on cfe-dev: https://lists.llvm.org/pipermail/cfe-dev/2020-May/065434.html
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D88905
function candidates
See: https://github.com/llvm/llvm-project/issues/54379
I tried to see if I can reuse ResolveAddressOfOverloadedFunction for
explicit function instantiation and so I managed to hit this ICE.
Bug was the diagnostic required an argument (%0) and specific code path
didn't pass an argument.
Differential Revision: https://reviews.llvm.org/D121646
Motivation:
```
int test(int x, int y) {
int r = 0;
[[clang::always_inline]] r += foo(x, y); // force compiler to inline this function here
return r;
}
```
In 2018, @kuhar proposed "Introduce per-callsite inline intrinsics" in https://reviews.llvm.org/D51200 to solve this motivation case (and many others).
This patch solves this problem with call site attribute. "noinline" statement attribute already landed in D119061. Also, some LLVM Inliner fixes landed so call site attribute is stronger than function attribute.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D120717
WG14 adopted N2775 (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2775.pdf)
at our Feb 2022 meeting. This paper adds a literal suffix for
bit-precise types that automatically sizes the bit-precise type to be
the smallest possible legal _BitInt type that can represent the literal
value. The suffix chosen is wb (for a signed bit-precise type) which
can be combined with the u suffix (for an unsigned bit-precise type).
The preprocessor continues to operate as-if all integer types were
intmax_t/uintmax_t, including bit-precise integer types. It is a
constraint violation if the bit-precise literal is too large to fit
within that type in the context of the preprocessor (when still using
a pp-number preprocessing token), but it is not a constraint violation
in other circumstances. This allows you to make bit-precise integer
literals that are wider than what the preprocessor currently supports
in order to initialize variables, etc.
This change teaches the Sema logic for `__builtin_memcpy_inline` to implicitly convert arrays passed as arguments to pointers, similarly to regular `memcpy`.
This code will no longer cause a compiler crash:
```
void f(char *p) {
char s[1] = {0};
__builtin_memcpy_inline(p, s, 1);
}
```
rdar://88147527
Differential Revision: https://reviews.llvm.org/D121475
This patch implements support for the +, -, *, / and % operators on sizeless SVE
types. Support for these operators on svbool_t is excluded.
Differential Revision: https://reviews.llvm.org/D120323
As far as I can tell, MSVC allows the relevant conversions for all
pointer types. Found compiling a Windows SDK header.
I've verified that the updated errors in MicrosoftExtensions.cpp match
the ones that MSVC actually emits, except for the one with a FIXME. (Not
sure why this wasn't done for the patch that added the tests.)
To make up for the missing error, add a warning that triggers on
conversions that drop the __unaligned qualfier.
Differential Revision: https://reviews.llvm.org/D120936
Regresses:
typedef struct {
static void f() {
}
} a_t;
Causing this to error instead of warn, because the linkage is computed
earlier/too early perhaps. I'll send out a review to see if there's some
other path forward or if this is an acceptable regression, etc.
This reverts commit 275c56226d.
We were not creating an evaluation context for the TU scope, so we
never popped an evaluation context for it. Popping the evaluation
context triggers a number of diagnostics, including warnings about
immediate invocations that we were previously missing.
Note: I think we have an additional issue that we should solve, but not
as part of this patch. I don't think Clang is properly modeling static
initialization as happening before constant expression evaluation. I
think structure members members are zero initialized per
http://eel.is/c++draft/basic.start.static#1,
https://eel.is/c++draft/basic.start.static#2.sentence-2, and
http://eel.is/c++draft/dcl.init#general-6.2 and the new test case
actually should be accepted. However, it's also worth noting that other
compilers behave the way this patch makes Clang behave:
https://godbolt.org/z/T7noqhdPr
Otherwise we will fail to generate the definition of a defaulted destructor,
if the only reference was in a templated temporary.
rdar://89366678
Differential Revision: https://reviews.llvm.org/D120426
The paramemter of hint clause in OpenMP critical hint should be
non-negative. The omp_lock_hint_none is 0 in omp.h.
Reviewed By: Alexey Bataev
Differential Revision: https://reviews.llvm.org/D121101
This is a Sema function that now no longer depends on any of the
functionality in SemaTemplateInstantiateDecl.cpp (as the static function
was moved to Sema in a previous NFC). Moving it to SemaConcept means
that it and CheckFunctionConstraints can be changed to share more.
Aaron Ballman