[llvm-bugs] [Bug 135506] clang++ 21 crash
Issue
135506
Summary
clang++ 21 crash
Labels
clang
Assignees
Reporter
apache-hb
```
elliothb@ELLIOT-SERVER:~/github/bezos/build/packages/kernel$ /home/elliothb/github/bezos/install/llvm/bin/clang++ bug.cpp
In file included from /home/elliothb/github/bezos/sources/kernel/test/system/device.cpp:1:
In file included from /home/elliothb/github/bezos/sources/kernel/test/system/system_test.hpp:4:
In file included from ../../../sources/kernel/include/system/system.hpp:6:
In file included from ../../../sources/kernel/include/std/vector.hpp:5:
In file included from /home/elliothb/github/bezos/install/llvm-libcxx/include/c++/v1/memory:943:
In file included from /home/elliothb/github/bezos/install/llvm-libcxx/include/c++/v1/__memory/allocator.h:17:
In file included from /home/elliothb/github/bezos/install/llvm-libcxx/include/c++/v1/__memory/allocate_at_least.h:14:
In file included from /home/elliothb/github/bezos/install/llvm-libcxx/include/c++/v1/__memory/allocator_traits.h:17:
/home/elliothb/github/bezos/install/llvm-libcxx/include/c++/v1/__memory/pointer_traits.h:260:3: error: unknown type name 'requires'
260 | requires(__has_pointer<_Tp>::value)
| ^
/home/elliothb/github/bezos/install/llvm-libcxx/include/c++/v1/__memory/pointer_traits.h:260:32: error: no member named 'value' in '__has_pointer'
260 | requires(__has_pointer<_Tp>::value)
| ^
/home/elliothb/github/bezos/install/llvm-libcxx/include/c++/v1/__memory/pointer_traits.h:260:38: error: expected ';' after top level declarator
260 | requires(__has_pointer<_Tp>::value)
| ^
/home/elliothb/github/bezos/install/llvm-libcxx/include/c++/v1/__memory/pointer_traits.h:261:21: error: use of undeclared identifier '_Tp'
261 | struct __pointer_of<_Tp> {
| ^
/home/elliothb/github/bezos/install/llvm-libcxx/include/c++/v1/__memory/pointer_traits.h:266:3: error: a type specifier is required for all declarations
266 | requires(!__has_pointer<_Tp>::value && __has_element_type<_Tp>::value)
| ^
/home/elliothb/github/bezos/install/llvm-libcxx/include/c++/v1/__memory/pointer_traits.h:266:73: error: expected ';' after top level declarator
266 | requires(!__has_pointer<_Tp>::value && __has_element_type<_Tp>::value)
| ^
/home/elliothb/github/bezos/install/llvm-libcxx/include/c++/v1/__memory/pointer_traits.h:267:21: error: use of undeclared identifier '_Tp'
267 | struct __pointer_of<_Tp> {
| ^
/home/elliothb/github/bezos/install/llvm-libcxx/include/c++/v1/__memory/pointer_traits.h:272:3: error: a type specifier is required for all declarations
272 | requires(!__has_pointer<_Tp>::value && !__has_element_type<_Tp>::value &&
| ^
/home/elliothb/github/bezos/install/llvm-libcxx/include/c++/v1/__memory/pointer_traits.h:273:59: error: expected ';' after top level declarator
273 | __has_element_type>::value)
| ^
/home/elliothb/github/bezos/install/llvm-libcxx/include/c++/v1/__memory/pointer_traits.h:274:21: error: use of undeclared identifier '_Tp'
274 | struct __pointer_of<_Tp> {
| ^
/home/elliothb/github/bezos/install/llvm-libcxx/include/c++/v1/__memory/pointer_traits.h:287:3: error: unknown type name 'requires'
287 | requires requires { typename __pointer_of_t<_Tp>; }
| ^
/home/elliothb/github/bezos/install/llvm-libcxx/include/c++/v1/__memory/pointer_traits.h:287:32: error: expected a qualified name after 'typename'
287 | requires requires { typename __pointer_of_t<_Tp>; }
| ^
/home/elliothb/github/bezos/install/llvm-libcxx/include/c++/v1/__memory/pointer_traits.h:287:51: error: expected '(' for function-style cast or type construction
287 | requires requires { typename __pointer_of_t<_Tp>; }
| ~~~^
/home/elliothb/github/bezos/install/llvm-libcxx/include/c++/v1/__memory/pointer_traits.h:287:54: error: expected ';' after top level declarator
287 | requires requires { typename __pointer_of_t<_Tp>; }
| ^
/home/elliothb/github/bezos/install/llvm-libcxx/include/c++/v1/__memory/pointer_traits.h:288:24: error: use of undeclared identifier '_Tp'
288 | struct __pointer_of_or<_Tp, _Up> {
| ^
/home/elliothb/github/bezos/install/llvm-libcxx/include/c++/v1/__memory/pointer_traits.h:296:1: error: unknown type name 'concept'
296 | concept __resettable_smart_pointer = requires(_Smart __s) { __s.reset(); };
| ^
/home/elliothb/github/bezos/install/llvm-libcxx/include/c++/v1/__memory/pointer_traits.h:296:47: error: '_Smart' does not refer to a value
296 | concept __resettable_smart_pointer = requires(_Smart __s) { __s.reset(); };
| ^
/home/elliothb/github/bezos/install/llvm-libcxx/include/c++/v1/__memory/pointer_traits.h:295:17: note: declared here
295 | template
| ^
/home/elliothb/github/bezos/install/llvm-libcxx/include/c+
[llvm-bugs] [Bug 135508] [clang-tidy] Check request: bugprone-union-inactive-member-access
Issue
135508
Summary
[clang-tidy] Check request: bugprone-union-inactive-member-access
Labels
clang-tidy
Assignees
Reporter
denzor200
Needs a check that will find a reading of a union's field which was executed after another field has been written which remains active.
EXAMPLE:
```
union SimpleUnion {
int x;
double y;
};
void process() {
SimpleUnion u;
u.x = 10;
std::cout << "x = " << u.x << std::endl; // OK
u.y = 3.14;
std::cout << "y = " << u.x << std::endl; // BAD - looks like a typo, are you meaning `std::cout << "y = " << u.y`??
}
```
In the case when the union's trick used for obtaining a value of another type by reinterpreting the representation of an object, the check will suggest to use `std::memcpy` or even `std::bit_cast` if it's available. The efficiency would remain the same - compilers know how to optimize both of them.
BEFORE:
```
template
T perform_type_punning(std::ptrdiff_t offset)
{
union {
T memptr;
std::ptrdiff_t offset_;
};
offset_ = offset;
return memptr;
}
```
AFTER:
```
template
T perform_type_punning(std::ptrdiff_t offset)
{
T memptr;
std::memcpy(&memptr, &offset, sizeof(offset));
return memptr;
}
```
AFTER(C++20):
```
template
T perform_type_punning(std::ptrdiff_t offset)
{
return std::bit_cast(offset);
}
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 135486] [LLVM] APInt::tcAdd has quiet poor codegen.
Issue 135486 Summary [LLVM] APInt::tcAdd has quiet poor codegen. Labels new issue Assignees Reporter Ralender Here is an example of 1 iteration of the loop Compiled with clang trunk -O3 ```asm ; start of iteration 89: 4c 8b 14 cf movq (%rdi,%rcx,8), %r10 ; load dst[i] 8d: 4c 8b 0c ce movq (%rsi,%rcx,8), %r9 ; load rhs[i] 91: 48 85 d2 testq %rdx, %rdx ; test if we have a carry 94: 74 1a je 0xb0 <_ZN4llvm5APInt5tcAddEPmPKmmj+0xb0> 96: 4f 8d 4c 0a 01 leaq 0x1(%r10,%r9), %r9 ; add with a carry 9b: 4d 39 d1 cmpq %r10, %r9 9e: 41 0f 96 c2 setbe %r10b ; put carry of next iteration in r10b a2: eb 13 jmp 0xb7 <_ZN4llvm5APInt5tcAddEPmPKmmj+0xb7> b0: 4d 01 d1 addq %r10, %r9 ; add without carry b3: 41 0f 92 c2 setb %r10b ; put carry of next iteration in r10b b7: 4c 89 0c cf movq %r9, (%rdi,%rcx,8) ; write result back to memory ; next iteration unrolled bb: 4c 8b 4c cf 08 movq 0x8(%rdi,%rcx,8), %r9 c0: 48 8b 54 ce 08 movq 0x8(%rsi,%rcx,8), %rdx c5: 45 84 d2 testb %r10b, %r10b ; ... ``` Just as a reference here is What I think optimal x86-64 code looks like ``` ; start of iteration ; carry is in CF, 12a1: 4a 8b 4c ce f0 movq -0x10(%rsi,%r9,8), %rcx ; load rhs[i] 12a6: 4a 11 4c cf f0 adcq %rcx, -0x10(%rdi,%r9,8) ; lhs[i] = lhs[i] + rhs[i] + carry ; next iteration unrolled 12ab: 4a 8b 4c ce e8 movq -0x18(%rsi,%r9,8), %rcx 12b0: 4a 11 4c cf e8 adcq %rcx, -0x18(%rdi,%r9,8) ;... ``` Stuff that could be done better: - one side of the branch detects overflow with a cmp instead of CF - The branch doesn't get eliminated. - adc is not used. I made a benchmark to get an idea of how big the impact is. APInt::tcAdd : 1728.4 ns for 4096 iterations in average optimized code : 1045.6 ns for 4096 iterations in average ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 135496] crash
Issue 135496 Summary crash Labels new issue Assignees Reporter MacroModel see: https://github.com/MacroModel/uwvm2/tree/659415f92e64ec669580bd419c347d2f3d160487 https://github.com/MacroModel/uwvm2/actions/runs/14420900303/job/40443327096 https://github.com/MacroModel/uwvm2/actions/runs/14420900303/job/40443327102 ```bash Stack dump: 0. Program arguments: /usr/lib/llvm-20/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 execute_wasm.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 znver3 -target-feature +prfchw -target-feature -cldemote -target-feature +avx -target-feature +aes -target-feature +sahf -target-feature +pclmul -target-feature -xop -target-feature +crc32 -target-feature -amx-fp8 -target-feature +xsaves -target-feature -avx512fp16 -target-feature -usermsr -target-feature -sm4 -target-feature -egpr -target-feature +sse4.1 -target-feature -avx512ifma -target-feature +xsave -target-feature +sse4.2 -target-feature -tsxldtrk -target-feature -sm3 -target-feature -ptwrite -target-feature -widekl -target-feature -movrs -target-feature +invpcid -target-feature +64bit -target-feature +xsavec -target-feature -avx10.1-512 -target-feature -avx512vpopcntdq -target-feature +cmov -target-feature -avx512vp2intersect -target-feature -avx512cd -target-feature +movbe -target-feature -avxvnniint8 -target-feature -ccmp -target-feature -amx-int8 -target-feature -kl -target-feature -avx10.1-256 -target-feature -sha512 -target-feature -avxvnni -target-feature -rtm -target-feature +adx -target-feature +avx2 -target-feature -hreset -target-feature -movdiri -target-feature -serialize -target-feature +vpclmulqdq -target-feature -avx512vl -target-feature -uintr -target-feature -cf -target-feature +clflushopt -target-feature -raoint -target-feature -cmpccxadd -target-feature +bmi -target-feature -amx-tile -target-feature +sse -target-feature -avx10.2-256 -target-feature -gfni -target-feature -avxvnniint16 -target-feature -amx-fp16 -target-feature -zu -target-feature -ndd -target-feature +xsaveopt -target-feature +rdrnd -target-feature -avx512f -target-feature -amx-bf16 -target-feature -avx512bf16 -target-feature -avx512vnni -target-feature -push2pop2 -target-feature +cx8 -target-feature -avx512bw -target-feature +sse3 -target-feature -pku -target-feature -nf -target-feature -amx-tf32 -target-feature -amx-avx512 -target-feature +fsgsbase -target-feature +clzero -target-feature -mwaitx -target-feature -lwp -target-feature +lzcnt -target-feature +sha -target-feature -movdir64b -target-feature -ppx -target-feature -wbnoinvd -target-feature -enqcmd -target-feature -amx-transpose -target-feature -avx10.2-512 -target-feature -avxneconvert -target-feature -tbm -target-feature -pconfig -target-feature -amx-complex -target-feature +ssse3 -target-feature +cx16 -target-feature +bmi2 -target-feature +fma -target-feature +popcnt -target-feature -avxifma -target-feature +f16c -target-feature -avx512bitalg -target-feature +rdpru -target-feature +clwb -target-feature +mmx -target-feature +sse2 -target-feature +rdseed -target-feature -avx512vbmi2 -target-feature -prefetchi -target-feature -amx-movrs -target-feature +rdpid -target-feature -fma4 -target-feature -avx512vbmi -target-feature +shstk -target-feature +vaes -target-feature -waitpkg -target-feature -sgx -target-feature +fxsr -target-feature -avx512dq -target-feature +sse4a -debug-info-kind=constructor -dwarf-version=5 -debugger-tuning=gdb -fdebug-compilation-dir=/home/runner/work/uwvm2/uwvm2 -fcoverage-compilation-dir=/home/runner/work/uwvm2/uwvm2 -resource-dir /usr/lib/llvm-20/lib/clang/20 -O0 -Wall -Wextra -Werror -Wno-braced-scalar-init -std=c++26 -fdeprecated-macro -ferror-limit 19 -fno-rtti -fgnuc-version=4.2.1 -fno-implicit-modules -fmodule-file=fast_io=build/.gens/uwvm/linux/x86_64/debug/rules/bmi/cache/modules/63f7f4c9/fast_io.pcm -fmodule-file=parser.wasm.base=build/.gens/uwvm/linux/x86_64/debug/rules/bmi/cache/modules/63f7f4c9/parser.wasm.base.pcm -fmodule-file=parser.wasm.base:abi=build/.gens/uwvm/linux/x86_64/debug/rules/bmi/cache/modules/63f7f4c9/parser.wasm.base-abi.pcm -fmodule-file=parser.wasm.base:mode=build/.gens/uwvm/linux/x86_64/debug/rules/bmi/cache/modules/63f7f4c9/parser.wasm.base-mode.pcm -fmodule-file=parser.wasm.concepts=build/.gens/uwvm/linux/x86_64/debug/rules/bmi/cache/modules/63f7f4c9/parser.wasm.concepts.pcm -fmodule-file=parser.wasm.concepts:operation=build/.gens/uwvm/linux/x86_64/debug/rules/bmi/cache/modules/63f7f4c9/parser.wasm.concepts-operation.pcm -fmodule-file=parser.wasm.concepts:root=build/.gens/uwvm/linux
[llvm-bugs] [Bug 135481] [[deprecated]] attribute ignored after definition
Issue
135481
Summary
[[deprecated]] attribute ignored after definition
Labels
new issue
Assignees
Reporter
kimbarrett
If a function declaration is adding the `[[deprecated]]` attribute to an
already defined but not deprecated function, that attribute is ignored. It
generates a `-Wignored-attribute` warning if that's enabled. The attribute is
successfully added if there are only prior non-definition declarations of the
function. There's not an obvious (to me) reason to ignore the added attribute
after a definition. Redeclarations to add this attribute are permitted by the
standard. And whether there is or is not a prior definition may depend on a
multitude of factors.
Test case:
--
inline int frob(int x)
#ifdef DEFINE_BEFORE_DEPRECATE
{ return x; }
#else
;
#endif
[[deprecated]] int frob(int);
--
Compile without defining DEFINE_BEFORE_DEPRECATE => no warnings.
Compile with -DDEFINE_BEFORE_DEPRECATE =>
ignored-deprecation-after-definition.cpp:7:3: warning: attribute declaration must precede definition [-Wignored-attributes]
7 | [[deprecated]] int frob(int);
| ^
ignored-deprecation-after-definition.cpp:1:12: note: previous definition is here
1 | inline int frob(int x)
|^
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 135487] [aarch64][x86] llvm keep .rodata..L__const section
Issue
135487
Summary
[aarch64][x86] llvm keep .rodata..L__const section
Labels
new issue
Assignees
Reporter
guoxin049
https://godbolt.org/z/oTqx9jKzb
Option is: `-O2 -g0 -mgeneral-regs-only -fdata-sections -ffunction-sections`
```
void test(void)
{
char tmp_str2[20]="te";
__asm__ volatile ("":"+m"(tmp_str2)::);
}
```
AArch64 ASM:
```
test:
sub sp, sp, #0x20
mov x8, #0x6574 // #25972
str wzr, [sp, #24]
add x9, sp, #0x8
movk x8, #0x3030, lsl #16
movk x8, #0x3030, lsl #32
stp x8, xzr, [sp, #8]
add sp, sp, #0x20
ret
```
x86 ASM:
```
test:
movabs rax,0x303030306574
movQWORD PTR [rsp-0x18],rax
movDWORD PTR [rsp-0x8],0x0
movQWORD PTR [rsp-0x10],0x0
ret
```
Segment info:
```
***
[ 4] .rodata..L__const.test.tmp_str2 PROGBITS
***
```
AArch64 uses mov and movk for loading constants, whereas x86 generates movabs for the same purpose. Is the .rodata..L__const.test.tmp_str2 segment required, or can it be removed?
Similar issues：https://github.com/llvm/llvm-project/issues/133684
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 135521] [LoongArch] ADD/SUB and TLS relocation should move away from `FirstLiteralRelocationKind + offset`
Issue
135521
Summary
[LoongArch] ADD/SUB and TLS relocation should move away from `FirstLiteralRelocationKind + offset`
Labels
backend:loongarch
Assignees
Reporter
MaskRay
The current implementation of `R_LARCH_SUB{8,16,32,64}` and TLS relocation types relies on fixup kinds `FirstLiteralRelocationKind + offset` (originally intended for `.reloc` directives). While this is clever and prevents switch cases like
```c
case fixup_...sub8:
return ELF::R_LARCH_SUB8;
```
it needs revision.
GNU Assembler treats `.reloc` directives differently from standard relocations, notably by skipping
* Skipping STT_SECTION adjustments (when a referenced symbol is local and satisfies certain conditions, it can be redirected to a section symbol).
* Skipping STT_TLS symbol type setting for TLS relocations.
I intend to fix a `.reloc` behavior in ELFObjectWriter (https://github.com/llvm/llvm-project/pull/135519) and notice that `llvm/test/MC/LoongArch/Relocations/relax-addsub.s` (#76433) will be broken. @MQ-mengqing
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 135522] [Clang] Missing source location in diagnostic for invalid conversion in function w/ explicit object parameter
Issue
135522
Summary
[Clang] Missing source location in diagnostic for invalid conversion in function w/ explicit object parameter
Labels
clang:frontend,
regression:20
Assignees
Reporter
Sirraide
Consider (https://godbolt.org/z/aa475YbW6):
```c++
struct X{};
template
struct A {
auto Error(this auto&& This) -> T {
return T();
}
};
struct B : A {
bool f();
};
bool B::f() {
return Error();
}
```
Obviously, `X` isn’t convertible to `bool`, so we print an error, but the error is missing a source location:
```console
error: no viable conversion from returned value of type 'X' to function return type 'bool'
```
If I remove the explicit object parameter, we instead print
```console
:15:12: error: no viable conversion from returned value of type 'X' to function return type 'bool'
15 | return Error();
|^~~
```
This appears to be a regression since the source location *is* present in Clang 19.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
