I don't have a test case for this but noticed this warning when including system headers with `-I` rather than `-isystem`.
```
In file included from <built-in>:1:
In file included from /nix/store/jq6bpm0xmhnbffhs5rkxq4n88g5xi2zg-clang-wrapper-11.0.1/resource-root/include/__clang_cuda_runtime_wrapper.h:157:
/nix/store/jq6bpm0xmhnbffhs5rkxq4n88g5xi2zg-clang-wrapper-11.0.1/resource-root/include/__clang_cuda_math.h:39:25: warning: extra tokens at end of #ifdef directive [-Wextra-tokens]
^
```
Reviewed By: tra
Differential Revision: https://reviews.llvm.org/D95299
(cherry picked from commit c49142e4f5c8645a4d741d233f0cb55ef1ef87a2)
In a standalone build, there is no guarantee that flang code would be
saved in a directory named flang. Check only the path under flang's root
directory.
Reviewed By: #flang, kiranchandramohan
Differential Revision: https://reviews.llvm.org/D157642
(cherry picked from commit 94f377d880376fa6d5653430cad2777e51759d48)
An empty struct is handled as a struct with a dummy i8, on all targets.
Most targets treat an empty struct return value as essentially
void - but some don't. (Currently, at least x86_64-windows-* and
powerpc64le-* don't treat it as void.)
When intializing a struct with such a no_unique_address member,
make sure we don't write the dummy i8 into the struct where there's
no space allocated for it.
Previously it would clobber the actual valid data of the struct.
Fixes https://github.com/llvm/llvm-project/issues/64253, and
possibly https://github.com/llvm/llvm-project/issues/64077
and https://github.com/llvm/llvm-project/issues/64427 as well.
We should omit the store for any empty record (not only ones
declared with no_unique_address); we can have a situation where a
class doesn't have the no_unique_address attribute, but is embedded
in an outer struct with the no_unique_address attribute - like this:
struct S {};
S f();
struct S2 : public S { S2();};
S2::S2() : S(f()) {}
struct S3 { int x; [[no_unique_address]] S2 y; S3(); };
S3::S3() : x(1), y() {}
Here, the problematic store (which this patch omits) is in
the constructor of S2. In the case of S3, S2 has no valid storage
and aliases x - thus the constructor of S2 should omit the dummy
store.
Differential Revision: https://reviews.llvm.org/D157332
(cherry picked from commit d60c3d08e78dfbb4b180776b83e910d810e1f36a)
Check iterator validity before use; fixes a crash seen in the RISC-V
Zcmp Push/Pop optimization pass when compiling an internal benchmark.
Reviewed By: asb, wangpc
Differential Revision: https://reviews.llvm.org/D157674
(cherry picked from commit 53e89f5e3f2cefa432f7262343654c2a582dcbe1)
This adds a RISC-V special case to ToolChain::GetDefaultDwarfVersion,
affecting Linux/Haiku/RISCVToolChain.
DWARF v5 .debug_loclists/.debug_rnglists's
DW_LLE_offset_pair/DW_RLE_offset_pair entry kinds utilitize `.uleb128 A-B`
directives where A and B reference local labels in code sections.
When A and B are separated by a RISC-V linker-relaxable instruction,
A-B is incorrectly folded without a relocation, causing incorrect debug
information.
```
void ext(void);
int foo(int x) {ext(); return 0;}
// DW_AT_location [DW_FORM_loclistx] of a DW_TAG_formal_parameter references a DW_LLE_offset_pair that can be incorrect after linker relaxation.
int ext(void);
void foo() { {
int ret = ext();
if (__builtin_expect(ret, 0))
ext();
} }
// DW_AT_ranges [DW_FORM_rnglistx] of a DW_TAG_lexical_block references a DW_RLE_offset_pair that can be incorrect after linker relaxation.
```
D157657 will implement R_RISCV_SET_ULEB128/R_RISCV_SUB_ULEB128
relocations, fixing the issue, but the relocation is only supported by
bleeding-edge binutils 2.41 and not by lld/ELF yet.
The goal is to make the emitted DWARF correct after linking.
Many users don't care about the default DWARF version, but a linker
error will be unacceptable. Let's just downgrade the default DWARF
version, before binutils>=2.41 is more widely available.
An alternative compatibility option is to add a toggle to DwarfDebug.cpp,
but that doesn't seem like a good idea.
Reviewed By: asb, kito-cheng
Differential Revision: https://reviews.llvm.org/D157663
(cherry picked from commit bbc0f99f3bc96f1db16f649fc21dd18e5b0918f6)
(with a release note)
Fix crash when diagnostic is emit with invalid location,
but with attached valid ranges. Diagnostic can contain
invalid location, but SourceManager attached to it still
can be valid, use it in such case or fallback to known
SourceManager.
Fixes: #64602
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D157649
(cherry picked from commit efd44f80a5a8194b9fe26ff3244ce702cd8dab73)
This reverts commit d031ff38779bd688c514136dbdcce3169ee82b6e.
See https://reviews.llvm.org/D154503#4576393 for a reproducer and
details.
(cherry picked from commit 7d259b36d2e8148d13087844e6494ad3a5c63edf)
This issue was raised on https://github.com/llvm/llvm-project/issues/64268.
`flang/lib/Optimizer/Transforms/SimplifyIntrinsics.cpp` includes
`flang/Optimizer/HLFIR/HLFIRDialect.h` and might fails if the HLFIR related
tablegen files have not been generated.
Reviewed By: vzakhari
Differential Revision: https://reviews.llvm.org/D156751
(cherry picked from commit 103907bc5fcf656b1551e191af8176cd7bfb91da)
D141386 changed the semantics of !range metadata to return poison
on violation. If !range is combined with !noundef, violation is
immediate UB instead, matching the old semantics.
In theory, these IR semantics should also carry over into SDAG.
In practice, DAGCombine has at least one key transform that is
invalid in the presence of poison, namely the conversion of logical
and/or to bitwise and/or (c7b537bf09/llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp (L11252)).
Ideally, we would fix this transform, but this will require
substantial work to avoid codegen regressions.
In the meantime, avoid transferring !range metadata without
!noundef, effectively restoring the old !range metadata semantics
on the SDAG layer.
Fixes https://github.com/llvm/llvm-project/issues/64589.
Differential Revision: https://reviews.llvm.org/D157685
(cherry picked from commit 9deee6bffa9c331f46c68e5dd4cb4abf93dc0716)
The function changeVectorElementType assumes MVT input types will
result in MVT output types. There's no gurantee this is possible
during early code generation and so this patch converts an instance
used during initial DAG construction to instead explicitly create a
new EVT.
NOTE: I could have added more MVTs, but that seemed unscalable as
you can either have MVTs with 100% element count coverage or 100%
bitwidth coverage, but not both.
Differential Revision: https://reviews.llvm.org/D157392
(cherry picked from commit b7e6e568b4f28124060b868e433f36af18c510db)
Differential https://reviews.llvm.org/D145477 removed the check for `(yaml and args.export_fixes)` in line 303 to skip looking for the `clang-apply-replacements` binary. However, the `tmpdir` variable was set in this true branch when exporting fixes and therefore is `None` when invoking run-clang-tidy with `run-clang-tidy -p . -export-fixes fixes.yaml`.
Reviewed By: PiotrZSL
Differential Revision: https://reviews.llvm.org/D157773
(cherry picked from commit c3da99275a520b73235d975017502876e07e3e8e)
When compiling Rust code we may end up with calls to functions provided
by other code units. Presently this code crashes on a null pointer
dereference - this patch avoids that crash and adds a test.
Reviewed By: ast
Differential Revision: https://reviews.llvm.org/D156446
(cherry picked from commit 055893beacb34441467eb997a270a620c57c138f)
This was an oversight when the GFX11 early release VGPRs optimization
was reimplemented in D153279.
Sending the DEALLOC_VGPRS message is a performance optimization so there
is no need to do it at -O0. In addition it makes some kinds of post
mortem debugging hard or impossible, since VGPR values are no longer
available to inspect at the s_endpgm instruction.
Differential Revision: https://reviews.llvm.org/D157599
(cherry picked from commit 3091bdb86d55e404866823b64d21fd87c247d893)
Since GCC 11, the bundled Solaris/SPARC GCC uses the `sparcv8plus`
subdirectory for 32-bit objects, just like upstream GCC. Before that, it
used `32` instead from a local patch.
Since `clang` doesn't know about that `sparcv8plus` subdirectory, it
wouldn't properly use GCC 11+ installations.
The new `solaris-sparc-gcc-search.test` testcase wasn't run initially (like
the existing `crash-report-null.test`) because the `.test` suffix wasn't
handled.
Tested on `sparcv9-sun-solaris2.11`, `amd64-pc-solaris2.11`, and
`x86_64-pc-linux-gnu`.
Differential Revision: https://reviews.llvm.org/D157013
(cherry picked from commit 43dfe0f08ecaf50f986512d0548bd3ac84d1813b)
* 4d494e7: Handle static_assert messages with an expression started by a literal
* 49e0495 Produce a warning instead of an error in unevaluated strings before C++26
Emiting an error on unexpected encoding prefix - which was allowed before C++26 -
caused build errors for a few users.
This downgrade the error to a warning on older language modes and C
`R_LARCH_PCREL20_S2` is a new added relocation type in LoongArch ELF
psABI v2.10 [1] which is not corvered by D138135 except `R_LARCH_64_PCREL`.
A motivation to support `R_LARCH_PCREL20_S2` in lld is to build the
runtime of .NET core (a.k.a `CoreCLR`) in which strict PC-relative
semantics need to be guaranteed [2]. The normal `pcalau12i + addi.d`
approach doesn't work because the code will be copied to other places
with different "page" and offsets. To achieve this, we can use `pcaddi`
with explicit `R_LARCH_PCREL20_S2` reloc to address +-2MB PC-relative
range with 4-bytes aligned.
[1]: https://github.com/loongson/la-abi-specs/releases/tag/v2.10
[2]: https://github.com/dotnet/runtime/blob/release/7.0/src/coreclr/vm/loongarch64/asmhelpers.S#L307
Reviewed By: xen0n, MaskRay
Differential Revision: https://reviews.llvm.org/D156772
(cherry picked from commit 8a31f7ddb8436fa2a8ad754eb51618139cf63415)
When generating unwind tables for code which uses return-address
signing, we need to toggle the RA_SIGN_STATE DWARF register around any
tail-calls, because these require the return address to be authenticated
before the call, and could throw an exception. This is done using the
.cfi_negate_ra_state directive before the call, and .cfi_restore_state
at the start of the next basic block.
However, since D153098, the .cfi_restore_state isn't being inserted,
because the CFIFixup pass isn't being run. This re-enables that pass
when return-adress signing is enabled.
Reviewed By: ikudrin, MaskRay
Differential Revision: https://reviews.llvm.org/D156428
(cherry picked from commit f2e7285b03fbfc263c8a2eaa2b5e2e1cfafc6abd)
Using implicit CHECK prefix in one FileCheck invocation and explicit
CHECK-V83A in the other one seems to misguide to use CHECK: lines as
a common matching prefix at various places. Also note that
; CHECK, CHECK-V83A: ...
line only matches the "CHECK-V83A" prefix.
This commit explicitly splits the checks into common ones (CHECK) and
invocation-specific ones (COMPAT and V83A) and updates the assertions
with the update_llc_test_checks.py script.
Reviewed By: efriedma, MaskRay
Differential Revision: https://reviews.llvm.org/D156327
(cherry picked from commit 4210204f521be3caa0e60bd596af3444cbd44d04)
Set the ReplaceFlags variable to false, since there is code meant only
for the ADDItocHi/ADDItocL nodes. This has the side effect of disabling
the peephole when the load/store instruction has a non-zero offset.
This patch also fixes retrieving the `ImmOpnd` node from the AIX small
code model pseduos and does the same for the register operand node.
This allows cleaning up the later calls to replaceOperands.
Finally move calculating the MaxOffset into the code guarded by
ReplaceFlags as it is only used there and the comment is specific to the ELF
ABI.
Fixes https://github.com/llvm/llvm-project/issues/63927
Differential Revision: https://reviews.llvm.org/D155957
(cherry picked from commit b37c7ed0c95c7f24758b1532f04275b4bb65d3c1)
There are cases where the -1 doesn't become visible until lowering
so the folding doesn't have a chance to run.
I think in these cases there is a missed DAGCombine for truncate (undef),
which I may fix separately, but RISC-V backend should protect itself.
Fixes#64503.
Reviewed By: asb
Differential Revision: https://reviews.llvm.org/D157314
(cherry picked from commit 7cc615413fd7c93421052a193bc3e114465747c9)
The llvm-rc tool tries to locate a suitable Clang executable to
use for preprocessing. For this purpose, it first checks within
the same directory as the llvm-rc tool, checking with a couple
different names, followed by checking all of $PATH for another
couple names.
On Windows, the InitLLVM() function always sets up Argv[0] with the
full path to the executable, while on Unix, Argv[0] is kept as is.
Therefore, call getMainExecutable to try to resolve the directory of
the executable before looking for colocated Clang executables.
This makes 282744a9ce18120dc0a6eceb02693b36980d9498 actually have
the desired effect.
Differential Revision: https://reviews.llvm.org/D157241
(cherry picked from commit 8c6a0c8bf50bca6c3a0c4de1b84f21466ee31655)
Previously, foldExtractFromBroadcast() would incorrectly fold:
func.func @extract_from_stretch_broadcast(%src: vector<3x1x2xf32>) -> f32 {
%0 = vector.broadcast %src : vector<3x1x2xf32> to vector<3x4x2xf32>
%1 = vector.extract %0[0, 2, 0] : vector<3x4x2xf32>
return %1: f32
}
to:
func.func @extract_from_stretch_broadcast(%src: vector<3x1x2xf32>) -> f32 {
%0 = vector.extract %src[0, 2, 0] : vector<3x1x2xf32>
return %0: f32
}
This was due to the wrong offset being used when zeroing the "dim-1"
broadcasted dims. It should use the difference in rank across the
broadcast as the starting offset, as the ranks after that are the ones
that could have been stretched.
Reviewed By: awarzynski, dcaballe
Differential Revision: https://reviews.llvm.org/D157003
This revision uses std::array instead of normal c arrays to store the
operand and result segment sizes. This is a follow up to
https://reviews.llvm.org/D155919, which converted the operand and result
segment sizes to properties. Its use of c arrays triggered warnings in
downstream projects due to the direct comparison of c arrays. This
revision fixes the warnings using std::arrays that implement a
proper comparison operator, which compares the array elements rather
that the array pointers.
Note: it seems the comparison operator is effectively dead code for now.
It still seems useful to fix the warning and ensure the comparison works
as expected assume someone starts using it at some point in time.
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D156888
Leaving this field unitialized could led to crashes when it'll diverge from the
IRNumbering phase.
Differential Revision: https://reviews.llvm.org/D156965
When the operation has no attributes, the generated assertion is
always false and triggers lots of warnings in the build.
```
warning: comparison of unsigned expression < 0 is always false
```
Just return a StringAttr when there is no attribute.
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D156819
The `allocsize` attribute is weird because it packs two 32-bit values
into a 64-bit value. It also turns out that the passthrough attribute
exporter was using `int`, which is incorrectly handling 64-bit integers.
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D156574
The verifier for some arith ops were not considering that ranked
tensor types can have encodings.
Differential Revision: https://reviews.llvm.org/D156557
Different identified struct types may have the same name ("").
Previously, these were deduplicated based on their name, which caused
an assertion failure when nesting identified structs:
%0 = type { %1 }
%1 = type { i8 }
declare void @fn(%0)
Reviewed By: gysit
Differential Revision: https://reviews.llvm.org/D156531
This allows for users of the lsp transport libraries to process replies
in parallel, without overlapping/clobbering the output.
Differential Revision: https://reviews.llvm.org/D156295
Zero region operations return true for both isBeforeAllRegions and
isAfterAllRegions when using WalkStage. The bytecode walk only
expects region holding operations in the after regions path, so
guard against that.
We currently only support lazy loading for regions that
statically implement the IsolatedFromAbove trait, but that
limits the amount of operations that can be lazily loaded. This review
lifts that restriction by computing which operations have isolated
regions when numbering, allowing any operation to be lazily loaded
as long as it doesn't use values defined above.
Differential Revision: https://reviews.llvm.org/D156199
We currently encode each region as a separate section, but
the reader expects all of the regions to be in the same section.
This updates the writer to match the behavior that the reader
expects.
Differential Revision: https://reviews.llvm.org/D156198
1-element vectors are not valid in SPIR-V and fail `Bitcast` op verification.
Reviewed By: antiagainst
Differential Revision: https://reviews.llvm.org/D156207
These instructions show worse performance on Neoverse-V1 compared
to pair of LDR(LDP)/MOV instructions.
This patch adds `no-sve-fp-ld1r` sub-target feature, which is enabled
only on Neoverse-V1.
Fixes https://github.com/llvm/llvm-project/issues/64498
Differential Revision: https://reviews.llvm.org/D157279
(cherry picked from commit 60e2a849b0a537f96ca12fb032c4a0e32e07b4ae)
When compiling against recent glibc (>= 2.35) but old kernel headers (< 4.18), `SYS_rseq` is not defined and thus llvm-exegesis fails to build. So also check that `SYS_rseq` is defined before trying to use it.
Fixes https://github.com/llvm/llvm-project/issues/64456
Reviewed By: MaskRay, gchatelet
Differential Revision: https://reviews.llvm.org/D157189
(cherry picked from commit f70e83af7a708a22fdde8c644ac5810223090cd4)
* Remove the incorrect patterns from AArch64fmla_p/AArch64fmls_p
* Add correct patterns to AArch64fmla_m1/AArch64fmls_m1
* Refactor fma_patfrags for the sake of PatFrags
Fixes https://github.com/llvm/llvm-project/issues/64419
Differential Revision: https://reviews.llvm.org/D157095
(cherry picked from commit 84d444f90900d1b9d6c08be61f8d62090df28042)
