The test otherwise fails on FreeBSD, which wasn't noticed when
originally landing the patch that added the test because FreeBSD
CI was disabled at that moment.
Currently the deferred diag fails to diagnose calling of host function
in host device function in device compilation triggered by destructors.
This can be further divided into two issuse:
1. the deferred diag visitor does not visit dtor of member and parent
class when visiting dtor, which it should
2. the deferred diag visitor does not visit virtual dtor of explicit
template class instantiation, which it should
Due to these issues, some constexpr functions which call host functions
are emitted on device side, which causes undefind symbols in linking
stage, as revealed by
https://github.com/llvm/llvm-project/issues/108548
By fixing these issue, clang will diag the issues early during
compilation instead of linking.
This also fixes test failures in the clang-cl build configs that started
a couple days ago. It seems like the failures were triggered by an update
to the base image on the Github provided runners.
There were failures in test/libcxx/system_reserved_names.gen.py, due to
an issue in an Clang intrinsics header (avx512fp16intrin.h); this issue
was observed and fixed for Clang 19 in 6f04f46927c. The test does
#define A SYSTEM_RESERVED_NAME
which clashes with a parameter with the name `A` in that header.
By upgrading the toolchain to Clang 19, we get fixed version of this
intrinsics header.
Also update the llvm-mingw toolchains to a version with Clang 19.1.7.
Basically, we may leave the loop because if exhaust the fields, array
elements or other subobjects to initialize.
In that case, the Bindings may be in an exhausted state, thus no further
addBinding calls are allowed.
Let's harden the code by sprinkling some early exists in the recursive
dispatcher functions.
And to actually fix the issue, I added a check guarding the single
unguarded addBinding right after a loop I mentioned.
Fixes#129211
True16 Add OpSel when optimizing exec mask
True16 VOPCX have the opsel argument. Add it when we create these
instructions in SIOptimizeExecMasking.
---------
Co-authored-by: Matt Arsenault <arsenm2@gmail.com>
Before commit 6e17ed9 the test files `outofbound.c` and
`outofbound-notwork.c` tested the behavior of the old alpha checker
`alpha.security.ArrayBound` (V1); then that commit converted them into
tests for the checker `security.ArrayBound` which was previously called
`alpha.security.ArrayBoundV2`.
This commit removes these test files and migrates their useful content
to `out-of-bounds.c`. The file `outofbound.c` contained lots of
testcases that covered features which are also covered in
`out-of-bounds.c` or `out-of-bounds-diagnostics.c`; those redundant
cases are discarded during this migration process.
This is part of a commit series that reorganizes the tests of
`security.ArrayBound` to a system that's easier to understand and
maintain.
This should be replaced with captures(address), but tablegen currently
has
no way to indicate that on an intrinsic. I opened issue #129184 to fix
this.
It seems that there can be other cases with this that also can lead to
wrong code (discovered with csmith). This time it involved not the kill
flag but the undef flag.
Use the intersection of the flags from both MachineOperand:s instead
of the RegState from just one of them.
emitc.expression ops are expected to be inlined in the if condition in
the lowering of cf.cond_br if this is their only use but they weren't
inlined.
Instead, a use of the variable corresponding to the expression result
was generated but with no declaration/definition.
Compiling this:
`int main() {`
` #pragma omp metadirective when(use r= {condition(0)}`
`: parallel for)`
`for (int i=0; i<10; i++)`
;
}`
is generating an error:
`error: expected expression`
The compiler is interpreting this as if it's compiling a `#pragma omp
metadirective` with no `otherwise` clause.
In the OMP5.2 specs chapter 7.4 it's mentioned that:
`If no otherwise clause is specified the effect is as if one was
specified without an associated directive variant.`
This patch fixes the issue.
Follow on to #128035. It is a small extension to support vectorizing
`llvm.modf.*` and `llvm.sincospi.*` too.
This renames the test files from `sincos.ll` ->
`multiple-result-intrinsics.ll` to group together the similar tests
(which make up most of this PR).
Previously the wrong detection macro has been used to check whether arm
NEON is available. This fixes it, and removes a few unnecessary includes
from `__algorithm/simd_utils.h` as a drive-by.
The default triple of Amazon Linux on AArch64 is aarch64-amazon-linux,
see issue highlighded by PR #109263, somewhat serious linker issues are
encountered if any other triple is being used.
Unfortunately, this makes XFAIL lines like:
`XFAIL: target=aarch64{{.*}}-linux-gnu` ineffective,
making it impossible to complete all of the check-cxx without failures.
For non floating point operations NaN propagation mode has no meaning
and can be safely ignored. For non integer types skip the compare and
select materialization for NaN propagation even in "IGNORE" mode. This
fixes a bug where an unchecked `cast<FloatType>()` was called in the
"IGNORE" case even when the operation is acting on integers.
Update the lit tests for the NaN propagation lowering to check that the
propagation logic is not materialized in the case of a non floating
point type e.g. i8.
Signed-off-by: Jack Frankland <jack.frankland@arm.com>
Matching the CaptureTracking change in abd97d9685c07c4787ff22e56c0a7b8963630063,
only directly infer captures(none) for
readonly+nocapture+willreturn+void.
Part of https://github.com/llvm/llvm-project/issues/129090.
I've been trying to resolve instances of the unique-object-duplication
warning in chromium code. Unfortunately, I've found that practically
speaking, it's near-impossible to actually fix the problem when
templates are involved.
My understanding is that the warning is correct -- the variables it's
flagging are indeed duplicated and potentially causing bugs as a result.
The problem is that hiddenness is contagious: if a templated class or
variable depends on something hidden, then it itself must also be
hidden, even if the user explicitly marked it visible. In order to make
it actually visible, the user must manually figure out everything that
it depends on, mark them as visible, and do so recursively until all of
its ancestors are visible.
This process is extremely difficult and unergonomic, negating much of
the benefits of templates since now each new use requires additional
work. Furthermore, the process doesn't work if the user can't edit some
of the files, e.g. if they're in a third-party library.
Since a warning that can't practically be fixed isn't useful, this PR
disables the warning for _all_ templated code by inverting the check.
The warning remains active (and, in my experience, easily fixable) in
non-templated code.
Add header guard macros to clang/lib/Headers/vecintrin.h. Found while
compiling the latest numpy with clang 19 on s390x which ends up
including vecintrin.h twice. The gcc version of this file has header
guards so numpy compiles fine with gcc.
Signed-off-by: Jonathan Albrecht <jonathan.albrecht@ibm.com>
Parameters to a coroutine get copied (moved) to coroutine-local
instances which code inside the coroutine then uses.
The original parameters should not be part of the frame. Normally
CoroSplit figures that out by itself, but for [[clang::trivial_abi]]
parameters which, get destructed at the end of the ramp function, it
does not (see bug), causing use-after-free's if the frame is destroyed
before the end of the ramp (as happens if it doesn't suspend).
Since Clang knows these should never be part of the frame, use metadata
to make it so.
Fixes#127499
This patch updates fir.coordinate_op to carry the field index as
attributes instead of relying on getting it from the fir.field_index
operations defining its operands.
The rational is that FIR currently has a few operations that require
DAGs to be preserved in order to be able to do code generation. This is
the case of fir.coordinate_op, which requires its fir.field operand
producer to be visible.
This makes IR transformation harder/brittle, so I want to update FIR to
get rid if this.
Codegen/printer/parser of fir.coordinate_of and many tests need to be
updated after this change.
Sometimes number of expressions in InitListExpr is used for template
argument deduction. So, in these cases we need to pay attention to real
number of expressions including expanded #embed data.
Fixes https://github.com/llvm/llvm-project/issues/122306
The root source of other odd bugs.
We performed a hack in CodeGen/Coroutines. But we didn't recognize that
the CodeGen is a consumer of AST. The CodeGen shouldn't change AST in
any ways. It'll break the assumption about the ASTConsumer in Clang's
framework, which may break any other clang-based tools which depends on
multiple consumers to work together.
The fix here is simple. But I am not super happy about the test. It is
too specific and verbose. We can remove this if we can get the signature
of the AST in ASTContext.
Found in downstream. I didn't realize the output file for precompile and
reduced BMI refers to the same location. Then the generating process of
reduced BMI is basically a waste of time.
Instead of inferring the output shape argument of
memref.expand_shape op, use output_shape argument of tensor.expand_shape
op by adding dynamic dimension support for bufferization of
tensor.expand_shape when there are more than one dynamic dim within a
reassociation set.
