[llvm-bugs] [Bug 137619] clang++: wrong error about non-const member
Issue
137619
Summary
clang++: wrong error about non-const member
Labels
clang
Assignees
Reporter
stsp
```
class A {
static const char *aaa = "aaa";
};
```
clang++:
```
cstr.cpp:2:24: error: non-const static data member must be initialized out of line
2 | static const char *aaa = "aaa";
```
This error is absolutely wrong
and misleading. I had to use gcc
to get a clue:
g++:
```
cstr.cpp:2:24: error: ‘constexpr’ needed for in-class initialization of static data member ‘const char* A::aaa’ of non-integral type [-fpermissive]
2 | static const char *aaa = "aaa";
```
Perfectly clear and valid msg.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 137660] [LLDB] Flakey DAP tests on builders
Issue 137660 Summary [LLDB] Flakey DAP tests on builders Labels lldb, lldb-dap Assignees Reporter shafik It looks like the DAP tests are pretty flakey. Right now it looks like `TestDAP_attachByPortNum.py` is failing a bunch now e.g.: https://lab.llvm.org/buildbot/#/builders/18/builds/15174 but if we keep going back various other DAP tests are also failing regularly. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 137648] Missing dependency from clang-scan-deps after b768a8c1db85b9e84fd8b356570a3a8fbe37acf6
Issue 137648 Summary Missing dependency from clang-scan-deps after b768a8c1db85b9e84fd8b356570a3a8fbe37acf6 Labels clang:tooling Assignees Reporter tru Hi @jansvoboda11 I know I am late on the ball here, but we have been using clang-scan-deps from LLVM 18 until I recently started to upgrade to 19 and the 20. We use clang-scan-deps as part of our build system to figure out the dependencies of C++ files to build. When I started to integrate test LLVM 19 I noticed that clang-scan-deps was missing output a specific header. This header is included inside a `#ifdef` statement, but there something else going on as well. I bisected the problem to b768a8c1db85b9e84fd8b356570a3a8fbe37acf6 and the problem exists within `main` as well. And the issue only exists with the non-preprocessor mode, the preprocessor mode works fine (but is to slow). The problem here is that I don't know exactly how to make a reproducible issue out of this. the include tree is pretty complicated and the source is not something I can share. Let me know how I can provide you with more information or how to debug this issue further. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 137647] [HLSL][SPIRV] Map the arguments in the DXC `spv-extension` option to the SPIR-V backend's `-spirv-ext` options.
Issue 137647 Summary [HLSL][SPIRV] Map the arguments in the DXC `spv-extension` option to the SPIR-V backend's `-spirv-ext` options. Labels HLSL, backend:SPIR-V Assignees Reporter s-perron ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 137685] [DirectX] Move FNeg legalization to the DXILLegalization pass
Issue 137685 Summary [DirectX] Move FNeg legalization to the DXILLegalization pass Labels new issue Assignees Reporter bogner Currently DXILPrepare legalizes the FNeg instruction into an FSub. This isn't the right place for that and we should move it to DXILLegalization instead. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 137600] `-Wpreferred-type-bitfield-enum-conversion` reported in `include/clang/Basic/LangOptions.def`
Issue 137600 Summary `-Wpreferred-type-bitfield-enum-conversion` reported in `include/clang/Basic/LangOptions.def` Labels code-quality Assignees Reporter firewave Doing a downstream `include-what-you-use` with Clang 21 against LLVM 21 shows the following warning: ``` In file included from /mnt/s/GitHub/include-what-you-use/iwyu_globals.cc:22: In file included from /usr/lib/llvm-21/include/clang/AST/PrettyPrinter.h:17: In file included from /usr/lib/llvm-21/include/clang/Basic/LangOptions.h:663: /usr/lib/llvm-21/include/clang/Basic/LangOptions.def:350:1: warning: assigning value of preferred signed enum type 'FPEvalMethodKind' to unsigned bit-field 'FPEvalMethod'; negative enumerators of enum 'FPEvalMethodKind' will be converted to positive values [-Wpreferred-type-bitfield-enum-conversion] 350 | BENIGN_ENUM_LANGOPT(FPEvalMethod, FPEvalMethodKind, 3, FEM_UnsetOnCommandLine, "FP type used for floating point arithmetic") | ^ /usr/lib/llvm-21/include/clang/Basic/LangOptions.def:67:6: note: expanded from macro 'BENIGN_ENUM_LANGOPT' 67 | COMPATIBLE_ENUM_LANGOPT(Name, Type, Bits, Default, Description) | ^ /usr/lib/llvm-21/include/clang/Basic/LangOptions.def:62:6: note: expanded from macro 'COMPATIBLE_ENUM_LANGOPT' 62 | ENUM_LANGOPT(Name, Type, Bits, Default, Description) | ^ /usr/lib/llvm-21/include/clang/Basic/LangOptions.h:661:10: note: expanded from macro 'ENUM_LANGOPT' 661 | Name = static_cast(Value); \ | ^ /usr/lib/llvm-21/include/clang/Basic/LangOptions.def:350:1: note: consider making the bit-field type signed 350 | BENIGN_ENUM_LANGOPT(FPEvalMethod, FPEvalMethodKind, 3, FEM_UnsetOnCommandLine, "FP type used for floating point arithmetic") | ^~~~ /usr/lib/llvm-21/include/clang/Basic/LangOptions.def:67:6: note: expanded from macro 'BENIGN_ENUM_LANGOPT' 67 | COMPATIBLE_ENUM_LANGOPT(Name, Type, Bits, Default, Description) | ^~~ /usr/lib/llvm-21/include/clang/Basic/LangOptions.def:62:6: note: expanded from macro 'COMPATIBLE_ENUM_LANGOPT' 62 | ENUM_LANGOPT(Name, Type, Bits, Default, Description) | ^~~~ /usr/lib/llvm-21/include/clang/Basic/LangOptions.h:501:3: note: expanded from macro 'ENUM_LANGOPT' 501 | unsigned Name : Bits; | ^~~~ /usr/lib/llvm-21/include/clang/Basic/LangOptions.def:350:1: note: preferred type for bit-field 'FPEvalMethodKind' specified here /usr/lib/llvm-21/include/clang/Basic/LangOptions.def:67:6: note: expanded from macro 'BENIGN_ENUM_LANGOPT' 67 | COMPATIBLE_ENUM_LANGOPT(Name, Type, Bits, Default, Description) | ^ /usr/lib/llvm-21/include/clang/Basic/LangOptions.def:62:6: note: expanded from macro 'COMPATIBLE_ENUM_LANGOPT' 62 | ENUM_LANGOPT(Name, Type, Bits, Default, Description) | ^ /usr/lib/llvm-21/include/clang/Basic/LangOptions.h:500:3: note: expanded from macro 'ENUM_LANGOPT' 500 | LLVM_PREFERRED_TYPE(Type) \ | ^ /usr/lib/llvm-21/include/llvm/Support/Compiler.h:708:47: note: expanded from macro 'LLVM_PREFERRED_TYPE' 708 | #define LLVM_PREFERRED_TYPE(T) __attribute__((preferred_type(T))) | ^ ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 137599] Many lldb-dap TestDAP_Launch.py tests fail on Windows due to get_stdout()
Issue 137599 Summary Many lldb-dap TestDAP_Launch.py tests fail on Windows due to get_stdout() Labels test-suite, lldb-dap Assignees Reporter DavidSpickett For example: https://lab.llvm.org/buildbot/#/builders/141/builds/8271 ``` FAIL: test_args (TestDAP_launch.TestDAP_launch.test_args) Tests launch of a simple program with arguments -- Traceback (most recent call last): File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\API\tools\lldb-dap\launch\TestDAP_launch.py", line 245, in test_args self.assertTrue(output and len(output) > 0, "expect program output") AssertionError: None is not true : expect program output Config=aarch64-C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\clang.exe == FAIL: test_cwd (TestDAP_launch.TestDAP_launch.test_cwd) Tests the default launch of a simple program with a current working -- Traceback (most recent call last): File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\API\tools\lldb-dap\launch\TestDAP_launch.py", line 109, in test_cwd self.assertTrue(output and len(output) > 0, "expect program output") AssertionError: None is not true : expect program output Config=aarch64-C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\clang.exe == FAIL: test_default (TestDAP_launch.TestDAP_launch.test_default) Tests the default launch of a simple program. No arguments, -- Traceback (most recent call last): File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\API\tools\lldb-dap\launch\TestDAP_launch.py", line 26, in test_default self.assertTrue(output and len(output) > 0, "expect program output") AssertionError: None is not true : expect program output Config=aarch64-C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\clang.exe == FAIL: test_environment_with_array (TestDAP_launch.TestDAP_launch.test_environment_with_array) Tests launch of a simple program with environment variables -- Traceback (most recent call last): File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\API\tools\lldb-dap\launch\TestDAP_launch.py", line 304, in test_environment_with_array self.assertTrue(output and len(output) > 0, "expect program output") AssertionError: None is not true : expect program output Config=aarch64-C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\clang.exe == FAIL: test_environment_with_object (TestDAP_launch.TestDAP_launch.test_environment_with_object) Tests launch of a simple program with environment variables -- Traceback (most recent call last): File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\API\tools\lldb-dap\launch\TestDAP_launch.py", line 275, in test_environment_with_object self.assertTrue(output and len(output) > 0, "expect program output") AssertionError: None is not true : expect program output Config=aarch64-C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\clang.exe == FAIL: test_shellExpandArguments_disabled (TestDAP_launch.TestDAP_launch.test_shellExpandArguments_disabled) Tests the default launch of a simple program with shell expansion -- Traceback (most recent call last): File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\API\tools\lldb-dap\launch\TestDAP_launch.py", line 225, in test_shellExpandArguments_disabled self.assertTrue(output and len(output) > 0, "expect no program output") AssertionError: None is not true : expect no program output Config=aarch64-C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\clang.exe ``` All these tests call `self.get_stdout()` which returns `None` despite the program printing output as expected: ``` C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build>C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\lldb-test-build.noindex\tools\lldb-dap\launch\TestDAP_launch.test_default\a.out arg[0] = "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\lldb-test-build.noindex\tools\lldb-dap\launc
[llvm-bugs] [Bug 137603] `-Wpreferred-type-bitfield-enum-conversion` reported in `include/clang/Basic/LangOptions.def` (ComplexRange)
Issue
137603
Summary
`-Wpreferred-type-bitfield-enum-conversion` reported in `include/clang/Basic/LangOptions.def` (ComplexRange)
Labels
code-quality
Assignees
Reporter
firewave
Compiling `include-what-you-use` with Clang 21 against LLVM 20 shows the following:
```
In file included from /mnt/s/GitHub/include-what-you-use/iwyu_globals.cc:22:
In file included from /usr/lib/llvm-20/include/clang/AST/PrettyPrinter.h:17:
In file included from /usr/lib/llvm-20/include/clang/Basic/LangOptions.h:649:
/usr/lib/llvm-20/include/clang/Basic/LangOptions.def:242:1: warning: bit-field 'ComplexRange' is not wide enough to store all enumerators of preferred type 'ComplexRangeKind' [-Wpreferred-type-bitfield-enum-conversion]
242 | ENUM_LANGOPT(ComplexRange, ComplexRangeKind, 2, CX_None, "Enable use of range reduction for complex arithmetics.")
| ^
/usr/lib/llvm-20/include/clang/Basic/LangOptions.h:648:37: note: expanded from macro 'ENUM_LANGOPT'
648 | void set##Name(Type Value) { Name = static_cast(Value); }
| ^
/usr/lib/llvm-20/include/clang/Basic/LangOptions.def:242:46: note: widen this field to 3 bits to store all values of 'ComplexRangeKind'
242 | ENUM_LANGOPT(ComplexRange, ComplexRangeKind, 2, CX_None, "Enable use of range reduction for complex arithmetics.")
| ^
/usr/lib/llvm-20/include/clang/Basic/LangOptions.def:242:1: note: preferred type for bit-field 'ComplexRangeKind' specified here
242 | ENUM_LANGOPT(ComplexRange, ComplexRangeKind, 2, CX_None, "Enable use of range reduction for complex arithmetics.")
| ^
/usr/lib/llvm-20/include/clang/Basic/LangOptions.h:495:3: note: expanded from macro 'ENUM_LANGOPT'
495 | LLVM_PREFERRED_TYPE(Type) \
| ^
/usr/lib/llvm-20/include/llvm/Support/Compiler.h:687:47: note: expanded from macro 'LLVM_PREFERRED_TYPE'
687 | #define LLVM_PREFERRED_TYPE(T) __attribute__((preferred_type(T)))
| ^
```
This does not happen when you compile with Clang 21 against LLVM 21. So this either needs a backport or can be closed as already fixed.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 137588] 【clang】The while loop is lost when in -O1 or higher Optimization level
Issue
137588
Summary
【clang】The while loop is lost when in -O1 or higher Optimization level
Labels
clang
Assignees
Reporter
hippyll123
in llvm18，the following code will be in an infinite loop at -O0, but not at -O1 or higher Optimization level, Is this expected or bug ? This problem can be avoided by using `-fno-finite-loops` .
In GCC, -O0 or higher Optimization level are all infinite loops.
```
#include
void bar() {
int a = 0;
int b = 10;
printf("a = %p\n", &a);
while (a < b) {}
printf("b = %p\n", &b);
}
int main() {
bar();
return 0;
}
```
command:
`clang++ --target=x86_64-unknown-linux-gnu 1.cpp -O0 && ./a.out`
`clang++ --target=x86_64-unknown-linux-gnu 1.cpp -O1 && ./a.out`
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 137715] [DirectX] OpLowerer::cleanupHandleCasts incompatible cast trying to cast to TargetExtTyID CallInst
Issue
137715
Summary
[DirectX] OpLowerer::cleanupHandleCasts incompatible cast trying to cast to TargetExtTyID CallInst
Labels
backend:DirectX
Assignees
Reporter
farzonl
## Assert
```gdb
Assertion failed: (isa(Val) && "cast() argument of incompatible type!"), function cast, file Casting.h, line 578.
Process 34770 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = hit program assert
frame #4: 0x000100102b54 clang-dxc`decltype(auto) llvm::cast(Val=0x00012f71f8f0) at Casting.h:578:3
575
576 template
577 [[nodiscard]] inline decltype(auto) cast(From *Val) {
-> 578 assert(isa(Val) && "cast() argument of incompatible type!");
579return CastInfo::doCast(Val);
580 }
581
(lldb) expr *Val->getType()
(llvm::Type) $3 = {
Context = 0x00012f625040
ID = TargetExtTyID
SubclassData = 2
NumContainedTys = 1
ContainedTys = 0x00012901bd48
}
```
## From by looking one frame up
```gdb
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
frame #0: 0x0001000fa640 clang-dxc`(anonymous namespace)::OpLowerer::cleanupHandleCasts(this=0x00016fdf43d0) at DXILOpLowering.cpp:175:38
172}
173// Otherwise, we're the second handle in a pair. Forward the arguments and
174// remove the (second) cast.
-> 175CallInst *Def = cast(Cast->getOperand(0));
176 assert(Def->getIntrinsicID() == Intrinsic::dx_resource_casthandle &&
177 "Unbalanced pair of temporary handle casts");
178 Cast->replaceAllUsesWith(Def->getOperand(0));
```
## IR causing assert
```llvm
%agg.tmp.i1.sroa.0.0.agg.tmp.i1.sroa.0.0.agg.tmp.i1.sroa.0.0.agg.tmp.i1.sroa.0.0.5 = load target("dx.RawBuffer", i32, 1, 0), ptr %agg.tmp.i1.sroa.0, align 8, !tbaa !24
```
## IR Context
```llvm
if.end.i: ; preds = %if.then.i
%14 = call %dx.types.ResRet.f16 @dx.op.rawBufferLoad.f16(i32 139, %dx.types.Handle %_ZL11inputBuffer_h.i.i12, i32 %add.i, i32 0, i8 1, i32 2)
%15 = extractvalue %dx.types.ResRet.f16 %14, 0
%conv.i = fpext reassoc nnan ninf nsz arcp afn half %15 to float
%16 = call %dx.types.ResRet.f16 @dx.op.rawBufferLoad.f16(i32 139, %dx.types.Handle %_ZL14inputMinBuffer_h.i.i11, i32 0, i32 0, i8 1, i32 2)
%17 = extractvalue %dx.types.ResRet.f16 %16, 0
%conv4.i = fpext reassoc nnan ninf nsz arcp afn half %17 to float
%18 = call %dx.types.ResRet.f16 @dx.op.rawBufferLoad.f16(i32 139, %dx.types.Handle %_ZL14inputMaxBuffer_h.i.i10, i32 0, i32 0, i8 1, i32 2)
%19 = extractvalue %dx.types.ResRet.f16 %18, 0
%conv6.i = fpext reassoc nnan ninf nsz arcp afn half %19 to float
%elt.min.i19 = call float @dx.op.binary.f32(i32 36, float %conv4.i, float 0.00e+00) #4
%elt.max.i22 = call float @dx.op.binary.f32(i32 35, float %conv6.i, float 0.00e+00) #4
%sub.i = fsub reassoc nnan ninf nsz arcp afn float %elt.max.i22, %elt.min.i19
%div9.i = fdiv reassoc nnan ninf nsz arcp afn float 0x406FDFFFE000, %sub.i
%neg.i = fneg reassoc nnan ninf nsz arcp afn float %elt.min.i19
%20 = call float @dx.op.tertiary.f32(i32 46, float %neg.i, float %div9.i, float -1.28e+02) #4
%dx.max620 = call float @dx.op.binary.f32(i32 35, float %20, float -1.28e+02) #4
%dx.min717 = call float @dx.op.binary.f32(i32 36, float %dx.max620, float 1.27e+02) #4
%elt.roundeven.i24 = call float @dx.op.unary.f32(i32 26, float %dx.min717) #4
%mul.i = fmul reassoc nnan ninf nsz arcp afn float %div9.i, %conv.i
%elt.roundeven13.i23 = call float @dx.op.unary.f32(i32 26, float %mul.i) #4
%add14.i = fadd reassoc nnan ninf nsz arcp afn float %elt.roundeven13.i23, %elt.roundeven.i24
%dx.max21 = call float @dx.op.binary.f32(i32 35, float %add14.i, float -1.28e+02) #4
%dx.min18 = call float @dx.op.binary.f32(i32 36, float %dx.max21, float 1.27e+02) #4
%conv18.i = fptosi float %dx.min18 to i32
%21 = load i32, ptr @_ZL12outputBuffer, align 4, !tbaa !21
call void @llvm.lifetime.start.p0(i64 4, ptr nonnull %agg.tmp.i1.sroa.0)
store i32 %21, ptr %agg.tmp.i1.sroa.0, align 8
%div9.i2 = lshr i32 %add.i, 2
%rem.i3 = shl i32 %add.i, 3
%mul.i4 = and i32 %rem.i3, 24
%shl.i = shl nuw i32 255, %mul.i4
%agg.tmp.i1.sroa.0.0.agg.tmp.i1.sroa.0.0.agg.tmp.i1.sroa.0.0.agg.tmp.i1.sroa.0.0.5 = load target("dx.RawBuffer", i32, 1, 0), ptr %agg.tmp.i1.sroa.0, align 8, !tbaa !24
%22 = call %dx.types.Handle @llvm.dx.resource.casthandle.s_dx.types.Handles.tdx.RawBuffer_i32_1_0t(target("dx.RawBuffer", i32, 1, 0) %agg.tmp.i1.sroa.0.0.agg.tmp.i1.sroa.0.0.agg.tmp.i1.sroa.0.0.agg.tmp.i1.sroa.0.0.5)
%23 = call %dx.types.ResRet.i32 @dx.op.rawBufferLoad.i32(i32 139, %dx.types.Handle %22, i32 %div9.i2, i32 0, i8 1, i32 4)
%24 = extractvalue %dx.types.ResRet.i32 %23, 0
%shl2.i = shl i32 %conv18.i, %mul.i4
%xor.i = xor i32 %24, %shl2.i
%an
[llvm-bugs] [Bug 137726] [RISCV] `clang` encounters a fatal error in `getCopyFromParts()` when referencing an array element in inline assembly for `Zilsd` and `Zclsd` instructions
Issue
137726
Summary
[RISCV] `clang` encounters a fatal error in `getCopyFromParts()` when referencing an array element in inline assembly for `Zilsd` and `Zclsd` instructions
Labels
clang
Assignees
Reporter
thebigclub
This happens even when you have an invalid combination (`Zilsd` paired with `c.ld`). I'll document a single example:
```bash
$ cat << EOF > test.c
#include
int fn(void *arg1, int arg2, int arg3, int arg4, int arg5) {
uint32_t val[2];
asm volatile ("c.ld %0, 0(%1)"
: "=R" (val[0])
: "r" (arg1)
);
return val[1] + arg2 + arg3 + arg4 + arg5;
}
EOF
$ clang -march=rv32i_zclsd -c test.c
fatal error: error in backend: Unknown mismatch in getCopyFromParts!
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 -march=rv32i_zclsd -c test.c
1. parser at end of file
2. Code generation
3. Running pass 'Function Pass Manager' on module 'test.c'.
4. Running pass 'RISC-V DAG->DAG Pattern Instruction Selection' on function '@fn'
#0 0x016f8c1b llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/home/thebigclub/riscv/llvm/rv32ec/bin/clang-21+0x16f8c1b)
#1 0x016f6a44 llvm::sys::CleanupOnSignal(unsigned long) (/home/thebigclub/riscv/llvm/rv32ec/bin/clang-21+0x16f6a44)
#2 0x016441b2 llvm::CrashRecoveryContext::HandleExit(int) (/home/thebigclub/riscv/llvm/rv32ec/bin/clang-21+0x16441b2)
#3 0x016edf0e llvm::sys::Process::Exit(int, bool) (/home/thebigclub/riscv/llvm/rv32ec/bin/clang-21+0x16edf0e)
#4 0x0056f897 LLVMErrorHandler(void*, char const*, bool) cc1_main.cpp:0:0
#5 0x0164c71c llvm::report_fatal_error(llvm::Twine const&, bool) (/home/thebigclub/riscv/llvm/rv32ec/bin/clang-21+0x164c71c)
#6 0x0164c878 (/home/thebigclub/riscv/llvm/rv32ec/bin/clang-21+0x164c878)
#7 0x02919ec1 getCopyFromParts(llvm::SelectionDAG&, llvm::SDLoc const&, llvm::SDValue const*, unsigned int, llvm::MVT, llvm::EVT, llvm::Value const*, llvm::SDValue, std::optional, std::optional) (.isra.0) SelectionDAGBuilder.cpp:0:0
#8 0x0291de37 llvm::RegsForValue::getCopyFromRegs(llvm::SelectionDAG&, llvm::FunctionLoweringInfo&, llvm::SDLoc const&, llvm::SDValue&, llvm::SDValue*, llvm::Value const*) const (/home/thebigclub/riscv/llvm/rv32ec/bin/clang-21+0x291de37)
#9 0x02947f32 llvm::SelectionDAGBuilder::visitInlineAsm(llvm::CallBase const&, llvm::BasicBlock const*) (/home/thebigclub/riscv/llvm/rv32ec/bin/clang-21+0x2947f32)
#10 0x0297eb80 llvm::SelectionDAGBuilder::visit(llvm::Instruction const&) (/home/thebigclub/riscv/llvm/rv32ec/bin/clang-21+0x297eb80)
#11 0x02a0270c llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator_w_bits, false, true>, llvm::ilist_iterator_w_bits, false, true>, bool&) (/home/thebigclub/riscv/llvm/rv32ec/bin/clang-21+0x2a0270c)
#12 0x02a03bc7 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) (/home/thebigclub/riscv/llvm/rv32ec/bin/clang-21+0x2a03bc7)
#13 0x02a05b08 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) (/home/thebigclub/riscv/llvm/rv32ec/bin/clang-21+0x2a05b08)
#14 0x029f4319 llvm::SelectionDAGISelLegacy::runOnMachineFunction(llvm::MachineFunction&) (/home/thebigclub/riscv/llvm/rv32ec/bin/clang-21+0x29f4319)
#15 0x00b40813 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (.part.0) MachineFunctionPass.cpp:0:0
#16 0x0115b689 llvm::FPPassManager::runOnFunction(llvm::Function&) (/home/thebigclub/riscv/llvm/rv32ec/bin/clang-21+0x115b689)
#17 0x0115b82c llvm::FPPassManager::runOnModule(llvm::Module&) (/home/thebigclub/riscv/llvm/rv32ec/bin/clang-21+0x115b82c)
#18 0x0115aa54 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/home/thebigclub/riscv/llvm/rv32ec/bin/clang-21+0x115aa54)
#19 0x019a47be clang::emitBackendOutput(clang::CompilerInstance&, clang::CodeGenOptions&, llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::IntrusiveRefCntPtr, std::unique_ptr>, clang::BackendConsumer*) (/home/thebigclub/riscv/llvm/rv32ec/bin/clang-21+0x19a47be)
#20 0x0202b6f4 clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) (/home/thebigclub/riscv/llvm/rv32ec/bin/clang-21+0x202b6f4)
#21 0x03aa6edc clang::ParseAST(clang::Sema&, bool, bool) (/home/thebigclub/riscv/llvm/rv32ec/bin/clang-21+0x3aa6edc)
#22 0x023647fa clang::FrontendAction::Execute() (/home/thebigclub/riscv/llvm/rv32ec/bin/clang-21+0x23647fa)
#23 0x022e21be clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/home/thebigclub/riscv/llvm/rv32ec/bin/clang-21+0x2
[llvm-bugs] [Bug 137733] [HLSL] Ambiguous intrinsic uses in MiniEngine
Issue 137733 Summary [HLSL] Ambiguous intrinsic uses in MiniEngine Labels HLSL Assignees Reporter V-FEXrt MiniEngine has many uses of the following set in intrinsics that are ambiguous under C++'s overload resolution rules. - [ ] `clamp` - [ ] `dot` - [ ] `lerp` - [ ] `max` - [ ] `min` - [ ] `pow` Other ambiguous cases my arise as [used but unimplemented intrinsics](https://github.com/llvm/wg-hlsl/issues/237) are implemented A similar case was discussed and resolved for `select` here: https://github.com/llvm/llvm-project/issues/126570 It should be determined if the uses here are intended source breakages requiring migration or if a path similar to select should be forged. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 137736] [RISCV] `clang` permits invalid operand for `Zclsd` instructions in inline assembly when using any optimization level other than `-O0`
Issue
137736
Summary
[RISCV] `clang` permits invalid operand for `Zclsd` instructions in inline assembly when using any optimization level other than `-O0`
Labels
Assignees
Reporter
thebigclub
The `Zclsd` [extension](https://github.com/riscv/riscv-isa-manual/blob/main/src/zilsd.adoc) requires the use of registers in the range of `x8-15` for `c.ld` and `c.sd` instructions. `clang` will use an invalid register when the compiler is free to choose the destination. This occurs for both the `I` and `E` base ISAs:
```bash
$ cat << EOF > test.c
#include
int fn(void *arg1, int arg2, int arg3, int arg4, int arg5) {
uint64_t val;
asm volatile ("c.ld %0, 0(%1)"
: "=R" (val)
: "r" (arg1)
);
return val + arg2 + arg3 + arg4 + arg5;
}
EOF
$ for isa in i e; do for level in 0 1 2 3 s z; do (set -x; clang -march=rv32"$isa"_zclsd -O"$level" -c test.c); echo Return value: $?; done; done
+ clang -march=rv32i_zclsd -O0 -c test.c
Return value: 0
+ clang -march=rv32i_zclsd -O1 -c test.c
test.c:6:23: error: invalid operand for instruction
6 | asm volatile ("c.ld %0, 0(%1)"
| ^
:1:7: note: instantiated into assembly here
1 | c.ld a6, 0(a0)
| ^
1 error generated.
Return value: 1
+ clang -march=rv32i_zclsd -O2 -c test.c
test.c:6:23: error: invalid operand for instruction
6 | asm volatile ("c.ld %0, 0(%1)"
| ^
:1:7: note: instantiated into assembly here
1 | c.ld a6, 0(a0)
| ^
1 error generated.
Return value: 1
+ clang -march=rv32i_zclsd -O3 -c test.c
test.c:6:23: error: invalid operand for instruction
6 | asm volatile ("c.ld %0, 0(%1)"
| ^
:1:7: note: instantiated into assembly here
1 | c.ld a6, 0(a0)
| ^
1 error generated.
Return value: 1
+ clang -march=rv32i_zclsd -Os -c test.c
test.c:6:23: error: invalid operand for instruction
6 | asm volatile ("c.ld %0, 0(%1)"
| ^
:1:7: note: instantiated into assembly here
1 | c.ld a6, 0(a0)
| ^
1 error generated.
Return value: 1
+ clang -march=rv32i_zclsd -Oz -c test.c
test.c:6:23: error: invalid operand for instruction
6 | asm volatile ("c.ld %0, 0(%1)"
| ^
:1:7: note: instantiated into assembly here
1 | c.ld a6, 0(a0)
| ^
1 error generated.
Return value: 1
+ clang -march=rv32e_zclsd -O0 -c test.c
Return value: 0
+ clang -march=rv32e_zclsd -O1 -c test.c
test.c:6:23: error: invalid operand for instruction
6 | asm volatile ("c.ld %0, 0(%1)"
| ^
:1:7: note: instantiated into assembly here
1 | c.ld t1, 0(a0)
| ^
1 error generated.
Return value: 1
+ clang -march=rv32e_zclsd -O2 -c test.c
test.c:6:23: error: invalid operand for instruction
6 | asm volatile ("c.ld %0, 0(%1)"
| ^
:1:7: note: instantiated into assembly here
1 | c.ld t1, 0(a0)
| ^
1 error generated.
Return value: 1
+ clang -march=rv32e_zclsd -O3 -c test.c
test.c:6:23: error: invalid operand for instruction
6 | asm volatile ("c.ld %0, 0(%1)"
| ^
:1:7: note: instantiated into assembly here
1 | c.ld t1, 0(a0)
| ^
1 error generated.
Return value: 1
+ clang -march=rv32e_zclsd -Os -c test.c
test.c:6:23: error: invalid operand for instruction
6 | asm volatile ("c.ld %0, 0(%1)"
| ^
:1:7: note: instantiated into assembly here
1 | c.ld t1, 0(a0)
| ^
1 error generated.
Return value: 1
+ clang -march=rv32e_zclsd -Oz -c test.c
test.c:6:23: error: invalid operand for instruction
6 | asm volatile ("c.ld %0, 0(%1)"
| ^
:1:7: note: instantiated into assembly here
1 | c.ld t1, 0(a0)
| ^
1 error generated.
Return value: 1
$ clang -v
clang version 21.0.0git (https://github.com/llvm/llvm-project.git 913dcf1aa36f3ea2d67a0d2b05b9d1375987e553)
Target: riscv32-unknown-unknown-elf
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 137739] UB optimization leads to really bad code gen
Issue 137739 Summary UB optimization leads to really bad code gen Labels new issue Assignees Reporter bwendling Linux has some code that may result in dividing by zero or shifting by negative numbers. For instance, in one of the ARMGPU drivers, a "divide by zero" results in a fall through into the following function. ``` drivers/gpu/drm/amd/amdgpu/../display/dc/basics/fixpt31_32.o: warning: objtool: dc_fixpt_recip() falls through to next function dc_fixpt_sinc() drivers/gpu/drm/amd/amdgpu/../display/dc/sspl/spl_fixpt31_32.o: warning: objtool: spl_fixpt_recip() falls through to next function spl_fixpt_sinc() ``` It is undefined behavior, but in these cases it will silently generate incorrect code. It's far better to generate the bad code so that it signals/traps/whatever. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 137622] `--mlir-print-ir-tree-dir` fails with "Error while creating directory ...: No such file or directory" if symbol name contains path separator
Issue
137622
Summary
`--mlir-print-ir-tree-dir` fails with "Error while creating directory ...: No such file or directory" if symbol name contains path separator
Labels
new issue
Assignees
Reporter
i-ky
Consider the following example MLIR code in `/tmp/test.mlir`:
```mlir
module @"/foo/bar/" {}
```
Running `mlir-opt --canonicalize --mlir-print-ir-before-all --mlir-print-ir-after-all /tmp/test.mlir` outputs the following (as expected):
```
// -// IR Dump Before Canonicalizer (canonicalize) //- //
module @"/foo/bar/" {
}
// -// IR Dump After Canonicalizer (canonicalize) //- //
module @"/foo/bar/" {
}
module @"/foo/bar/" {
}
```
But when `--mlir-print-ir-tree-dir=/tmp/test` is added to the command - `mlir-opt --canonicalize --mlir-print-ir-before-all --mlir-print-ir-after-all --mlir-print-ir-tree-dir=/tmp/test /tmp/test.mlir` - the output is the following (note the errors):
```
Error while creating directory /tmp/test/builtin_module_/foo/bar/: No such file or directory
Error while creating directory /tmp/test/builtin_module_/foo/bar/: No such file or directory
module @"/foo/bar/" {
}
```
...and the `/tmp/test/` directory is empty.
There is no issue if `/` is swapped for `\` (I am on MacOS, on Windows it may be the opposite):
```
mlir-opt --canonicalize --mlir-print-ir-before-all --mlir-print-ir-after-all --mlir-print-ir-tree-dir=/tmp/test /tmp/test.mlir
module @"\\foo\\bar\\" {
}
tree /tmp/test
/tmp/test
└── builtin_module_\foo\bar\
├── 0_canonicalize.mlir
└── 1_canonicalize.mlir
2 directories, 2 files
```
The code responsible for generating paths is sanitizing op names by replacing `.` with `_`, but does nothing to symbol names:
https://github.com/llvm/llvm-project/blob/e086d7b1464ad091ae849cb907f8647c8439cb66/mlir/lib/Pass/IRPrinting.cpp#L207-L240
[Symbol names can be string literals](https://mlir.llvm.org/docs/LangRef/#identifiers-and-keywords), so there is a need to sanitize them before using in filesystem paths.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 137614] [AArch64][SVE] can fold whilele comparison with MAX to ptrue
Issue
137614
Summary
[AArch64][SVE] can fold whilele comparison with MAX to ptrue
Labels
new issue
Assignees
Reporter
k-arrows
Here is the test case from gcc testsuite(gcc.target/aarch64/sve/acle/general/whilele_12.c).
https://godbolt.org/z/o65qTs1T6
```c
#include
#include
svbool_t
f1 (volatile int32_t *ptr)
{
return svwhilele_b8_s32 (*ptr, INT32_MAX);
}
svbool_t
f2 (volatile uint32_t *ptr)
{
return svwhilele_b16_u32 (*ptr, UINT32_MAX);
}
svbool_t
f3 (volatile int64_t *ptr)
{
return svwhilele_b32_s64 (*ptr, INT64_MAX);
}
svbool_t
f4 (volatile uint64_t *ptr)
{
return svwhilele_b64_u64 (*ptr, UINT64_MAX);
}
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 137640] [flang] Parser error in fixed-form
Issue
137640
Summary
[flang] Parser error in fixed-form
Labels
flang:frontend
Assignees
Reporter
DanielCChen
Consider the following code:
```
program pointer4e
if ((ifac1 (4) .ne. 24) .or. (ifac2 (4) .ne. 24)) ERROR STOP(5)
end
```
When compile it with `-ffixed-form`, flang issues an error as
```
./pointer4e.f:2:71: error: Unmatched '('
if ((ifac1 (4) .ne. 24) .or. (ifac2 (4) .ne. 24)) ERROR STOP(5)
^
```
It compiles fine if I used `-ffree-form`.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 137760] Bad diagnostic after `--`: `no such file or directory X, did you mean X`
Issue 137760 Summary Bad diagnostic after `--`: `no such file or directory X, did you mean X` Labels new issue Assignees Reporter HolyBlackCat A little diagnostic bug. If you do `clang++ -- -fsyntax-only`, Clang says: ```console error: no such file or directory: '-fsyntax-only'; did you mean '-fsyntax-only'? ``` It shouldn't do this for obvious reasons. `did you mean '-some-flag'` should only trigger for parameters before the `--`. Tested on Clang 20 and trunk. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 137700] [AVX-512] `vpsubd a, b, vpmovm2d` can be done via a masked `vpsubd`
Issue
137700
Summary
[AVX-512] `vpsubd a, b, vpmovm2d` can be done via a masked `vpsubd`
Labels
new issue
Assignees
Reporter
dzaima
This code, compiled via `-O3 -march=znver5`:
```c
#include
#include
__m512i count_gt100(uint32_t* in, size_t count) {
__m512i neg_one = _mm512_set1_epi32(-1);
__m512i acc = _mm512_set1_epi32(0);
#pragma clang loop unroll(disable) // just to reduce noise
for (size_t i = 0; i < count; i++) {
__m512i val = _mm512_loadu_si512(in);
__mmask16 mask = _mm512_cmpgt_epi32_mask(val, _mm512_set1_epi32(100));
acc = _mm512_mask_sub_epi32(acc, mask, acc, neg_one);
in += 16;
}
return acc;
}
```
contains:
```asm
vpmovm2d zmm2, k0
vpsubd zmm0, zmm0, zmm2
```
whereas the implied desired code by the intrinsics, and as such gcc's codegen, takes just one instruction to do that - a masked `vpsubd`.
https://godbolt.org/z/MGjfGq96h
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 137650] [HLSL][SPIRV] Add a `KHR` special option to `spirv-ext` CLI option
Issue 137650 Summary [HLSL][SPIRV] Add a `KHR` special option to `spirv-ext` CLI option Labels HLSL, backend:SPIR-V Assignees s-perron Reporter s-perron In DXC, there is an options to limit the extension to just the KHR options: `-fspv-extension=KHR`. We would like to add the same to `spirv-ext` to make it easier to be backwards compatible with DXC. This can be implemented using a special value in SPIRVExtensionsParser::parse like "all". Then it can traverse the `SPIRVExtensionMap` to add all entries that start with "SPV_KHR". ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 137669] [BOLT] Malformed / corrupted profile counter on ARM
Issue 137669 Summary [BOLT] Malformed / corrupted profile counter on ARM Labels BOLT Assignees Reporter hilldani After collecting linux perf samples following [ARM documentation for BOLT](https://learn.arm.com/learning-paths/servers-and-cloud-computing/bolt/bolt-samples/) with this perf command ```bash perf record -e cycles:u -o perf.data -- ./binary ``` The perf data looks like ``` perf6061 [000] 475.121158: 1 cycles:u:5e4350 [unknown] (/usr/bin/perf) perf6061 [000] 475.121179: 1 cycles:u:5e437c [unknown] (/usr/bin/perf) perf 6061 [000] 475.121197: 1 cycles:u:4cab00 [unknown] (/usr/bin/perf) perf6061 [000] 475.121215: 3 cycles:u:4caadc [unknown] (/usr/bin/perf) perf 6061 [000] 475.121232: 8 cycles:u:4caae8 [unknown] (/usr/bin/perf) perf6061 [000] 475.121249: 22 cycles:u:5e2738 [unknown] (/usr/bin/perf) perf 6061 [000] 475.121267: 59 cycles:u:4cab60 [unknown] (/usr/bin/perf) perf6061 [000] 475.121285:159 cycles:u:4cb704 [unknown] (/usr/bin/perf) perf 6061 [000] 475.121303:413 cycles:u:5e25ec [unknown] (/usr/bin/perf) etc... ``` I generate the profile data ```bash $ ./perf2bolt -p perf.data -o a.fdata -nl binary BOLT-INFO: shared object or position-independent executable detected PERF2BOLT: Starting data aggregation job for perf.data PERF2BOLT: spawning perf job to read events without LBR PERF2BOLT: spawning perf job to read mem events PERF2BOLT: spawning perf job to read process events PERF2BOLT: spawning perf job to read task events BOLT-INFO: Target architecture: aarch64 BOLT-INFO: BOLT version: d7d4b5ec2904208b4ff88a280d2cc3fcb3edc3a9 BOLT-INFO: first alloc address is 0x0 BOLT-INFO: creating new program header table at address 0x9c0, offset 0x9c0 BOLT-INFO: enabling relocation mode BOLT-INFO: disabling -align-macro-fusion on non-x86 platform BOLT-INFO: enabling strict relocation mode for aggregation purposes BOLT-INFO: pre-processing profile using perf data aggregator BOLT-INFO: binary build-id is: 1faaef2ee4de701d PERF2BOLT: spawning perf job to read buildid list PERF2BOLT: matched build-id and file name PERF2BOLT: waiting for perf mmap events collection to finish... PERF2BOLT: parsing perf-script mmap events output PERF2BOLT: waiting for perf task events collection to finish... PERF2BOLT: parsing perf-script task events output PERF2BOLT: input binary is associated with 1 PID(s) PERF2BOLT: waiting for perf events collection to finish... PERF2BOLT: parsing basic events (without LBR)... PERF2BOLT: waiting for perf mem events collection to finish... PERF2BOLT: processing basic events (without LBR)... PERF2BOLT: read 19 samples PERF2BOLT: out of range samples recorded in unknown regions: 7 (36.8%) PERF2BOLT: wrote 12 objects and 0 memory objects to a.fdata BOLT-INFO: 11 out of 183192 functions in the binary (0.0%) have non-empty execution profile BOLT-INFO: 3 functions have instructions with unknown control flow. Use -print-unknown to see the list. ``` The profile looks like ``` no_lbr cycles:u: 1 pthread_mutex_lock@PLT 8 1 etc... ``` If I try merging this profile with anything it fails ```bash $ ./merge-fdata a.fdata > combined.fdata Using legacy profile format. merge-fdata: 'a.fdata': Malformed / corrupted profile counter. ``` However it can be used to generate a BOLT'ed binary ```bash $ ./llvm-bolt binary -o ./bolt_binary -data a.fdata -reorder-functions=hfsort BOLT-INFO: shared object or position-independent executable detected BOLT-INFO: Target architecture: aarch64 BOLT-INFO: BOLT version: d7d4b5ec2904208b4ff88a280d2cc3fcb3edc3a9 BOLT-INFO: first alloc address is 0x0 BOLT-INFO: creating new program header table at address 0x9c0, offset 0x9c0 BOLT-INFO: enabling relocation mode BOLT-INFO: disabling -align-macro-fusion on non-x86 platform BOLT-INFO: pre-processing profile using branch profile reader BOLT-INFO: operating with basic samples profiling data (no LBR). BOLT-INFO: normalizing samples by instruction count. BOLT-INFO: number of removed linker-inserted veneers: 0 BOLT-INFO: 9 out of 183192 functions in the binary (0.0%) have non-empty execution profile BOLT-INFO: 2 functions with profile could not be optimized BOLT-INFO: removed 21129 empty blocks BOLT-INFO: merged 17 duplicate CFG edges BOLT-INFO: Starting stub-insertion pass BOLT-INFO: Inserted 0 stubs in the hot area and 0 stubs in the cold area. Shared 0 times, iterated 1 times. BOLT-INFO: patched build-id (flipped last bit) BOLT-INFO: setting __hot_start to 0x9e0 BOLT-
[llvm-bugs] [Bug 137693] Address of empty function is not unique
Issue
137693
Summary
Address of empty function is not unique
Labels
Assignees
Reporter
fekir
Consider following snippet (https://godbolt.org/z/beGsh8zoj) compiled at least with `-O1`:
#include
void foo() { __builtin_unreachable(); }
void bar() {}
int main() {
auto ap = size_t(&foo);
auto bp = size_t(&bar);
std::cout
<< ap << "\n"
<< bp << "\n"
<< ap-bp << "\n"
<< (ap == bp ? "true\n" : "false\n");
}
the output of this programs look like
95027430187360
95027430187360
0
false
clang manages to creates two equal numbers (the difference is `0`), that are not equal
I believe this issue is related to https://github.com/llvm/llvm-project/issues/60588 (the oldest one I could find), which was (IMHO wrongly) rejected.
`void foo() { __builtin_unreachable(); }` does not have undefined behavior as long as it is not called, and taking the address of `foo` should thus not trigger undefined behavior.
The argument "The problematic code doesn't need to be executed for UB to take effect" is strangely worded.
The function `int baz(int i){return 1/i;}` also has UB when called as `baz(0)`, but as long as no one calls `baz` with the parameter `0`, there is no UB.
Contrary to most linked bug reports linked to https://github.com/llvm/llvm-project/issues/60588, the problematic function is not called.
As to why one would write something like `foo`; an example would be to write code for a compiler that does not support `__builtin_unreachable`; for example
#ifdef PLATFORM_WITH_BUILTIN_UNREACHABLE
void foo() { __builtin_unreachable(); }
#else
void foo() { abort(); }
#endif
// some code that uses foo instead of
// __builtin_unreachable directly to ensure portability
// with different compilers
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 137696] [clang-tidy] Check request: modernize-use-move-instead-swap
Issue
137696
Summary
[clang-tidy] Check request: modernize-use-move-instead-swap
Labels
clang-tidy
Assignees
Reporter
denzor200
C++03 did not have move semantics (`std::move`), so `swap` was used to efficiently transfer resources:
```
class CookieManager {
std::vector m_cookies;
public:
CookieManager() = default;
void initialize();
};
void CookieManager::initialize() {
std::vector v(1'000'000);
for (int i=0;i<1'000'000;++i) {
v[i] = // TODO: generate one cookie
}
m_cookies.swap(v); // exchange m_cookies with v (resources are transferred to m_cookies)
}
```
Needs a check that will find usages of `swap` and will suggest to use move-semanthic instead:
```
void CookieManager::initialize() {
std::vector v(1'000'000);
for (int i=0;i<1'000'000;++i) {
v[i] = // TODO: generate one cookie
}
m_cookies = std::move(v); // move semanthic (no copy)
}
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 137699] Misinterpreting debug information when stepping through a loop in a binary compiled with -O1
Issue
137699
Summary
Misinterpreting debug information when stepping through a loop in a binary compiled with -O1
Labels
new issue
Assignees
Reporter
edumoot
This issue arises when debugging into a while loop using step-by-step execution. The debugger incorrectly indicates that line 24 and 26 of the main function is part of the loop body. This behavior can be consistently reproduced with LLVM versions 17.0.6, 18.1.3, and 18.1.8.
Further details are provided below:
```
clang -g -O1 bug_5.c -o 5.out
lldb
(lldb) file 5.out
(lldb) b 14
(lldb) r
(lldb) s
(lldb) s
[...]
* thread #1, name = '5.out', stop reason = step in
frame #0: 0x51d0 5.out`main at bug_5.c:24
21 return sum > 500 ? 1 : 0;
22 }
23
-> 24 int main(){
25 int arr[] = {12, 9, 8, 15, 7, 18, 20, -1};
26 return f(arr);
27 }
(lldb) s
* thread #1, name = '5.out', stop reason = step in
frame #0: 0x51d3 5.out`main at bug_5.c:26:12
23
24 int main(){
25 int arr[] = {12, 9, 8, 15, 7, 18, 20, -1};
-> 26 return f(arr);
27 }
(lldb) s
* thread #1, name = '5.out', stop reason = step in
frame #0: 0x51d3 5.out`main [inlined] f(a=) at bug_5.c:13:28
10 int sum = 0;
11
12 while (i < filter.size && a[i] != filter.terminal_value && sum < filter.threshold) {
-> 13 if ((a[i] % 2 == 0 && a[i] > 10) || (a[i] % 4 == 0 && a[i] > 0 && a[i] < 50)) {
14 sum += a[i] * 2;
15 } else if (a[i] % 3 == 0) {
16 sum += a[i] / 3;
```
`cat bug_5.c`
```
struct Filter {
int size;
int threshold;
int terminal_value;
};
int f(int *a) {
struct Filter filter = {100, 1000, -1};
int i = 0;
int sum = 0;
while (i < filter.size && a[i] != filter.terminal_value && sum < filter.threshold) {
if ((a[i] % 2 == 0 && a[i] > 10) || (a[i] % 4 == 0 && a[i] > 0 && a[i] < 50)) {
sum += a[i] * 2;
} else if (a[i] % 3 == 0) {
sum += a[i] / 3;
}
i++;
}
return sum > 500 ? 1 : 0;
}
int main(){
int arr[] = {12, 9, 8, 15, 7, 18, 20, -1};
return f(arr);
}
```
GDB produces a similar result:
```
gdb
GNU gdb (Ubuntu 15.0.50.20240403-0ubuntu1) 15.0.50.20240403-git
...
(gdb) file 5.out
(gdb) b 14
(gdb) r
[...]
(gdb) s
12 while (i < filter.size && a[i] != filter.terminal_value && sum < filter.threshold) {
(gdb) s
26 return f(arr);
(gdb) s
f (a=) at bug_5.c:13
13 if ((a[i] % 2 == 0 && a[i] > 10) || (a[i] % 4 == 0 && a[i] > 0 && a[i] < 50)) {
(gdb)
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 137704] libc++ headers vs GCC 15 type traits builtins
Issue 137704 Summary libc++ headers vs GCC 15 type traits builtins Labels libc++ Assignees Reporter frobtech Between GCC 14 and GCC 15, a bunch of new C++ traits builtins were added that Clang already has: ``` 1b7cfa715c6 c++: introduce __builtin_is_virtual_base_of 3dab8f8a542 c++: Implement __is_nothrow_invocable built-in trait 7bd33955970 c++: Implement __is_invocable built-in trait 37fad797ade c++: Implement __array_rank built-in trait 142d1d8e057 c++: Implement __decay built-in trait 85c2ba42441 c++: Implement __add_rvalue_reference built-in trait c08d1afbf53 c++: Implement __add_lvalue_reference built-in trait 86812be98a1 c++: Implement __remove_all_extents built-in trait e1ca1fa1c7a c++: Implement __remove_extent built-in trait 2763f81e0b9 c++: Implement __add_pointer built-in trait 06d64eb96cd c++: Implement __is_unbounded_array built-in trait cb5d904c775 c++: Implement __is_pointer built-in trait 9b51b3e79e4 c++: Implement __is_volatile built-in trait 7dd8c905219 c++: Implement __is_const built-in trait ``` Unlike Clang, GCC gets upset if these are used via template aliases rather than only via the standard `...::type` type aliases. PR #81386 addressed the same issue earlier for `__remove_cv` and `__remove_cvref`. Equivalent changes are needed for all the other ones where `__has_builtin(...)` has become true in GCC 15. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 137705] __attribute__((nonstring)) and -Wunterminated-string-initialization
Issue 137705 Summary __attribute__((nonstring)) and -Wunterminated-string-initialization Labels clang Assignees Reporter frobtech GCC has `-Wunterminated-string-initialization` and `__attribute__((nonstring))` to counteract it. The warning is included in `-Wextra`. It warns for e.g. `char foo[3] = "foo";` because the string will not have a `'\0'` terminator. It doesn't warn for `__attribute__((nonstring)) char foo[3] = "foo";`. This would be a useful feature to add to Clang. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 137706] [libc] check-libc fails at LlvmLibcDyadicFloatTest.EdgeRangesLongDouble test
Issue 137706 Summary [libc] check-libc fails at LlvmLibcDyadicFloatTest.EdgeRangesLongDouble test Labels libc Assignees Reporter amemov I'm trying to build and run the libc on my machine using WSL (Ubuntu 24.04.1 LTS) on i7-9700K CPU. For building the project, I use the same cmake command provided on the [Libc's website](https://libc.llvm.org/overlay_mode.html#overlay-mode): ``` cmake ../runtimes -G Ninja -DLLVM_ENABLE_RUNTIMES="libc" \ -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ \ -DCMAKE_BUILD_TYPE=Release ``` Below is the error message that `ninja check-libc `outputs: [error_msg.txt](https://github.com/user-attachments/files/19948309/error_msg.txt) ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 137710] [LLDB] Provide an unconditional `@skip` annotation for API tests
Issue 137710 Summary [LLDB] Provide an unconditional `@skip` annotation for API tests Labels Assignees Reporter felipepiovezan The correct way of doing this today is to use `@skipIf` with no arguments, which reads like it expects a condition. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 137713] [HLSL][GlobalOpt] Target extension type not allowed to have a zeroinitializer
Issue
137713
Summary
[HLSL][GlobalOpt] Target extension type not allowed to have a zeroinitializer
Labels
HLSL,
clang:HLSL:DX
Assignees
Reporter
farzonl
## Crashing IR
```llvm
target("dx.RawBuffer", i16, 1, 0), ptr @_ZL3src, align 4, !tbaa !11
```
## IR more context
```llvm
if.then.i: ; preds = %entry
%agg.tmp1.i.sroa.0.0.copyload = load <4 x i32>, ptr addrspace(2) @dimSizes, align 16
%agg.tmp1.i.sroa.4.0.copyload = load <4 x i32>, ptr addrspace(2) getelementptr inbounds nuw (i8, ptr addrspace(2) @dimSizes, i32 16), align 16, !tbaa !10
%vecext.i = extractelement <4 x i32> %agg.tmp1.i.sroa.4.0.copyload, i64 3
%vecins3.i = shufflevector <4 x i32> , <4 x i32> %agg.tmp1.i.sroa.4.0.copyload, <4 x i32>
%vecext5.i = extractelement <4 x i32> %agg.tmp1.i.sroa.4.0.copyload, i64 2
%mul.i = mul i32 %vecext5.i, %vecext.i
%vecext11.i = extractelement <4 x i32> %agg.tmp1.i.sroa.4.0.copyload, i64 1
%mul14.i = mul i32 %mul.i, %vecext11.i
%3 = insertelement <4 x i32> %vecins3.i, i32 %mul14.i, i64 0
%vecins16.i = insertelement <4 x i32> %3, i32 %mul.i, i64 1
%vecext18.i = extractelement <4 x i32> %agg.tmp1.i.sroa.4.0.copyload, i64 0
%mul21.i = mul i32 %mul14.i, %vecext18.i
%vecext25.i = extractelement <4 x i32> %agg.tmp1.i.sroa.0.0.copyload, i64 3
%mul28.i = mul i32 %mul21.i, %vecext25.i
%vecext32.i = extractelement <4 x i32> %agg.tmp1.i.sroa.0.0.copyload, i64 2
%mul35.i = mul i32 %mul28.i, %vecext32.i
%vecext39.i = extractelement <4 x i32> %agg.tmp1.i.sroa.0.0.copyload, i64 1
%mul42.i = mul i32 %mul35.i, %vecext39.i
%4 = insertelement <4 x i32> poison, i32 %mul42.i, i64 0
%5 = insertelement <4 x i32> %4, i32 %mul35.i, i64 1
%6 = insertelement <4 x i32> %5, i32 %mul28.i, i64 2
%vecins44.i = insertelement <4 x i32> %6, i32 %mul21.i, i64 3
%splat.splatinsert.i = insertelement <4 x i32> poison, i32 %add.i, i64 0
%splat.splat.i = shufflevector <4 x i32> %splat.splatinsert.i, <4 x i32> poison, <4 x i32> zeroinitializer
%div.i = udiv <4 x i32> %splat.splat.i, %vecins44.i
%rem.i = urem <4 x i32> %div.i, %agg.tmp1.i.sroa.0.0.copyload
%div6.i = udiv <4 x i32> %splat.splat.i, %vecins16.i
%rem8.i = urem <4 x i32> %div6.i, %agg.tmp1.i.sroa.4.0.copyload
%agg.tmp4.i.sroa.0.0.copyload = load <4 x i32>, ptr addrspace(2) @outputStrides, align 16
%agg.tmp4.i.sroa.4.0.copyload = load <4 x i32>, ptr addrspace(2) getelementptr inbounds nuw (i8, ptr addrspace(2) @outputStrides, i32 16), align 16, !tbaa !10
%agg.tmp8.i.sroa.0.0.copyload = load <4 x i32>, ptr addrspace(2) @inputStrides, align 16
%agg.tmp8.i.sroa.4.0.copyload = load <4 x i32>, ptr addrspace(2) getelementptr inbounds nuw (i8, ptr addrspace(2) @inputStrides, i32 16), align 16, !tbaa !10
%hlsl.dot.i27 = tail call i32 @llvm.dx.udot.v4i32(<4 x i32> %rem.i, <4 x i32> %agg.tmp4.i.sroa.0.0.copyload)
%hlsl.dot4.i30 = tail call i32 @llvm.dx.udot.v4i32(<4 x i32> %rem8.i, <4 x i32> %agg.tmp4.i.sroa.4.0.copyload)
%add.i31 = add i32 %hlsl.dot4.i30, %hlsl.dot.i27
%hlsl.dot.i = tail call i32 @llvm.dx.udot.v4i32(<4 x i32> %rem.i, <4 x i32> %agg.tmp8.i.sroa.0.0.copyload)
%hlsl.dot4.i = tail call i32 @llvm.dx.udot.v4i32(<4 x i32> %rem8.i, <4 x i32> %agg.tmp8.i.sroa.4.0.copyload)
%add.i24 = add i32 %hlsl.dot4.i, %hlsl.dot.i
%7 = load target("dx.RawBuffer", i16, 1, 0), ptr @_ZL3src, align 4, !tbaa !11
%8 = tail call noundef nonnull align 2 dereferenceable(2) ptr @llvm.dx.resource.getpointer.p0.tdx.RawBuffer_i16_1_0t(target("dx.RawBuffer", i16, 1, 0) %7, i32 %add.i24)
%9 = load i16, ptr %8, align 2, !tbaa !13
%10 = tail call i16 @llvm.abs.i16(i16 %9, i1 false)
%11 = tail call noundef nonnull align 2 dereferenceable(2) ptr @llvm.dx.resource.getpointer.p0.tdx.RawBuffer_i16_1_0t(target("dx.RawBuffer", i16, 1, 0) %_ZL4dest_h.i.i, i32 %add.i31)
store i16 %10, ptr %11, align 2, !tbaa !13
br label %_Z6CSMainDv3_j.exit
```
## Assert
```gdb
Assertion failed: (Ty->hasProperty(TargetExtType::HasZeroInit) && "Target extension type not allowed to have a zeroinitializer"), function get, file Constants.cpp, line 1847.
Process 34436 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = hit program assert
frame #4: 0x000101d21d20 clang-dxc`llvm::ConstantTargetNone::get(Ty=0x00011c866030) at Constants.cpp:1846:3
1843 //
1844
1845 ConstantTargetNone *ConstantTargetNone::get(TargetExtType *Ty) {
-> 1846 assert(Ty->hasProperty(TargetExtType::HasZeroInit) &&
1847 "Target extension type not allowed to have a zeroinitializer");
1848 std::unique_ptr &Entry =
1849 Ty->getContext().pImpl->CTNConstants[Ty];
```
## Stack Trace
```gdb
* thread #1, queue = 'com.apple.main-thread', stop reason = hit program assert
frame #0: 0x0001842b4388 libsystem_kernel.dylib`__pthr
