[llvm-bugs] [Bug 137896] "'ownership_returns' attribute takes no more than 1 argument" is wrong
Issue 137896 Summary "'ownership_returns' attribute takes no more than 1 argument" is wrong Labels new issue Assignees Reporter halbi2 https://godbolt.org/z/nz8vMME7r ``` [[clang::ownership_returns()]] int *bad0(int); [[clang::ownership_returns(x)]] int *good1(int); [[clang::ownership_returns(x,1)]] int *good2(int); [[clang::ownership_returns(x,1,1)]] int *bad3(int); ``` Issues only two errors, on `bad0` and `bad3`. `good2` is accepted. But for `bad3` the error message is: ``` :4:3: error: 'ownership_returns' attribute takes no more than 1 argument 4 | [[clang::ownership_returns(x,1,1)]] int *bad3(int); | ^ ``` I think this is a bug. "1 argument" should be "2 arguments". ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 137892] [SPIR-V] Legalize the `llvm.is.fpclass` intrinsic
Issue 137892 Summary [SPIR-V] Legalize the `llvm.is.fpclass` intrinsic Labels Assignees Reporter Icohedron ## Description LLVM Language Reference: [`llvm.is.fpclass`](https://llvm.org/docs/LangRef.html#llvm-is-fpclass-intrinsic) The lowering of `llvm.is.fpclass` depends on the compile-time constant operand `i32 `. Valid bits for `` are defined in an enum named [FPClassTest](https://github.com/llvm/llvm-project/blob/dd2a1590c34d250b70de6d9a4a11b9a13aacb8ac/llvm/include/llvm/ADT/FloatingPointMode.h#L237-L265). The following FPClassTest cases are of interest: - `FPClassTest::fcInf`, `FPClassTest::fcNan`, `FPClassTest::fcFinite`, `FPClassTest::fcNormal` map directly to SPIR-V Ops The lowering of `llvm.is.fpclass` to both SPIR-V and [DirectX](https://github.com/llvm/llvm-project/issues/137209) will simplify the codegen for HLSL intrinsics [`isinf`](https://github.com/llvm/llvm-project/issues/70095), [`isnan`](https://github.com/llvm/llvm-project/issues/99132), and [`isfinite`](https://github.com/llvm/llvm-project/issues/99131) ### SPIRV Ops - `OpIsInf` - `OpIsNan` - `OpIsNormal` - `OpIsFinite` Note: The [SPIRV specification](https://registry.khronos.org/SPIR-V/specs/unified1/SPIRV.html) states that the results of these ops depends on the floating-point encoding used. However, there are currently no alternative floating-point encodings listed in the specification. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 137922] error GB5ECA9C8: Type set is empty for each HW mode in 'V_CMP_F_F32_e64'
Issue 137922 Summary error GB5ECA9C8: Type set is empty for each HW mode in 'V_CMP_F_F32_e64' Labels new issue Assignees Reporter SevenIsSeven 192>D:/my/imported/llpc/imported/llvm-project/llvm/lib/Target/AMDGPU\VOPCInstructions.td(404,7): error GB5ECA9C8: Type set is empty for each HW mode in 'V_CMP_F_F32_e64' 192> def _e64 : VOP3_Pseudo.ret, /*IsVOP3P*/false, P.HasOpSel>, 192> ^ 192>Included from D:/my/imported/llpc/imported/llvm-project/llvm/lib/Target/AMDGPU/AMDGPUGISel.td:13: 192>Included from D:/my/imported/llpc/imported/llvm-project/llvm/lib/Target/AMDGPU\AMDGPU.td:3204: 192>Included from D:/my/imported/llpc/imported/llvm-project/llvm/lib/Target/AMDGPU\SIInstrInfo.td:3859: 192>Included from D:/my/imported/llpc/imported/llvm-project/llvm/lib/Target/AMDGPU\SIInstructions.td:29: 192>Included from D:/my/imported/llpc/imported/llvm-project/llvm/lib/Target/AMDGPU\VOPInstructions.td:2482: 192>D:/my/imported/llpc/imported/llvm-project/llvm/lib/Target/AMDGPU\VOPCInstructions.td:630:20: note: instantiated from multiclass 192>defm V_CMP_F_F32 : VOPC_F32 <"v_cmp_f_f32">; 192> ^ 192>PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. 192>Stack dump: 192>0. Program arguments: ..\\..\\..\\NATIVE\\Release\\bin\\llvm-tblgen.exe -gen-global-isel -I D:/my/imported/llpc/imported/llvm-project/llvm/lib/Target/AMDGPU -ID:/my/my_build/imported/llvm/include -ID:/my/imported/llpc/imported/llvm-project/llvm/include -DLLPC_BUILD_NPI -I D:/my/imported/llpc/imported/llvm-project/llvm/lib/Target --long-string-literals=0 D:/my/imported/llpc/imported/llvm-project/llvm/lib/Target/AMDGPU/AMDGPUGISel.td -o D:/my/my_build/imported/llvm/lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc 192>The system cannot find the batch label specified - VCEnd 192>C:\Program Files\Microsoft Visual Studio\2022\Professional\MSBuild\Microsoft\VC\v170\Microsoft.CppCommon.targets(237,5): error MSB8066: Custom build for 'd:\my\my_build\CMakeFiles\fb4144b3a45a13daeee1d58b37aa986d\AMDGPUGenGlobalISel.inc.rule' exited with code 1. 192>Included from D:/my/imported/llpc/imported/llvm-project/llvm/lib/Target/AMDGPU/AMDGPU.td:3204: 192>Included from D:/my/imported/llpc/imported/llvm-project/llvm/lib/Target/AMDGPU\SIInstrInfo.td:3859: 192>Included from D:/my/imported/llpc/imported/llvm-project/llvm/lib/Target/AMDGPU\SIInstructions.td:29: 192>Included from D:/my/imported/llpc/imported/llvm-project/llvm/lib/Target/AMDGPU\VOPInstructions.td:2482: ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 137885] A parameter pack appears both empty and non-empty at the same time
Issue
137885
Summary
A parameter pack appears both empty and non-empty at the same time
Labels
new issue
Assignees
Reporter
HolyBlackCat
Found a really concerning bug:
```cpp
template
struct A {};
struct B
{
consteval B() {} // Making this constexpr makes the assert below pass.
template
consteval operator A() const
{
static_assert(sizeof...(P) > 0); // This fails on Clang.
return {};
}
};
template
struct type_identity
{
using type = T;
};
template
void foo(typename type_identity>::type a, P...) {}
int main()
{
foo(B(), 1, 2);
}
```
The `static_assert` fires on Clang, meaning it calls `operator A<>` with no template arguments! But the corresponding function parameter is `A`.
Apparently `A<>` gets reinterpreted (!!) into `A` at compile-time. E.g. if you add a `int x = sizeof...(P)` data member to it, it'll be `0` despite the type actually being `A`.
Here's an example of this being used to `reinterpret_cast` a `float` into an `int`: https://gcc.godbolt.org/z/Txbsj8ofM
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 137894] Missed autovectorization opportunity
Issue
137894
Summary
Missed autovectorization opportunity
Labels
Assignees
Reporter
MatzeB
Got a report of a simple loop that should autovectorize but does not do so on aarch64 (but does on x86 / AVX512). Repro:
```
#include
#include
void noAutovec(uint32_t* __restrict ip, float* __restrict src, float* __restrict dst, size_t n) {
// If you encourage the compile with the `#pragma` this does autovectorize.
// #pragma clang loop vectorize(enable)
for (size_t i=0; i
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 137912] [Optimization opportunity] Optimize repeated inline assembly operations when semantically equivalent
Issue
137912
Summary
[Optimization opportunity] Optimize repeated inline assembly operations when semantically equivalent
Labels
new issue
Assignees
Reporter
399833783
I would like to propose an **optimization enhancement** regarding inline assembly operations in C++, specifically for cases where multiple non-volatile `asm` statements perform similar or nearly identical operations.
### Issue description
Currently, when a function calls multiple other functions containing similar inline assembly operations (e.g., one retrieving the quotient and another retrieving the remainder from a division operation), Clang generates code that **repeats the same assembly instruction multiple times**, even though **a single execution could provide all needed results**.
### Reproduction case
64-bit version
# C++ code:
```cpp
#include
using U = uint64_t;
struct A { U quo; U rem; };
U myDiv(U const& a, U const& b)
{
U result, dummyDividendHigh;
asm (
"xor %[dividendHigh], %[dividendHigh] \n\t"
"divq %[divisor] \n\t"
: [quotient] "=a"(result), [dividendHigh] "=d" (dummyDividendHigh)
: [dividendLow] "a"(a), [divisor] "rm"(b)
);
return result;
}
U myMod(U const& a, U const& b)
{
U result;
asm (
"xor %[dividendHigh], %[dividendHigh] \n\t"
"divq %[divisor] \n\t"
: [dividendHigh] "=d" (result)
: [dividendLow] "a"(a), [divisor] "rm"(b)
);
return result;
}
A myDivMod1(U const& a, U const& b)
{
A result;
result.quo = myDiv(a, b);
result.rem = myMod(a, b);
return result;
}
A myDivMod2(U const& a, U const& b)
{
A result;
asm (
"xor %[dividendHighOrRemainder], %[dividendHighOrRemainder] \n\t"
"divq %[divisor] \n\t"
: [quotient] "=a"(result.quo), [dividendHighOrRemainder] "=d" (result.rem)
: [dividendLow] "a"(a), [divisor] "rm"(b)
);
return result;
}
```
# Generated assembly:
```asm
myDiv(unsigned long const&, unsigned long const&):
mov rax, qword ptr [rdi]
mov rcx, qword ptr [rsi]
mov qword ptr [rsp - 8], rcx
xor rdx, rdx
div qword ptr [rsp - 8]
ret
myMod(unsigned long const&, unsigned long const&):
mov rax, qword ptr [rdi]
mov rcx, qword ptr [rsi]
mov qword ptr [rsp - 8], rcx
xor rdx, rdx
div qword ptr [rsp - 8]
mov rax, rdx
ret
myDivMod1(unsigned long const&, unsigned long const&):
mov rcx, qword ptr [rdi]
mov rdi, qword ptr [rsi]
mov qword ptr [rsp - 8], rdi
mov rax, rcx
xor rdx, rdx
div qword ptr [rsp - 8]
mov rsi, rax
mov qword ptr [rsp - 16], rdi
mov rax, rcx
xor rdx, rdx
div qword ptr [rsp - 16]
mov rax, rsi
ret
myDivMod2(unsigned long const&, unsigned long const&):
mov rax, qword ptr [rdi]
mov rcx, qword ptr [rsi]
mov qword ptr [rsp - 8], rcx
xor rdx, rdx
div qword ptr [rsp - 8]
ret
```
# Godbolt link (64-bit version):
https://gcc.godbolt.org/z/rqfhxrGMf
32/16/8-bit version
# Godbolt link (32-bit version):
https://gcc.godbolt.org/z/MK6Y9rrd7
# Godbolt link (16-bit version):
https://gcc.godbolt.org/z/aMcqqWz14
# Godbolt link (8-bit version, **optimize correctly**):
https://gcc.godbolt.org/z/aoxPcWfxs
### Optimization suggestion
I suggest enhancing Clang to recognize situations where multiple non-volatile inline assembly blocks across function calls share identical or highly similar operations, and optimize them by merging the operations when semantically safe.
For the example above, the assembly code generated for `myDivMod1` should be no more complex than that of `myDivMod2` and contain no more than one `div` instruction.
### Theoretical basis
According to Clang's inline assembly documentation, **non-volatile `asm` statements can be reordered and optimized by the compiler**. In this case, both `myDiv` and `myMod` are essentially performing the same `div` operation but extracting different outputs (quotient vs. remainder). Since the x86 `div` instruction naturally produces both results simultaneously, executing it twice is redundant.
Another strong reason to support this optimization suggestion is that, in the case of `uint8_t`, Clang generates **identical code** for both `myDivMod1` and `myDivMod2`, which proves that Clang has effectively optimized the case in `myDivMod1`.
### Broader application
This optimization pattern would benefit not just this specific case but any scenario where:
- Multiple non-volatile inline assembly blocks across function calls contain similar operations.
- These operations could be merged without changing program semantics.
- The reuse of intermediate results would reduce instruction count.
Similar to function inlining optimizations, the compiler could analyze the
[llvm-bugs] [Bug 137891] Clang compiles `_Generic` expressions very slowly
Issue
137891
Summary
Clang compiles `_Generic` expressions very slowly
Labels
clang
Assignees
Reporter
JacksonAllan
Hello :)
Clang appears to compile C’s `_Generic` expressions far slower than other compilers. This I noticed because Clang takes [more than 3x longer](https://github.com/JacksonAllan/CC/issues/28) than GCC to compile the unit tests of my own library, which relies heavily on `_Generic`. These unit tests make more than 4,000 library API calls that together contain more than 35,000 `_Generic` expressions. Another library I maintain also makes ample – albeit not as extensive – use of `_Generic`, and it too compiles much more slowly with Clang than with GCC (see the previous link).
To demonstrate, I’ve created a [simple benchmark](https://github.com/JacksonAllan/_Generic_compile_speed_benchmark) that uses the preprocessor to generate 100,000 `_Generic` expressions, each supporting 24 types paired with empty functions:
```c
static void handle_unsigned_char( unsigned char x ){}
static void handle_signed_char( signed char x ){}
static void handle_unsigned_short( unsigned short x ){}
static void handle_short( short x ){}
static void handle_unsigned_int( unsigned int x ){}
static void handle_int( int x ){}
static void handle_unsigned_long( unsigned long x ){}
static void handle_long( long x ){}
static void handle_unsigned_long_long( unsigned long long x ){}
static void handle_long_long( long long x ){}
static void handle_float( float x ){}
static void handle_double( double x ){}
static void handle_unsigned_char_ptr( unsigned char *x ){}
static void handle_signed_char_ptr( signed char *x ){}
static void handle_unsigned_short_ptr( unsigned short *x ){}
static void handle_short_ptr( short *x ){}
static void handle_unsigned_int_ptr( unsigned int *x ){}
static void handle_int_ptr( int *x ){}
static void handle_unsigned_long_ptr( unsigned long *x ){}
static void handle_long_ptr( long *x ){}
static void handle_unsigned_long_long_ptr( unsigned long long *x ){}
static void handle_long_long_ptr( long long *x ){}
static void handle_float_ptr( float *x ){}
static void handle_double_ptr( double *x ){}
int main( void )
{
int foo = 0;
#define X \
(void)_Generic( foo, \
unsigned char: handle_unsigned_char, \
signed char: handle_signed_char, \
unsigned short: handle_unsigned_short, \
short: handle_short, \
unsigned int: handle_unsigned_int, \
int: handle_int, \
unsigned long: handle_unsigned_long, \
long: handle_long, \
unsigned long long: handle_unsigned_long_long, \
long long: handle_long_long, \
float: handle_float, \
double: handle_double, \
unsigned char *: handle_unsigned_char_ptr, \
signed char *: handle_signed_char_ptr, \
unsigned short *: handle_unsigned_short_ptr, \
short *: handle_short_ptr, \
unsigned int *: handle_unsigned_int_ptr, \
int *: handle_int_ptr, \
unsigned long *: handle_unsigned_long_ptr, \
long *: handle_long_ptr, \
unsigned long long *: handle_unsigned_long_long_ptr, \
long long *: handle_long_long_ptr, \
float *: handle_float_ptr, \
double *: handle_double_ptr \
)( foo ); \
#define X10 X X X X X X X X X X
#define X100 X10 X10 X10 X10 X10 X10 X10 X10 X10 X10
#define X1000 X100 X100 X100 X100 X100 X100 X100 X100 X100 X100
#define X1 X1000 X1000 X1000 X1000 X1000 X1000 X1000 X1000 X1000 X1000
#define X10 X1 X1 X1 X1 X1 X1 X1 X1 X1 X1
X10
}
```
Here are the results I get (best of five attempts) on Windows with an AMD Ryzen 7 5800H for MSVC 19.43.34810 and GCC 14.2.0 and Clang 19.1.7 via the [WinLibs](https://winlibs.com/) distribution of MinGW-w64:
As we can see, Clang is approximately 3x slower than GCC. The fact that the build time for Clang varies little between `-O1` and `-O3` suggests that the issue is not related to optimizations.
I get slightly better results on [Replit](https://replit.com/) (i.e. Linux), which provides older versions of Clang and GCC (17.0.6 and 13.2.0, respectively). In that case, Clang is only
[llvm-bugs] [Bug 137907] inherited constructor causes `source_locationI::current()` to point at wrong line
Issue
137907
Summary
inherited constructor causes `source_locationI::current()` to point at wrong line
Labels
new issue
Assignees
Reporter
snarkmaster
In this code (https://godbolt.org/z/dPhq718e5), `Foo foo{}` ends up with an incorrect `source_location`, while `Foo foo{Potato{}` is fine.
It looks like `using Bar::Bar` generates a default ctor for `Foo`, which becomes the evaluation site for `source_location::current()`.
I'm not a standards lawyer, but I didn't find any suggestion that what we're seeing here is the specified behavior. And for default arguments, the the clear intent of the C++ standard is for default arguments to be evaluated at the **call site**. The current behavior violates at least the spirit of that rule. It also breaks the typical `source_location`-stamping technique.
```
#include
#include
struct Potato {};
struct Bar {
std::source_location sl_;
explicit Bar(Potato = {}, std::source_location sl = std::source_location::current())
: sl_(sl) {}
};
struct Foo : Bar { // `foo.sl_` points here on GCC & clang
using Bar::Bar;
}; // `foo.sl_` points here on MSVC
int main() {
Foo foo{}; // Why isn't `sl_` pointing here?
std::cout << "foo @ line " << foo.sl_.line() << std::endl;
Foo foo2{Potato{}}; // But this is fine!
std::cout << "foo2 @ line " << foo2.sl_.line() << std::endl;
return 0;
}
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 137764] 32-bit registers store variables of unsigned char type without zero extension
Issue 137764 Summary 32-bit registers store variables of unsigned char type without zero extension Labels new issue Assignees Reporter zhaojiangkun-1 I found that the 32-bit register stores unsigned char type variables without zero extension in x86. However, in arm and gcc x86, there are zero extension instructions. In gcc x86, `movzx edi and dil `are used. In ARM, `and x8, x0, #0xff` are used to implement this function. Why does x86 not have zero extension instructions? Is this a bug? https://godbolt.org/z/4PWhnz7a5 ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 137802] [AArch64] cfi_negate_ra_state emitted incorrectly.
Issue 137802 Summary [AArch64] cfi_negate_ra_state emitted incorrectly. Labels backend:AArch64, regression:20 Assignees DanielKristofKiss Reporter DanielKristofKiss `.cfi_negate_ra_state` is emitted before the corresponding instruction which is incorrect. Debuggers or unwinders might not able to unwind the frames correctly. This is a regression on the 20.x release (19.x is not affected): #137800 revert on the mainline: #137795 ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 137797] Instruction does not dominate all uses! LLVM ERROR: Broken module found, compilation aborted!
Issue
137797
Summary
Instruction does not dominate all uses! LLVM ERROR: Broken module found, compilation aborted!
Labels
new issue
Assignees
Reporter
TatyanaDoubts
To reproduce run opt with the test below using -passes=slp-vectorizer -slp-threshold=-9:
```
; ModuleID = './reduced.ll'
source_filename = "./reduced.ll"
target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128-ni:1-p2:32:8:8:32-ni:2"
target triple = "x86_64-unknown-linux-gnu"
define void @wombat() #0 gc "statepoint-example" {
bb:
br i1 false, label %bb1, label %bb5
bb1: ; preds = %bb1, %bb
%phi = phi i32 [ %or4, %bb1 ], [ 0, %bb ]
%phi2 = phi i32 [ %add, %bb1 ], [ 0, %bb ]
%add = add i32 1, 0
%or = or i32 0, %phi2
%or3 = or i32 %or, 0
%mul = mul i32 0, 0
%or4 = or i32 %phi, %mul
br i1 false, label %bb1, label %bb5
bb5: ; preds = %bb1, %bb
%phi6 = phi i32 [ 0, %bb ], [ %or4, %bb1 ]
%phi7 = phi i32 [ 0, %bb ], [ %or, %bb1 ]
ret void
}
attributes #0 = { "target-features"="+prfchw,-cldemote,+avx,+aes,+sahf,+pclmul,-xop,+crc32,-amx-fp8,+xsaves,-avx512fp16,-usermsr,-sm4,-egpr,+sse4.1,-avx512ifma,+xsave,+sse4.2,-tsxldtrk,-sm3,-ptwrite,-widekl,-movrs,+invpcid,+64bit,+xsavec,-avx10.1-512,-avx512vpopcntdq,+cmov,-avx512vp2intersect,+avx512cd,+movbe,-avxvnniint8,-ccmp,-amx-int8,-kl,-avx10.1-256,+evex512,-avxvnni,+rtm,+adx,+avx2,-hreset,-movdiri,-serialize,-sha512,-vpclmulqdq,+avx512vl,-uintr,-cf,+clflushopt,-raoint,-cmpccxadd,+bmi,-amx-tile,+sse,-avx10.2-256,-gfni,-avxvnniint16,-amx-fp16,-zu,-ndd,+xsaveopt,+rdrnd,+avx512f,-amx-bf16,-avx512bf16,-avx512vnni,-push2pop2,+cx8,+avx512bw,+sse3,+pku,-nf,-amx-tf32,-amx-avx512,+fsgsbase,-clzero,-mwaitx,-lwp,+lzcnt,-sha,-movdir64b,-ppx,-wbnoinvd,-enqcmd,-amx-transpose,-avx10.2-512,-avxneconvert,-tbm,-pconfig,-amx-complex,+ssse3,+cx16,+bmi2,+fma,+popcnt,-avxifma,+f16c,-avx512bitalg,-rdpru,+clwb,+mmx,+sse2,+rdseed,-avx512vbmi2,-prefetchi,-amx-movrs,-rdpid,-fma4,-avx512vbmi,-shstk,-vaes,-waitpkg,-sgx,+fxsr,+avx512dq,-sse4a,-avx512f" }
```
Reproducer: https://godbolt.org/z/YbPKn761h
Stack dump:
```
0. Program arguments: /opt/compiler-explorer/clang-assertions-trunk/bin/opt -o /app/output.s -S -passes=slp-vectorizer -slp-threshold=-9
1. Running pass "verify" on module ""
#0 0x055242e8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x55242e8)
#1 0x05521c74 SignalHandler(int, siginfo_t*, void*) Signals.cpp:0:0
#2 0x73e542242520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#3 0x73e5422969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
#4 0x73e542242476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
#5 0x73e5422287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
#6 0x0080a091 llvm::json::operator==(llvm::json::Value const&, llvm::json::Value const&) (.cold) JSON.cpp:0:0
#7 0x054600e8 (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x54600e8)
#8 0x0535c8d8 (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x535c8d8)
#9 0x0093ee6e llvm::detail::PassModel>::run(llvm::Module&, llvm::AnalysisManager&) (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x93ee6e)
#10 0x0531b5a0 llvm::PassManager>::run(llvm::Module&, llvm::AnalysisManager&) (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x531b5a0)
#11 0x009492ba llvm::runPassPipeline(llvm::StringRef, llvm::Module&, llvm::TargetMachine*, llvm::TargetLibraryInfoImpl*, llvm::ToolOutputFile*, llvm::ToolOutputFile*, llvm::ToolOutputFile*, llvm::StringRef, llvm::ArrayRef, llvm::ArrayRef>, llvm::opt_tool::OutputKind, llvm::opt_tool::VerifierKind, bool, bool, bool, bool, bool, bool, bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x9492ba)
#12 0x0093ca8c optMain (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x93ca8c)
#13 0x73e542229d90 (/lib/x86_64-linux-gnu/libc.so.6+0x29d90)
#14 0x73e542229e40 __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x29e40)
#15 0x009346c5 _start (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x9346c5)
Program terminated with signal: SIGSEGV
Compiler returned: 139
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 137810] [MemCpyOpt or GVN] Load source from memcpy
Issue
137810
Summary
[MemCpyOpt or GVN] Load source from memcpy
Labels
llvm:optimizations,
missed-optimization
Assignees
dianqk
Reporter
dianqk
The following IR can be transformed from `load i24, ptr %dest` to `load i24, ptr %src` so that we can know `%arg` equals `%arg2`.
```llvm
define noundef i1 @wombat(ptr align 4 %src) {
bb:
%dest = alloca [3 x i8], align 4
%arg = load i24, ptr %src, align 4
call void @llvm.memcpy.p0.p0.i64(ptr noundef nonnull align 4 dereferenceable(3) %dest, ptr noundef nonnull align 4 dereferenceable(3) %src, i64 3, i1 false)
%arg2 = load i24, ptr %dest, align 4
%select = icmp eq i24 %arg, %arg2
call void @snork(ptr nonnull %dest)
ret i1 %select
}
declare void @snork(ptr)
declare void @llvm.memcpy.p0.p0.i64(ptr noalias writeonly captures(none), ptr noalias readonly captures(none), i64, i1 immarg)
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 137808] [SLP] -march=znver4 is slower than -march=znver3 on the znver4 series CPUs.
Issue
137808
Summary
[SLP] -march=znver4 is slower than -march=znver3 on the znver4 series CPUs.
Labels
llvm:SLPVectorizer
Assignees
Reporter
dianqk
I tested the following code using `-O3 -march=znver4` and `-O3 -march=znver3` on an AMD 7950X, the `-march=znver3` version is approximately 20% slower.
Details
```c
#include
#include
#define rotate_left(val, shift) ((val << shift) | (val >> (64 - shift)))
const uint32_t RHO[24] = {
1, 3, 6, 10, 15, 21, 28, 36, 45, 55, 2, 14,
27, 41, 56, 8, 25, 43, 62, 18, 39, 61, 20, 44,
};
const uint64_t PI[24] = {
10, 7, 11, 17, 18, 3, 5, 16, 8, 21, 24, 4,
15, 23, 19, 13, 12, 2, 20, 14, 22, 9, 6, 1,
};
const uint64_t RC[24] = {
0x0001ULL, 0x8082ULL, 0x8000808aULL,
0x800080008000ULL, 0x808bULL, 0x8001ULL,
0x800080008081ULL, 0x80008009ULL, 0x008aULL,
0x0088ULL, 0x80008009ULL, 0x800aULL,
0x8000808bULL, 0x808bULL, 0x80008089ULL,
0x80008003ULL, 0x80008002ULL, 0x8080ULL,
0x800aULL, 0x8000800aULL, 0x800080008081ULL,
0x80008080ULL, 0x8001ULL, 0x800080008008ULL,
};
void keccak_p(uint64_t state[25]) {
for (int i = 0; i < 24; ++i) {
uint64_t current_rc = RC[i];
uint64_t array[5] = {0};
// Theta
for (int x = 0; x < 5; ++x) {
for (int y = 0; y < 5; ++y) {
array[x] ^= state[5 * y + x];
}
}
for (int x = 0; x < 5; ++x) {
uint64_t t1 = array[(x + 4) % 5];
uint64_t t2 = rotate_left(array[(x + 1) % 5], 1);
for (int y = 0; y < 5; ++y) {
state[5 * y + x] ^= t1 ^ t2;
}
}
// Rho and pi
uint64_t last = state[1];
for (int x = 0; x < 24; ++x) {
array[0] = state[PI[x]];
state[PI[x]] = rotate_left(last, RHO[x]);
last = array[0];
}
// Chi
for (int y_step = 0; y_step < 5; ++y_step) {
int y = 5 * y_step;
for (int x = 0; x < 5; ++x) {
array[x] = state[y + x];
}
for (int x = 0; x < 5; ++x) {
uint64_t t1 = ~array[(x + 1) % 5];
uint64_t t2 = array[(x + 2) % 5];
state[y + x] = array[x] ^ (t1 & t2);
}
}
// Iota
state[0] ^= current_rc;
}
}
int main() {
uint64_t state[25] = {0};
for (int i = 0; i < 100; ++i) {
keccak_p(state);
}
return 0;
}
```
```
$ perf stat -r 5 ./znver3
Performance counter stats for './znver3' (5 runs):
408.52 msec task-clock:u #0.999 CPUs utilized ( +- 0.36% )
0 context-switches:u #0.000 /sec
0 cpu-migrations:u #0.000 /sec
49 page-faults:u# 119.946 /sec( +- 0.41% )
5,107,180,232 instructions:u #2.21 insn per cycle
#0.00 stalled cycles per insn ( +- 0.00% )
2,310,598,646 cycles:u #5.656 GHz ( +- 0.36% )
481,736 stalled-cycles-frontend:u#0.02% frontend cycles idle( +- 2.01% )
27,039,388 branches:u # 66.189 M/sec ( +- 0.00% )
5,051 branch-misses:u #0.02% of all branches ( +- 0.59% )
0.40895 +- 0.00147 seconds time elapsed ( +- 0.36% )
$ perf stat -r 5 ./znver4
Performance counter stats for './znver4' (5 runs):
576.39 msec task-clock:u # 0.999 CPUs utilized ( +- 0.20% )
0 context-switches:u #0.000 /sec
0 cpu-migrations:u #0.000 /sec
50 page-faults:u# 86.747 /sec( +- 0.89% )
4,062,180,550 instructions:u #1.25 insn per cycle
#0.00 stalled cycles per insn ( +- 0.00% )
3,261,654,058 cycles:u #5.659 GHz ( +- 0.20% )
630,199 stalled-cycles-frontend:u#0.02% frontend cycles idle( +- 0.44% )
27,039,720 branches:u # 46.912 M/sec ( +- 0.00% )
5,970 branch-misses:u #0.02% of all branches ( +- 0.36% )
0.57676 +- 0.00113 seconds time elapsed ( +- 0.20% )
```
cc @RKSimon @alexey-bataev (as it relates to AMD and SLP)
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/
[llvm-bugs] [Bug 137792] Add option to set default header language
Issue 137792 Summary Add option to set default header language Labels new issue Assignees Reporter oncipriani When `.clang-format` includes the setting `Language: C`, `clang-format` do not format header files (.h) and displays the message `Configuration file(s) do(es) not support C++`. Adding `// clang-format Language: C` to the beginning of the header files solves the problem and the headers are formatted as expected, but this should be considered a workaround. There should be an option for telling `clang-format` to treat all header files as C in order to prevent having to add the comment to all header files. In addition, the default language for header files should match the language set in the `.clang-format` file. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 137762] Clang 20.1.3 UBSAN link on Windows fails on LLVM version update
Issue 137762 Summary Clang 20.1.3 UBSAN link on Windows fails on LLVM version update Labels clang Assignees Reporter MisterBMisterB Dear all, first of all, I appreciate your great work in the LLVM project. I'm using LLVM 19.1.2 for compiling C code on Windows. I created successfully debug, release, coverage, ASAN and UBSAN builds. Everything went fine. When I upgrade to LLVM clang 20.1.3 the targets debug, release, coverage, ASAN build OK. When I try to build the UBSAN target I get the following link error:  If I copy the LLVM 19.1.2 clang_rt.ubsan_standalone-x86_64.lib library to LLVM 20.1.3 installation everything build and run OK again. Linking against a newer Windows SDK version also does not help. What do I wrong? Has there anything changed inside the build philosophy for UBSAN? Has there anything accidential changed in clang_rt.ubsan_standalone-x86_64.lib? Best regards Michael ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 137776] [flang] incorrect iostat for failed list-separated read into real
Issue 137776 Summary [flang] incorrect iostat for failed list-separated read into real Labels flang Assignees Reporter Inker2401 There appears to be some (possibly) non-standard conforming behaviour concerning the reading of an internal file (string) containing `..` into a real variable. Consider the following program: ``` program flang_read_dots implicit none character(len=2) :: str real :: x complex :: z integer :: n, ierr str='..' ! With status checks read(str,*,iostat=ierr) x ! ierr=0 (success) and then x is read as 0.0 (non-standard behaviour) print *, 'Read real number ierr, val =', ierr, x read(str,*,iostat=ierr) n ! ierr is non-zero as expected as cannot read to integer print *, 'Read integer number ierr, val =', ierr, n read(str,*,iostat=ierr) z ! ierr is non-zero as expected as cannot read to complex print *, 'Read complex number ierr, val=', ierr, z ! Without status checks read(str,*) x ! read succeeds (incorrectly!) print *, 'Read real number (no stat check) val =', x read(str,*) n ! read does not succeed, runtime error raised print *, 'Read integer number (no stat check) val =', n read(str,*) z ! read does not succeed, runtime warning print *, 'Read complex number (no stat check) val =', z end program flang_read_dots ``` The `str` containing `..` when read into `x` gives `0.0` with `iostat=0` for success (likewise, `iostat` is omitted, no runtime error is raised). This appears to be possibly non-standard conforming behaviour, as various other compilers such as ifort, Cray Fortran and gfortran all raise a runtime error (and will also return non-zero `iostat` codes). I suspect it has to do with the interpretation decimal point as if `str` is initialised to `hi`, then a non-zero `iostat` value is returned as expected. Similarly, if the `decimal="comma"` argument is passed into the `read` statement, a non-zero value for `iostat` is also returned. Compiler explorer link: [https://godbolt.org/z/9doTaGqKT](https://godbolt.org/z/9doTaGqKT) ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 137768] [Control Flow Optimizer] Bad machine code: Using an undefined physical register
Issue 137768 Summary [Control Flow Optimizer] Bad machine code: Using an undefined physical register Labels llvm:codegen Assignees Reporter JonPsson1 At first glance, I see: ``` bb.1 (%ir-block.1): ; predecessors: %bb.0 successors: %bb.3(0x8000); %bb.3(100.00%) ... renamable $r0l = LOCHIMux killed renamable $r0l(tied-def 0), 1, 14, 4, implicit killed $cc renamable $r2d = LARL @d STCMux renamable $r0l, killed renamable $r2d, 0, $noreg :: (store (s8) into @d, align 2) STMux killed renamable $r0l, killed renamable $r1d, 0, $noreg :: (volatile store (s32) into %ir.2) J %bb.3 bb.2 (%ir-block.7): ; predecessors: %bb.0 successors: %bb.3(0x8000); %bb.3(100.00%) renamable $r0l = LHIMux 0 renamable $r0l = LOCHIMux killed renamable $r0l(tied-def 0), 1, 14, 4, implicit killed $cc renamable $r2d = LARL @b STCMux killed renamable $r0l, killed renamable $r2d, 0, $noreg :: (store (s8) into @b, align 2) STMux undef renamable $r0l, killed renamable $r1d, 0, $noreg :: (volatile store (s32) into %ir.8) ``` => ``` # *** IR Dump After Control Flow Optimizer (branch-folder) ***: ... bb.3 (%ir-block.12): ; predecessors: %bb.2, %bb.1 liveins: $r0l, $r1d, $r2d STCMux killed renamable $r0l, killed renamable $r2d, 0, $noreg :: (store (s8) into @b, align 2), (store (s8) into @d, align 2) STMux renamable $r0l, killed renamable $r1d, 0, $noreg :: (volatile store (s32) into %ir.8), (volatile store (s32) into %ir.2) Return ``` ``` *** Bad machine code: Using an undefined physical register *** - function:n - basic block: %bb.3 (0x2aa047384c8) - instruction: STMux renamable $r0l, killed renamable $r1d, 0, $noreg :: (volatile store (s32) into %ir.8), (volatile store (s32) into %ir.2) - operand 0: renamable $r0l LLVM ERROR: Found 1 machine code errors. ``` Somehow the kill and undef flags have been combined into an illegal sequence where $r0l is used after a kill. @arsenm Once again, the maintaining of kill flags are coming back... @dominik-steenken This is the reduced test case, so not sure if the storing of undef is a bug, but probably not. Attaching also the original .i file and the reduced .i file. ``` clang -O3 -march=z15 crash10.orig.i -o a.out -w -mllvm -enable-unswitch-cost-multiplier=false -mllvm -sink-common-insts -mllvm -aggressive-machine-cse -mllvm -verify-misched llc -mcpu=z15 -O3 -verify-machineinstrs tc_crash10_aftercreduce.ll ``` [crash10.tar.gz](https://github.com/user-attachments/files/19955295/crash10.tar.gz) ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 137770] Wrong indentation on explicit operator calls
Issue
137770
Summary
Wrong indentation on explicit operator calls
Labels
clang-format,
regression
Assignees
Reporter
kadircet
> Starting with https://github.com/llvm/llvm-project/pull/136073, we now get the formatting of:
> ```cpp
> auto foo() {
> return s.
> operator int*();
> }
> ```
>
> emphasis on the missing indentation before `operator`.
_Originally posted by @kadircet in [#135972](https://github.com/llvm/llvm-project/issues/135972#issuecomment-2834911858)_
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 137779] [lld] LLD Linker Deadlock
Issue 137779 Summary [lld] LLD Linker Deadlock Labels lld Assignees Reporter zhangtianhao6 The link is suspended when the CMake testCCompiler is tested. The call stack is as follows: ``` (gdb) bt #0 0x7fe103fb6376 in pthread_cond_wait@@GLIBC_2.3.2 () from target:/lib/x86_64-linux-gnu/libpthread.so.0 #1 0x7fe103c3fe30 in std::condition_variable::wait(std::unique_lock&) () from target:/lib/x86_64-linux-gnu/libstdc++.so.6 #2 0x558a6bc003fb in llvm::parallelFor(unsigned long, unsigned long, llvm::function_ref) () #3 0x558a69dc70f8 in void lld::elf::OutputSection::writeTo >(unsigned char*) () #4 0x558a69e64216 in void lld::elf::writeResult >() () #5 0x558a69d32e2c in lld::elf::LinkerDriver::link(llvm::opt::InputArgList&) () #6 0x558a69d1fd93 in lld::elf::LinkerDriver::linkerMain(llvm::ArrayRef) () #7 0x558a69d1e614 in lld::elf::link(llvm::ArrayRef, llvm::raw_ostream&, llvm::raw_ostream&, bool, bool) () #8 0x558a69bb4b9c in ?? () #9 0x558a69bb4270 in main () ``` link option ``` ld.lld --sysroot=/xx/bin/../sysroot -pie -EL -z relro --hash-style=gnu --eh-frame-hdr -m aarch64linux -dynamic-linker /lib/ld-linux-aarch64.so.1 -o cmTC_26a76 /xx/bin/../sysroot/usr/lib/../lib64/Scrt1.o /xx/bin/../sysroot/usr/lib/../lib64/crti.o /xx/lib64/clang/15.0.4/lib/linux/clang_rt.crtbegin-aarch64.o -L/xx/bin/../sysroot/usr/lib/../lib64 -L/xx/bin/../sysroot/usr/lib CMakeFiles/cmTC_26a76.dir/testCCompiler.c.o /xx/common/lib64/clang/15.0.4/lib/linux/libclang_rt.builtins-aarch64.a -lc /xx/lib64/clang/15.0.4/lib/linux/libclang_rt.builtins-aarch64.a /xx/lib64/clang/15.0.4/lib/linux/clang_rt.crtend-aarch64.o /xx/bin/../sysroot/usr/lib/../lib64/crtn.o ``` What kind of scenarios will cause the linker to freeze? ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 137780] [Bug] Clang 17 crashes when default argument refers to another parameter in template class
Issue
137780
Summary
[Bug] Clang 17 crashes when default argument refers to another parameter in template class
Labels
clang
Assignees
Reporter
mariete1223
## Description
Clang 17.0.6 from LLMV suite sometimes crashes when compiling a C++23 program where a class template constructor defines a default argument that refers to a previous parameter (specifically: T* ptr = new T(), T* p_ptr = ptr).
The crash is non-deterministic: sometimes compilation fails gracefully with an error message (default argument references parameter 'ptr'), but other times Clang segfaults deeply inside ASTContext::getTypeInfoImpl.
This behavior occurs even when the program contains no undefined behavior at runtime.
## Command executed
```
clang-17 -x c++ -std=c++23 test.cpp
```
## Crash Backtrace
```
Stack dump:
0. Program arguments: /usr/lib/llvm-17/bin/clang -cc1 -triple x86_64-pc-linux-gnu -emit-obj -mrelax-all -dumpdir a- -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name prueba.cpp -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 -debugger-tuning=gdb -fcoverage-compilation-dir=/root -resource-dir /usr/lib/llvm-17/lib/clang/17 -internal-isystem /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9 -internal-isystem /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/x86_64-linux-gnu/c++/9 -internal-isystem /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/backward -internal-isystem /usr/lib/llvm-17/lib/clang/17/include -internal-isystem /usr/local/include -internal-isystem /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../x86_64-linux-gnu/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -std=c++23 -fdeprecated-macro -fdebug-compilation-dir=/root -ferror-limit 19 -fgnuc-version=4.2.1 -fno-implicit-modules -fcxx-exceptions -fexceptions -fcolor-diagnostics -faddrsig -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o /tmp/prueba-bf8357.o -x c++ prueba.cpp
1. prueba.cpp:19:40: current parser token ','
2. prueba.cpp:18:1: parsing function body 'main'
3. prueba.cpp:18:1: in compound statement ('{}')
#0 0x7f6c291e2ce6 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/usr/lib/llvm-17/bin/../lib/libLLVM-17.so.1+0xccbce6)
#1 0x7f6c291e0e80 llvm::sys::RunSignalHandlers() (/usr/lib/llvm-17/bin/../lib/libLLVM-17.so.1+0xcc9e80)
#2 0x7f6c291e3380 (/usr/lib/llvm-17/bin/../lib/libLLVM-17.so.1+0xccc380)
#3 0x7f6c33793420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420)
#4 0x7f6c306b770c clang::ASTContext::getTypeInfoImpl(clang::Type const*) const (/usr/lib/llvm-17/bin/../lib/libclang-cpp.so.17+0xb2570c)
#5 0x7f6c306b8a70 clang::ASTContext::getTypeInfo(clang::Type const*) const (/usr/lib/llvm-17/bin/../lib/libclang-cpp.so.17+0xb26a70)
#6 0x7f6c306b7c36 clang::ASTContext::getTypeInfoImpl(clang::Type const*) const (/usr/lib/llvm-17/bin/../lib/libclang-cpp.so.17+0xb25c36)
#7 0x7f6c306b8a70 clang::ASTContext::getTypeInfo(clang::Type const*) const (/usr/lib/llvm-17/bin/../lib/libclang-cpp.so.17+0xb26a70)
#8 0x7f6c306b9143 clang::ASTContext::getTypeAlignInChars(clang::QualType) const (/usr/lib/llvm-17/bin/../lib/libclang-cpp.so.17+0xb27143)
#9 0x7f6c30e2d955 clang::Sema::CheckArgAlignment(clang::SourceLocation, clang::NamedDecl*, llvm::StringRef, clang::QualType, clang::QualType) (/usr/lib/llvm-17/bin/../lib/libclang-cpp.so.17+0x129b955)
#10 0x7f6c30e2e79e clang::Sema::checkCall(clang::NamedDecl*, clang::FunctionProtoType const*, clang::Expr const*, llvm::ArrayRef, bool, clang::SourceLocation, clang::SourceRange, clang::Sema::VariadicCallType) (/usr/lib/llvm-17/bin/../lib/libclang-cpp.so.17+0x129c79e)
#11 0x7f6c30e2f5d5 clang::Sema::CheckConstructorCall(clang::FunctionDecl*, clang::QualType, llvm::ArrayRef, clang::FunctionProtoType const*, clang::SourceLocation) (/usr/lib/llvm-17/bin/../lib/libclang-cpp.so.17+0x129d5d5)
#12 0x7f6c30fd7ac4 clang::Sema::CompleteConstructorCall(clang::CXXConstructorDecl*, clang::QualType, llvm::MutableArrayRef, clang::SourceLocation, llvm::SmallVectorImpl&, bool, bool) (/usr/lib/llvm-17/bin/../lib/libclang-cpp.so.17+0x1445ac4)
#13 0x7f6c3122fd5e (/usr/lib/llvm-17/bin/../lib/libclang-cpp.so.17+0x169dd5e)
#14 0x7f6c3122b93d clang::InitializationSequence::Perform(clang::Sema&, clang::InitializedEntity const&, clang::InitializationKind const&, llvm::MutableArrayRef, clang::QualType*) (/usr/lib/llvm-17/bin/../lib/libclang-cpp.so.17+0x169993d)
#15 0x7f6c31186152 clang::Sema::BuildCXXNew(clang::SourceRange, b
[llvm-bugs] [Bug 137867] Clang 21 crash (Stack dump) when using _Atomic(struct) field access incorrectly in C code
Issue
137867
Summary
Clang 21 crash (Stack dump) when using _Atomic(struct) field access incorrectly in C code
Labels
clang
Assignees
Reporter
mariete1223
## Summary:
Clang 21 crashes with a segmentation fault (SIGSEGV) when compiling C code that uses _Atomic(struct) and tries to load and dereference a member incorrectly.
Instead of reporting a clean error about invalid atomic access, the compiler crashes during semantic analysis (Sema::RefersToMemberWithReducedAlignment).
## Stack dump
```
Stack dump:
0. Program arguments: /usr/local/bin/clang-21 -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -dumpdir a- -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name prueba.cpp -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=/root -fcoverage-compilation-dir=/root -resource-dir /usr/local/lib/clang/21 -internal-isystem /usr/local/lib/clang/21/include -internal-isystem /usr/local/include -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/9/../../../../x86_64-linux-gnu/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -O3 -std=c2x -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/prueba-4c1619.o -x c prueba.cpp
1. prueba.cpp:12:38: current parser token ')'
2. prueba.cpp:10:1: parsing function body 'main'
3. prueba.cpp:10:1: in compound statement ('{}')
^[[A #0 0x56358be8a18f llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/usr/local/bin/clang-21+0x3c4a18f)
#1 0x56358be87bd4 SignalHandler(int, siginfo_t*, void*) Signals.cpp:0:0
#2 0x7f65c50ae420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420)
#3 0x56358f68488b getInterestingTagDecl(clang::TagDecl*) Type.cpp:0:0
#4 0x56358e2ffb2b clang::Sema::RefersToMemberWithReducedAlignment(clang::Expr*, llvm::function_ref) (/usr/local/bin/clang-21+0x60bfb2b)
#5 0x56358e300180 clang::Sema::CheckAddressOfPackedMember(clang::Expr*) (/usr/local/bin/clang-21+0x60c0180)
#6 0x56358e5cd823 clang::Sema::CheckAddressOfOperand(clang::ActionResult&, clang::SourceLocation) (/usr/local/bin/clang-21+0x638d823)
#7 0x56358e5f1710 clang::Sema::CreateBuiltinUnaryOp(clang::SourceLocation, clang::UnaryOperatorKind, clang::Expr*, bool) (/usr/local/bin/clang-21+0x63b1710)
#8 0x56358e5f1f85 clang::Sema::BuildUnaryOp(clang::Scope*, clang::SourceLocation, clang::UnaryOperatorKind, clang::Expr*, bool) (/usr/local/bin/clang-21+0x63b1f85)
#9 0x56358e6fdb15 clang::TreeTransform (clang::Expr*)>)::TyposReplace>::TransformInitializer(clang::Expr*, bool) SemaExprCXX.cpp:0:0
#10 0x56358e6fd892 clang::TreeTransform (clang::Expr*)>)::TyposReplace>::TransformExprs(clang::Expr* const*, unsigned int, bool, llvm::SmallVectorImpl&, bool*) SemaExprCXX.cpp:0:0
#11 0x56358e7047e1 clang::TreeTransform (clang::Expr*)>)::TyposReplace>::TransformCallExpr(clang::CallExpr*) SemaExprCXX.cpp:0:0
#12 0x56358e715f64 clang::TreeTransform (clang::Expr*)>)::TyposReplace>::TransformCXXDependentScopeMemberExpr(clang::CXXDependentScopeMemberExpr*) SemaExprCXX.cpp:0:0
#13 0x56358e71b813 clang::TreeTransform (clang::Expr*)>)::TyposReplace>::TransformUnaryOperator(clang::UnaryOperator*) SemaExprCXX.cpp:0:0
#14 0x56358e6cd20d clang::Sema::CorrectDelayedTyposInExpr(clang::Expr*, clang::VarDecl*, bool, llvm::function_ref (clang::Expr*)>) (/usr/local/bin/clang-21+0x648d20d)
#15 0x56358e6ce45d clang::Sema::ActOnFinishFullExpr(clang::Expr*, clang::SourceLocation, bool, bool, bool) (/usr/local/bin/clang-21+0x648e45d)
#16 0x56358e5e23b5 clang::Sema::ActOnCondition(clang::Scope*, clang::SourceLocation, clang::Expr*, clang::Sema::ConditionKind, bool) (/usr/local/bin/clang-21+0x63a23b5)
#17 0x56358e1afef0 clang::Parser::ParseParenExprOrCondition(clang::ActionResult*, clang::Sema::ConditionResult&, clang::SourceLocation, clang::Sema::ConditionKind, clang::SourceLocation&, clang::SourceLocation&) (/usr/local/bin/clang-21+0x5f6fef0)
#18 0x56358e1bb526 clang::Parser::ParseWhileStatement(clang::SourceLocation*) (/usr/local/bin/clang-21+0x5f7b526)
#19 0x56358e1b211e clang::Parser::ParseStatementOrDeclarationAfterAttributes(llvm::SmallVector&, clang::Parser::ParsedStmtContext, clang::SourceLocation*, clang::ParsedAttributes&, clang::ParsedAttributes&) (/usr/local/bin/clang-21+0x5f7211e)
#20 0x56358e1b3104 clang::Parser::ParseStatementOrDeclaration(llvm::SmallVector&, clang::Parser::ParsedStmtC
[llvm-bugs] [Bug 137860] Clang 21 crash (stack dump) when using _Atomic anonymous struct field access with atomic_fetch_add
Issue
137860
Summary
Clang 21 crash (stack dump) when using _Atomic anonymous struct field access with atomic_fetch_add
Labels
clang
Assignees
Reporter
mariete1223
## Summary
Clang 21 crashes with a stack dump when trying to compile C code that uses _Atomic struct containing an anonymous struct, and accessing a subfield with atomic_fetch_add.
Instead of reporting a normal diagnostic, Clang crashes during semantic analysis (Sema::RefersToMemberWithReducedAlignment).
## Stack Trace
```
Stack dump:
0. Program arguments: /usr/local/bin/clang-21 -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -dumpdir a- -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name prueba.cpp -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 -debugger-tuning=gdb -fdebug-compilation-dir=/root -fcoverage-compilation-dir=/root -resource-dir /usr/local/lib/clang/21 -internal-isystem /usr/local/lib/clang/21/include -internal-isystem /usr/local/include -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/9/../../../../x86_64-linux-gnu/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -std=c2x -ferror-limit 19 -fgnuc-version=4.2.1 -fskip-odr-check-in-gmf -fcolor-diagnostics -faddrsig -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o /tmp/prueba-d1672b.o -x c prueba.cpp
1. prueba.cpp:17:1: current parser token '}'
2. prueba.cpp:15:1: parsing function body 'add'
3. prueba.cpp:15:1: in compound statement ('{}')
#0 0x55bf6ccfb18f llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/usr/local/bin/clang-21+0x3c4a18f)
#1 0x55bf6ccf8bd4 SignalHandler(int, siginfo_t*, void*) Signals.cpp:0:0
#2 0x7fcb90f86420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420)
#3 0x55bf704f588b getInterestingTagDecl(clang::TagDecl*) Type.cpp:0:0
#4 0x55bf6f170b2b clang::Sema::RefersToMemberWithReducedAlignment(clang::Expr*, llvm::function_ref) (/usr/local/bin/clang-21+0x60bfb2b)
#5 0x55bf6f171180 clang::Sema::CheckAddressOfPackedMember(clang::Expr*) (/usr/local/bin/clang-21+0x60c0180)
#6 0x55bf6f43e823 clang::Sema::CheckAddressOfOperand(clang::ActionResult&, clang::SourceLocation) (/usr/local/bin/clang-21+0x638d823)
#7 0x55bf6f462710 clang::Sema::CreateBuiltinUnaryOp(clang::SourceLocation, clang::UnaryOperatorKind, clang::Expr*, bool) (/usr/local/bin/clang-21+0x63b1710)
#8 0x55bf6f462f85 clang::Sema::BuildUnaryOp(clang::Scope*, clang::SourceLocation, clang::UnaryOperatorKind, clang::Expr*, bool) (/usr/local/bin/clang-21+0x63b1f85)
#9 0x55bf6f541845 clang::TreeTransform<(anonymous namespace)::TransformTypos>::TransformInitializer(clang::Expr*, bool) SemaExprCXX.cpp:0:0
#10 0x55bf6f5415c2 clang::TreeTransform<(anonymous namespace)::TransformTypos>::TransformExprs(clang::Expr* const*, unsigned int, bool, llvm::SmallVectorImpl&, bool*) SemaExprCXX.cpp:0:0
#11 0x55bf6f54851d clang::TreeTransform<(anonymous namespace)::TransformTypos>::TransformCallExpr(clang::CallExpr*) SemaExprCXX.cpp:0:0
#12 0x55bf6f55fd4e (anonymous namespace)::TransformTypos::RecursiveTransformLoop(clang::Expr*, bool&) SemaExprCXX.cpp:0:0
#13 0x55bf6f53d14a clang::Sema::CorrectDelayedTyposInExpr(clang::Expr*, clang::VarDecl*, bool, llvm::function_ref (clang::Expr*)>) (/usr/local/bin/clang-21+0x648c14a)
#14 0x55bf6f53f45d clang::Sema::ActOnFinishFullExpr(clang::Expr*, clang::SourceLocation, bool, bool, bool) (/usr/local/bin/clang-21+0x648e45d)
#15 0x55bf6f87b09e clang::Sema::ActOnExprStmt(clang::ActionResult, bool) (/usr/local/bin/clang-21+0x67ca09e)
#16 0x55bf6f02fdcc clang::Parser::ParseExprStatement(clang::Parser::ParsedStmtContext) (/usr/local/bin/clang-21+0x5f7edcc)
#17 0x55bf6f0236b2 clang::Parser::ParseStatementOrDeclarationAfterAttributes(llvm::SmallVector&, clang::Parser::ParsedStmtContext, clang::SourceLocation*, clang::ParsedAttributes&, clang::ParsedAttributes&) (/usr/local/bin/clang-21+0x5f726b2)
#18 0x55bf6f024104 clang::Parser::ParseStatementOrDeclaration(llvm::SmallVector&, clang::Parser::ParsedStmtContext, clang::SourceLocation*) (/usr/local/bin/clang-21+0x5f73104)
#19 0x55bf6f02546c clang::Parser::ParseCompoundStatementBody(bool) (/usr/local/bin/clang-21+0x5f7446c)
#20 0x55bf6f0277e2 clang::Parser::ParseFunctionStatementBody(clang::Decl*, clang::Parser::ParseScope&) (/usr/local/bin/clang-21+0x5f767e2)
#21 0x55bf6ef1ee83 clang::Parser::ParseFunctionDefinition(clang::ParsingDeclarator&, clang::Parser::ParsedTemplateInfo const&, clang::Parser::LateParsedAttrList*) (/usr/local/bin/clang-21+0x5e6de83)
[llvm-bugs] [Bug 137861] Clang 21 crash (stack dump) when parsing #pragma clang attribute push inside function body
Issue
137861
Summary
Clang 21 crash (stack dump) when parsing #pragma clang attribute push inside function body
Labels
clang
Assignees
Reporter
mariete1223
## Summary:
Clang 21 crashes when parsing a #pragma clang attribute push directive inside a function body, wrapping a compound statement {}.
Instead of rejecting the invalid pragma usage or handling it gracefully, Clang crashes during parsing and statement attribute processing (ProcessStmtAttribute).
## Stack trace
```
Stack dump:
0. Program arguments: /usr/local/bin/clang-21 -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -dumpdir a- -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name prueba.cpp -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 -debugger-tuning=gdb -fdebug-compilation-dir=/root -fcoverage-compilation-dir=/root -resource-dir /usr/local/lib/clang/21 -internal-isystem /usr/local/lib/clang/21/include -internal-isystem /usr/local/include -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/9/../../../../x86_64-linux-gnu/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -std=c2x -ferror-limit 19 -fgnuc-version=4.2.1 -fskip-odr-check-in-gmf -fcolor-diagnostics -faddrsig -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o /tmp/prueba-0fe160.o -x c prueba.cpp
1. prueba.cpp:11:1: current parser token '{'
2. prueba.cpp:5:11: parsing function body 'main'
3. prueba.cpp:5:11: in compound statement ('{}')
#0 0x55c08fa8118f llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/usr/local/bin/clang-21+0x3c4a18f)
#1 0x55c08fa7ebd4 SignalHandler(int, siginfo_t*, void*) Signals.cpp:0:0
#2 0x7f2863c40420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420)
#3 0x55c0931f2523 clang::Stmt::getBeginLoc() const (/usr/local/bin/clang-21+0x73bb523)
#4 0x55c092644dcb ProcessStmtAttribute(clang::Sema&, clang::Stmt*, clang::ParsedAttr const&, clang::SourceRange) SemaStmtAttr.cpp:0:0
#5 0x55c092648382 clang::Sema::ProcessStmtAttributes(clang::Stmt*, clang::ParsedAttributes const&, llvm::SmallVectorImpl&) (/usr/local/bin/clang-21+0x6811382)
#6 0x55c09260db87 clang::Sema::ActOnAttributedStmt(clang::ParsedAttributes const&, clang::Stmt*) (/usr/local/bin/clang-21+0x67d6b87)
#7 0x55c091daa315 clang::Parser::ParseStatementOrDeclaration(llvm::SmallVector&, clang::Parser::ParsedStmtContext, clang::SourceLocation*) (/usr/local/bin/clang-21+0x5f73315)
#8 0x55c091dab46c clang::Parser::ParseCompoundStatementBody(bool) (/usr/local/bin/clang-21+0x5f7446c)
#9 0x55c091dad7e2 clang::Parser::ParseFunctionStatementBody(clang::Decl*, clang::Parser::ParseScope&) (/usr/local/bin/clang-21+0x5f767e2)
#10 0x55c091ca4e83 clang::Parser::ParseFunctionDefinition(clang::ParsingDeclarator&, clang::Parser::ParsedTemplateInfo const&, clang::Parser::LateParsedAttrList*) (/usr/local/bin/clang-21+0x5e6de83)
#11 0x55c091ceef05 clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, clang::DeclaratorContext, clang::ParsedAttributes&, clang::Parser::ParsedTemplateInfo&, clang::SourceLocation*, clang::Parser::ForRangeInit*) (/usr/local/bin/clang-21+0x5eb7f05)
#12 0x55c091c9d62d clang::Parser::ParseDeclOrFunctionDefInternal(clang::ParsedAttributes&, clang::ParsedAttributes&, clang::ParsingDeclSpec&, clang::AccessSpecifier) (/usr/local/bin/clang-21+0x5e6662d)
#13 0x55c091c9e16e clang::Parser::ParseDeclarationOrFunctionDefinition(clang::ParsedAttributes&, clang::ParsedAttributes&, clang::ParsingDeclSpec*, clang::AccessSpecifier) (/usr/local/bin/clang-21+0x5e6716e)
#14 0x55c091ca7d73 clang::Parser::ParseExternalDeclaration(clang::ParsedAttributes&, clang::ParsedAttributes&, clang::ParsingDeclSpec*) (/usr/local/bin/clang-21+0x5e70d73)
#15 0x55c091ca96a8 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&, clang::Sema::ModuleImportState&) (/usr/local/bin/clang-21+0x5e726a8)
#16 0x55c091c9762a clang::ParseAST(clang::Sema&, bool, bool) (/usr/local/bin/clang-21+0x5e6062a)
#17 0x55c090405e45 clang::CodeGenAction::ExecuteAction() (/usr/local/bin/clang-21+0x45cee45)
#18 0x55c0906ea9b8 clang::FrontendAction::Execute() (/usr/local/bin/clang-21+0x48b39b8)
#19 0x55c090668d3b clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/usr/local/bin/clang-21+0x4831d3b)
#20 0x55c0907dcc7b clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/usr/local/bin/clang-21+0x49a5c7b)
#21 0x55c08ccd9f51 cc1_main(llvm::ArrayRef, char const*, void*) (/usr/local/bin/clang-21+0xea2f51)
#22 0x55c08ccd25fd ExecuteCC1Tool(llvm::SmallVectorImpl&
[llvm-bugs] [Bug 137862] No move elision in construction from nested brace-enclosed initializer list
Issue
137862
Summary
No move elision in construction from nested brace-enclosed initializer list
Labels
new issue
Assignees
Reporter
Fedr
This program
```c++
struct B {
int i, j;
};
struct A {
A(A&&) = delete;
A(const B &) {}
};
A a( { { 1, 2 } } );
```
is accepted by GCC and EDG. But Clang complains:
```
:10:3: error: call to deleted constructor of 'A'
10 | A a( { { 1, 2 } } );
| ^
:6:5: note: 'A' has been explicitly marked deleted here
6 | A(A&&) = delete;
| ^
```
Online demo: https://gcc.godbolt.org/z/eT9M59acx
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 137868] [HLSL] Report diagnostics for implicit resource bindings that cannot be assigned
Issue
137868
Summary
[HLSL] Report diagnostics for implicit resource bindings that cannot be assigned
Labels
HLSL
Assignees
Reporter
hekota
Report diagnostics for implicit resource bindings that cannot be assigned, such as:
```
RWBuffer A : register(u1);
RWBuffer B[]; // gets u6 (unbounded range)
RWBuffer C : register(u5);
RWBuffer D[4];// error - does not fit in the remaining descriptor ranges in space0
[numthreads(4,1,1)]
void main() {
A[0] = D[2][0] + C[0] + B[10][0];
}
```
https://godbolt.org/z/6bYoG599P
Expected:
```:4:1: error: resource D could not be allocated```
The error should be reported from `DXILPostOptimizationValidation` pass which can take the time and can depend on all completed resource analyses and/or debug info to lookup the resource variable name.
Implicit bindings are assigned by the `DXILResourceImplicitBinding` pass fairly early in the LLVM pipeline. It replaces `dx.resource.handlefromimplicitbinding` calls with `dx.resource.handlefrombinding` calls for all resources that can be allocated (= assigned a binding).
If a binding cannot be assigned, the pass will leave the `dx.resource.handlefromimplicitbinding` call associated with the resource in the IR to be picked up by the `DXILPostOptimizationValidation` pass for diagnostic. If there are no such resources (= all resources have binding), the `DXILResourceImplicitBinding` pass clear the `ContainsImplicitBindings` flag on `DXILResourceBindingAnalysis`.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 137870] Clang 21 crash when using __attribute__((alloc_size(2, 1))) on variadic function declaration
Issue
137870
Summary
Clang 21 crash when using __attribute__((alloc_size(2,1))) on variadic function declaration
Labels
clang
Assignees
Reporter
mariete1223
## Summary
Clang 21 crashes with a segmentation fault when compiling a variadic function declaration annotated with __attribute__((alloc_size(2,1))).
The compiler fails to check whether the arguments to the attribute are valid for a variadic function before trying to process them.
## Stack Dump
```
Stack dump:
0. Program arguments: /usr/local/bin/clang-21 -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -dumpdir a- -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name prueba.cpp -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=/root -fcoverage-compilation-dir=/root -resource-dir /usr/local/lib/clang/21 -internal-isystem /usr/local/lib/clang/21/include -internal-isystem /usr/local/include -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/9/../../../../x86_64-linux-gnu/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -O3 -std=c2x -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/prueba-ee2b13.o -x c prueba.cpp
1. prueba.cpp:7:64: current parser token '{'
#0 0x564cefc1e18f llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/usr/local/bin/clang-21+0x3c4a18f)
#1 0x564cefc1bbd4 SignalHandler(int, siginfo_t*, void*) Signals.cpp:0:0
#2 0x7fd7c765f420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420)
#3 0x564cf223ca85 bool checkParamIsIntegerType(clang::Sema&, clang::Decl const*, clang::ParsedAttr const&, unsigned int) SemaDeclAttr.cpp:0:0
#4 0x564cf2243e56 handleAllocSizeAttr(clang::Sema&, clang::Decl*, clang::ParsedAttr const&) SemaDeclAttr.cpp:0:0
#5 0x564cf224edb6 ProcessDeclAttribute(clang::Sema&, clang::Scope*, clang::Decl*, clang::ParsedAttr const&, clang::Sema::ProcessDeclAttributeOptions const&) (.isra.0) SemaDeclAttr.cpp:0:0
#6 0x564cf22520f5 clang::Sema::ProcessDeclAttributes(clang::Scope*, clang::Decl*, clang::Declarator const&) (/usr/local/bin/clang-21+0x627e0f5)
#7 0x564cf220787c clang::Sema::ActOnFunctionDeclarator(clang::Scope*, clang::Declarator&, clang::DeclContext*, clang::TypeSourceInfo*, clang::LookupResult&, llvm::MutableArrayRef, bool&) (/usr/local/bin/clang-21+0x623387c)
#8 0x564cf220d114 clang::Sema::HandleDeclarator(clang::Scope*, clang::Declarator&, llvm::MutableArrayRef) (/usr/local/bin/clang-21+0x6239114)
#9 0x564cf220d93c clang::Sema::ActOnStartOfFunctionDef(clang::Scope*, clang::Declarator&, llvm::MutableArrayRef, clang::SkipBodyInfo*, clang::Sema::FnBodyKind) (/usr/local/bin/clang-21+0x623993c)
#10 0x564cf1e41db1 clang::Parser::ParseFunctionDefinition(clang::ParsingDeclarator&, clang::Parser::ParsedTemplateInfo const&, clang::Parser::LateParsedAttrList*) (/usr/local/bin/clang-21+0x5e6ddb1)
#11 0x564cf1e8bf05 clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, clang::DeclaratorContext, clang::ParsedAttributes&, clang::Parser::ParsedTemplateInfo&, clang::SourceLocation*, clang::Parser::ForRangeInit*) (/usr/local/bin/clang-21+0x5eb7f05)
#12 0x564cf1e3a62d clang::Parser::ParseDeclOrFunctionDefInternal(clang::ParsedAttributes&, clang::ParsedAttributes&, clang::ParsingDeclSpec&, clang::AccessSpecifier) (/usr/local/bin/clang-21+0x5e6662d)
#13 0x564cf1e3b16e clang::Parser::ParseDeclarationOrFunctionDefinition(clang::ParsedAttributes&, clang::ParsedAttributes&, clang::ParsingDeclSpec*, clang::AccessSpecifier) (/usr/local/bin/clang-21+0x5e6716e)
#14 0x564cf1e44d73 clang::Parser::ParseExternalDeclaration(clang::ParsedAttributes&, clang::ParsedAttributes&, clang::ParsingDeclSpec*) (/usr/local/bin/clang-21+0x5e70d73)
#15 0x564cf1e466a8 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&, clang::Sema::ModuleImportState&) (/usr/local/bin/clang-21+0x5e726a8)
#16 0x564cf1e3462a clang::ParseAST(clang::Sema&, bool, bool) (/usr/local/bin/clang-21+0x5e6062a)
#17 0x564cf05a2e45 clang::CodeGenAction::ExecuteAction() (/usr/local/bin/clang-21+0x45cee45)
#18 0x564cf08879b8 clang::FrontendAction::Execute() (/usr/local/bin/clang-21+0x48b39b8)
#19 0x564cf0805d3b clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/usr/local/bin/clang-21+0x4831d3b)
#20 0x564cf0979c7b clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/usr/local/bin/clang-21+0x49a5c7b)
#21 0x564cece76f51 cc1_ma
[llvm-bugs] [Bug 137827] [HLSL] `lerp` overloads with mixed scalar and vector operands
Issue
137827
Summary
[HLSL] `lerp` overloads with mixed scalar and vector operands
Labels
HLSL
Assignees
Reporter
bogner
Clang currently fails to resolve `lerp` overloads where the weight parameter is a scalar. We should support overloads where `x` and `y` are vectors but the weight is scalar:
```hlsl
export float3 call(float3 x, float3 y, float weight) {
return lerp(x, y, weight); // calls lerp(float3, float3, float3)
}
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 137846] Clang 21 accepts invalid # 0 preprocessor lines leading to undefined behavior at compile time
Issue 137846 Summary Clang 21 accepts invalid # 0 preprocessor lines leading to undefined behavior at compile time Labels clang Assignees Reporter mariete1223 ## Summary Clang 21 accepts invalid standalone # 0 preprocessor lines in C source files without emitting an error or a warning. When compiled, the program exhibits undefined behavior (e.g., prints unlimited spaces or crashes), despite the code being syntactically invalid. ## Program ``` uint32_t square(uint32_t x) # 0 # 0 ``` ## To reproduce Quickly https://gcc.godbolt.org/z/c1daT34v6 It gets: [Truncated] Compiler returned: 143 ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 137845] Clang 21 crashes when compiling invalid initializer in C (struct array literal cast)
Issue
137845
Summary
Clang 21 crashes when compiling invalid initializer in C (struct array literal cast)
Labels
clang
Assignees
Reporter
mariete1223
## Summary
Clang 21 crashes with a stack dump when compiling a small invalid C program involving a struct array literal being cast and passed as an argument.
## Stack Trace
```
Stack dump:
0. Program arguments: /usr/local/bin/clang-21 -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -dumpdir a- -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name prueba.cpp -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 -debugger-tuning=gdb -fdebug-compilation-dir=/root -fcoverage-compilation-dir=/root -resource-dir /usr/local/lib/clang/21 -internal-isystem /usr/local/lib/clang/21/include -internal-isystem /usr/local/include -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/9/../../../../x86_64-linux-gnu/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -std=c2x -ferror-limit 19 -fgnuc-version=4.2.1 -fskip-odr-check-in-gmf -fcolor-diagnostics -faddrsig -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o /tmp/prueba-cf6791.o -x c prueba.cpp
1. prueba.cpp:7:49: current parser token ')'
2. prueba.cpp:5:11: parsing function body 'main'
3. prueba.cpp:5:11: in compound statement ('{}')
#0 0x55fee950018f llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/usr/local/bin/clang-21+0x3c4a18f)
#1 0x55fee94fdbd4 SignalHandler(int, siginfo_t*, void*) Signals.cpp:0:0
#2 0x7f5adbc08420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420)
#3 0x55feebe06b44 (anonymous namespace)::InitListChecker::CheckExplicitInitList(clang::InitializedEntity const&, clang::InitListExpr*, clang::QualType&, clang::InitListExpr*, bool) (.constprop.0) SemaInit.cpp:0:0
#4 0x55feebe07217 (anonymous namespace)::InitListChecker::InitListChecker(clang::Sema&, clang::InitializedEntity const&, clang::InitListExpr*, clang::QualType&, bool, bool, bool, llvm::SmallVectorImpl*) SemaInit.cpp:0:0
#5 0x55feebe08f23 clang::InitializationSequence::Perform(clang::Sema&, clang::InitializedEntity const&, clang::InitializationKind const&, llvm::MutableArrayRef, clang::QualType*) (/usr/local/bin/clang-21+0x6552f23)
#6 0x55feebe1355e clang::Sema::PerformCopyInitialization(clang::InitializedEntity const&, clang::SourceLocation, clang::ActionResult, bool, bool) (/usr/local/bin/clang-21+0x655d55e)
#7 0x55feebc70d36 clang::Sema::GatherArgumentsForCall(clang::SourceLocation, clang::FunctionDecl*, clang::FunctionProtoType const*, unsigned int, llvm::ArrayRef, llvm::SmallVectorImpl&, clang::Sema::VariadicCallType, bool, bool) (/usr/local/bin/clang-21+0x63bad36)
#8 0x55feebc718af clang::Sema::ConvertArgumentsForCall(clang::CallExpr*, clang::Expr*, clang::FunctionDecl*, clang::FunctionProtoType const*, llvm::ArrayRef, clang::SourceLocation, bool) (/usr/local/bin/clang-21+0x63bb8af)
#9 0x55feebc73760 clang::Sema::BuildResolvedCallExpr(clang::Expr*, clang::NamedDecl*, clang::SourceLocation, llvm::ArrayRef, clang::SourceLocation, clang::Expr*, bool, clang::CallExpr::ADLCallKind) (/usr/local/bin/clang-21+0x63bd760)
#10 0x55feebc6f052 clang::Sema::BuildCallExpr(clang::Scope*, clang::Expr*, clang::SourceLocation, llvm::MutableArrayRef, clang::SourceLocation, clang::Expr*, bool, bool) (/usr/local/bin/clang-21+0x63b9052)
#11 0x55feebc7456b clang::Sema::ActOnCallExpr(clang::Scope*, clang::Expr*, clang::SourceLocation, llvm::MutableArrayRef, clang::SourceLocation, clang::Expr*) (/usr/local/bin/clang-21+0x63be56b)
#12 0x55feeb7a6a10 clang::Parser::ParsePostfixExpressionSuffix(clang::ActionResult) (/usr/local/bin/clang-21+0x5ef0a10)
#13 0x55feeb79e5a7 clang::Parser::ParseCastExpression(clang::Parser::CastParseKind, bool, bool&, clang::Parser::TypeCastState, bool, bool*) (/usr/local/bin/clang-21+0x5ee85a7)
#14 0x55feeb7a072e clang::Parser::ParseCastExpression(clang::Parser::CastParseKind, bool, clang::Parser::TypeCastState, bool, bool*) (/usr/local/bin/clang-21+0x5eea72e)
#15 0x55feeb7a092d clang::Parser::ParseAssignmentExpression(clang::Parser::TypeCastState) (/usr/local/bin/clang-21+0x5eea92d)
#16 0x55feeb7a0d42 clang::Parser::ParseExpressionList(llvm::SmallVectorImpl&, llvm::function_ref, bool, bool, bool*) (/usr/local/bin/clang-21+0x5eead42)
#17 0x55feeb7a7142 clang::Parser::ParsePostfixExpressionSuffix(clang::ActionResult) (/usr/local/bin/clang-21+0x5ef1142)
#18 0x55feeb79e5a7 clang::Parser::ParseCastExpression(clang::Parser::CastParseKind, bool, bool&, clang::Parser:
[llvm-bugs] [Bug 137847] Clang 21 crashes (stack dump) on invalid nested struct initialization
Issue
137847
Summary
Clang 21 crashes (stack dump) on invalid nested struct initialization
Labels
clang
Assignees
Reporter
mariete1223
## Summary
Clang 21 crashes during compilation when trying to compile an invalid C program with incorrect nested struct initialization.
Instead of reporting a normal error about the bad initializer, the compiler crashes internally during InitListChecker::CheckExplicitInitList.
## Stack Trace
```
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/local/bin/clang-21 -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -dumpdir a- -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name prueba.cpp -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 -debugger-tuning=gdb -fdebug-compilation-dir=/root -fcoverage-compilation-dir=/root -resource-dir /usr/local/lib/clang/21 -internal-isystem /usr/local/lib/clang/21/include -internal-isystem /usr/local/include -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/9/../../../../x86_64-linux-gnu/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -std=c2x -ferror-limit 19 -fgnuc-version=4.2.1 -fskip-odr-check-in-gmf -fcolor-diagnostics -faddrsig -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o /tmp/prueba-871b16.o -x c prueba.cpp
1. prueba.cpp:11:20: current parser token ';'
2. prueba.cpp:4:1: parsing function body 'main'
3. prueba.cpp:4:1: in compound statement ('{}')
#0 0x55ecf098418f llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/usr/local/bin/clang-21+0x3c4a18f)
#1 0x55ecf0981bd4 SignalHandler(int, siginfo_t*, void*) Signals.cpp:0:0
#2 0x7fb911ec7420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420)
#3 0x55ecf328ab44 (anonymous namespace)::InitListChecker::CheckExplicitInitList(clang::InitializedEntity const&, clang::InitListExpr*, clang::QualType&, clang::InitListExpr*, bool) (.constprop.0) SemaInit.cpp:0:0
#4 0x55ecf328b217 (anonymous namespace)::InitListChecker::InitListChecker(clang::Sema&, clang::InitializedEntity const&, clang::InitListExpr*, clang::QualType&, bool, bool, bool, llvm::SmallVectorImpl*) SemaInit.cpp:0:0
#5 0x55ecf328cf23 clang::InitializationSequence::Perform(clang::Sema&, clang::InitializedEntity const&, clang::InitializationKind const&, llvm::MutableArrayRef, clang::QualType*) (/usr/local/bin/clang-21+0x6552f23)
#6 0x55ecf329b18a (anonymous namespace)::InitListChecker::CheckSubElementType(clang::InitializedEntity const&, clang::InitListExpr*, clang::QualType, unsigned int&, clang::InitListExpr*, unsigned int&, bool) SemaInit.cpp:0:0
#7 0x55ecf329be4b (anonymous namespace)::InitListChecker::CheckStructUnionTypes(clang::InitializedEntity const&, clang::InitListExpr*, clang::QualType, llvm::iterator_range, clang::DeclContext::specific_decl_iterator, bool, unsigned int&, clang::InitListExpr*, unsigned int&, bool) SemaInit.cpp:0:0
#8 0x55ecf3289f52 (anonymous namespace)::InitListChecker::CheckListElementTypes(clang::InitializedEntity const&, clang::InitListExpr*, clang::QualType&, bool, unsigned int&, clang::InitListExpr*, unsigned int&, bool) (.constprop.0) SemaInit.cpp:0:0
#9 0x55ecf328aa3d (anonymous namespace)::InitListChecker::CheckExplicitInitList(clang::InitializedEntity const&, clang::InitListExpr*, clang::QualType&, clang::InitListExpr*, bool) (.constprop.0) SemaInit.cpp:0:0
#10 0x55ecf328b217 (anonymous namespace)::InitListChecker::InitListChecker(clang::Sema&, clang::InitializedEntity const&, clang::InitListExpr*, clang::QualType&, bool, bool, bool, llvm::SmallVectorImpl*) SemaInit.cpp:0:0
#11 0x55ecf328cf23 clang::InitializationSequence::Perform(clang::Sema&, clang::InitializedEntity const&, clang::InitializationKind const&, llvm::MutableArrayRef, clang::QualType*) (/usr/local/bin/clang-21+0x6552f23)
#12 0x55ecf2f5ce2c clang::Sema::AddInitializerToDecl(clang::Decl*, clang::Expr*, bool) (/usr/local/bin/clang-21+0x6222e2c)
#13 0x55ecf2bdc15c clang::Parser::ParseDeclarationAfterDeclaratorAndAttributes(clang::Declarator&, clang::Parser::ParsedTemplateInfo const&, clang::Parser::ForRangeInit*) (/usr/local/bin/clang-21+0x5ea215c)
#14 0x55ecf2bf1a31 clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, clang::DeclaratorContext, clang::ParsedAttributes&, clang::Parser::ParsedTemplateInfo&, clang::SourceLocation*, clang::Parser::ForRangeInit*) (/usr/local/bin/clang-21+0x5eb7a31)
#15 0x55ecf2bf45f0 clang::
[llvm-bugs] [Bug 137833] Missing workaround for old glibc `__PTR_ALIGN` macro
Issue 137833 Summary Missing workaround for old glibc `__PTR_ALIGN` macro Labels clang:codegen Assignees dtcxzyw Reporter dtcxzyw See also https://github.com/llvm/llvm-project/pull/130742#issuecomment-2835528395. Do not set `inbounds` flag on GEPs for the following pattern: ``` ((sizeof(long int) < sizeof(void *) ? (base) : (char *)0) + (((pointer) - (sizeof(long int) < sizeof(void *) ? (base) : (char *)0) + (align_mask)) & ~(align_mask))); ``` 1. Handle the pointer addition case `(char *0) + idx` 2. Handle expr `((sizeof(long int) < sizeof(void *) ? (base) : (char *)0)` in `isUnderlyingBasePointerConstantNull`. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 137836] Performance regression / bad code generation on PPC603e CPU since clang/llvm v15
Issue
137836
Summary
Performance regression / bad code generation on PPC603e CPU since clang/llvm v15
Labels
clang
Assignees
Reporter
andyg1001
Compiled with the options "-target powerpc-unknown-linux-gnu -mcpu=603e -O2" the following code should produce almost identical outputs:
```
static char buffer[16];
int test1(int offset1, int offset2, int value)
{
*(int*)(buffer + offset1) = value;
return *(int*)(buffer + offset2);
}
int test2(char* buffer, int offset1, int offset2, int value)
{
*(int*)(buffer + offset1) = value;
return *(int*)(buffer + offset2);
}
```
On clang/llvm up to and including version 14, this is the correct (tested and functional) output (https://godbolt.org/z/qr9dn5che):
```
test1(int, int, int):
lis 6, _ZL6buffer@ha
la 6, _ZL6buffer@l(6)
stwx 5, 6, 3
lwzx 3, 6, 4
blr
test2(char*, int, int, int):
stwx 6, 3, 4
lwzx 3, 3, 5
blr
```
But since clang/llvm version 15 up to trunk version, this is the output (https://godbolt.org/z/qfzccdMqc):
```
.L0$poff:
.long .LTOC-.L0$pb
test1(int, int, int):
mflr 0
stw 0, 4(1)
stwu 1, -16(1)
stw 30, 8(1)
bl .L0$pb
.L0$pb:
mflr 30
lwz 6, .L0$poff-.L0$pb(30)
add 30, 6, 30
lwz 6, .LC0-.LTOC(30)
stwx 5, 6, 3
lwzx 3, 6, 4
lwz 0, 20(1)
lwz 30, 8(1)
addi 1, 1, 16
mtlr 0
blr
test2(char*, int, int, int):
stwx 6, 3, 4
lwzx 3, 3, 5
blr
.LC0:
.long _ZL6buffer
```
This is just test code to demonstrate the issue, but in actual production code which is too complex to post here, this explosion of code in the 'test1' case which uses a global buffer rather than a passed-in pointer is causing a significant performance regression, preventing the adoption of newer clang compilers.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 137855] libclang abort death test fails when run as part of AllClangUnitTests binary
Issue 137855 Summary libclang abort death test fails when run as part of AllClangUnitTests binary Labels new issue Assignees Reporter rnk After PR https://github.com/llvm/llvm-project/pull/134196 , a few buildbots reported that the LibclangParseTest.UninstallAbortingLLVMFatalErrorHandler test fails on Mac bots: https://lab.llvm.org/buildbot/#/builders/23/builds/9847 https://lab.llvm.org/buildbot/#/builders/190/builds/19202 I plan to disable this specific test rather than rolling back, and I'm filing this issue to track fixing the test. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 137819] Request Commit Access For tomershafir
Issue 137819 Summary Request Commit Access For tomershafir Labels infra:commit-access-request Assignees Reporter tomershafir I've recently started a new role as a compiler engineer at Apple, humbly requesting commit access. Previously, I have mostly worked on distributed systems, but I did work on LLVM XRay. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 137876] Possible hung git invocation causing presubmit failures
Issue 137876 Summary Possible hung git invocation causing presubmit failures Labels new issue Assignees Reporter Prabhuk Running into the following failure when uploading new PRs or updating existing PRs at times. ``` Running 'git gc'... | error: cannot lock ref 'refs/remotes/origin/users/matthias-springer/cse_filter': Unable to create '/var/lib/buildkite-agent/builds/service-855b8ffd5d-k7cg6-1/llvm-project/github-pull-requests/.git/refs/remotes/origin/users/matthias-springer/cse_filter.lock': File exists. | ``` Links to two separate failing instances: https://buildkite.com/llvm-project/github-pull-requests/builds/173742#01968337-b887-4d3e-99d9-6f5c9c3af89d https://buildkite.com/llvm-project/github-pull-requests/builds/173749#0196834c-83a2-4bbe-b9c2-038795ea088f ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
