[llvm-bugs] [Bug 122579] [Clang] Incorrect Diagnostic Message for Ambiguous Overloaded Operator in Clang
Issue
122579
Summary
[Clang] Incorrect Diagnostic Message for Ambiguous Overloaded Operator in Clang
Labels
clang
Assignees
Reporter
wangbo15
Given the following code:
```
#include
struct operand
{
int x;
operator int (){return x;};
operator bool() {return true;};
operator char() {return 'c';};
};
bool bar (operand i, operand j)
{
bool tst = (i == j);
return tst;
}
int main(){
operand o1{1}, o2{0};
std::cout<:12:17: error: use of overloaded operator '==' is ambiguous (with operand types 'operand' and 'operand')
12 | bool tst = (i == j);
| ~ ^ ~
:12:17: note: because of ambiguity in conversion of 'operand' to 'float'
:5:3: note: candidate function
5 | operator int (){return x;};
| ^
:6:3: note: candidate function
6 | operator bool() {return true;};
| ^
:7:3: note: candidate function
7 | operator char() {return 'c';};
| ^
:12:17: note: because of ambiguity in conversion of 'operand' to 'float'
12 | bool tst = (i == j);
| ^
:5:3: note: candidate function
5 | operator int (){return x;};
| ^
:6:3: note: candidate function
6 | operator bool() {return true;};
| ^
:7:3: note: candidate function
7 | operator char() {return 'c';};
| ^
:12:17: note: built-in candidate operator==(float, float)
12 | bool tst = (i == j);
```
Moreover, MSVC's output seems correct:
```
example.cpp
(12): error C2593: 'operator ==' is ambiguous
(12): note: could be 'built-in C++ operator==(int, int)'
(12): note: or 'built-in C++ operator==(int, bool)'
(12): note: or 'built-in C++ operator==(int, char)'
(12): note: or 'built-in C++ operator==(bool, int)'
(12): note: or 'built-in C++ operator==(bool, bool)'
(12): note: or 'built-in C++ operator==(bool, char)'
(12): note: or 'built-in C++ operator==(char, int)'
(12): note: or 'built-in C++ operator==(char, bool)'
(12): note: or 'built-in C++ operator==(char, char)'
(12): note: while trying to match the argument list '(operand, operand)'
cl : Command line warning D9002 : ignoring unknown option '-std=c++20'
Compiler returned: 2
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 122580] [X86][ISel] Assertion `(LZ + TZ) < Known.getBitWidth() && "Illegal shifted mask"' failed.
Issue
122580
Summary
[X86][ISel] Assertion `(LZ + TZ) < Known.getBitWidth() && "Illegal shifted mask"' failed.
Labels
backend:X86,
crash-on-valid
Assignees
Reporter
dtcxzyw
Reproducer: https://godbolt.org/z/eqMMqPavq
```
; bin/llc reduced.ll -o -
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"
target triple = "x86_64-unknown-linux-gnu"
@g_180 = external global i8
@g_1032 = external global [2 x i32]
define i32 @test(ptr %0) {
entry:
%.b577 = load i1, ptr @g_180, align 4
%1 = select i1 %.b577, i32 1, i32 878456582
store i32 0, ptr @g_1032, align 4
%.b576 = load i1, ptr @g_180, align 4
%2 = select i1 %.b576, i32 1, i32 878456582
%or542.1.i = or i32 %2, %1
store i32 0, ptr @g_1032, align 4
%.b575 = load i1, ptr @g_180, align 4
%3 = select i1 %.b575, i32 1, i32 878456582
%or542.2.i = or i32 %3, %or542.1.i
%or542.3.i = or i32 %or542.2.i, 1
store i32 %or542.3.i, ptr %0, align 4
%4 = load i32, ptr %0, align 4
%div.i1796.i = sdiv i32 %4, 1096912269
%5 = tail call i32 @llvm.ctpop.i32(i32 %div.i1796.i)
ret i32 %5
}
```
```
llc: /root/llvm-project/llvm/lib/Target/X86/X86ISelLowering.cpp:32177: llvm::SDValue LowerCTPOP(llvm::SDValue, const llvm::X86Subtarget&, llvm::SelectionDAG&): Assertion `(LZ + TZ) < Known.getBitWidth() && "Illegal shifted mask"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0. Program arguments: /opt/compiler-explorer/clang-assertions-trunk/bin/llc -o /app/output.s
1. Running pass 'Function Pass Manager' on module ''.
2. Running pass 'X86 DAG->DAG Instruction Selection' on function '@test'
#0 0x03ca0728 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x3ca0728)
#1 0x03c9e12c SignalHandler(int) Signals.cpp:0:0
#2 0x713ac9442520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#3 0x713ac94969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
#4 0x713ac9442476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
#5 0x713ac94287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
#6 0x713ac942871b (/lib/x86_64-linux-gnu/libc.so.6+0x2871b)
#7 0x713ac9439e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96)
#8 0x0204f30f LowerCTPOP(llvm::SDValue, llvm::X86Subtarget const&, llvm::SelectionDAG&) X86ISelLowering.cpp:0:0
#9 0x0218da52 llvm::X86TargetLowering::LowerOperation(llvm::SDValue, llvm::SelectionDAG&) const (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x218da52)
#10 0x03938110 (anonymous namespace)::SelectionDAGLegalize::LegalizeOp(llvm::SDNode*) (.part.0) LegalizeDAG.cpp:0:0
#11 0x0393bc16 llvm::SelectionDAG::Legalize() (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x393bc16)
#12 0x03a53dcd llvm::SelectionDAGISel::CodeGenAndEmitDAG() (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x3a53dcd)
#13 0x03a574b9 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x3a574b9)
#14 0x03a58760 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x3a58760)
#15 0x03a4910f llvm::SelectionDAGISelLegacy::runOnMachineFunction(llvm::MachineFunction&) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x3a4910f)
#16 0x02bda179 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (.part.0) MachineFunctionPass.cpp:0:0
#17 0x031e250f llvm::FPPassManager::runOnFunction(llvm::Function&) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x31e250f)
#18 0x031e28c1 llvm::FPPassManager::runOnModule(llvm::Module&) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x31e28c1)
#19 0x031e3161 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x31e3161)
#20 0x0089fc50 compileModule(char**, llvm::LLVMContext&) llc.cpp:0:0
#21 0x00788a0e main (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x788a0e)
#22 0x713ac9429d90 (/lib/x86_64-linux-gnu/libc.so.6+0x29d90)
#23 0x713ac9429e40 __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x29e40)
#24 0x00896525 _start (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x896525)
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 122581] [clang] Constraint normalization uses too much memory
Issue
122581
Summary
[clang] Constraint normalization uses too much memory
Labels
clang
Assignees
Reporter
cookiestarfish
```
template
concept C0 = true;
template
concept C1 = true;
template
concept C2 = true;
template
concept C3 = true;
template
concept C4 = true;
template
concept X =
(C0 && (C2 && C3) || (C2 && C4) || (C3 && C4)) ||
(C0 && (C1 && C2) ||
(C1 && (C1 && C3) || (C1 && C4) || (C3 && C4)) ||
(C2 && (C1 && C3) || (C1 && C4) || (C3 && C4))) ||
((C2 && C3) || (C2 && C4) ||
(C3 && C4) && (C1 && C2) ||
(C1 && (C1 && C3) || (C1 && C4) || (C3 && C4)) ||
(C2 && (C1 && C3) || (C1 && C4) || (C3 && C4)));
template
concept Y = C0 && X;
int foo(X auto x) { return 10; }
int foo(Y auto y) { return 20; }
int bar() { return foo(0); }
```
https://godbolt.org/z/d1e8z7vvK
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 122551] [CodeGen] inefficient code for multiple select instructions with same condition
Issue 122551 Summary [CodeGen] inefficient code for multiple select instructions with same condition Labels new issue Assignees Reporter weiguozhi The example test case is at https://godbolt.org/z/fEEonKhn9. Function foo is what I got from source code, there are two selects in two basic blocks, they use the same condition, it generates two pairs of "test + jns" instructions. An optimal result should be same as function expected, there is only one pair of "test + jns". ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 122567] [clang] Missed optimization: Failure to remove useless allocations / deallocations
Issue
122567
Summary
[clang] Missed optimization: Failure to remove useless allocations / deallocations
Labels
clang
Assignees
Reporter
davidstone
The following translation unit:
```c++
#include
struct Container {
~Container() {
if (m_pointer) {
std::allocator().deallocate(m_pointer, 1);
}
}
int * m_pointer = nullptr;
};
Container bad() {
auto container = Container{};
auto const original_pointer = std::allocator().allocate(1);
container.m_pointer = original_pointer;
container.m_pointer = std::allocator().allocate(1);
std::allocator().deallocate(
original_pointer,
1
);
return container;
}
```
when compiled with `-O3` generates the following output:
```
%struct.Container = type { ptr }
define dso_local void @bad()(ptr dead_on_unwind noalias nocapture writable writeonly sret(%struct.Container) align 8 initializes((0, 8)) %agg.result) local_unnamed_addr #0 personality ptr @__gxx_personality_v0 !dbg !394 {
entry:
#dbg_value(ptr undef, !401, !DIExpression(DW_OP_LLVM_fragment, 0, 8), !407)
#dbg_value(ptr undef, !401, !DIExpression(DW_OP_LLVM_fragment, 0, 8), !409)
#dbg_value(ptr undef, !411, !DIExpression(DW_OP_LLVM_fragment, 0, 8), !416)
#dbg_value(ptr %agg.result, !398, !DIExpression(DW_OP_deref), !418)
#dbg_value(ptr undef, !401, !DIExpression(), !407)
#dbg_value(i64 1, !404, !DIExpression(), !407)
#dbg_value(ptr null, !405, !DIExpression(), !407)
%call5.i14 = tail call noalias noundef nonnull dereferenceable(4) ptr @operator new(unsigned long)(i64 noundef 4) #3, !dbg !419
#dbg_value(ptr %call5.i14, !399, !DIExpression(), !418)
store ptr %call5.i14, ptr %agg.result, align 8, !dbg !420
#dbg_value(ptr undef, !401, !DIExpression(), !409)
#dbg_value(i64 1, !404, !DIExpression(), !409)
#dbg_value(ptr null, !405, !DIExpression(), !409)
%call5.i15 = invoke noalias noundef nonnull dereferenceable(4) ptr @operator new(unsigned long)(i64 noundef 4) #3
to label %invoke.cont4 unwind label %if.then.i, !dbg !427
invoke.cont4:
store ptr %call5.i15, ptr %agg.result, align 8, !dbg !428
#dbg_value(ptr undef, !411, !DIExpression(), !416)
#dbg_value(ptr %call5.i14, !414, !DIExpression(), !416)
#dbg_value(i64 1, !415, !DIExpression(), !416)
tail call void @operator delete(void*, unsigned long)(ptr noundef nonnull %call5.i14, i64 noundef 4) #4, !dbg !429
ret void, !dbg !430
if.then.i:
%0 = landingpad { ptr, i32 }
cleanup, !dbg !430
#dbg_value(ptr undef, !411, !DIExpression(DW_OP_LLVM_fragment, 0, 8), !431)
#dbg_value(ptr %agg.result, !438, !DIExpression(), !441)
#dbg_value(ptr undef, !411, !DIExpression(), !431)
#dbg_value(ptr %call5.i14, !414, !DIExpression(), !431)
#dbg_value(i64 1, !415, !DIExpression(), !431)
tail call void @operator delete(void*, unsigned long)(ptr noundef nonnull %call5.i14, i64 noundef 4) #4, !dbg !442
resume { ptr, i32 } %0, !dbg !430
}
declare i32 @__gxx_personality_v0(...)
declare void @operator delete(void*, unsigned long)(ptr noundef, i64 noundef) local_unnamed_addr #1
declare noundef nonnull ptr @operator new(unsigned long)(i64 noundef) local_unnamed_addr #2
attributes #0 = { mustprogress uwtable "min-legal-vector-width"="0" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+cmov,+cx8,+fxsr,+mmx,+sse,+sse2,+x87" "tune-cpu"="generic" }
attributes #1 = { nobuiltin nounwind "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+cmov,+cx8,+fxsr,+mmx,+sse,+sse2,+x87" "tune-cpu"="generic" }
attributes #2 = { nobuiltin allocsize(0) "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+cmov,+cx8,+fxsr,+mmx,+sse,+sse2,+x87" "tune-cpu"="generic" }
attributes #3 = { builtin allocsize(0) }
attributes #4 = { builtin nounwind }
```
which corresponds to the assembly
```asm
bad():
pushr14
pushrbx
pushrax
mov rbx, rdi
mov edi, 4
call operator new(unsigned long)@PLT
mov r14, rax
mov qword ptr [rbx], rax
mov edi, 4
calloperator new(unsigned long)@PLT
mov qword ptr [rbx], rax
mov esi, 4
mov rdi, r14
calloperator delete(void*, unsigned long)@PLT
mov rax, rbx
add rsp, 8
pop rbx
pop r14
ret
mov rbx, rax
mov esi, 4
mov rdi, r14
calloperator delete(void*, unsigned long)@PLT
mov rdi, rbx
call _Unwind_Resume@PLT
DW.ref.__gxx_personality_v0:
.quad __gxx_personality_v0
```
I want it to generate
```
%struct.Container = type { ptr }
define dso_local void @good()(pt
[llvm-bugs] [Bug 122571] Backend crashes on a store to a large vector
Issue
122571
Summary
Backend crashes on a store to a large vector
Labels
new issue
Assignees
Reporter
npanchen
I'm investigating issue we have that is similar to https://github.com/llvm/llvm-project/issues/93391. From my understanding, the #93391 was closed assuming it's impossible to write C/C++ code that generates provided code as frontend will catch and report that large type.
However, our case is possible to reproduce using vector type that Clang and GCC support:
```c
typedef int vtype __attribute__ ((vector_size (262144)));
void zero(vtype *x) {
*x = *x ^ *x;
}
```
```
% clang -c test.c -O1
Assertion failed: (SDNode::getMaxNumOperands() >= Vals.size() && "too many operands to fit into SDNode"), function createOperands, file SelectionDAG.cpp, line 13500
```
The IR is quite trivial:
```
define void @zero(ptr initializes((0, 262144)) %x) {
entry:
store <65536 x i32> zeroinitializer, ptr %x, align 16
ret void
}
```
C code can be compiled by GCC without any problems.
So the questions is: should backend correctly handle large vector sizes or it's assumed to be unsupported by LLVM in general, therefore vector with `#elements > 65535` are disallowed ?
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 122537] [TBAA][GVN] Miscompile due to incorrectly replacing pointer with undef
Issue
122537
Summary
[TBAA][GVN] Miscompile due to incorrectly replacing pointer with undef
Labels
new issue
Assignees
mshockwave
Reporter
mshockwave
This is a relatively intertwinding bug and I think the best way to describe it is through chronological order:
At this moment RISC-V LLVM miscompiles 482.sphinx3 (and potentially 445.gobmk) when we enable VLS vectorization + LTO:
```
clang -O3 -flto -target riscv64-linux-gnu -mcpu=sifive-p670 -mrvv-vector-bits=zvl ...
```
If we remove the `-mrvv-vector-bits=zvl` flag (i.e. not using VLS vectorization), the issue goes away. Here are what happened:
1. With `-mrvv-vector-bits=zvl`, since we use a fixed VLEN all the `llvm.vscale` intrinsic calls will go away. All kinds of code simplifications then kick in and make some of the functions smaller
2. Some of the these functions started to get inlined, among them is a function (let's name it `allocate2D`) that allocates and returns a 2D array
3. This is what it looks like after `allocate2D` got inlined
``` llvm
declare i32 @bar(ptr nocapture noundef)
declare dso_local noalias noundef ptr @malloc(i64 noundef) local_unnamed_addr #0
define i32 @foo(ptr %src, i64 %num, i64 %N) {
b3:
%p0 = call noalias ptr @malloc(i64 noundef %num)
br label %b2
b2:
%offset = phi i64 [0, %b3], [%iv, %b2]
%p2 = getelementptr inbounds nuw ptr, ptr %p0, i64 %offset
store ptr %src, ptr %p2, align 8, !tbaa !4
%iv = add nuw nsw i64 %offset, 1
%c = icmp eq i64 %iv, %N
br i1 %c, label %b1, label %b2
b1:
%p = load ptr, ptr %p0, align 8, !tbaa !6
br label %b0
b0:
%r = call i32 @bar(ptr noundef %p)
ret i32 %r
}
attributes #0 = { mustprogress nofree nounwind willreturn allockind("alloc,uninitialized") allocsize(0) memory(inaccessiblemem: readwrite) "alloc-family"="malloc" }
!0 = !{!"any pointer", !1, i64 0}
!1 = !{!"omnipotent char", !2, i64 0}
!2 = !{!"Simple C/C++ TBAA"}
!3 = !{!"p1 omnipotent char", !0, i64 0}
!4 = !{!3, !3, i64 0}
!5 = !{!"p1 float", !0, i64 0}
!6 = !{!5, !5, i64 0}
```
b2, and b3 are originally belong to `allocate2D`: b3 do the malloc, b2 initialize the raw chunk of memory (the code showed here is NOT what it actually did but merely demonstrating that it's using a loop to initialize the memory). b1 and b0 grab the first row from this 2D array and pass it to `bar`.
4. The problem is, after GVN, `%r = call i32 @bar(ptr noundef %p)` will be turned into `%r = call i32 @bar(ptr noundef undef)`. Which is of course incorrect.
5. The reason GVN thought it's a good idea to replace %p with undef is twofold: first it uses MemoryDependenceAnalysis to retrieve all the dependencies of `%p = load ptr, ptr %p0, align 8, !tbaa !6`. And for some reasons it only returns `%p0 = call noalias ptr @malloc(i64 noundef %num)` as the only Def dependency and (incorrectly) ignores `store ptr %src, ptr %p2, align 8, !tbaa !4` which might clobber `%p0`. And since `malloc` has the `allockind("uninitialized")` attribute, loading unintialized content is, to my best understandingss, undefined behavior so the optimizer can replace it with whatever it wants, hence the undef value.
6. The store instruction was ignored because the AA pipeline thought `store ptr %src, ptr %p2` and `%p = load ptr, ptr %p0` have NoAlias, which is rare considered 90% of the time we expected MayAlias and also wrong -- it should return MayAlias for the potential clobber.
7. Now the problem can be boiled down to the incorrect AA result between the said load and store instructions. This AA query was first processed by BasicAA, which (correctly) returns MayAlias
8. But when it passes to the subsequent TBAA, it thought they are NoAlias because of their type descriptor graph. Specifically, this is store instruction's tree:
```
<0x55676658> = !{<0x555b33d8>, <0x555b33d8>, i64 0}
<0x555b33d8> = !{!"p1 omnipotent char", <0x5583a118>, i64 0}
!"p1 omnipotent char"
<0x5583a118> = !{!"any pointer", <0x5583a3c8>, i64 0}
!"any pointer"
<0x5583a3c8> = !{!"omnipotent char", <0x5583a0d8>, i64 0}
!"omnipotent char"
<0x5583a0d8> = !{!"Simple C/C++ TBAA"}
!"Simple C/C++ TBAA"
```
and this is load instruction's tree:
```
<0x557bdbe8> = !{<0x557c9108>, <0x557c9108>, i64 0}
<0x557c9108> = !{!"p1 float", <0x5583a118>, i64 0}
!"p1 sink"
<0x5583a118> = !{!"any pointer", <0x5583a3c8>, i64 0}
!"any pointer"
<0x5583a3c8> = !{!"omnipotent char", <0x5583a0d8>, i64 0}
!"omnipotent char"
<0x5583a0d8> = !{!"Simple C/C++ TBAA"}
!"Simple C/C++ TBAA"
```
And based on TBAA's rule, these two type descriptor graphs are indeed not alias.
___
llvm-bugs mailing list
ll
[llvm-bugs] [Bug 122543] Build failure when setting optimized tablegen
Issue 122543 Summary Build failure when setting optimized tablegen Labels new issue Assignees Reporter R-Goc When setting optimized tablegen: ```-DLLVM_OPTIMIZED_TABLEGEN=ON``` my build fails with this output: ``` FAILED: include/llvm/TargetParser/ARMTargetParserDef.inc D:/lib/llvm-dev/build/include/llvm/TargetParser/ARMTargetParserDef.inc C:\Windows\system32\cmd.exe /C "cd /D D:\lib\llvm-dev\build && D:\lib\llvm-dev\build\NATIVE\bin\llvm-min-tblgen.exe -gen-arm-target-def -I D:/lib/llvm-dev/llvm/lib/Target/ARM/ -I D:/lib/llvm-dev/llvm/include/llvm/TargetParser -ID:/lib/llvm-dev/build/include -ID:/lib/llvm-dev/llvm/include D:/lib/llvm-dev/llvm/lib/Target/ARM/ARM.td --write-if-changed -o include/llvm/TargetParser/ARMTargetParserDef.inc -d include/llvm/TargetParser/ARMTargetParserDef.inc.d" ``` All tablegen jobs tried fail with no output, and %errorlevel% is -1073741819 when they are ran separately. I'm on a windows system building with clang-cl 19.1.6. Full build command: ``` cmake -B build -GNinja -Sllvm -Wno-dev -DLLVM_ENABLE_PROJECTS="clang;lld" -DLLVM_ENABLE_RUNTIMES="compiler-rt;libcxx" -DCMAKE_BUILD_TYPE=Debug -DLLVM_PARALLEL_LINK_JOBS=3 -DLLVM_PARALLEL_COMPILE_JOBS=16 -DLLVM_TARGETS_TO_BUILD="X86" -DLLVM_ENABLE_RTTI=ON -DLLVM_ENABLE_EH=ON -DCMAKE_CXX_COMPILER=clang-cl.exe -DCMAKE_ASM_COMPILER=clang-cl.exe -DCMAKE_C_COMPILER=clang-cl.exe -DLLVM_ENABLE_LLD=ON -DCMAKE_C_COMPILER_LAUNCHER=sccache -DCMAKE_CXX_COMPILER_LAUNCHER=sccache -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -DLLVM_OPTIMIZED_TABLEGEN=ON ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 122553] [HLSL] cbuffer: Create host layout struct and add resource handle to AST
Issue
122553
Summary
[HLSL] cbuffer: Create host layout struct and add resource handle to AST
Labels
HLSL
Assignees
Reporter
hekota
The `cbuffer` language syntax allows declarations inside `cbuffer` context that do not contribute to the constant buffer layout, such as static variables, function definitions, declarations of classes and namespaces, resources, or empty struct and zero-sized arrays. As part of semantic analysis we need to create a "layout struct" for the constant buffer that will only include elements that affect the buffer memory layout. This layout struct will be used as the contained type of the `cbuffer` resource handle type and for layout calculations in codegen.
If the constant buffer includes a struct that contains any of the above undesirable declarations, a new version of this struct should be created with these declarations filtered out as well.
The buffer layout struct will be declared within the HLSLBufferDecl context and will be followed by 'cbuffer` resource handle declaration that will reference the layout struct as its contained type.
For example:
```
struct Something {
int a;
float f[0];
};
cbuffer CB {
float x;
RWBuffer buf;
Something s;
}
```
The buffer layout should look like this:
```
; struct hostlayout.CB
; {
; float x; ; Offset:0
; struct hostlayout.struct.Something
; {
; int a; ; Offset: 16
; } s; ; Offset: 16
; } CB; ; Offset:0 Size:20
;
```
And the resource handle added to the `HLSLBufferDecl` will look like this:
```
__hlsl_resource_t [[hlsl::resource_class(CBuffer)]] [[hlsl::contained_type(hostlayout.CB)] __handle;
```
https://godbolt.org/z/j37r1Tede
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 122560] [clang] Worse code gen when default constructing with `()` than `{}`
Issue
122560
Summary
[clang] Worse code gen when default constructing with `()` than `{}`
Labels
clang
Assignees
Reporter
davidstone
The following translation unit
```c++
long get();
void unused() noexcept;
struct s {
~s() {
if (m0 != 0) {
unused();
}
}
long m0 = 0;
long m1 = 0;
};
s f() {
#if defined USE_BRACES
auto x = s{};
#else
auto x = s();
#endif
x.m1 = get();
return x;
}
```
Generates the following code when compiled with `-DUSE_BRACES -O3 -emit-llvm`:
```
%struct.s = type { i64, i64 }
define dso_local void @f()(ptr dead_on_unwind noalias nocapture writable writeonly sret(%struct.s) align 8 initializes((0, 16)) %agg.result) local_unnamed_addr #0 personality ptr @__gxx_personality_v0 !dbg !21 {
entry:
#dbg_value(ptr %agg.result, !24, !DIExpression(DW_OP_deref), !25)
%m1 = getelementptr inbounds nuw i8, ptr %agg.result, i64 8, !dbg !26
store i64 0, ptr %agg.result, align 8, !dbg !26
%call = tail call noundef i64 @get()(), !dbg !27
store i64 %call, ptr %m1, align 8, !dbg !28
ret void, !dbg !34
}
declare !dbg !35 noundef i64 @get()() local_unnamed_addr #1
declare i32 @__gxx_personality_v0(...)
attributes #0 = { mustprogress uwtable "min-legal-vector-width"="0" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+cmov,+cx8,+fxsr,+mmx,+sse,+sse2,+x87" "tune-cpu"="generic" }
attributes #1 = { "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+cmov,+cx8,+fxsr,+mmx,+sse,+sse2,+x87" "tune-cpu"="generic" }
```
but generates the following when compiled with `-O3 -emit-llvm`:
```
%struct.s = type { i64, i64 }
define dso_local void @f()(ptr dead_on_unwind noalias nocapture writable writeonly sret(%struct.s) align 8 initializes((0, 16)) %agg.result) local_unnamed_addr #0 personality ptr @__gxx_personality_v0 !dbg !21 {
entry:
#dbg_value(ptr %agg.result, !24, !DIExpression(DW_OP_deref), !25)
#dbg_value(ptr %agg.result, !26, !DIExpression(), !31)
tail call void @llvm.memset.p0.i64(ptr noundef nonnull align 8 dereferenceable(16) %agg.result, i8 0, i64 16, i1 false), !dbg !33
%call = tail call noundef i64 @get()(), !dbg !34
%m1 = getelementptr inbounds nuw i8, ptr %agg.result, i64 8, !dbg !35
store i64 %call, ptr %m1, align 8, !dbg !36
ret void, !dbg !42
}
declare void @llvm.memset.p0.i64(ptr nocapture writeonly, i8, i64, i1 immarg) #1
declare !dbg !43 noundef i64 @get()() local_unnamed_addr #2
declare i32 @__gxx_personality_v0(...)
attributes #0 = { mustprogress uwtable "min-legal-vector-width"="0" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+cmov,+cx8,+fxsr,+mmx,+sse,+sse2,+x87" "tune-cpu"="generic" }
attributes #1 = { mustprogress nocallback nofree nounwind willreturn memory(argmem: write) }
attributes #2 = { "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+cmov,+cx8,+fxsr,+mmx,+sse,+sse2,+x87" "tune-cpu"="generic" }
```
These correspond to the assembly
`-DUSE_BRACES`:
```asm
f():
pushrbx
mov rbx, rdi
mov qword ptr [rdi], 0
callget()@PLT
mov qword ptr [rbx + 8], rax
mov rax, rbx
pop rbx
ret
```
and without:
```asm
f():
push rbx
mov rbx, rdi
xorps xmm0, xmm0
movups xmmword ptr [rdi], xmm0
callget()@PLT
mov qword ptr [rbx + 8], rax
mov rax, rbx
pop rbx
ret
```
See it live: https://godbolt.org/z/hfcPeTsfo
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 122577] Request Commit Access For veera-sivarajan
Issue 122577 Summary Request Commit Access For veera-sivarajan Labels infra:commit-access-request Assignees Reporter veera-sivarajan ### Why Are you requesting commit access ? I recently started contributing to the middle end of the compiler and plan to contribute regularly moving forward. So, having commit access would be helpful. Thank you ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 122435] [MinGW] [libunwind] undefined __gxx_personality_seh0 when build libunwind with LTO+Exceptions
Issue 122435 Summary [MinGW] [libunwind] undefined __gxx_personality_seh0 when build libunwind with LTO+Exceptions Labels new issue Assignees Reporter Andarwinux See #121819 for background context This may become a problem in the future, but for now it won't actually happen unless libunwind does switch to using `-fexceptions` to compile the whole library To build a libunwind that reproduces this problem, we need to hack the build system: ``` -DLIBUNWIND_ENABLE_SHARED=OFF -DCXX_SUPPORTS_FNO_EXCEPTIONS_FLAG=OFF -DCMAKE_C_FLAGS=“-flto=thin” -DCMAKE_CXX_FLAGS=“-flto=thin” ``` Then use `-flto=thin` to compile any source and link them with libunwind.a: ``` x86_64-w64-mingw32-clang -flto=thin test.c --static lld-link: error: undefined symbol: __gxx_personality_seh0 >>> referenced by llvm-project/libunwind/src/libunwind.cpp >>> libunwind.a(libunwind.cpp.obj) ``` [report.zip](https://github.com/user-attachments/files/18374405/report.zip) (lld reproduce) ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 122439] [DAG] SDPatternMatch - add m_Undef matcher
Issue 122439 Summary [DAG] SDPatternMatch - add m_Undef matcher Labels good first issue, llvm:SelectionDAG Assignees Reporter RKSimon Add SDPatternMatch matcher and unit test coverage for ISD::UNDEF opcode e.g. ``` m_InsertSubVector(m_Undef(), m_Value(), m_Zero()) // subvector widening pattern ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 122558] [LoopVectorizer] Assertion `EPResumeVal && "must have a resume value for the canonical IV"' failed.
Issue 122558 Summary [LoopVectorizer] Assertion `EPResumeVal && "must have a resume value for the canonical IV"' failed. Labels new issue Assignees Reporter JonPsson1 clang -Wno-incompatible-pointer-types -O3 -march=z13 -S -c crash19.i -o a.out -w -mllvm -disable-licm-promotion -mllvm -epilogue-vectorization-force-VF=2 [crash19.tar.gz](https://github.com/user-attachments/files/18383534/crash19.tar.gz) #9 0x02aa3ff5e440 preparePlanForEpilogueVectorLoop #12 0x02aa3ffa098a llvm::LoopVectorizePass::run @bmahjour @fhahn ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 122583] [SLPVectorizer] Miscompilation
Issue
122583
Summary
[SLPVectorizer] Miscompilation
Labels
miscompilation,
llvm:SLPVectorizer,
generated by fuzzer
Assignees
Reporter
dtcxzyw
Reproducer: https://godbolt.org/z/7eEEeeKoo
Sorry, I cannot provide alive2 link since `llvm.vector.insert.v8i64.v4i64` is not supported.
```
; bin/opt -passes=slp-vectorizer reduced.ll -S -o opt.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"
target triple = "x86_64-unknown-linux-gnu"
@j = global [4 x i64] zeroinitializer
define i32 @main() {
entry:
%.pre.i = load i64, ptr getelementptr inbounds nuw (i8, ptr @j, i64 24), align 8
%.pre50.i = load i64, ptr getelementptr inbounds nuw (i8, ptr @j, i64 16), align 16
%.pre51.i = load i64, ptr getelementptr inbounds nuw (i8, ptr @j, i64 8), align 8
%.pre52.i = load i64, ptr @j, align 16
%0 = or i64 %.pre51.i, 0
%1 = trunc i64 %.pre.i to i32
%2 = add i32 %1, 0
%3 = trunc i64 %.pre50.i to i32
%4 = add i32 %3, 0
%5 = trunc i64 %.pre51.i to i32
%6 = add i32 %5, 0
%7 = trunc i64 0 to i32
%8 = add i32 %5, 0
%9 = add i32 %7, 0
%10 = add i32 %1, 0
%11 = add i32 %3, 0
%12 = add i32 %5, 0
%13 = add i32 %7, 0
%14 = trunc i64 %.pre.i to i32
%15 = add i32 %14, 0
%16 = trunc i64 %.pre50.i to i32
%17 = add i32 %16, 0
%18 = trunc i64 %.pre51.i to i32
%19 = add i32 %18, 0
%20 = trunc i64 %.pre52.i to i32
%conv14.1.i = or i32 %9, %13
%21 = or i32 %conv14.1.i, %6
%22 = or i32 %21, %8
%23 = or i32 %22, %12
%24 = or i32 %23, %4
%25 = or i32 %24, %11
%26 = or i32 %25, %2
%27 = or i32 %26, %10
%28 = or i32 %27, %15
%29 = or i32 %28, %17
%30 = or i32 %29, %19
%31 = add i32 %14, 0
%32 = add i32 %16, 0
%33 = add i32 %18, 0
%34 = add i32 %20, 0
%35 = add i32 %14, 0
%36 = add i32 %16, 0
%37 = add i32 %18, 0
%38 = add i32 %20, 0
%39 = add i32 %14, 0
%40 = add i32 %16, 0
%41 = add i32 %18, 0
%42 = add i32 %20, 0
%inc.3.3.i.1 = or i64 %.pre52.i, 0
%conv14.i.1 = or i32 %38, %34
%conv14.1.i.1 = or i32 %conv14.i.1, %42
%conv14.3.i.1 = or i32 %conv14.1.i.1, %33
%conv14.145.i.1 = or i32 %conv14.3.i.1, %37
%conv14.1.1.i.1 = or i32 %conv14.145.i.1, %41
%conv14.3.1.i.1 = or i32 %conv14.1.1.i.1, %32
%conv14.247.i.1 = or i32 %conv14.3.1.i.1, %36
%conv14.1.2.i.1 = or i32 %conv14.247.i.1, %40
%conv14.3.2.i.1 = or i32 %conv14.1.2.i.1, %31
%conv14.349.i.1 = or i32 %conv14.3.2.i.1, %35
%conv14.1.3.i.1 = or i32 %conv14.349.i.1, %39
%conv14.3.3.i.1 = or i32 %conv14.1.3.i.1, %30
ret i32 %conv14.3.3.i.1
}
```
Output:
```
source_filename = "/app/example.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"
target triple = "x86_64-unknown-linux-gnu"
define i32 @main() {
%0 = load <4 x i64>, ptr @j, align 16
%1 = or i64 poison, 0
%2 = shufflevector <4 x i64> %0, <4 x i64> poison, <8 x i32>
%3 = shufflevector <4 x i64> %0, <4 x i64> poison, <8 x i32>
%4 = shufflevector <8 x i64> %3, <8 x i64> , <8 x i32>
%5 = call <8 x i64> @llvm.vector.insert.v8i64.v4i64(<8 x i64> %4, <4 x i64> %0, i64 0)
%6 = trunc <8 x i64> %5 to <8 x i32>
%7 = shufflevector <8 x i32> %6, <8 x i32> poison, <16 x i32>
%8 = add <16 x i32> %7, zeroinitializer
%9 = extractelement <4 x i64> %0, i32 0
%inc.3.3.i.1 = or i64 %9, 0
%10 = call i32 @llvm.vector.reduce.or.v16i32(<16 x i32> %8)
%11 = call i32 @llvm.vector.reduce.or.v8i32(<8 x i32> poison)
%op.rdx = or i32 %10, %11
ret i32 %op.rdx
}
declare <8 x i64> @llvm.vector.insert.v8i64.v4i64(<8 x i64>, <4 x i64>, i64 immarg) #0
declare i32 @llvm.vector.reduce.or.v16i32(<16 x i32>) #0
declare i32 @llvm.vector.reduce.or.v8i32(<8 x i32>) #0
attributes #0 = { nocallback nofree nosync nounwind speculatable willreturn memory(none) }
```
lli output:
```
> bin/lli reduced.ll
> echo $?
0
> bin/lli opt.ll
> echo $?
255
```
[llubi](https://github.com/dtcxzyw/llvm-ub-aware-interpreter) output:
Before:
```
> ./llubi reduced.ll --verbose
Entering function main
%0 = getelementptr inbounds nuw i8, ptr @j, i64 24 -> Ptr 40[@j + 24]
%.pre.i = load i64, ptr %0, align 8 -> i64 0
%1 = getelementptr inbounds nuw i8, ptr @j, i64 16 -> Ptr 32[@j + 16]
%.pre50.i = load i64, ptr %1, align 16 -> i64 0
%2 = getelementptr inbounds nuw i8, ptr @j, i64 8 -> Ptr 24[@j + 8]
%.pre51.i = load i64, ptr %2, align 8 -> i64 0
%.pre52.i = load i64, ptr @j, align 16 -> i64 0
%3 = or i64 %.pre51.i, 0 -> i64 0
%4 = trunc i64 %.pre.i to i32 -> i32 0
%5 = add i32 %4, 0 -> i32 0
%6 = trunc i64 %.pre50.i to i32 -> i32 0
%7 = add i32 %6, 0 -> i32 0
%8 = trunc i64 %.pre51.i to i32 -> i32 0
%9 = add i32 %8, 0 -> i32 0
%10 = trunc i64 0 to i32 -> i32 0
%11 = add i32 %8, 0 -> i32 0
%1
[llvm-bugs] [Bug 122457] [Clang] Diagnose invalid pointer overflow check with intermediate variable
Issue
122457
Summary
[Clang] Diagnose invalid pointer overflow check with intermediate variable
Labels
clang:diagnostics
Assignees
Reporter
nikic
https://github.com/llvm/llvm-project/pull/120222 added support to `-Wtautological-compare` to diagnose comparisons like `ptr + unsigned_offset < ptr`, which are always false due to undefined behavior on pointer overflow during addition.
However, most commonly this pattern appears when the result of the addition is stored in an intermediate variable first (because it will also be used later):
```
bool test(const char *ptr, size_t index) {
const char *end_ptr = ptr + index;
return end_ptr < ptr;
}
```
It would be great to diagnose these cases as well, based on CFG analysis.
cc @AaronBallman @ldionne as we discussed this on Wednesday.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 122461] [LV][EVL] Incorrect behavior of fixed-order recurrence idiom with EVL tail folding
Issue 122461 Summary [LV][EVL] Incorrect behavior of fixed-order recurrence idiom with EVL tail folding Labels vectorizers Assignees Mel-Chen Reporter Mel-Chen When enabling EVL tail folding, the llvm.splice operation may encounter errors in the final iteration because the EVL in the second-to-last iteration might not equal VF * UF. This could result in unexpected behavior, such as: ``` llvm.splice([A, B, C, poison], [D, E, poison, poison], -1) ==> [poison, D, E, poison] ``` This issue was identified by the LLVM test-suite in `SingleSource/UnitTests/Vectorizer/recurrences.test`. ``` Checking first_order_recurrence Checking second_order_recurrence Checking third_order_recurrence Miscompare ``` Currently, we have temporarily disabled this feature using https://github.com/llvm/llvm-project/pull/122458. It will be re-enabled after implementing the following fixes. ``` vector.ph:; preds = %for.body.preheader.i.i.i ... %max.vf.1 = tail call i32 @llvm.vscale.i32() %max.vf = shl nuw nsw i32 %max.vf.1, 2 br label %vector.body vector.body: ; preds = %vector.body, %vector.ph %index = phi i64 [ 0, %vector.ph ], [ %index.next, %vector.body ] %evl.based.iv = phi i64 [ 0, %vector.ph ], [ %index.evl.next, %vector.body ] ### Record the evl of previous iteration. Initialized by VF ### %prev.evl = phi i32 [ %max.vf, %vector.ph ], [ %17, %vector.body ] %vector.recur = phi [ %vector.recur.init, %vector.ph ], [ %vp.op.load, %vector.body ] %vector.recur8 = phi [ %vector.recur.init7, %vector.ph ], [ %19, %vector.body ] %vector.recur10 = phi [ %vector.recur.init9, %vector.ph ], [ %20, %vector.body ] %avl = sub i64 %wide.trip.count.i.i.i, %evl.based.iv %17 = tail call i32 @llvm.experimental.get.vector.length.i64(i64 %avl, i32 4, i1 true) %18 = getelementptr inbounds nuw i32, ptr %__args.val, i64 %evl.based.iv %vp.op.load = tail call @llvm.vp.load.nxv4i32.p0(ptr align 4 %18, splat (i1 true), i32 %17), !tbaa !6 ### Replace llvm.splice with llvm.experimental.vp.splice. ### %19 = tail call @llvm.experimental.vp.splice.nxv4i32( %vector.recur, %vp.op.load, i32 -1, splat (i1 true), i32 %prev.evl, i32 %17) %20 = tail call @llvm.experimental.vp.splice.nxv4i32( %vector.recur8, %19, i32 -1, splat (i1 true), i32 %prev.evl, i32 %17) %21 = tail call @llvm.experimental.vp.splice.nxv4i32( %vector.recur10, %20, i32 -1, splat (i1 true), i32 %prev.evl, i32 %17) %vp.op = tail call @llvm.vp.add.nxv4i32( %20, %19, splat (i1 true), i32 %17) %vp.op11 = tail call @llvm.vp.add.nxv4i32( %vp.op, %21, splat (i1 true), i32 %17) %22 = getelementptr inbounds nuw i32, ptr %__args1.val, i64 %evl.based.iv tail call void @llvm.vp.store.nxv4i32.p0( %vp.op11, ptr align 4 %22, splat (i1 true), i32 %17), !tbaa !6 %23 = zext i32 %17 to i64 %index.evl.next = add nuw i64 %evl.based.iv, %23 %index.next = add nuw i64 %index, %7 %24 = icmp eq i64 %index.next, %n.vec br i1 %24, label %"_ZSt10__invoke_rIvRZ4mainE3$_1JPjS2_jEENSt9enable_ifIX16is_invocable_r_vIT_T0_DpT1_EES4_E4typeEOS5_DpOS6_.exit", label %vector.body, !llvm.loop !39 ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 122467] crash compiling with TypeSanitizer
Issue 122467 Summary crash compiling with TypeSanitizer Labels crash, compiler-rt:tysan Assignees Reporter firewave ``` Stack dump: 0. Program arguments: /usr/bin/clang++-20 -DCHECK_INTERNAL -DFILESDIR=\"/mnt/s/GitHub/cppcheck-fw\" -DHAVE_RULES -D_LIBCPP_HARDENING_MODE=_LIBCPP_HARDENING_MODE_DEBUG -I/mnt/s/GitHub/cppcheck-fw/cmake-build-debug-wsl-ubuntu-2004-clang-20-libcxx/lib -I/mnt/s/GitHub/cppcheck-fw/lib -I/mnt/s/GitHub/cppcheck-fw/externals -I/mnt/s/GitHub/cppcheck-fw/externals/tinyxml2 -I/mnt/s/GitHub/cppcheck-fw/externals/picojson -I/mnt/s/GitHub/cppcheck-fw/externals/simplecpp -g -Weverything -pedantic -gdwarf-4 -stdlib=libc++ -Wno-documentation-unknown-command -Wno-unused-exception-parameter -Wno-old-style-cast -Wno-sign-conversion -Wno-shadow-field-in-constructor -Wno-covered-switch-default -Wno-shorten-64-to-32 -Wno-implicit-int-conversion -Wno-double-promotion -Wno-shadow-field -Wno-shadow-uncaptured-local -Wno-implicit-float-conversion -Wno-switch-enum -Wno-date-time -Wno-disabled-macro-expansion -Wno-bitwise-instead-of-logical -Wno-sign-compare -Wno-unsafe-buffer-usage -Wno-global-constructors -Wno-exit-time-destructors -Wno-padded -Wno-c++98-compat -Wno-c++98-compat-pedantic -Wno-switch-default -Wno-four-char-constants -Wno-weak-vtables -Wno-multichar -U_GLIBCXX_DEBUG -fsanitize=type -std=c++11 -Xclang -include-pch -Xclang /mnt/s/GitHub/cppcheck-fw/cmake-build-debug-wsl-ubuntu-2004-clang-20-libcxx/lib/CMakeFiles/cppcheck-core.dir/cmake_pch.hxx.pch -o CMakeFiles/cppcheck-core.dir/vf_analyzers.cpp.o -c /mnt/s/GitHub/cppcheck-fw/lib/vf_analyzers.cpp 1. parser at end of file 2. Optimizer 3. Running pass "tysan" on module "/mnt/s/GitHub/cppcheck-fw/lib/vf_analyzers.cpp" Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it): 0 libLLVM.so.20.0 0x7f6b63feba96 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 54 1 libLLVM.so.20.0 0x7f6b63fe9740 llvm::sys::RunSignalHandlers() + 80 2 libLLVM.so.20.0 0x7f6b63feaef4 llvm::sys::CleanupOnSignal(unsigned long) + 244 3 libLLVM.so.20.0 0x7f6b63f35370 4 libpthread.so.0 0x7f6b6f76c420 5 libLLVM.so.20.0 0x7f6b6419a070 llvm::Value::getContext() const + 0 6 libLLVM.so.20.0 0x7f6b64e3f14e 7 libLLVM.so.20.0 0x7f6b64e3db04 llvm::TypeSanitizerPass::run(llvm::Module&, llvm::AnalysisManager&) + 6116 8 libclang-cpp.so.20.0 0x7f6b6d4e3dbd 9 libLLVM.so.20.0 0x7f6b64175327 llvm::PassManager>::run(llvm::Module&, llvm::AnalysisManager&) + 487 10 libclang-cpp.so.20.0 0x7f6b6d4dbcac 11 libclang-cpp.so.20.0 0x7f6b6d4d4b93 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::IntrusiveRefCntPtr, std::unique_ptr>, clang::BackendConsumer*) + 6739 12 libclang-cpp.so.20.0 0x7f6b6d8a54a4 clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 2052 13 libclang-cpp.so.20.0 0x7f6b6c4325c9 clang::ParseAST(clang::Sema&, bool, bool) + 633 14 libclang-cpp.so.20.0 0x7f6b6e3152d5 clang::FrontendAction::Execute() + 85 15 libclang-cpp.so.20.0 0x7f6b6e28fa14 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 980 16 libclang-cpp.so.20.0 0x7f6b6e39761e clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 702 17 clang++-20 0x7f6b6f7dcacf cc1_main(llvm::ArrayRef, char const*, void*) + 5903 18 clang++-20 0x7f6b6f7d9b35 19 libclang-cpp.so.20.0 0x7f6b6df2dac9 20 libLLVM.so.20.0 0x7f6b63f35108 llvm::CrashRecoveryContext::RunSafely(llvm::function_ref) + 136 21 libclang-cpp.so.20.0 0x7f6b6df2d5dd clang::driver::CC1Command::Execute(llvm::ArrayRef>, std::__cxx11::basic_string, std::allocator>*, bool*) const + 365 22 libclang-cpp.so.20.0 0x7f6b6def7566 clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, clang::driver::Command const*&, bool) const + 486 23 libclang-cpp.so.20.0 0x7f6b6def771e clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&, llvm::SmallVectorImpl>&, bool) const + 142 24 libclang-cpp.so.20.0 0x7f6b6df1198d clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&, llvm::SmallVectorImpl>&) + 365 25 clang++-20 0x7f6b6f7d960f clang_main(int, char**, llvm::ToolContext const&) + 6223 26 clang++-20 0x7f6b6f7e5c86 main + 102 27 libc.so.60x7f6b62b04083 __libc_start_main + 243 28 clang++-20 0x7f6b6f7d7a6e _start + 46 clang++-20: error: clang frontend command failed with exit code 139 (use -v to see invocati
[llvm-bugs] [Bug 122451] Request Commit Access For emaxx-google
Issue 122451 Summary Request Commit Access For emaxx-google Labels infra:commit-access-request Assignees Reporter emaxx-google ### Why Are you requesting commit access ? A Google engineer working on Clang Frontend. Commit access would let me land PRs myself (per approval). ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 122453] OpenCL C++: printf becomes mangled c++ symbol, not working with e.g. pocl and llvm-spirv
Issue
122453
Summary
OpenCL C++: printf becomes mangled c++ symbol, not working with e.g. pocl and llvm-spirv
Labels
new issue
Assignees
Reporter
davidrohr
With clang 19.1.3, the following example
```
__kernel void test()
{
printf("test");
}
```
compiles in OpenCL C mode to SPIRV:
```
clang++ --target=spirv64 -cl-std=CL2.0 -fno-integrated-objemitter -o test.spirv test.cl -O0
```
but in C++ for OpenCL mode
```
clang++ --target=spirv64 -cl-std=CLC++2021 -fno-integrated-objemitter -o test.spirv test.cl -O0
```
I get:
```
error: 0: Unresolved external reference to "_Z6printfPU3AS2Kcz".
clang++: error: spirv-link command failed with exit code 1 (use -v to see invocation)
```
(the same happens with `-cl-std clc++`).
It seems that the LLVM-SPIRV translater expects an unmangled printf symbol, but llvm emits a C++ mangled symbol.
It works when I use the experimental internal SPIRV emiter via `-fintegrated-objemitter`.
Also with POCL it does not work due to the mangled symbol (see https://github.com/pocl/pocl/issues/1759), thus I assume llvm should produce an unmangled printf symbol as specified in OpenCL 1.2. Or all other software packages will need to adapt for `clc++`.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 122470] TypeSanitizer errors with global or static STL container
Issue
122470
Summary
TypeSanitizer errors with global or static STL container
Labels
compiler-rt:tysan
Assignees
Reporter
firewave
```cpp
#include
static const std::unordered_set s_s;
int main()
{
}
```
```
==1==ERROR: TypeSanitizer: type-aliasing-violation on address 0x6166d60cfca8 (pc 0x6166d5769c55 bp 0x7fffc9c45f90 sp 0x7fffc9c45f20 tid 1)
WRITE of size 8 at 0x6166d60cfca8 with type long (in std::__1::__bucket_list_deallocator*>*>> at offset 0) accesses part of an existing object of type std::__1::unordered_set, std::__1::equal_to, std::__1::allocator> that starts at offset -8
#0 0x6166d5769c54 (/app/output.s+0x2dc54)
==1==ERROR: TypeSanitizer: type-aliasing-violation on address 0x6166d60cfcb0 (pc 0x6166d5769385 bp 0x7fffc9c46000 sp 0x7fffc9c45f90 tid 1)
WRITE of size 8 at 0x6166d60cfcb0 with type p1 _ZTSNSt3__116__hash_node_baseIPNS_11__hash_nodeIiPv (in std::__1::__hash_node_base*> at offset 0) accesses part of an existing object of type std::__1::unordered_set, std::__1::equal_to, std::__1::allocator> that starts at offset -16
#0 0x6166d5769384 (/app/output.s+0x2d384)
==1==ERROR: TypeSanitizer: type-aliasing-violation on address 0x6166d60cfcb8 (pc 0x6166d57687bf bp 0x7fffc9c46070 sp 0x7fffc9c46000 tid 1)
WRITE of size 8 at 0x6166d60cfcb8 with type long (in std::__1::__hash_table, std::__1::equal_to, std::__1::allocator> at offset 24) accesses part of an existing object of type std::__1::unordered_set, std::__1::equal_to, std::__1::allocator> that starts at offset -24
#0 0x6166d57687be (/app/output.s+0x2c7be)
==1==ERROR: TypeSanitizer: type-aliasing-violation on address 0x6166d60cfcc0 (pc 0x6166d5768920 bp 0x7fffc9c46070 sp 0x7fffc9c46000 tid 1)
WRITE of size 4 at 0x6166d60cfcc0 with type float (in std::__1::__hash_table, std::__1::equal_to, std::__1::allocator> at offset 32) accesses part of an existing object of type std::__1::unordered_set, std::__1::equal_to, std::__1::allocator> that starts at offset -32
#0 0x6166d576891f (/app/output.s+0x2c91f)
==1==ERROR: TypeSanitizer: type-aliasing-violation on address 0x6166d60cfcb0 (pc 0x6166d576ac5d bp 0x7fffc9c45fa0 sp 0x7fffc9c45f30 tid 1)
READ of size 8 at 0x6166d60cfcb0 with type p1 _ZTSNSt3__116__hash_node_baseIPNS_11__hash_nodeIiPv (in std::__1::__hash_table, std::__1::equal_to, std::__1::allocator> at offset 16) accesses part of an existing object of type std::__1::unordered_set, std::__1::equal_to, std::__1::allocator> that starts at offset -16
#0 0x6166d576ac5c (/app/output.s+0x2ec5c)
```
https://godbolt.org/z/sjnE1974P
Errors will also be reported if you remove the `static` or if you move the static declaration into the function.
A local declaration is not causing any errors.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 122441] std::barrier constructor is not constexpr
Issue 122441 Summary std::barrier constructor is not constexpr Labels new issue Assignees Reporter jwakely See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118395 where this was first reported. Everything below only applies when `_LIBCPP_HAS_NO_TREE_BARRIER` is undefined, but that seems to be always true? I'm not sure, see https://github.com/llvm/llvm-project/blob/3def49cb64ec1298290724081bd37dbdeb2ea5f8/libcxx/test/tools/clang_tidy_checks/internal_ftm_use.cpp#L29-L30 The `std::barrier(ptrdiff_t, CompletionFunction)` is supposed to be constexpr. It can't be, because it calls a non-inline function which allocates memory. Also `std::barrier<>(std::barrier<>::max())` should be valid, but `max()` just returns `numeric_limits::max()` and then the non-inline allocating function does: https://github.com/llvm/llvm-project/blob/3def49cb64ec1298290724081bd37dbdeb2ea5f8/libcxx/src/barrier.cpp#L28-L29 so if `__expected == max()` then `__expected + 1` overflows, with undefined behaviour. Yay. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 122442] Missed optimization: (x % (C1 * C2) / C2) vs. ((x / C2) % C1)
Issue
122442
Summary
Missed optimization: (x % (C1 * C2) / C2) vs. ((x / C2) % C1)
Labels
new issue
Assignees
Reporter
Explorer09
When an _expression_ contains modulo and division, if the modulo happens first but the divisor is a multiple of the divisor later on, the _expression_ can be optimized by swapping and division and modulo, especially when this can reduce code size (`-Os` option).
(Sometimes it is desirable to swap the operators the other way around, if the compiler can tell if the divisor has been loaded already by the surrounding code.)
Below are the examples: `func1a`, `func1b` and `func1c` are equivalent; likewise for `func2a`, `func2b` and `func2c`.
(Can be tested in Compiler Explorer. x86-64 clang 19.1.0 with `-Os` option)
```c
unsigned long long func1a(unsigned long long x) {
return (x / 60) % 60;
}
unsigned long long func1b(unsigned long long x) {
return (x % 3600) / 60;
}
unsigned long long func1c(unsigned long long x) {
return (x % (60 * 60)) / 60;
}
unsigned long long func2a(unsigned long long x) {
return (x / 60) % 24;
}
unsigned long long func2b(unsigned long long x) {
return (x % 1440) / 60;
}
unsigned long long func2c(unsigned long long x) {
return (x % (24 * 60)) / 60;
}
```
Note: I also reported this bug in gcc (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118397)
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 122480] clang-tidy modernize-use-default-member-init false negatives
Issue
122480
Summary
clang-tidy modernize-use-default-member-init false negatives
Labels
clang-tidy
Assignees
Reporter
nick-potenski
clang-tidy's modernize-use-default-member-init check will ignore constructor member initializers that either directly or indirectly use mathematical operations or casting. For instance, the following code only generates a warning for struct member `a`. Live example in compiler explorer here: https://godbolt.org/z/9E7Pv5jfa.
```
#define THE_ANSWER (44 - 2)
struct Bar {
Bar() : a{0}, b{1 + 1}, c{THE_ANSWER}, d{static_cast(-1)} {}
int a;
int b;
int c;
unsigned int d;
};
```
```
[:5:9: warning: use default member initializer for 'a' [modernize-use-default-member-init]](_javascript_:;)
4 | Bar() : a{0}, b{1 + 1}, c{THE_ANSWER}, d{static_cast(-1)} {}
|
5 | int a;
| ^
| {0}
1 warning generated.
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 122496] [clang] Miscompilation at -O2/3
Issue
122496
Summary
[clang] Miscompilation at -O2/3
Labels
clang
Assignees
Reporter
cardigan1008
This code prints 0 at `-O0/1` and triggers SIGKILL at `-O2/3`:
```c
int printf(const char *, ...);
int a;
short b, c;
long e;
int f[8][1];
unsigned g;
int h(int i) {
long d = 0;
for (; (a -= i) >= 0; d += 6)
;
return d;
}
void j() {
g = 0;
for (; h(90) + g <= 0; g++) {
int k = -1;
b = 0;
for (; k + g - -1 + b <= 3; b++)
f[b + 3][0] = c;
for (; b + g - 3 + e <= 8; e++)
;
for (; e <= 3;)
;
}
}
int main() {
j();
printf("%d\n", f[0][0]);
}
```
Compiler Explorer: https://godbolt.org/z/3x8Yc3fnW
It seems to be a recent regression.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 122479] [Clang] Crash involving lambda in unevaluated context and initialization of a static constexpr member of a class template
Issue
122479
Summary
[Clang] Crash involving lambda in unevaluated context and initialization of a static constexpr member of a class template
Labels
clang
Assignees
Reporter
MagentaTreehouse
The following C++20 code causes a crash:
```c++
template
struct A {
F funcObj;
};
template
struct B {
static constexpr auto f{A{}.funcObj};
};
int main() {
B<0>::f;
}
```
See https://compiler-explorer.com/z/caoTTePx1.
Assertion:
```console
clang++: /root/llvm-project/clang/lib/Sema/SemaDecl.cpp:16395:
clang::Decl* clang::Sema::ActOnFinishFunctionBody(clang::Decl*, clang::Stmt*, bool):
Assertion `!Cleanup.exprNeedsCleanups() && "Unaccounted cleanups in function"' failed.
```
Stack dump
```console
0. Program arguments: /opt/compiler-explorer/clang-assertions-trunk/bin/clang++ -gdwarf-4 -g -o /app/output.s -mllvm --x86-asm-syntax=intel -fno-verbose-asm -S --gcc-toolchain=/opt/compiler-explorer/gcc-snapshot -fcolor-diagnostics -fno-crash-diagnostics -std=c++20
1. parser at end of file
2. :11:12: parsing function body 'main'
#0 0x03c905f8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x3c905f8)
#1 0x03c8e304 llvm::sys::CleanupOnSignal(unsigned long) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x3c8e304)
#2 0x03bda5f8 CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0
#3 0x7feddc842520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#4 0x7feddc8969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
#5 0x7feddc842476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
#6 0x7feddc8287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
#7 0x7feddc82871b (/lib/x86_64-linux-gnu/libc.so.6+0x2871b)
#8 0x7feddc839e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96)
#9 0x069dcd2b clang::Sema::ActOnFinishFunctionBody(clang::Decl*, clang::Stmt*, bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x69dcd2b)
#10 0x067367ef clang::Parser::ParseFunctionStatementBody(clang::Decl*, clang::Parser::ParseScope&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x67367ef)
#11 0x06648bb3 clang::Parser::ParseFunctionDefinition(clang::ParsingDeclarator&, clang::Parser::ParsedTemplateInfo const&, clang::Parser::LateParsedAttrList*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6648bb3)
#12 0x0667d68d clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, clang::DeclaratorContext, clang::ParsedAttributes&, clang::Parser::ParsedTemplateInfo&, clang::SourceLocation*, clang::Parser::ForRangeInit*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x667d68d)
#13 0x0663c91e clang::Parser::ParseDeclOrFunctionDefInternal(clang::ParsedAttributes&, clang::ParsedAttributes&, clang::ParsingDeclSpec&, clang::AccessSpecifier) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x663c91e)
#14 0x0663d0d9 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::ParsedAttributes&, clang::ParsedAttributes&, clang::ParsingDeclSpec*, clang::AccessSpecifier) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x663d0d9)
#15 0x06644883 clang::Parser::ParseExternalDeclaration(clang::ParsedAttributes&, clang::ParsedAttributes&, clang::ParsingDeclSpec*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6644883)
#16 0x0664575d clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&, clang::Sema::ModuleImportState&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x664575d)
#17 0x06637bba clang::ParseAST(clang::Sema&, bool, bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6637bba)
#18 0x0461eed8 clang::CodeGenAction::ExecuteAction() (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x461eed8)
#19 0x048dca59 clang::FrontendAction::Execute() (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x48dca59)
#20 0x0485f0be clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x485f0be)
#21 0x049c9d1e clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x49c9d1e)
#22 0x00cef5af cc1_main(llvm::ArrayRef, char const*, void*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0xcef5af)
#23 0x00ce707a ExecuteCC1Tool(llvm::SmallVectorImpl&, llvm::ToolContext const&) driver.cpp:0:0
#24 0x04664cd9 void llvm::function_ref::callback_fn>, std::__cxx11::basic_string, std::allocator>*, bool*) const::'lambda'()>(long) Job.cpp:0:0
#25 0x03bdaaa4 llvm::CrashRecoveryContext::RunSafely(llvm::function_ref) (/opt/compiler-explorer/clang-assertions-
[llvm-bugs] [Bug 122493] Assertion failure and invalid Wunitialized error after
Issue 122493 Summary Assertion failure and invalid Wunitialized error after Labels clang:modules Assignees dmpolukhin Reporter ilya-biryukov After https://github.com/llvm/llvm-project/commit/38b3d87bd384a469a6618ec6a971352cb4f813ba we started seeing invalid `Wunitialized` errors in some rare cases involving modules with lambdas and an assertion failures. See https://gcc.godbolt.org/z/GzP568fxd for the code causing this (it's a result of `-frewrite-imports`, so slightly unreadable, sorry about that). (Click to expand) Assertion `isa(D) && "declaration not instantiated in this scope"' failed. ) ```shell clang-20: /usr/local/google/home/ibiryukov/code/llvm-project/clang/lib/Sema/SemaTemplateInstantiate.cpp:4646: llvm::PointerUnion *clang::LocalInstantiationScope::findInstantiationOf(const Decl *): Assertion `isa(D) && "declaration not instantiated in this scope"' failed. PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script. Stack dump: 0. Program arguments: /usr/local/google/home/ibiryukov/code/llvm-project/build/bin/clang-20 -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -dumpdir a- -disable-free -clear-ast-before-backend -main-file-name all.cc -mrelocation-model pic -pic-level 2 -pic-is-pie -mframe-pointer=all -fmath-errno -ffp-contract=on -f no-rounding-math -mconstructor-aliases -funwind-tables=2 -target-cpu x86-64 -tune-cpu generic -debugger-tuning=gdb -fdebug-compilation-dir=/usr/local/google/home/ibiryukov/repro/uninit/foobarbaz -fcoverage-compilation-dir=/usr/local/google/home/ibiryukov/repro/uninit/foobarbaz -resource-dir /usr/local/google/home/ibiry ukov/code/llvm-project/build/lib/clang/20 -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/14/../../../../include/c++/14 -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/14/../../../../include/x86_64-linux-gnu/c++/14 -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/14/../../../../include/c++/14/backward -internal-isystem /usr/local/google/home/ibiryukov/code/llvm-project/build/lib/clang/20/include -internal-isystem /usr/local/include -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/14/../../../../x86_64-linux-gnu/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -fdeprecated-macro -ferror-limit 19 -fgnuc-version=4.2.1 -fmodules -fimplicit-module-maps -fmodules-cache-path=/usr/local/google/home/ibiryukov/.cache/clang/ModuleCache -fmodules-validate-system-headers -fskip-odr-check-in-gmf -fcxx-exceptions -fexceptions -fcolor-diagnostics -faddrsig -D__GCC_HAVE_DWARF2_ CFI_ASM=1 -o /tmp/all-46cd28.o -x c++ all.cc 1. parser at end of file 2. /usr/local/google/home/ibiryukov/repro/uninit/foobarbaz/bbb/public/sql_transform_builder.h:18:8: instantiating function definition 'www::SqlTransformBuilder::DoTransform' 3. /usr/local/google/home/ibiryukov/repro/uninit/foobarbaz/bbb/public/sql_transform_builder.h:11:13: instantiating function definition 'www::DecodeHelper2' 4. /usr/local/google/home/ibiryukov/repro/uninit/foobarbaz/bitset/set_bits2.h:13:6: instantiating function definition 'aaa::bitset::ForEachSetBit2<(lambda at /usr/local/google/home/ibiryukov/repro/uninit/foobarbaz/bbb/public/sql_transform_builder.h:12:31)>' #0 0x556d9f07a4c8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /usr/local/google/home/ibiryukov/code/llvm-project/llvm/lib/Support/Unix/Signals.inc:800:13 #1 0x556d9f07807e llvm::sys::RunSignalHandlers() /usr/local/google/home/ibiryukov/code/llvm-project/llvm/lib/Support/Signals.cpp:106:18 #2 0x556d9f07ab58 SignalHandler(int) /usr/local/google/home/ibiryukov/code/llvm-project/llvm/lib/Support/Unix/Signals.inc:417:1 #3 0x7f5fb1029590 (/lib/x86_64-linux-gnu/libc.so.6+0x3f590) #4 0x7f5fb10783ac __pthread_kill_implementation ./nptl/pthread_kill.c:44:76 #5 0x7f5fb10294f2 raise ./signal/../sysdeps/posix/raise.c:27:6 #6 0x7f5fb10124ed abort ./stdlib/abort.c:81:7 #7 0x7f5fb1012415 _nl_load_domain ./intl/loadmsgcat.c:1177:9 #8 0x7f5fb1022012 (/lib/x86_64-linux-gnu/libc.so.6+0x38012) #9 0x556da1f9e6cf dyn_cast /usr/local/google/home/ibiryukov/code/llvm-project/llvm/include/llvm/Support/Casting.h:662:3 #10 0x556da1f9e6cf clang::LocalInstantiationScope::findInstantiationOf(clang::Decl const*) /usr/local/google/home/ibiryukov/code/llvm-project/clang/lib/Sema/SemaTemplateInstantiate.cpp:4610:32 #11 0x556da2031dce clang::Sema::FindInstantiatedDecl(clang::SourceLocation, clang::NamedDecl*, clang::MultiLevelTemplateArgumentList const&, bool) /usr/local/google/home/ibiryukov/code/llvm-project/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp:6216:16 #12 0x556da1ffb1a1 clang
[llvm-bugs] [Bug 122490] [Flang] Incorrect diagnostic of defined assignment
Issue 122490 Summary [Flang] Incorrect diagnostic of defined assignment Labels bug, flang:frontend Assignees Reporter DanielCChen Consider the following code ``` module m type base contains procedure, pass(b) :: U_base generic :: assignment(=) => U_base end type contains subroutine U_base ( a, b ) class(*), intent(out) :: a class(base), intent(in) :: b end subroutine end module ``` Flang currently issues an error as ``` ./t.f:8:38: error: Defined assignment subroutine 'u_base' conflicts with intrinsic assignment generic :: assignment(=) => U_base ^^ ./t.f:13:15: Declaration of 'u_base' subroutine U_base ( a, b ) ^^ ``` This seems incorrect. The compilers that I have tried (gfortran, ifort and XLF) all compiled it successfully. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 122502] [libc++] `shrink_to_fit` never shrinks
Issue
122502
Summary
[libc++] `shrink_to_fit` never shrinks
Labels
libc++
Assignees
Reporter
winner245
The current implementation of the `shrink_to_fit` function in `vector` effectively acts as a no-op, failing to shrink the capacity to fit the size. This can be demonstrated with the following example:
[Godbolt Link](https://godbolt.org/z/cYs9bMn9f)
```cpp
#include
#include
int main() {
std::vector v(1024, true);
std::cout << "Before shrink: capacity = " << v.capacity() << '\n';
v.erase(v.begin() + 512, v.end());
v.shrink_to_fit();
std::cout << "After shrink: capacity = " << v.capacity() << '\n';
v.erase(v.begin(), v.end());
v.shrink_to_fit();
std::cout << "After shrink: capacity = " << v.capacity() << '\n';
}
```
Program output:
```
Before shrink: capacity = 1024
After shrink: capacity = 1024
After shrink: capacity = 1024
```
This is because the current implementation of `shrink_to_fit` checks the following condition
```cpp
if (__external_cap_to_internal(size()) > __cap_) {
try {
do_shrink();
} catch (...) {
}
}
```
However, this condition is **always false**, as the number of used internal words `__external_cap_to_internal(size())` will never exceed the internal storage capacity `__cap_`. Thus, the above implementation is equivalent to
```cpp
if (false) {
...
}
```
which will never shrink.
While the current implementation of `shrink_to_fit` technically conforms to the standard—since the shrink-to-fit request is non-binding—it appears to be a logical error that messed up `>` and `<`, particularly since a similar logical error was found in the `__split_buffer::reserve`, where `<` was incorrectly used instead of `>` (an issue reported in #105681 and fixed in #115735).
Proposed Solution
If the intent is to keep the existing no-op behavior, the function should be modified to have an empty body. The current implementation, which is non-empty yet effectively behaves as empty, is misleading.
Another approach would be modifying `shrink_to_fit` to actually perform capacity reduction, aligning its behavior with the `shrink_to_fit` function of `std::vector`. This approach is currently being pursued in #120495.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 122500] [libc] gcc errors related to complex floats
Issue
122500
Summary
[libc] gcc errors related to complex floats
Labels
libc
Assignees
lntue,
Sh0g0-1758
Reporter
nickdesaulniers
```
$ gcc --version | head -n1
gcc (Debian 14.2.0-3+build3) 14.2.0
$ cmake ../runtimes -G Ninja -DLLVM_ENABLE_RUNTIMES="libc" -DCMAKE_BUILD_TYPE=Release -DLLVM_LIBC_FULL_BUILD=ON
$ ninja libc-unit-tests
...
/android0/llvm-project/libc/src/complex/generic/cimagf128.cpp:16:42: error: ‘cfloat128’ was not declared in this scope; did you mean ‘float128’?
16 | LLVM_LIBC_FUNCTION(float128, cimagf128, (cfloat128 x)) {
| ^
/android0/llvm-project/libc/src/__support/common.h:49:64: note: in definition of macro ‘LLVM_LIBC_FUNCTION_IMPL’
49 | #define LLVM_LIBC_FUNCTION_IMPL(type, name, arglist) type name arglist
|^~~
/android0/llvm-project/libc/src/complex/generic/cimagf128.cpp:16:1: note: in expansion of macro ‘LLVM_LIBC_FUNCTION’
16 | LLVM_LIBC_FUNCTION(float128, cimagf128, (cfloat128 x)) {
| ^~
...
```
is our compiler detection for complex float support broken?
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 122501] [slp] vectorizer ICEs with "InstructionsState is invalid" with neoverse-v1 but not neoverse-n1
Issue
122501
Summary
[slp] vectorizer ICEs with "InstructionsState is invalid" with neoverse-v1 but not neoverse-n1
Labels
new issue
Assignees
Reporter
ashermancinelli
```
> clang++ --version
clang version 20.0.0git (https://github.com/llvm/llvm-project 3def49cb64ec1298290724081bd37dbdeb2ea5f8)
Target: aarch64-unknown-linux-gnu
Thread model: posix
InstalledDir: /install/llvm/bin
Build config: +assertions
```
Started sometime in the range `(211bcf67aadb1175af382f55403ae759177281c7, 3def49cb64ec1298290724081bd37dbdeb2ea5f8]`.
I see some potentially related changes like this:
```
commit 760f550de25792db83cd39c88ef57ab6d80a41a0
Author: Han-Kuan Chen
Commit: GitHub
[SLP] NFC. Replace MainOp and AltOp in TreeEntry with InstructionsState. (#120198)
Add TreeEntry::hasState.
Add assert for getTreeEntry.
Remove the OpValue parameter from the canReuseExtract function.
Remove the Opcode parameter from the ComputeMaxBitWidth lambda function.
```
Maybe @HanKuanChen could you help us narrow this down?
Only ICEs with neoverse-v1
```
# ok
> clang++ -O2 -mcpu=neoverse-n1 -S ./reduced.ll
# ICE
> clang++ -O2 -mcpu=neoverse-v1 -S ./first-reduced.ll
clang++: /install/llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp:821: llvm::Instruction* {anonymous}::InstructionsState::getMainOp() const: Assertion `valid() && "InstructionsState is invalid."' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments: clang++ -O2 -mcpu=neoverse-v1 -S ./first-reduced.ll
1. Optimizer
2. Running pass "function(float2int,lower-constant-intrinsics,loop(loop-rotate,loop-deletion),loop-distribute,inject-tli-mappings,loop-vectorize,infer-alignment,loop-load-elim,instcombine,simplifycfg,slp-vectorizer,vector-combine,instcombine,loop-unroll,transform-warning,sroa,infer-alignment,instcombine,loop-mssa(licm),alignment-from-assumptions,loop-sink,instsimplify,div-rem-pairs,tailcallelim,simplifycfg)" on module "./first-reduced.ll"
3. Running pass "slp-vectorizer" on function "foo"
#0 0xaaad9a2828e0 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/install/llvm/bin/clang-20+0x46028e0)
#1 0xaaad9a280638 llvm::sys::RunSignalHandlers() (/install/llvm/bin/clang-20+0x4600638)
#2 0xaaad9a2809f0 llvm::sys::CleanupOnSignal(unsigned long) (/install/llvm/bin/clang-20+0x46009f0)
#3 0xaaad9a1d64c4 CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0
#4 0x156908dc (linux-vdso.so.1+0x8dc)
#5 0x1530f200 __pthread_kill_implementation ./nptl/pthread_kill.c:44:76
#6 0x152ca67c gsignal ./signal/../sysdeps/posix/raise.c:27:6
#7 0x152b7130 abort ./stdlib/abort.c:81:7
#8 0x152c3fd0 __assert_fail_base ./assert/assert.c:89:7
#9 0x152c4040 __assert_perror_fail ./assert/assert-perr.c:31:1
#10 0xaaad9be052c0 (anonymous namespace)::InstructionsState::getAltOp() const (.part.0) SLPVectorizer.cpp:0:0
#11 0xaaad9bebb060 llvm::slpvectorizer::BoUpSLP::transformNodes() (/install/llvm/bin/clang-20+0x623b060)
#12 0xaaad9bececf4 (anonymous namespace)::HorizontalReduction::tryToReduce(llvm::slpvectorizer::BoUpSLP&, llvm::DataLayout const&, llvm::TargetTransformInfo*, llvm::TargetLibraryInfo const&, llvm::AssumptionCache*) SLPVectorizer.cpp:0:0
#13 0xaaad9bed0de8 llvm::SLPVectorizerPass::vectorizeHorReduction(llvm::PHINode*, llvm::Instruction*, llvm::BasicBlock*, llvm::slpvectorizer::BoUpSLP&, llvm::SmallVectorImpl&) (/install/llvm/bin/clang-20+0x6250de8)
#14 0xaaad9bed4f84 llvm::SLPVectorizerPass::vectorizeRootInstruction(llvm::PHINode*, llvm::Instruction*, llvm::BasicBlock*, llvm::slpvectorizer::BoUpSLP&) (.constprop.0) SLPVectorizer.cpp:0:0
#15 0xaaad9bed8a50 llvm::SLPVectorizerPass::vectorizeChainsInBlock(llvm::BasicBlock*, llvm::slpvectorizer::BoUpSLP&) (/install/llvm/bin/clang-20+0x6258a50)
#16 0xaaad9bede468 llvm::SLPVectorizerPass::runImpl(llvm::Function&, llvm::ScalarEvolution*, llvm::TargetTransformInfo*, llvm::TargetLibraryInfo*, llvm::AAResults*, llvm::LoopInfo*, llvm::DominatorTree*, llvm::AssumptionCache*, llvm::DemandedBits*, llvm::OptimizationRemarkEmitter*) (.part.0) SLPVectorizer.cpp:0:0
#17 0xaaad9bedee90 llvm::SLPVectorizerPass::run(llvm::Function&, llvm::AnalysisManager&) (/install/llvm/bin/clang-20+0x625ee90)
#18 0xaaad9b94ca24 llvm::detail::PassModel>::run(llvm::Function&, llvm::AnalysisManager&) PassBuilder.cpp:0:0
#19 0xaaad99d26a28 llvm::PassManager>::run(llvm::Function&, llvm::AnalysisManager&) (/install/llvm/bin/clang-20+0x40a6a28)
#20 0xaaad98dc5c44 llvm::detail::PassModel>, llvm::AnalysisManager>::run(llvm::Function&, llvm::AnalysisManager
[llvm-bugs] [Bug 122517] [TySan] False positive related to structs in structs?
Issue
122517
Summary
[TySan] False positive related to structs in structs?
Labels
new issue
Assignees
Reporter
seanm
Maybe I'm just not using it right, or not understanding something, but OTOH TySan is new, and thus probably a bit buggy... I used creduce to create a C test case showing, I think, a false positive.
```C
typedef struct {
int len;
char *list;
} str_list;
typedef struct {
str_list infiles;
char command;
} nt_opts;
int add_string(str_list *slist) {
(void)(slist->list);
}
int process_opts(nt_opts *opts) {
add_string(&opts->infiles);
}
void free_opts_mem(nt_opts *nopt) {
(void)(nopt->infiles.list); // •••TySan warns here•••
}
void main(int argc, char *argv[]) {
nt_opts opts;
int rv = process_opts(&opts);
free_opts_mem(&opts);
}
```
then I run:
`(xcrun /Users/sean/llvm/llvm-install/bin/clang -w -g -fsanitize=type test.c && ./a.out)`
and I get:
```
==4848==ERROR: TypeSanitizer: type-aliasing-violation on address 0x00016cfc71f0 (pc 0x000102e3b690 bp 0x00016cfc6ea0 sp 0x00016cfc6620 tid 24776816)
READ of size 8 at 0x00016cfc71f0 with type p1 omnipotent char (in at offset 8) accesses an existing object of type p1 omnipotent char (in at offset 8)
#0 0x000102e3b68c in free_opts_mem test.c:20
```
Aside:
- what is an "omnipotent char"?
- what is "type p1" referring to?
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 122509] `memory find` crashes when given an empty string to find
Issue 122509 Summary `memory find` crashes when given an empty string to find Labels new issue Assignees Reporter bbb23exposed ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 122510] [libc] wrap `mpc_t` and `mpfr_t` from MPCWrapper and MPFRWrapper in a simple RAII type
Issue 122510 Summary [libc] wrap `mpc_t` and `mpfr_t` from MPCWrapper and MPFRWrapper in a simple RAII type Labels libc Assignees Reporter Sh0g0-1758 Refer: [this](https://github.com/llvm/llvm-project/pull/121261#discussion_r1907995590) ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 122430] [SLPVectorizer] Miscompilation
Issue
122430
Summary
[SLPVectorizer] Miscompilation
Labels
miscompilation,
llvm:SLPVectorizer,
generated by fuzzer
Assignees
Reporter
dtcxzyw
Reproducer: https://alive2.llvm.org/ce/z/BopDTn
```
; bin/opt -passes=slp-vectorizer test.ll -S
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"
target triple = "x86_64-unknown-linux-gnu"
define i16 @test(ptr %p1, i16 %inc.143.i76136.lcssa158200.i.i, i16 %inc.1.1.i82139.lcssa160199.i.i, i16 %inc.143.1.i98142.lcssa162198.i.i) {
entry:
%0 = and i16 %inc.1.1.i82139.lcssa160199.i.i, %inc.143.i76136.lcssa158200.i.i
%1 = and i16 %0, 0
%2 = and i16 %1, 0
%3 = icmp ne i16 %2, 0
%.not5.not = or i1 %3, false
%inc.1.1.i82.i.i = or i16 %inc.1.1.i82139.lcssa160199.i.i, 0
%inc.143.1.i98.i.i = or i16 %inc.143.1.i98142.lcssa162198.i.i, 0
%4 = or i16 %inc.1.1.i82.i.i, 0
%5 = or i16 %4, 0
%6 = or i16 %5, 0
%7 = icmp ne i16 %6, 0
%.not7.not = or i1 false, %7
%8 = or i1 %.not5.not, %.not7.not
%9 = and i16 %inc.1.1.i82.i.i, 0
%10 = and i16 0, %inc.143.1.i98.i.i
%11 = and i16 %10, 0
%12 = icmp ne i16 %11, 0
%.not5.not.1 = or i1 %12, false
%inc.143.i76.i.i.1 = or i16 %inc.143.i76136.lcssa158200.i.i, 0
%inc.143.1.i98.i.i.1 = or i16 %inc.143.1.i98142.lcssa162198.i.i, 0
%13 = or i16 0, %inc.143.i76.i.i.1
%14 = or i16 %13, 0
%15 = or i16 %14, 0
%16 = icmp ne i16 %15, 0
%.not7.not.1 = or i1 false, %16
%17 = or i1 %.not5.not.1, %.not7.not.1
%18 = or i1 %8, %17
%19 = and i16 0, %inc.143.i76.i.i.1
%20 = and i16 0, %inc.143.1.i98.i.i.1
%21 = and i16 %20, 0
%22 = icmp ne i16 %21, 0
%.not5.not.2 = or i1 %22, false
%inc.143.i76.i.i.2 = or i16 %inc.143.i76136.lcssa158200.i.i, 0
%inc.143.1.i98.i.i.2 = or i16 %inc.143.1.i98142.lcssa162198.i.i, 1
%23 = or i16 0, %inc.143.i76.i.i.2
%24 = or i16 %23, 0
%25 = or i16 %24, 0
%26 = icmp ne i16 %25, 0
%.not7.not.2 = or i1 false, %26
%27 = or i1 %.not5.not.2, %.not7.not.2
%28 = or i1 false, %27
%29 = and i16 0, %inc.143.i76.i.i.2
%30 = and i16 0, %inc.143.1.i98.i.i.2
%31 = and i16 %30, 0
%32 = icmp ne i16 %31, 0
%.not5.not.3 = or i1 %32, false
%inc.143.i76.i.i.3 = or i16 %inc.143.i76136.lcssa158200.i.i, 0
%33 = or i16 0, %inc.143.i76.i.i.3
%34 = or i16 %33, 0
%35 = or i16 %34, 0
%36 = icmp ne i16 %35, 0
%.not7.not.3 = or i1 false, %36
%37 = or i1 %.not5.not.3, %.not7.not.3
%38 = select i1 %37, i1 true, i1 %27
%39 = select i1 %38, i1 true, i1 %17
%40 = select i1 %39, i1 true, i1 %8
%spec.select31 = select i1 %40, i32 0, i32 0
%41 = or i1 false, %37
store i32 %spec.select31, ptr %p1, align 4
ret i16 %inc.143.i76.i.i.3
}
```
```
define i16 @test(ptr %p1, i16 %inc.143.i76136.lcssa158200.i.i, i16 %inc.1.1.i82139.lcssa160199.i.i, i16 %inc.143.1.i98142.lcssa162198.i.i) {
entry:
%#0 = and i16 %inc.1.1.i82139.lcssa160199.i.i, %inc.143.i76136.lcssa158200.i.i
%#1 = and i16 %#0, 0
%#2 = and i16 %#1, 0
%#3 = icmp ne i16 %#2, 0
%.not5.not = or i1 %#3, 0
%inc.1.1.i82.i.i = or i16 %inc.1.1.i82139.lcssa160199.i.i, 0
%inc.143.1.i98.i.i = or i16 %inc.143.1.i98142.lcssa162198.i.i, 0
%#4 = or i16 %inc.1.1.i82.i.i, 0
%#5 = or i16 %#4, 0
%#6 = or i16 %#5, 0
%#7 = icmp ne i16 %#6, 0
%.not7.not = or i1 0, %#7
%#8 = or i1 %.not5.not, %.not7.not
%#10 = and i16 0, %inc.143.1.i98.i.i
%#11 = and i16 %#10, 0
%#12 = icmp ne i16 %#11, 0
%.not5.not.1 = or i1 %#12, 0
%inc.143.i76.i.i.1 = or i16 %inc.143.i76136.lcssa158200.i.i, 0
%inc.143.1.i98.i.i.1 = or i16 %inc.143.1.i98142.lcssa162198.i.i, 0
%#13 = or i16 0, %inc.143.i76.i.i.1
%#14 = or i16 %#13, 0
%#15 = or i16 %#14, 0
%#16 = icmp ne i16 %#15, 0
%.not7.not.1 = or i1 0, %#16
%#17 = or i1 %.not5.not.1, %.not7.not.1
%#20 = and i16 0, %inc.143.1.i98.i.i.1
%#21 = and i16 %#20, 0
%#22 = icmp ne i16 %#21, 0
%.not5.not.2 = or i1 %#22, 0
%inc.143.i76.i.i.2 = or i16 %inc.143.i76136.lcssa158200.i.i, 0
%inc.143.1.i98.i.i.2 = or i16 %inc.143.1.i98142.lcssa162198.i.i, 1
%#23 = or i16 0, %inc.143.i76.i.i.2
%#24 = or i16 %#23, 0
%#25 = or i16 %#24, 0
%#26 = icmp ne i16 %#25, 0
%.not7.not.2 = or i1 0, %#26
%#27 = or i1 %.not5.not.2, %.not7.not.2
%#30 = and i16 0, %inc.143.1.i98.i.i.2
%#31 = and i16 %#30, 0
%#32 = icmp ne i16 %#31, 0
%.not5.not.3 = or i1 %#32, 0
%inc.143.i76.i.i.3 = or i16 %inc.143.i76136.lcssa158200.i.i, 0
%#33 = or i16 0, %inc.143.i76.i.i.3
%#34 = or i16 %#33, 0
%#35 = or i16 %#34, 0
%#36 = icmp ne i16 %#35, 0
%.not7.not.3 = or i1 0, %#36
%#37 = or i1 %.not5.not.3, %.not7.not.3
%#38 = select i1 %#37, i1 1, i1 %#27
%#39 = select i1 %#38, i1 1, i1 %#17
%#40 = select i1 %#39, i1 1, i1 %#8
%spec.select31 = select
[llvm-bugs] [Bug 122522] [TySan] Add documentation analagous to address sanitizer & thread sanitizer documentation
Issue
122522
Summary
[TySan] Add documentation analagous to address sanitizer & thread sanitizer documentation
Labels
new issue
Assignees
Reporter
seanm
Unless I'm just missing it, TySan (type sanitizer) doesn't have any doc analogous to these two:
- https://clang.llvm.org/docs/AddressSanitizer.html
- https://clang.llvm.org/docs/ThreadSanitizer.html
Those are both great write ups, and users like me would benefit from something similar for TySan.
Some ideas of things to cover:
- ASan & TSan cannot be used together. Similar limitations with TySan?
- Do suppressions work the same as with other sanitzers?
- is there a `__has_feature` to detect TySan?
- is there a `__attribute__((no_sanitize("type")))`?
- can TySan be configured to trap instead of just log?
- TySan error messages are often of the form:
`==4848==ERROR: TypeSanitizer: type-aliasing-violation on address 0x00016cfc71f0 (pc 0x000102e3b690 bp 0x00016cfc6ea0 sp 0x00016cfc6620 tid 24776816)
READ of size 8 at 0x00016cfc71f0 with type p1 omnipotent char (in at offset 8) accesses an existing object of type p1 omnipotent char (in at offset 8)
#0 0x000102e3b68c in free_opts_mem test.c:20`
- The terms "omnipotent char", "type p1", etc. should be documented & explained
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 122523] Unique function identifier considered ambiguous as part of an overload set
Issue
122523
Summary
Unique function identifier considered ambiguous as part of an overload set
Labels
new issue
Assignees
Reporter
03F001
clang 19.1
```cpp
#include
template
void f(T) {}
template
requires std::same_as
void f(T) {}
int main() {
auto a = f; // error: variable 'a' with type 'auto' has incompatible initializer of type ''
}
```
I don't know whether this should compile, but gcc does accept it. At least the diagnostic could use some work.
https://godbolt.org/z/bojPze9Kf
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 122528] [libc++] Ambiguous call encountered in ranges::count
Issue
122528
Summary
[libc++] Ambiguous call encountered in ranges::count
Labels
libc++
Assignees
Reporter
winner245
When using `vector` with a custom-sized allocator, the `std::ranges::count` and `std::count` algorithms encounter an ambiguous call to the internal function `__libcpp_popcount`, as demonstrated below.
Note: This issue came up while working on #119801.
[Godbolt link](https://godbolt.org/z/eG1n57qGx)
```cpp
#include
#include
#include
#include
#include
#include
template
class sized_allocator {
template
friend class sized_allocator;
public:
using value_type = T;
using size_type = SIZE_TYPE;
using difference_type = DIFF_TYPE;
using propagate_on_container_swap = std::true_type;
explicit sized_allocator(int i = 0) : data_(i) {}
template
constexpr sized_allocator(const sized_allocator& a) noexcept : data_(a.data_) {}
constexpr T* allocate(size_type n) {
if (n > max_size())
throw std::bad_array_new_length();
return std::allocator().allocate(n);
}
constexpr void deallocate(T* p, size_type n) noexcept { std::allocator().deallocate(p, n); }
constexpr size_type max_size() const noexcept { return std::numeric_limits::max() / sizeof(value_type); }
int get() { return data_; }
private:
int data_;
constexpr friend bool operator==(const sized_allocator& a, const sized_allocator& b) {
return a.data_ == b.data_;
}
constexpr friend bool operator!=(const sized_allocator& a, const sized_allocator& b) {
return a.data_ != b.data_;
}
};
int main() {
using Alloc = sized_allocator;
std::vector in(200, true, Alloc(1));
assert(std::ranges::count(in, true) == 200); // Error: ambiguous call to __libcpp_popcount
return 0;
}
```
The error message from clang is:
```
/opt/compiler-explorer/clang-trunk-20250110/bin/../include/c++/v1/__algorithm/count.h:59:30: error: call to '__libcpp_popcount' is ambiguous
59 | __r = std::__libcpp_popcount(std::__invert_if(*__first.__seg_) & __m);
| ^~
```
Analysis
When used with `sized_allocator` with smaller integral types, the internal bitwise arithmetic exhibits integral promotions, yielding an `int` result. This does not match any of the three internal function overloads `__libcpp_popcount(unsigned)`, `__libcpp_popcount(unsigned long)`, and `__libcpp_popcount(unsigned long long)`, causing an ambiguous call error.
Proposed Solution
Provide a function template that dispatches the call to the appropriate `__libcpp_popcount` overload based on the size of the integral types. Specifically, for all smaller unsigned integer types (`unsigned short`, `uint8_t`, `uint16_t`, etc), dispatch the call to `__libcpp_popcount(unsigned)`. For the remaining larger integral types, dispatch the call to `__libcpp_popcount(unsigned long)` or `__libcpp_popcount(unsigned long long)` according to the `sizeof(type)` values.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 122532] Undef description of branching in LangRef seems ambiguous.
Issue 122532 Summary Undef description of branching in LangRef seems ambiguous. Labels new issue Assignees Reporter Chobbes In the section on undefined values https://llvm.org/docs/LangRef.html#undefined-values LangRef provides the following example: ``` %A = select undef, %X, %Y %B = select undef, 42, %Y %C = select %X, %Y, undef Safe: %A = %X (or %Y) %B = 42 (or %Y) %C = %Y (if %Y is provably not poison; unsafe otherwise) Unsafe: %A = undef %B = undef %C = undef ``` And states: > This set of examples shows that undefined ‘select’ (and conditional branch) conditions can go either way, but they have to come from one of the two operands Later on in this section, the following is stated: >Branching on an undefined value is undefined behavior. This explains optimizations that depend on branch conditions to construct predicates, such as Correlated Value Propagation and Global Value Numbering. In case of switch instruction, the branch condition should be frozen, otherwise it is undefined behavior. The first quote seems to suggest that a conditional branch on `undef` is a non-deterministic jump. The second statement claims that it is in fact UB, unless the `undef` value has been frozen first. My interpretation of what is meant is the following: 1. `select` instructions don't count as branches, and selecting with an `undef` condition is allowed. 2. Branching on an `undef` value is UB (i.e., if the value represents multiple values, branching on it is UB). Under this interpretation the first quote isn't necessarily wrong (the program can do anything when UB is encountered, including going down one of the branches), but I assume that isn't the intention, and maybe this should be rephrased to be more clear --- perhaps we should just remove the "(and conditional branch)" part? Would love to hear what other people think, especially if I'm misunderstanding something! Thanks! ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
