[llvm-bugs] [Bug 129261] Should -Wwrite-strings be renamed to -fwrite-strings?
Issue
129261
Summary
Should -Wwrite-strings be renamed to -fwrite-strings?
Labels
new issue
Assignees
Reporter
alejandro-colomar
GCC bug:
Cc: @AaronBallman
-f flags are meant to change the meaning of code, while -W flags are meant to add diagnostics without changing the meaning of code.
-Wwrite-strings is an oddity, since it does change the meaning of code:
```c
alx@debian:~/tmp$ cat ws.c
int
main(void)
{
return _Generic(&*"", const char *: 0, char *: 1);
}
alx@debian:~/tmp$ gcc -Wall -Wextra -Wwrite-strings ws.c
alx@debian:~/tmp$ ./a.out; echo $?
0
alx@debian:~/tmp$ gcc -Wall -Wextra -Wno-write-strings ws.c
alx@debian:~/tmp$ ./a.out; echo $?
1
alx@debian:~/tmp$ clang -Weverything -Wwrite-strings ws.c -Wno-pre-c11-compat
alx@debian:~/tmp$ ./a.out; echo $?
0
alx@debian:~/tmp$ clang -Weverything -Wno-write-strings ws.c -Wno-pre-c11-compatalx@debian:~/tmp$ ./a.out; echo $?
1
```
Should we add -fwrite-strings, and keep -Wwrite-strings as a deprecated synonym?
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129337] [clang] Missed attribute dereferenceable() for complex argument in stack
Issue
129337
Summary
[clang] Missed attribute dereferenceable() for complex argument in stack
Labels
clang
Assignees
Reporter
weiguozhi
Compile the following source code
```
clang -O3 -fno-exceptions -c test2.cc -o test2.o
#include
char foo(std::string str, int i) {
return str[i];
}
std::string ha;
char qux() {
foo(ha, 3);
}
```
I got the following IR
```
; Function Attrs: mustprogress nounwind uwtable
define dso_local noundef signext i8 @_Z3fooNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEi(ptr noundef %str, i32 noundef %i) #0 {
entry:
%str.indirect_addr = alloca ptr, align 8
%i.addr = alloca i32, align 4
store ptr %str, ptr %str.indirect_addr, align 8, !tbaa !5
store i32 %i, ptr %i.addr, align 4, !tbaa !10
%0 = load i32, ptr %i.addr, align 4, !tbaa !10
%conv = sext i32 %0 to i64
%call = call noundef nonnull align 1 dereferenceable(1) ptr @_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEixEm(ptr noundef nonnull align 8 dereferenceable(32) %str, i64 noundef %conv)
%1 = load i8, ptr %call, align 1, !tbaa !12
ret i8 %1
}
; Function Attrs: mustprogress nounwind uwtable
define dso_local noundef signext i8 @_Z3quxv() #0 {
entry:
%agg.tmp = alloca %"class.std::__cxx11::basic_string", align 8
call void @_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEC2ERKS4_(ptr noundef nonnull align 8 dereferenceable(32) %agg.tmp, ptr noundef nonnull align 8 dereferenceable(32) @_Z2haB5cxx11)
%call = call noundef signext i8 @_Z3fooNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEi(ptr noundef %agg.tmp, i32 noundef 3)
call void @_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED2Ev(ptr noundef nonnull align 8 dereferenceable(32) %agg.tmp) #2
unreachable
}
```
The first parameter of foo is of type string, it's too complex, so it is actually allocated in the caller's stack, and the pointer is passed to foo. I expect it has the attribute dereferenceable(32), like the function @_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEixEm, but it is missed in function foo.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129267] Please create issue-subscribers-lldb-dap
Issue 129267 Summary Please create issue-subscribers-lldb-dap Labels lldb-dap Assignees tstellar Reporter JDevlieghere Please create an issue-subscribers team for the lldb-dap label. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129328] [libc++] Reimplement `std::vector` operations in terms of relocation
Issue 129328 Summary [libc++] Reimplement `std::vector` operations in terms of relocation Labels libc++, performance Assignees ldionne Reporter ldionne From initial testing, this can yield easily 50% speedups. I have WIP patches already for that. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129319] [libc++] Optimize std::find_first_of
Issue 129319 Summary [libc++] Optimize std::find_first_of Labels libc++, performance Assignees Reporter ldionne `std::find_first_of` could use `any_of` or `find_if` to piggy-back on other algorithm's optimizations. This can be done when searching through the needle once we have something in the haystack. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129321] [libc++] `ranges::contains(vector)` is slow
Issue 129321 Summary [libc++] `ranges::contains(vector)` is slow Labels libc++, performance Assignees Reporter ldionne Preliminary testing seems to suggest that it's 50% slower than libstdc++'s version. We should investigate that benchmark and why we're doing so poorly, since this is such a simple algorithm. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129322] [libc++] Optimize `ranges::contains_subrange`
Issue 129322 Summary [libc++] Optimize `ranges::contains_subrange` Labels libc++, performance Assignees Reporter ldionne There are a few special cases that are easy to spot: - subrange is only 1 element (this is a `contains`) - the two ranges are the same length (this is `equal`) And we can probably take advantage of a properly optimized `std::find_if` in the general version. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129325] [libc++] Ensure `std::lexicographical_compare_three_way` is optimized properly
Issue 129325 Summary [libc++] Ensure `std::lexicographical_compare_three_way` is optimized properly Labels libc++, performance Assignees Reporter ldionne I don't think we are using `std::memcmp` in `lexicographical_compare_three_way`, but it seems like we could. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129316] [libc++] Check whether `std::fill_n` and `std::fill` lower to `memset` for specific arguments
Issue 129316 Summary [libc++] Check whether `std::fill_n` and `std::fill` lower to `memset` for specific arguments Labels libc++, performance Assignees Reporter ldionne This seems like an obvious optimization and we should ensure it happens. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129314] [libc++] std::transform with an identity predicate is much slower than std::copy
Issue 129314 Summary [libc++] std::transform with an identity predicate is much slower than std::copy Labels libc++, performance Assignees Reporter ldionne This needs to be investigated. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129330] [libc++] Optimize associative container insertion
Issue 129330 Summary [libc++] Optimize associative container insertion Labels libc++, performance Assignees Reporter ldionne We seem to be very poorly in these operations, often 2x slower than other implementations. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129315] [libc++] Optimize std::replace and std::replace_if
Issue 129315 Summary [libc++] Optimize std::replace and std::replace_if Labels libc++, performance Assignees Reporter ldionne We might be able to use `std::find` to replace contiguous ranges, and `replace_if` might be able to use `find_if`. This might be worth it if `std::find_if` is unrolled, for example. Or maybe it'll be worse because `std::find_if` has more data dependency because of short-circuiting. But this should be investigated. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129312] [libc++] Ensure that passing predicates through `reference_wrapper` doesn't kill `desugars_to` optimizations
Issue 129312 Summary [libc++] Ensure that passing predicates through `reference_wrapper` doesn't kill `desugars_to` optimizations Labels libc++, performance Assignees Reporter ldionne We do that in e.g. `ranges::contains` where we pass a `reference_wrapper` to the projection to `ranges::find`. Does that turn off optimizations? ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129318] [libc++] Optimize std::find_end
Issue 129318 Summary [libc++] Optimize std::find_end Labels libc++, performance Assignees Reporter ldionne That algorithm is super slow, I noticed while benchmarking it. We could probably short-circuit it with a `std::find` for the first element of the needle. We should also consider starting from the end for bidirectional iterators if we don't already. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129327] [libc++] Optimize `std::search_n`
Issue 129327 Summary [libc++] Optimize `std::search_n` Labels libc++, performance Assignees Reporter ldionne We can use `std::find` to figure out where to start, and then we can probably use `std::find_if` to find the end of the sequence of `n` values. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129324] [libc++] Low-hanging fruit optimizations in `std::is_permutation`
Issue 129324 Summary [libc++] Low-hanging fruit optimizations in `std::is_permutation` Labels libc++, performance Assignees Reporter ldionne There's a place in `std::is_permutation` where we eliminate a common prefix at the start. We could use `std::mismatch` instead of a hand-written loop, since `mismatch` is vectorized. Inside `__is_permutation_impl`, we can use `std::find` for "Have we already counted the number of `*__i` in `[f1, l1)`?" ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129276] [X86] Suboptimal codegen for broadcasting a 16-bit vector element
Issue
129276
Summary
[X86] Suboptimal codegen for broadcasting a 16-bit vector element
Labels
new issue
Assignees
Reporter
dzaima
This LLVM IR:
```llvm
define <16 x i16> @broadcast_sel15(<16 x i16> noundef %x) {
%r = shufflevector <16 x i16> %x, <16 x i16> poison, <16 x i32> splat(i32 15)
ret <16 x i16> %r
}
```
could be compiled to:
```asm
vpshufhw ymm0, ymm0, 255
vpermq ymm0, ymm0, 255
```
but llvm produces:
```asm
vpshufhwymm0, ymm0, 255
vpbroadcastdymm1, dword ptr [rip + .LCPI15_0] ; 6
vpermd ymm0, ymm1, ymm0
```
[all 16 cases with C intrinsics with gcc for comparison](https://c.godbolt.org/z/r6ssxno7z), and [direct LLVM IR](https://llvm.godbolt.org/z/eYvbrjvME)
12..15 are the most problematic ones, but the codegen for 8 of `vextracti128`+`vpbroadcastw` would also likely be better off as `vpshuflw`+`vpermq` to avoid having two cross-lane ops. The rest are fine either way I think.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129206] [MLIR] [AMDGPU] refactor how we handle target features
Issue 129206 Summary [MLIR] [AMDGPU] refactor how we handle target features Labels mlir Assignees Reporter dhernandez0 Currently, we hardcode hardware features in the code (see https://github.com/llvm/llvm-project/blob/15c49b9db3f60bdbd320271d5e97f118c00b95dd/mlir/lib/Dialect/AMDGPU/Transforms/EmulateAtomics.cpp#L173). We want to implement a better way of handling subtarget features. See this PR for discussion about possible implementations: https://github.com/llvm/llvm-project/pull/129029 ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129208] Support: llvm/test/tools/llvm-rc/windres-preproc.test fails on our platform with different error message.
Issue 129208 Summary Support: llvm/test/tools/llvm-rc/windres-preproc.test fails on our platform with different error message. Labels new issue Assignees Reporter mark-sed Recent change in Program.inc (https://github.com/llvm/llvm-project/pull/128821) has caused a llvm-lit failure in our CI. The expected error message does not match as our message does not have the prefix expected in this test. ``` /builds/llvm/test/tools/llvm-rc/windres-preproc.test:23:11: error: CHECK4: expected string not found in input ; CHECK4: llvm-rc: Preprocessing failed: posix_spawn failed: [[MSG]] ^ :1:1: note: scanning from here llvm-rc: Preprocessing failed: No such file or directory ^ :1:1: note: with "MSG" equal to "No such file or directory" llvm-rc: Preprocessing failed: No such file or directory ^ Input file: Check file: /builds/llvm/test/tools/llvm-rc/windres-preproc.test -dump-input=help explains the following input dump. Input was: << 1: llvm-rc: Preprocessing failed: No such file or directory check:23'0 X error: no match found check:23'1 with "MSG" equal to "No such file or directory" >> -- ``` Currently the test expects `posix_spawn failed:`, which does not get output on our machine. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129213] Clang 10 Incorrectly Accepts Invalid Enum Base Type Syntax enum class a : int b;
Issue
129213
Summary
Clang 10 Incorrectly Accepts Invalid Enum Base Type Syntax enum class a : int b;
Labels
clang
Assignees
Reporter
starbugs-qurong
Clang 10 erroneously compiles code containing an invalid enum base type declaration (enum class a : int b;), while MSVC/GCC correctly reject it. This violates the C++ standard syntax rules.
For the following code test.cpp:
```
template
void qux() {
enum class a : int b; // Invalid syntax
}
int main() {
qux();
return 0;
}
```
Compile with Clang 10:
clang++ -std=c++11 test.cpp
Expected Result:
Compilation fails with a syntax error (as in MSVC/GCC).
Actual Result:
Clang 10 compiles the code without errors.
Environment:
Compiler: Clang 10.0.0
Flags: -std=c++11
Compiler Explorer link: https://godbolt.org/z/P3sa4EKhd
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129216] [mlir][td] check-use-after-free.mlir failing (AppleSillcon + shared libs)
Issue 129216 Summary [mlir][td] check-use-after-free.mlir failing (AppleSillcon + shared libs) Labels mlir Assignees banach-space Reporter banach-space Hi, [check-use-after-free.mlir](https://github.com/llvm/llvm-project/blob/main/mlir/test/Dialect/Transform/check-use-after-free.mlir) fails for for me on **AppleSilicon** (checked on M3 and M4) with: * -DBUILD_SHARED_LIBS=**On** (static libs build is fine). I've tracked it down to the TD logic incorrectly assuming that at runtime there will be only one instance of [DerivedResource](https://github.com/llvm/llvm-project/blob/78c96aa24f0406e630674d82eef073ea3d4c8141/mlir/include/mlir/Interfaces/SideEffectInterfaces.h#L90-L93). That assumption is effectively made here: https://github.com/llvm/llvm-project/blob/78c96aa24f0406e630674d82eef073ea3d4c8141/mlir/include/mlir/Interfaces/SideEffectInterfaceBase.td#L132 I actually end up with **two** instances of that class at runtime, both are instantiations of: ```cpp mlir::SideEffects::Resource::Base: ``` * one instance "lives" in `libMLIRTransformDialectInterfaces.dylib`, * another instances "lives" in `libMLIRTransformDialectTransforms.dylib`. **QUESITON:** Should I update [getEffectsOnResource](https://github.com/llvm/llvm-project/blob/78c96aa24f0406e630674d82eef073ea3d4c8141/mlir/include/mlir/Interfaces/SideEffectInterfaceBase.td#L132) to compare `ResourceID` instead? ```cpp return it.getResource()->getResourceID() != resource->getResourceID(); ``` https://github.com/llvm/llvm-project/blob/78c96aa24f0406e630674d82eef073ea3d4c8141/mlir/include/mlir/Interfaces/SideEffectInterfaces.h#L108 Alternatively, we could explore ways to ensure that there is only one instance across all shared objects, but I’m not sure how best to achieve that. @ftynse, could you take a look when you get a chance? "git log" wasn’t very helpful here (this logic depends on quite a few components), and you’re my go-to TD expert. 🙂 —Andrzej ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129218] codegen for the popcount like loop is bad
Issue
129218
Summary
codegen for the popcount like loop is bad
Labels
new issue
Assignees
Reporter
DenisYaroshevskiy
On [twitter](https://x.com/lemire/status/1895297881592209657) people complained about the codegen for this loop
```
#include
std::uint32_t count(std::uint64_t bits) {
std::uint32_t used = 0;
for (std::uint32_t i = 0; i < 64; ++i) {
if (bits & (1ull << i)) {
++used;
}
}
return used;
}
```
https://godbolt.org/z/vo4MK4hGq
It indeed looks questionable
```
count(unsigned long):
vpbroadcastdxmm0, edi
vpbroadcastqymm1, rdi
vpmovqd xmm2, ymm1
vpsrlvd xmm3, xmm0, xmmword ptr [rip + .LCPI0_0]
vinserti128 ymm4, ymm2, xmm2, 1
mov eax, edi
shr eax, 30
mov ecx, edi
vpsrlvq ymm5, ymm1, ymmword ptr [rip + .LCPI0_1]
vpsrlvq ymm6, ymm1, ymmword ptr [rip + .LCPI0_2]
vpsrlvq ymm7, ymm1, ymmword ptr [rip + .LCPI0_3]
vpsrlvq ymm8, ymm1, ymmword ptr [rip + .LCPI0_4]
vpsrlvq ymm9, ymm1, ymmword ptr [rip + .LCPI0_5]
shr ecx, 31
mov rdx, rdi
vpsrlvq ymm10, ymm1, ymmword ptr [rip + .LCPI0_6]
vpackusdw ymm9, ymm10, ymm9
vpsrlvd xmm10, xmm2, xmmword ptr [rip + .LCPI0_7]
vpsrlvd ymm11, ymm4, ymmword ptr [rip + .LCPI0_8]
vpsrlvd ymm4, ymm4, ymmword ptr [rip + .LCPI0_9]
vpsrlvd xmm2, xmm2, xmmword ptr [rip + .LCPI0_10]
shr rdx, 32
vpmovqd xmm8, ymm8
vpmovqd xmm7, ymm7
vinserti128 ymm7, ymm8, xmm7, 1
vpmovqd xmm6, ymm6
vpmovqd xmm5, ymm5
vinserti128 ymm5, ymm6, xmm5, 1
vpermq ymm6, ymm9, 216
vpsrld xmm0, xmm0, 1
vpinsrd xmm0, xmm0, edi, 1
vpunpcklqdq xmm0, xmm0, xmm3
vpbroadcastdymm8, eax
vpmovsxbq ymm9, dword ptr [rip + .LCPI0_14]
vpermi2qymm9, ymm3, ymm8
vpbroadcastdymm3, edx
vpblenddymm3, ymm9, ymm3, 128
vinserti128 ymm8, ymm0, xmm10, 1
vpblenddymm2, ymm3, ymm2, 15
vpbroadcastdymm3, dword ptr [rip + .LCPI0_12]
vpand ymm2, ymm2, ymm3
vpand ymm5, ymm5, ymm3
vpand ymm6, ymm6, ymm3
vpand ymm4, ymm4, ymm3
vpaddd ymm4, ymm4, ymm6
vpand ymm6, ymm7, ymm3
vpand ymm7, ymm11, ymm3
vpaddd ymm6, ymm7, ymm6
vpaddd ymm2, ymm6, ymm2
vpand ymm6, ymm8, ymm3
vpsrlvq ymm1, ymm1, ymmword ptr [rip + .LCPI0_13]
vpmovqd xmm1, ymm1
vpand xmm1, xmm1, xmm3
mov rax, rdi
shr rax, 63
vpand xmm0, xmm0, xmm3
vpaddd xmm0, xmm0, xmm1
vpblenddymm0, ymm6, ymm0, 15
vpaddd ymm0, ymm0, ymm5
vpaddd ymm0, ymm0, ymm4
vpaddd ymm0, ymm0, ymm2
vextracti128xmm1, ymm0, 1
vpaddd xmm0, xmm0, xmm1
vpextrd edx, xmm0, 1
vmovd esi, xmm0
add esi, edx
vpextrd edx, xmm0, 2
vpextrd r8d, xmm0, 3
add r8d, edx
add r8d, esi
bt rdi, 62
adc eax, 0
bt rdi, 61
adc eax, r8d
add eax, ecx
vzeroupper
ret
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129217] clang++-21 crashed report
Issue
129217
Summary
clang++-21 crashed report
Labels
clang
Assignees
Reporter
sweihub
Hi, C++-21 crashed, the required files are attached.
[main-b707af.zip](https://github.com/user-attachments/files/19025531/main-b707af.zip)
```
➜ coin git:(develop) ✗ b
-- The C compiler identification is Clang 21.0.0
-- The CXX compiler identification is Clang 21.0.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/clang-21 - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/clang++-21 - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found ZLIB: /usr/lib/x86_64-linux-gnu/libz.so (found version "1.3")
-- Found Boost: /usr/lib/x86_64-linux-gnu/cmake/Boost-1.83.0/BoostConfig.cmake (found suitable version "1.83.0", minimum required is "1.71.0")
-- Configuring done (0.9s)
-- Generating done (0.0s)
-- Build files have been written to: /root/quant/algo/coin/build
[29/30] Building CXX object CMakeFiles/demo.dir/src/main.cppm.o
FAILED: CMakeFiles/demo.dir/src/main.cppm.o CMakeFiles/demo.dir/main.pcm
/usr/bin/clang++-21 -I/root/quant/algo/coin/include -fsanitize=address -fno-omit-frame-pointer -g -DDEBUG -g -std=c++26 -MD -MT CMakeFiles/demo.dir/src/main.cppm.o -MF CMakeFiles/demo.dir/src/main.cppm.o.d @CMakeFiles/demo.dir/src/main.cppm.o.modmap -o CMakeFiles/demo.dir/src/main.cppm.o -c /root/quant/algo/coin/src/main.cppm
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments: /usr/lib/llvm-21/bin/clang -cc1 -triple x86_64-pc-linux-gnu -emit-obj -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name main.cppm -mrelocation-model pic -pic-level 2 -pic-is-pie -mframe-pointer=all -fmath-errno -ffp-contract=on -fno-rounding-math -mconstructor-aliases -funwind-tables=2 -target-cpu x86-64 -tune-cpu generic -debug-info-kind=constructor -dwarf-version=5 -debugger-tuning=gdb -fdebug-compilation-dir=/root/quant/algo/coin/build -fcoverage-compilation-dir=/root/quant/algo/coin/build -resource-dir /usr/lib/llvm-21/lib/clang/21 -std=c++26 -fdeprecated-macro -ferror-limit 19 -fgnuc-version=4.2.1 -fno-implicit-modules -fmodule-file=websocket=CMakeFiles/demo.dir/websocket.pcm -fmodule-file=recipe=CMakeFiles/demo.dir/recipe.pcm -fmodule-file=binance=CMakeFiles/demo.dir/binance.pcm -fmodule-file=log=CMakeFiles/demo.dir/log.pcm -fmodule-file=coin=CMakeFiles/demo.dir/coin.pcm -fmodule-file=json=CMakeFiles/demo.dir/json.pcm -fmodule-file=semaphore=CMakeFiles/demo.dir/semaphore.pcm -fmodule-file=time=CMakeFiles/demo.dir/time.pcm -fmodule-file=web=CMakeFiles/demo.dir/web.pcm -fmodule-file=ws=CMakeFiles/demo.dir/ws.pcm -fmodule-file=wss=CMakeFiles/demo.dir/wss.pcm -fskip-odr-check-in-gmf -fcxx-exceptions -fexceptions -fsanitize=address -fsanitize-system-ignorelist=/usr/lib/llvm-21/lib/clang/21/share/asan_ignorelist.txt -fno-sanitize-memory-param-retval -fsanitize-address-use-after-scope -fsanitize-address-globals-dead-stripping -fno-assume-sane-operator-new -faddrsig -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o CMakeFiles/demo.dir/src/main.cppm.o -x pcm CMakeFiles/demo.dir/main.pcm
1. parser at end of file
2. Per-file LLVM IR generation
3. /root/quant/algo/coin/include/httplib.h:9637:24: Generating code for declaration 'httplib::SSLClient::shutdown_ssl_impl'
4. /root/quant/algo/coin/include/httplib.h:9639:38: LLVM IR generation of compound statement ('{}')
#0 0x7fc825b35fef llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/usr/lib/llvm-21/bin/../lib/libLLVM.so.21.0+0x102efef)
#1 0x7fc825b33cf9 llvm::sys::RunSignalHandlers() (/usr/lib/llvm-21/bin/../lib/libLLVM.so.21.0+0x102ccf9)
#2 0x7fc825b3670d (/usr/lib/llvm-21/bin/../lib/libLLVM.so.21.0+0x102f70d)
#3 0x7fc82459a330 (/lib/x86_64-linux-gnu/libc.so.6+0x45330)
#4 0x7fc82e3631b8 (/usr/lib/llvm-21/bin/../lib/libclang-cpp.so.21.0+0xef81b8)
#5 0x7fc82e3532be (/usr/lib/llvm-21/bin/../lib/libclang-cpp.so.21.0+0xee82be)
#6 0x7fc82e3be86d (/usr/lib/llvm-21/bin/../lib/libclang-cpp.so.21.0+0xf5386d)
#7 0x7fc82e3a8e60 (/usr/lib/llvm-21/bin/../lib/libclang-cpp.so.21.0+0xf3de60)
#8 0x7fc82e34d963 (/usr/lib/llvm-21/bin/../lib/libclang-cpp.so.21.0+0xee2963)
#9 0x7fc82e34b201 (/usr/lib/llvm-21/bin/../lib/libclang-cpp.so.21.0+0xee0201)
#10 0x7fc82e34749b (/usr/lib/llvm-21/bin/../lib/libclang-cpp.so.21.0+0xedc49b)
#11 0x7fc82e3473a2 clang::Expr::EvaluateAsInt(clang::Expr::EvalResult&, clang::ASTContext c
[llvm-bugs] [Bug 129249] Poor scalability of empty block elimination in SimplifyCFG
Issue
129249
Summary
Poor scalability of empty block elimination in SimplifyCFG
Labels
new issue
Assignees
Reporter
amonakov
```c
int f(int);
#define T if (f(++i)) { return i; }
#define X16(X) X X X X X X X X X X X X X X X X
int g()
{
int i = 0;
X16(X16(X16(T)))
#ifdef TWICE
X16(X16(X16(T)))
#endif
return 0;
}
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129256] wbN: A suffix for specifying the width of a bit-precise integer literal
Issue
129256
Summary
wbN: A suffix for specifying the width of a bit-precise integer literal
Labels
new issue
Assignees
Reporter
alejandro-colomar
Currently, we have no way of specifying the width of a bit-precise integer literal. We only have the wb suffix, which say "pick the smaller width possible".
That wb suffix is insufficient, as sometimes we need a type wider than the value we're using, if we're going to use for example shifts.
As an example, there's no good way (and by good, I mean something that doesn't involve casts) to create a value of width N (let's use 3 as a small example) where all bits are 1 except for the leftmost (or rightmost) one.
```c
alx@debian:~/tmp$ cat bw.c
int
main(void)
{
unsigned _BitInt(3) i = ~0wb >> 1;
return i;
}
alx@debian:~/tmp$ gcc -Wall -Wextra bw.c
alx@debian:~/tmp$ ./a.out; echo $?
7
alx@debian:~/tmp$ clang -Weverything -Wno-c23-extensions -Wno-bit-int-extension bw.c
bw.c:4:31: warning: implicit conversion changes signedness: '_BitInt(2)' to 'unsigned _BitInt(3)' [-Wsign-conversion]
4 | unsigned _BitInt(3) i = ~0wb >> 1;
| ~ ~^~~~
1 warning generated.
alx@debian:~/tmp$ ./a.out; echo $?
7
```
It would make sense to be able to write it like this (IMO):
```c
unsigned _BitInt(3) i = ~0wb3u >> 1; // stores the value 5 (0b011).
```
GCC bug:
Cc: @AaronBallman
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129260] Allow in C the more relaxed rules from C++ for assignments with const T*const *
Issue 129260 Summary Allow in C the more relaxed rules from C++ for assignments with const T*const * Labels new issue Assignees Reporter alejandro-colomar Cc: @AaronBallman , @pinskia GCC bug: There is interest in standardizing this in the committee, and it would be interesting to have Clang do this, to show prior art to the committee. I'm also proposing the same exact change to GCC. The rules have been proven by C++ to just work, so time has proved that these rules work, unless someone points out any issues that I didn't know about with these rules from C++. No existing code should break, since it's only removing existing diagnostics, and not adding any new ones. And const correctness still holds after this relaxation of implicit conversions. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129211] [analyzer] Crash
Issue
129211
Summary
[analyzer] Crash
Labels
clang:static analyzer,
crash-on-valid
Assignees
Reporter
balazs-benics-sonarsource
The analyzer would crash after #127602 on the following code: https://compiler-explorer.com/z/fzoqP36xq
```c++
struct a {
int b;
int : 0;
};
void top() {
struct a d[][5][5] = {
{
{{}, {}, {}, {}, {}},
{{}, {}, {}, {}, {}},
{{}, {}, {}, {}, {}},
{{}, {}, {}, {}, {}},
{{}, {}, {}, {}, {}}
},
{
{{}, {}, {}, {}, {}},
{{}, {}, {}, {}, {}},
{{}, {}, {}, {}, {}},
{{}, {}, {}, {}, {}},
{{}, {}, {}, {}, {}},
},
{
{{}, {}, {}, {}, {}},
{{}, {}, {}, {}, {}},
{{}, {}, {}, {}},
}
};
}
```
```sh
clang --analyze -Xclang -analyzer-checker=core crash.c
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129242] clang crashes on valid code at -O{2, 3} on x86_64-linux-gnu: Assertion `valid() && "InstructionsState is invalid."' failed
Issue
129242
Summary
clang crashes on valid code at -O{2,3} on x86_64-linux-gnu: Assertion `valid() && "InstructionsState is invalid."' failed
Labels
clang
Assignees
Reporter
zhendongsu
It appears to be a recent regression as it doesn't reproduce with 19.1.0 and earlier.
Compiler Explorer: https://godbolt.org/z/8KTq9hGv9
```
[516] % clangtk -v
clang version 21.0.0git (https://github.com/llvm/llvm-project.git d0edd931bcc328b9502289d346f2b2219341f853)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /local/suz-local/software/local/clang-trunk/bin
Build config: +assertions
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/10
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/11
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/9
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/11
Candidate multilib: .;@m64
Selected multilib: .;@m64
[517] %
[517] % clangtk -O2 -w small.c
clang-21: /local/suz-local/software/clangbuild/llvm-project/llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp:821: llvm::Instruction* {anonymous}::InstructionsState::getMainOp() const: Assertion `valid() && "InstructionsState is invalid."' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments: /local/suz-local/software/local/clang-trunk/bin/clang-21 -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -dumpdir a- -disable-free -clear-ast-before-backend -main-file-name small.c -mrelocation-model pic -pic-level 2 -pic-is-pie -mframe-pointer=none -fmath-errno -ffp-contract=on -fno-rounding-math -mconstructor-aliases -funwind-tables=2 -target-cpu x86-64 -tune-cpu generic -debugger-tuning=gdb -fdebug-compilation-dir=/local/suz-local/software/emitesting/bugs/20250227-clangtk-m64-O3-build-235136/delta -fcoverage-compilation-dir=/local/suz-local/software/emitesting/bugs/20250227-clangtk-m64-O3-build-235136/delta -resource-dir /local/suz-local/software/local/clang-trunk/lib/clang/21 -I /usr/local/include -I /local/suz-local/software/local/include -internal-isystem /local/suz-local/software/local/clang-trunk/lib/clang/21/include -internal-isystem /usr/local/include -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/11/../../../../x86_64-linux-gnu/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -O2 -w -ferror-limit 19 -fgnuc-version=4.2.1 -fskip-odr-check-in-gmf -fcolor-diagnostics -vectorize-loops -vectorize-slp -faddrsig -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o /tmp/small-933a0f.o -x c small.c
1. parser at end of file
2. Optimizer
3. Running pass "function(float2int,lower-constant-intrinsics,loop(loop-rotate,loop-deletion),loop-distribute,inject-tli-mappings,loop-vectorize,infer-alignment,loop-load-elim,instcombine,simplifycfg,slp-vectorizer,vector-combine,instcombine,loop-unroll,transform-warning,sroa,infer-alignment,instcombine,loop-mssa(licm),alignment-from-assumptions,loop-sink,instsimplify,div-rem-pairs,tailcallelim,simplifycfg)" on module "small.c"
4. Running pass "slp-vectorizer" on function "main"
#0 0x5597e9b142df llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/local/suz-local/software/local/clang-trunk/bin/clang-21+0x455e2df)
#1 0x5597e9b11ab4 SignalHandler(int, siginfo_t*, void*) Signals.cpp:0:0
#2 0x7fa06c8aa420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420)
#3 0x7fa06c2e100b raise /build/glibc-LcI20x/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:51:1
#4 0x7fa06c2c0859 abort /build/glibc-LcI20x/glibc-2.31/stdlib/abort.c:81:7
#5 0x7fa06c2c0729 get_sysdep_segment_value /build/glibc-LcI20x/glibc-2.31/intl/loadmsgcat.c:509:8
#6 0x7fa06c2c0729 _nl_load_domain /build/glibc-LcI20x/glibc-2.31/intl/loadmsgcat.c:970:34
#7 0x7fa06c2d1fd6 (/lib/x86_64-linux-gnu/libc.so.6+0x33fd6)
#8 0x5597eb591745 (/local/suz-local/software/local/clang-trunk/bin/clang-21+0x5fdb745)
#9 0x5597eb62a4e5 llvm::slpvectorizer::BoUpSLP::getEntryCost(llvm::slpvectorizer::BoUpSLP::TreeEntry const*, llvm::ArrayRef, llvm::SmallPtrSetImpl&)::'lambda0'(llvm::function_ref, llvm::function_ref)::operator()(llvm::function_ref, llvm::function_ref) const SLPVectorizer.cpp:0:0
#10 0x5597eb633034 llvm::slpvectorizer::BoUpSLP::getEntryCost(llvm::slpvectorizer::BoUpSLP::TreeEntry const*, llvm::ArrayRef, llvm::SmallPtrSetImpl&) (/local/suz-local/software/local/clang-trunk/bin/clang-21+0x607d034)
#11 0x5597eb668741 llvm::slpvectorizer::BoUpSLP::getTreeCost(llvm::ArrayRef) (/local/suz-local/software/local/clang-trunk/bin/clang-21+0x60b2741)
#12 0x5597eb672691 llvm::SLPVectorizerPass::tryToVectorizeList(llvm::Arr
[llvm-bugs] [Bug 129244] [clang] Miscompile at -O2/3
Issue
129244
Summary
[clang] Miscompile at -O2/3
Labels
clang
Assignees
Reporter
cardigan1008
This code prints 0 at `-O0/1` and returns 3 at `-O2/3`:
```c
int printf(const char *, ...);
int a, b, d;
void exit(int);
int c(int e, unsigned long p2) {
double g = -p2 / 100.0;
if (g > 3)
g = 3;
int f = e * 10 + g;
return f;
}
int h(int *e) {
if (0 >= d)
return 0;
return e[0];
}
int i(int e) {
int j = h(&e);
return c(67, j + 2) - 673 + j;
}
void k(int e, int p2) {
int l = e - p2;
if (1 != l)
exit(3);
}
int main() {
int m = i(9), q = i(5);
b = m;
k(5, q + 4);
printf("%X\n", a);
}
```
Compiler Explorer: https://godbolt.org/z/1bvrehz5j
Bisected to https://github.com/llvm/llvm-project/commit/42cbceb0f0160d67145723613fda325dbd129308, which was committed by @alexey-bataev
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129223] clang -winsdkdir is overridden in presence of a system-installed Visual Studio
Issue 129223 Summary clang -winsdkdir is overridden in presence of a system-installed Visual Studio Labels clang Assignees Reporter mkre Hi, We are trying to build a binary on Windows using a specific set of Visual Studio (installed under `C:\Users\ydfb4q\BDM-2130\16.9.31910.168`) and Windows libraries (`C:\Users\ydfb4q\BDM-2130\10.0.19041.0`). ### No VS installed This is working as expected with `-winsdkdir` and `-vctoolsdir` when there is no Visual Studio installed on the system: ``` .\clang.exe -fuse-ld=lld-link.exe C:\Users\ydfb4q\BDM-2130\hello.cpp -Wl,-vctoolsdir:C:\Users\ydfb4q\BDM-2130\16.9.31910.168\Professional\VC\Tools\MSVC\14.28.29910\ -Wl,-winsdkdir:C:\Users\ydfb4q\BDM-2130\10.0.19041.0\ -o C:\Users\ydfb4q\BDM-2130\hello.exe -L C:\Users\ydfb4q\BDM-2130\10.0.19041.0\lib\um\x64\ -Wl,-verbose -isystem C:\Users\ydfb4q\BDM-2130\16.9.31910.168\Professional\VC\Tools\MSVC\14.28.29910\include -isystem C:\Users\ydfb4q\BDM-2130\10.0.19041.0\include\ucrt ``` [link_no_vs.txt](https://github.com/user-attachments/files/19026076/link_no_vs.txt) indicates the correct libraries being used: ``` lld-link: Reading C:\Users\ydfb4q\BDM-2130\10.0.19041.0\lib\um\x64\kernel32.lib lld-link: Reading C:\Users\ydfb4q\BDM-2130\16.9.31910.168\Professional\VC\Tools\MSVC\14.28.29910\lib\x64\libvcruntime.lib lld-link: Reading C:\Users\ydfb4q\BDM-2130\10.0.19041.0\Lib\ucrt\x64\libucrt.lib ``` ### VS installed After installing Visual Studio on the system, we would still like ignore its installation when linking our binary. However, the same command line no leads to [link_with_vs_installed.txt](https://github.com/user-attachments/files/19026083/link_with_vs_installed.txt), which shows that system libraries are pulled in: ``` lld-link: Reading C:\Program Files (x86)\Windows Kits\10\Lib\10.0.22000.0\um\x64\kernel32.lib lld-link: Reading c:\apps\MVS174\VC\Tools\MSVC\14.34.31933\lib\x64\libvcruntime.lib lld-link: Reading C:\Program Files (x86)\Windows Kits\10\Lib\10.0.22000.0\ucrt\x64\libucrt.lib ``` Setting the `VCINSTALLDIR` environment variable ``` set VCINSTALLDIR=C:\Users\ydfb4q\BDM-2130\16.9.31910.168 ``` leads to correctly picking up the Visual Studio libraries (but still the system Windows libraries, obviously): [link_with_vs_installed-vcinstalldir.txt](https://github.com/user-attachments/files/19026106/link_with_vs_installed-vcinstalldir.txt) ``` lld-link: Reading C:\Program Files (x86)\Windows Kits\10\Lib\10.0.22000.0\um\x64\kernel32.lib lld-link: Reading C:\Users\ydfb4q\BDM-2130\16.9.31910.168\Professional\VC\Tools\MSVC\14.28.29910\lib\x64\libvcruntime.lib lld-link: Reading C:\Program Files (x86)\Windows Kits\10\Lib\10.0.22000.0\ucrt\x64\libucrt.lib ``` Setting the `WindowsSdkDir` environment variable ``` set WindowsSdkDir=C:\Users\ydfb4q\BDM-2130\10.0.19041.0 ``` has no effect, it is still linking against the system Windows libs: [link_with_vs_installed-vcinstalldir-windowssdkdir.txt](https://github.com/user-attachments/files/19026124/link_with_vs_installed-vcinstalldir-windowssdkdir.txt) ``` lld-link: Reading C:\Program Files (x86)\Windows Kits\10\Lib\10.0.22000.0\um\x64\kernel32.lib lld-link: Reading C:\Users\ydfb4q\BDM-2130\16.9.31910.168\Professional\VC\Tools\MSVC\14.28.29910\lib\x64\libvcruntime.lib lld-link: Reading C:\Program Files (x86)\Windows Kits\10\Lib\10.0.22000.0\ucrt\x64\libucrt.lib ``` ### Workaround The only way we could find to get the desired behavior is to specify absolute paths to the Windows system libraries, adding ``` -lC:\Users\ydfb4q\BDM-2130\10.0.19041.0\lib\um\x64\kernel32.lib -lC:\Users\ydfb4q\BDM-2130\10.0.19041.0\lib\um\x64\uuid.lib -lC:\Users\ydfb4q\BDM-2130\10.0.19041.0\lib\ucrt\x64\libucrt.lib ``` to the command line: [link_with_vs_installed-vcinstalldir-windowssdkdir-explicitpath.txt](https://github.com/user-attachments/files/19026142/link_with_vs_installed-vcinstalldir-windowssdkdir-explicitpath.txt) ``` lld-link: Reading C:\Users\ydfb4q\BDM-2130\10.0.19041.0\lib\um\x64\kernel32.lib lld-link: Reading C:\Users\ydfb4q\BDM-2130\10.0.19041.0\lib\um\x64\uuid.lib lld-link: Reading C:\Users\ydfb4q\BDM-2130\10.0.19041.0\lib\ucrt\x64\libucrt.lib lld-link: Reading C:\Users\ydfb4q\BDM-2130\16.9.31910.168\Professional\VC\Tools\MSVC\14.28.29910\lib\x64\libcpmt.lib ``` While that works, it is not very robust, because we have to specify all libraries explicitly. If we were to change our source code to require more Windows libraries, there is always the risk of unintendedly pulling in system libraries. - Can we somehow get `-winsdkdir` to take precedence over any system-installed libraries? The same question applies to `-vctoolsdir`. Ideally, it would pick up only the libraries under the specified location without having to set `VCTOOLSDIR` additionally. _
[llvm-bugs] [Bug 129233] [clang] reference gets unnecessarily loaded twice
Issue
129233
Summary
[clang] reference gets unnecessarily loaded twice
Labels
clang
Assignees
Reporter
M-Kusumgar
test assembly: https://godbolt.org/z/TWdvPPGYs
```c++
#include
struct foo {
const uint64_t& x;
void f();
uint64_t g() {
uint64_t y = x;
f();
return y * x;
}
};
uint64_t h(foo* x) {
return x->g();
}
```
the reference to x gets loaded twice vs
expected assembly: https://godbolt.org/z/rW39W6h1e
```c++
#include
struct foo {
const uint64_t& x;
void f();
uint64_t g() {
auto& tmp = x;
uint64_t y = tmp;
f();
return y * tmp;
}
};
uint64_t h(foo* x) {
return x->g();
}
```
the reference to x gets loaded once. shouldn't the compiler be able to optimise the first code block into the assembly produced by the second code block?
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129236] [clang] Crash at -O2: Assertion Assertion `(BestFactor.Width == LegacyVF.Width || PlanForEarlyExitLoop...' failed.
Issue
129236
Summary
[clang] Crash at -O2: Assertion Assertion `(BestFactor.Width == LegacyVF.Width || PlanForEarlyExitLoop...' failed.
Labels
clang
Assignees
Reporter
cardigan1008
This code crashes at `-O2`:
```c
char a;
struct b {
short c;
char d;
long e;
int f;
} static g;
int h;
void i(struct b j) {
char k;
int l;
for (; j.d; --j.d) {
l = g.c == 0 ? 0 : 4294967295U % g.c;
k = l >= 2 || a >> l ? 0 : l;
h = k;
}
}
void m() { i(g); }
```
Compiler Explorer: https://godbolt.org/z/WG85qYnc6
Bisected to https://github.com/llvm/llvm-project/commit/30f3752e54fa7cd595a434a985efbe9a7abe9b65, which was committed by @fhahn
Crash:
```console
clang: /root/llvm-project/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:7589: llvm::VectorizationFactor llvm::LoopVectorizationPlanner::computeBestVF(): Assertion `(BestFactor.Width == LegacyVF.Width || PlanForEarlyExitLoop || planContainsAdditionalSimplifications(getPlanFor(BestFactor.Width), CostCtx, OrigLoop) || planContainsAdditionalSimplifications(getPlanFor(LegacyVF.Width), CostCtx, OrigLoop)) && " VPlan cost model and legacy cost model disagreed"' failed.
```
Backtrace:
```console
Stack dump:
0. Program arguments: /opt/compiler-explorer/clang-assertions-trunk/bin/clang -gdwarf-4 -g -o /app/output.s -mllvm --x86-asm-syntax=intel -fno-verbose-asm -S --gcc-toolchain=/opt/compiler-explorer/gcc-snapshot -fcolor-diagnostics -fno-crash-diagnostics -O2 -Wall -Wextra
1. parser at end of file
2. Optimizer
3. Running pass "function(float2int,lower-constant-intrinsics,loop(loop-rotate,loop-deletion),loop-distribute,inject-tli-mappings,loop-vectorize,infer-alignment,loop-load-elim,instcombine,simplifycfg,slp-vectorizer,vector-combine,instcombine,loop-unroll,transform-warning,sroa,infer-alignment,instcombine,loop-mssa(licm),alignment-from-assumptions,loop-sink,instsimplify,div-rem-pairs,tailcallelim,simplifycfg)" on module ""
4. Running pass "loop-vectorize" on function "i"
#0 0x03e76828 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x3e76828)
#1 0x03e744e4 llvm::sys::CleanupOnSignal(unsigned long) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x3e744e4)
#2 0x03dc0e18 CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0
#3 0x7e3b78e42520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#4 0x7e3b78e969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
#5 0x7e3b78e42476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
#6 0x7e3b78e287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
#7 0x7e3b78e2871b (/lib/x86_64-linux-gnu/libc.so.6+0x2871b)
#8 0x7e3b78e39e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96)
#9 0x059b6042 llvm::LoopVectorizationPlanner::computeBestVF() (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x59b6042)
#10 0x059cd46c llvm::LoopVectorizePass::processLoop(llvm::Loop*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x59cd46c)
#11 0x059cfb19 llvm::LoopVectorizePass::runImpl(llvm::Function&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x59cfb19)
#12 0x059d0193 llvm::LoopVectorizePass::run(llvm::Function&, llvm::AnalysisManager&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x59d0193)
#13 0x05546d4e llvm::detail::PassModel>::run(llvm::Function&, llvm::AnalysisManager&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x5546d4e)
#14 0x0381d3f0 llvm::PassManager>::run(llvm::Function&, llvm::AnalysisManager&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x381d3f0)
#15 0x0119ab8e llvm::detail::PassModel>, llvm::AnalysisManager>::run(llvm::Function&, llvm::AnalysisManager&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x119ab8e)
#16 0x0381bd0b llvm::ModuleToFunctionPassAdaptor::run(llvm::Module&, llvm::AnalysisManager&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x381bd0b)
#17 0x01199e3e llvm::detail::PassModel>::run(llvm::Module&, llvm::AnalysisManager&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x1199e3e)
#18 0x0381b710 llvm::PassManager>::run(llvm::Module&, llvm::AnalysisManager&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x381b710)
#19 0x041305e8 (anonymous namespace)::EmitAssemblyHelper::RunOptimizationPipeline(clang::BackendAction, std::unique_ptr>&, std::unique_ptr>&, clang::BackendConsumer*) BackendUtil.cpp:0:0
#20 0x0413485e clang::emitBackendOutput(clang::CompilerInstance&, clang::CodeGenOptions&, llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::IntrusiveRefCntPtr, std::unique_ptr>, clang::BackendConsumer*) (/opt/compiler-explorer/clang-assertions-trunk/bin/cla
[llvm-bugs] [Bug 129241] Clang unexpectedly crashing
Issue 129241 Summary Clang unexpectedly crashing Labels clang Assignees Reporter shvrma The project attempted to compile: [https://sources.shvrma.click/shvrma/lualike](url). Version of Clang: the latest one from the Arch Linux repo, *19.1.7-1*. It seems to be a frontend bug as determined by instructions in the Submitting Bug Report guide. Clang complains about inability to produce code for *std::__do_visit* for variant visitation. Latest g++ refuses to compile the code, complaining about an invalid template parameter, which in turn defines some method with such. Latest MSVC compiles the given code and it seems to run. As asked, additional files attached, but the problem seems reproducible at least across my PC's: [tmp.zip](https://github.com/user-attachments/files/19027959/tmp.zip). ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129246] Visibility of a global variable affects autovectorization
Issue
129246
Summary
Visibility of a global variable affects autovectorization
Labels
new issue
Assignees
Reporter
artem
```c++
#ifdef STT
static
#endif
int barx[8];
void inc() {
for (auto& foo : barx) {
foo += 1;
}
}
```
https://godbolt.org/z/sfPnGcW5a
`static int barx[8]` version simply unrolls 8 sequential increments, while int `int barx[8]` performs a SIMD operation.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129202] [MLIR][OpenMP] Translaton of `omp.target` is broken when `private` variables are cleaned up
Issue
129202
Summary
[MLIR][OpenMP] Translaton of `omp.target` is broken when `private` variables are cleaned up
Labels
mlir
Assignees
bhandarkar-pranav
Reporter
bhandarkar-pranav
```
$> cat reproducer.mlir
module attributes {omp.is_target_device = false, omp.requires = #omp, omp.target_triples = [], omp.version = #om\
p.version} {
llvm.func @free(!llvm.ptr)
llvm.func @malloc(i64) -> !llvm.ptr
omp.private {type = private} @_QFtarget_allocatableEnon_alloc_var_private_box_10xi32 : !llvm.struct<(ptr, i64, i32, i8, i8, i8, i8, \
array<1 x array<3 x i64>>)> init {
^bb0(%arg0: !llvm.ptr, %arg1: !llvm.ptr):
omp.yield(%arg1 : !llvm.ptr)
} dealloc {
^bb0(%arg0: !llvm.ptr):
llvm.br ^bb1
^bb1: // 2 preds: ^bb0, ^bb1
omp.yield
}
llvm.func @target_allocatable_(%arg0: !llvm.ptr {fir.bindc_name = "lb", llvm.nocapture}, %arg1: !llvm.ptr {fir.bindc_name = "ub", ll\
vm.nocapture}) attributes {fir.internal_name = "_QPtarget_allocatable"} {
%2 = llvm.mlir.constant(1 : i64) : i64
%5 = llvm.alloca %2 x !llvm.struct<(ptr, i64, i32, i8, i8, i8, i8, array<1 x array<3 x i64>>)> : (i64) -> !llvm.ptr
omp.target private(@_QFtarget_allocatableEnon_alloc_var_private_box_10xi32 %5 -> %arg2 : !llvm.ptr) {
omp.terminator
}
llvm.return
}
}
```
Command to reproduce the problem
```
mlir-translate -mlir-to-llvmir -allow-unregistered-dialect ./reproducer.mlir
Basic Block in function '__omp_offloading_10304_b734e3e_target_allocatable__l16' does not have terminator!
label %omp.region.cont1
```
This happens because after translating the `dealloc` regions of `omp.private` in the translation of `omp.target` we do not return the corret `InsertPoint`
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129227] [AArch64] Assertion "Invalid vector type!" with AdvSIMD intrinsics
Issue
129227
Summary
[AArch64] Assertion "Invalid vector type!" with AdvSIMD intrinsics
Labels
new issue
Assignees
Reporter
ostannard
This code using AdvSIMD intrinsics causes an assertion failure in the AArch64 backend:
```c
#include
uint8x8_t test_0() {
uint8x8_t v1 = vset_lane_u8(0xff, vdup_n_u8(0), 3);
uint8x8_t v72 = vrhadd_u8(v1, vdup_n_u8(0));
return vuzp1_u8(v72, vdup_n_u8(0));
}
```
```
$ /work/llvm/build/bin/clang --target=aarch64-linux-gnu -march=armv8-a -S test.c -O1 -mllvm -debug-_only_=dagcombine,isel
...
Legalized selection DAG: %bb.0 'test_0:entry'
SelectionDAG has 15 nodes:
t0: ch,glue = EntryToken
t27: v2i32 = AArch64ISD::MOVIshift Constant:i32<128>, Constant:i32<24>
t28: v8i8 = AArch64ISD::NVCAST t27
t29: f64 = AArch64ISD::NVCAST t28
t30: f64 = fneg t29
t31: v8i8 = AArch64ISD::NVCAST t30
t8: v8i8 = BUILD_VECTOR Constant:i32<0>, undef:i32, Constant:i32<0>, undef:i32, Constant:i32<0>, undef:i32, Constant:i32<0>, undef:i32
t18: v8i8 = AArch64ISD::UZP1 t31, t8
t11: ch,glue = CopyToReg t0, Register:v8i8 $d0, t18
t12: ch = AArch64ISD::RET_GLUE t11, Register:v8i8 $d0, t11:1
Combining: t31: v8i8 = AArch64ISD::NVCAST t30
Combining: t30: f64 = fneg t29
Combining: t29: f64 = AArch64ISD::NVCAST t28
... into: t32: f64 = AArch64ISD::NVCAST t27
Combining: t32: f64 = AArch64ISD::NVCAST t27
Combining: t30: f64 = fneg t32
Combining: t27: v2i32 = AArch64ISD::MOVIshift Constant:i32<128>, Constant:i32<24>
Combining: t26: i32 = Constant<24>
Combining: t24: i32 = Constant<128>
Combining: t18: v8i8 = AArch64ISD::UZP1 t31, t8
clang: /work/llvm/llvm-project/llvm/include/llvm/CodeGen/ValueTypes.h:346: llvm::ElementCount llvm::EVT::getVectorElementCount() const: Assertion `(isVector()) && "Invalid vector type!"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments: /work/llvm/build/bin/clang --target=aarch64-linux-gnu -march=armv8-a -S test.c -O1 -mllvm -debug-_only_=dagcombine,isel
1. parser at end of file
2. Code generation
3. Running pass 'Function Pass Manager' on module 'test.c'.
4. Running pass 'AArch64 Instruction Selection' on function '@test_0'
#0 0x561a2efed1b7 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/work/llvm/build/bin/clang+0x4f4e1b7)
#1 0x561a2efeadae llvm::sys::RunSignalHandlers() (/work/llvm/build/bin/clang+0x4f4bdae)
#2 0x561a2ef5aa28 CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0
#3 0x7f33b3e42520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#4 0x7f33b3e969fc __pthread_kill_implementation ./nptl/pthread_kill.c:44:76
#5 0x7f33b3e969fc __pthread_kill_internal ./nptl/pthread_kill.c:78:10
#6 0x7f33b3e969fc pthread_kill ./nptl/pthread_kill.c:89:10
#7 0x7f33b3e42476 gsignal ./signal/../sysdeps/posix/raise.c:27:6
#8 0x7f33b3e287f3 abort ./stdlib/abort.c:81:7
#9 0x7f33b3e2871b _nl_load_domain ./intl/loadmsgcat.c:1177:9
#10 0x7f33b3e39e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96)
#11 0x561a2dde43a2 isNVCastToHalfWidthElements(llvm::SDValue) AArch64ISelLowering.cpp:0:0
#12 0x561a2dda8ba1 llvm::AArch64TargetLowering::PerformDAGCombine(llvm::SDNode*, llvm::TargetLowering::DAGCombinerInfo&) const AArch64ISelLowering.cpp:0:0
#13 0x561a3022e8f8 (anonymous namespace)::DAGCombiner::combine(llvm::SDNode*) DAGCombiner.cpp:0:0
#14 0x561a3022cf52 llvm::SelectionDAG::Combine(llvm::CombineLevel, llvm::BatchAAResults*, llvm::CodeGenOptLevel) (/work/llvm/build/bin/clang+0x618df52)
#15 0x561a303f72b9 llvm::SelectionDAGISel::CodeGenAndEmitDAG() (/work/llvm/build/bin/clang+0x63582b9)
#16 0x561a303f525b llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) (/work/llvm/build/bin/clang+0x635625b)
#17 0x561a303f2211 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) (/work/llvm/build/bin/clang+0x6353211)
#18 0x561a303efa39 llvm::SelectionDAGISelLegacy::runOnMachineFunction(llvm::MachineFunction&) (/work/llvm/build/bin/clang+0x6350a39)
#19 0x561a2e49e538 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (/work/llvm/build/bin/clang+0x43ff538)
#20 0x561a2ea9a2bb llvm::FPPassManager::runOnFunction(llvm::Function&) (/work/llvm/build/bin/clang+0x49fb2bb)
#21 0x561a2eaa22c1 llvm::FPPassManager::runOnModule(llvm::Module&) (/work/llvm/build/bin/clang+0x4a032c1)
#22 0x561a2ea9accf llvm::legacy::PassManagerImpl::run(llvm::Module&) (/work/llvm/build/bin/clang+0x49fbccf)
#23 0x561a2f8adbdf clang::emitBackendOutput(clang::CompilerInstance&, clang::CodeGenOptions&, llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::IntrusiveRefCn
[llvm-bugs] [Bug 129201] [alias] will bring in correctness when 2 objects part overlap
Issue
129201
Summary
[alias] will bring in correctness when 2 objects part overlap
Labels
new issue
Assignees
Reporter
vfdff
* test: https://godbolt.org/z/Peb3G1zWx
```
typedef struct {
int a;
int b;
} S;
S g_info;
__attribute__((noinline))
int foo1(S * s)
{
int start = g_info.a;
s->b = 0;
int end = g_info.a;
return end - start;
}
```
* Now both gcc and clang think **s->b** will not alias to **g_info.a**, so start and end are same value, and return 0 derectlly.
But when &g_info and s are part overlap, **s->b** and **g_info.a** may be point to same address ?
- I already use -Wall to report all warning, but the **dangling pointer** is not identified by clang
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129254] [CMake] `llvm_add_library` does not preserve `SYSTEM` property for headers in `OBJECT` mode
Issue 129254 Summary [CMake] `llvm_add_library` does not preserve `SYSTEM` property for headers in `OBJECT` mode Labels new issue Assignees Reporter ingomueller-net If a `LINK_LIB` dependency is passed to `llvm_add_library` together with the `OBJECT` keyword (or with, both, the `STATIC` and `SHARED` keywords), then the include directories from that library use their `SYSTEM` marker. As a consequence, these directories will be linked to with `-I` instead of `-isystem`, such that warnings will be reported, making it impossible to use `-Werror` if there are any warnings. I, thus, think that the `SYSTEM` property should be preserved. I believe that this is due to some manual construction of dependencies and/or include directories for the `obj.XXX` target that is created in that case, which doesn't seem to preserve the `SYSTEM` property. I have tried a few ways to set that or related properties but failed and exhausted my CMake knowledge. https://github.com/ingomueller-net/llvm-project/tree/llvm-add-library-system-headers contains a reproducer that adds the `Protobuf` library to a new target `MLIREmitCDialect2`. If CMake is configure with XXX, we can see the following output (note the `-I` flag): ``` $ grep MLIREmitCDialect2 build/compile_commands.json | grep protobuf "command": "/usr/bin/clang++ ... -I/.../git/llvm-project/build-Debug/_deps/protobuf-src/src ... -o tools/mlir/lib/Dialect/EmitC/IR/CMakeFiles/obj.MLIREmitCDialect2.dir/EmitC.cpp.o -c .../git/llvm-project/mlir/lib/Dialect/EmitC/IR/EmitC.cpp" ``` If we remove the `OBJECT` keyword in the call to `llvm_add_library` as the comment indicates, then the library is included with `-isystem` instead of `-I`. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129361] [libc] Bad includes in `stdfix.h`
Issue 129361 Summary [libc] Bad includes in `stdfix.h` Labels libc Assignees Reporter lazyprop The generated `stdfix.h` tries to include the following headers which do not exist ``` #include "llvm-libc-types/int_hk_t.h" #include "llvm-libc-types/int_hr_t.h" #include "llvm-libc-types/int_k_t.h" #include "llvm-libc-types/int_lk_t.h" #include "llvm-libc-types/int_lr_t.h" #include "llvm-libc-types/int_r_t.h" #include "llvm-libc-types/uint_uhk_t.h" #include "llvm-libc-types/uint_uhr_t.h" #include "llvm-libc-types/uint_uk_t.h" #include "llvm-libc-types/uint_ulk_t.h" #include "llvm-libc-types/uint_ulr_t.h" #include "llvm-libc-types/uint_ur_t.h" ``` All these types are already defined in `llvm-libc-types/stdfix-types.h`. Manually commenting out all of the above fixes the error. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129326] [libc++] Optimize `std::search`
Issue 129326 Summary [libc++] Optimize `std::search` Labels libc++, performance Assignees Reporter ldionne It seems easy to use `std::find` to find the first matching element in `std::search`, and we might be able to use `std::mismatch` afterwards. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129364] [clang] i586-msdosdjgpp target support?
Issue 129364 Summary [clang] i586-msdosdjgpp target support? Labels clang Assignees Reporter trcrsired GCC supports i586-msdosdjgpp. Can we support it with clang too by adding a new target? It should be that hard right? ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129365] [C23] Compound literal with `constexpr` (or any other) storage specifier emits syntax error
Issue
129365
Summary
[C23] Compound literal with `constexpr` (or any other) storage specifier emits syntax error
Labels
new issue
Assignees
Reporter
euclidianAce
I couldn't find a specific issue on this, but it is part of C23. See `6.5.3.6p7` and `6.6.3p6`
Simple repro
```c
int main() {
int x = (constexpr int){1};
}
```
```
$ clang repro.c -std=c23 -Wall -Wextra -pedantic
repro.c:2:11: error: expected _expression_
2 | int x = (constexpr int){1};
| ^
1 error generated.
```
```
$ clang --version
clang version 19.1.7
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /nix/store/azdqrk7n19ipjh2yav5kllzll7a49phn-clang-19.1.7/bin
```
Looking through `clang/test/Sema/constexpr.c` this case wasn't covered
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
