[llvm-bugs] [Bug 120535] [Mlir] -one-shot-bufferize crashes in OneShotModuleBufferize.cpp:137: aliasingFuncOpBBArgsAnalysis
Issue
120535
Summary
[Mlir] -one-shot-bufferize crashes in OneShotModuleBufferize.cpp:137: aliasingFuncOpBBArgsAnalysis
Labels
mlir
Assignees
Reporter
Emilyaxe
git version: 881447fe443
system: `Ubuntu 18.04.6 LTS`
reproduce with: `/data/szy/MLIR/llvm-debug/llvm-project/build/bin/mlir-opt a.mlir -one-shot-bufferize`
a.mlir:
```
func.func private @main() {
llvm.return
}
```
stack trace:
```
mlir-opt: /data/szy/MLIR/llvm-debug/llvm-project/mlir/lib/Dialect/Bufferization/Transforms/OneShotModuleBufferize.cpp:137: LogicalResult (anonymous namespace)::aliasingFuncOpBBArgsAnalysis(FuncOp, OneShotAnalysisState &, FuncAnalysisState &): Assertion `!returnOps.empty() && "expected at least one ReturnOp"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0. Program arguments: /data/szy/MLIR/llvm-debug/llvm-project/build/bin/mlir-opt a.mlir -one-shot-bufferize=bufferize-function-boundaries
#0 0x558d7dfe9919 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /data/szy/MLIR/llvm-debug/llvm-project/llvm/lib/Support/Unix/Signals.inc:723:11
#1 0x558d7dfe9dcb PrintStackTraceSignalHandler(void*) /data/szy/MLIR/llvm-debug/llvm-project/llvm/lib/Support/Unix/Signals.inc:798:1
#2 0x558d7dfe7fff llvm::sys::RunSignalHandlers() /data/szy/MLIR/llvm-debug/llvm-project/llvm/lib/Support/Signals.cpp:105:5
#3 0x558d7dfea49e SignalHandler(int) /data/szy/MLIR/llvm-debug/llvm-project/llvm/lib/Support/Unix/Signals.inc:413:1
#4 0x7f78827bf420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420)
#5 0x7f7881dfc00b raise /build/glibc-LcI20x/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:51:1
#6 0x7f7881ddb859 abort /build/glibc-LcI20x/glibc-2.31/stdlib/abort.c:81:7
#7 0x7f7881ddb729 get_sysdep_segment_value /build/glibc-LcI20x/glibc-2.31/intl/loadmsgcat.c:509:8
#8 0x7f7881ddb729 _nl_load_domain /build/glibc-LcI20x/glibc-2.31/intl/loadmsgcat.c:970:34
#9 0x7f7881decfd6 (/lib/x86_64-linux-gnu/libc.so.6+0x33fd6)
#10 0x558d7ea29f63 (anonymous namespace)::aliasingFuncOpBBArgsAnalysis(mlir::func::FuncOp, mlir::bufferization::OneShotAnalysisState&, mlir::bufferization::func_ext::FuncAnalysisState&) /data/szy/MLIR/llvm-debug/llvm-project/mlir/lib/Dialect/Bufferization/Transforms/OneShotModuleBufferize.cpp:140:37
#11 0x558d7ea29754 mlir::bufferization::analyzeModuleOp(mlir::ModuleOp, mlir::bufferization::OneShotAnalysisState&, mlir::bufferization::BufferizationStatistics*) /data/szy/MLIR/llvm-debug/llvm-project/mlir/lib/Dialect/Bufferization/Transforms/OneShotModuleBufferize.cpp:504:16
#12 0x558d7ea4777f mlir::bufferization::insertTensorCopies(mlir::Operation*, mlir::bufferization::OneShotBufferizationOptions const&, mlir::bufferization::BufferizationStatistics*) /data/szy/MLIR/llvm-debug/llvm-project/mlir/lib/Dialect/Bufferization/Transforms/TensorCopyInsertion.cpp:37:16
#13 0x558d7ea2b14c mlir::bufferization::runOneShotModuleBufferize(mlir::ModuleOp, mlir::bufferization::OneShotBufferizationOptions const&, mlir::bufferization::BufferizationStatistics*) /data/szy/MLIR/llvm-debug/llvm-project/mlir/lib/Dialect/Bufferization/Transforms/OneShotModuleBufferize.cpp:616:18
#14 0x558d7e9c6d39 (anonymous namespace)::OneShotBufferizePass::runOnOperation() /data/szy/MLIR/llvm-debug/llvm-project/mlir/lib/Dialect/Bufferization/Transforms/Bufferize.cpp:187:18
#15 0x558d82f3cc04 mlir::detail::OpToOpPassAdaptor::run(mlir::Pass*, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int)::$_1::operator()() const /data/szy/MLIR/llvm-debug/llvm-project/mlir/lib/Pass/Pass.cpp:0:17
#16 0x558d82f3cba5 void llvm::function_ref::callback_fn(long) /data/szy/MLIR/llvm-debug/llvm-project/llvm/include/llvm/ADT/STLFunctionalExtras.h:46:5
#17 0x558d7e00d9d9 llvm::function_ref::operator()() const /data/szy/MLIR/llvm-debug/llvm-project/llvm/include/llvm/ADT/STLFunctionalExtras.h:69:5
#18 0x558d82f3f96b void mlir::MLIRContext::executeAction(llvm::function_ref, llvm::ArrayRef, mlir::Pass&) /data/szy/MLIR/llvm-debug/llvm-project/mlir/include/mlir/IR/MLIRContext.h:281:3
#19 0x558d82f387e7 mlir::detail::OpToOpPassAdaptor::run(mlir::Pass*, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int) /data/szy/MLIR/llvm-debug/llvm-project/mlir/lib/Pass/Pass.cpp:532:17
#20 0x558d82f38d07 mlir::detail::OpToOpPassAdaptor::runPipeline(mlir::OpPassManager&, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int, mlir::PassInstrumentor*, mlir::PassInstrumentation::PipelineParentInfo const*) /data/szy/MLIR/llvm-debug/llvm-project/mlir/lib/Pass/Pass.cpp:592:16
#21 0x558d82f3a618 mlir::PassManager::runPasses(mlir::Operation*, mlir::AnalysisManager) /data/szy/MLIR/llvm-debug/
[llvm-bugs] [Bug 120608] debian:testing (trixie) has removed `software-properties-common` dpkg required by `llvm.sh`
Issue 120608 Summary debian:testing (trixie) has removed `software-properties-common` dpkg required by `llvm.sh` Labels new issue Assignees Reporter ldalessa Debian is no longer providing the `software-properties-common` package that is required in `llvm.sh`. The binary required appears to be `add-apt-repository` but I do not know where to get that from anymore. According to a comment in https://github.com/wimpysworld/deb-get/issues/1215, this package will not be returning. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120543] Diagnose dangling issues on member field access
Issue
120543
Summary
Diagnose dangling issues on member field access
Labels
clang:diagnostics,
clang:memory-safety
Assignees
Reporter
hokein
We have some supports in member field access for references (#81589). It would be good to diagnose on the view types, see https://godbolt.org/z/zbx8hPera
```
#include
#include
struct S2 {
std::string s2;
};
struct Q3 {
const S2* get() const [[clang::lifetimebound]];
};
void test() {
auto& t = Q3().get()->s2; //dangling, clang diagnoses it.
std::string_view v = Q3().get()->s2; // dangling, clang doesn't diagnose it, bad.
}
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120573] `__builtin_cos` loses accuracy as doubles gain precision
Issue
120573
Summary
`__builtin_cos` loses accuracy as doubles gain precision
Labels
bug,
clang
Assignees
Reporter
cjdb
Given
```cpp
std::println("{}", __builtin_cos(1.5));
std::println("{}", __builtin_cos(1.57));
std::println("{}", __builtin_cos(1.570));
std::println("{}", __builtin_cos(1.5707));
std::println("{}", __builtin_cos(1.57079));
std::println("{}", __builtin_cos(1.570796));
std::println("{}", __builtin_cos(1.5707963));
std::println("{}", __builtin_cos(1.57079632));
std::println("{}", __builtin_cos(1.570796326));
std::println("{}", __builtin_cos(1.5707963267));
std::println("{}", __builtin_cos(1.57079632679));
std::println("{}", __builtin_cos(1.570796326794));
std::println("{}", __builtin_cos(1.5707963267948));
std::println("{}", __builtin_cos(1.57079632679489));
std::println("{}", __builtin_cos(1.570796326794896));
std::println("{}", __builtin_cos(1.5707963267948966));
```
we get the output
```
0.0707372016677029 // WolframAlpha: 0.0707372
0.0007963267107332633 // WolframAlpha: 0.000796327
0.0007963267107332633 // WolframAlpha: 0.000796327
9.632679474766714e-05 // WolframAlpha: 9.63268 × 10^-5
6.326794896668469e-06 // WolframAlpha: 6.32679 × 10^-6
3.2679489653813835e-07 // WolframAlpha: 3.26795 × 10^-7
2.6794896585028633e-08 // WolframAlpha: 2.67949 × 10^-8
6.794896706578056e-09 // WolframAlpha: 6.79490 × 10^-9
7.948966542250398e-10 // WolframAlpha: 7.94897 × 10^-10
9.489659630678013e-11 // WolframAlpha: 9.48966 × 10^-11
4.8965888601467475e-12 // WolframAlpha: 4.89662 × 10^-12
8.966773470272338e-13 // WolframAlpha: 8.96619 × 10^-13
9.665063548234599e-14 // WolframAlpha: 9.66192 × 10^-14
6.722570487708307e-15 // WolframAlpha: 6.61923 × 10^-15
7.273661547324616e-16 // WolframAlpha: 6.19231 × 10^-16
6.123233995736766e-17 // WolframAlpha: 1.92313 × 10^-17
```
Things start to get a bit wobbly at 14 decimal points, and very wrong thereafter.
This was originally noticed by the following program:
```cpp
#include
#include
int main() {
auto const c = std::sqrt(std::complex(-4.0f, 0.0f));
auto const z = std::sqrt(std::complex(-4.0, 0.0));
std::cout << c << z << '\n';
}
```
which gives the output
```
(-8.74228e-08,2)(1.22465e-16,2)
```
I was then able to trace this to `__builtin_cos` by playing with the implementation of `std::sqrt(std::complex)`.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120604] Request Commit Access For abhigargrepo
Issue
120604
Summary
Request Commit Access For abhigargrepo
Labels
infra:commit-access-request
Assignees
Reporter
abhigargrepo
I would like to request commit access to the LLVM GitHub repository.
Here are my details:
Name: Abhinav Garg
GitHub Username: abhigargrepo [abhinav.g...@amd.com]
Contributions: -
https://github.com/llvm/llvm-project/pull/90085 {Fix in si-mode-register pass}
https://github.com/llvm/llvm-project/pull/88858 {Pre commit test}
I understand and agree to abide by the LLVM Developer Policy and will ensure that my commits follow the project's coding and contribution guidelines.
Thank you for your consideration.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120539] [SimplifyCFG] Convert conditional branch into unconditional branch if the incoming values of phi node can be represented by the condition
Issue
120539
Summary
[SimplifyCFG] Convert conditional branch into unconditional branch if the incoming values of phi node can be represented by the condition
Labels
missed-optimization,
llvm:transforms
Assignees
dtcxzyw
Reporter
dtcxzyw
Alive2: https://alive2.llvm.org/ce/z/K8WVKU
```
define i1 @src1(i32 noundef %0, i32 noundef %1) {
start:
%2 = icmp eq i32 %0, 0
br i1 %2, label %bb6, label %bb5
bb6:
%3 = icmp eq i32 %1, 0
br i1 %3, label %bb2, label %bb3
bb5:
%.not = icmp ult i32 %0, %1
br i1 %.not, label %bb3, label %bb2
bb2:
br label %bb3
bb3:
%_0.sroa.0.0 = phi i1 [ true, %bb2 ], [ false, %bb6 ], [ false, %bb5 ]
ret i1 %_0.sroa.0.0
}
define i1 @tgt1(i32 %0, i32 %1) {
start:
%2 = icmp eq i32 %0, 0
%3 = icmp eq i32 %1, 0
%.not = icmp uge i32 %0, %1
%cond = select i1 %2, i1 %3, i1 %.not
ret i1 %cond
}
```
We can convert conditional branches into unconditional branches and adjust incoming values of the phi node:
```
define i1 @src2(i32 noundef %0, i32 noundef %1) {
start:
%2 = icmp eq i32 %0, 0
br i1 %2, label %bb6, label %bb5
bb6:
%3 = icmp eq i32 %1, 0
br i1 %3, label %bb2, label %bb3
bb5:
%.not = icmp ult i32 %0, %1
br i1 %.not, label %bb3, label %bb2
bb2:
br label %bb3
bb3:
%_0.sroa.0.0 = phi i1 [ true, %bb2 ], [ false, %bb6 ], [ false, %bb5 ]
ret i1 %_0.sroa.0.0
}
define i1 @tgt2(i32 noundef %0, i32 noundef %1) {
start:
%2 = icmp eq i32 %0, 0
br i1 %2, label %bb6, label %bb5
bb6:
%3 = icmp eq i32 %1, 0
br i1 %3, label %bb2, label %bb3
bb5:
%.not = icmp uge i32 %0, %1
br label %bb3
bb2:
br label %bb3
bb3:
%_0.sroa.0.0 = phi i1 [ true, %bb2 ], [ false, %bb6 ], [ %.not, %bb5 ]
ret i1 %_0.sroa.0.0
}
```
Finally we will get a select instruction with `foldTwoEntryPHINode`.
Inspired by https://github.com/llvm/llvm-project/pull/120177: https://rust.godbolt.org/z/cEjsW56Pq
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120544] llvm-objcopy doesn't support -O default
Issue 120544 Summary llvm-objcopy doesn't support -O default Labels new issue Assignees Reporter stsp With GNU objcopy you can convert binary files to the native arch by using `-I binary -O default`. But llvm-objcopy doesn't understand `-O default`. I tried the linker trick instead, which is to do: `ld -r -b binary -o data.o data.txt` as suggested here: https://stackoverflow.com/questions/5381254/whats-the-correct-way-to-determine-target-and-architecture-for-gnu-binutils This works with ld.bfd, but is rejected by ld.lld. So with llvm tools I've found no way of achiving this simple task. For compatibility with GNU objcopy it would be very nice to support "-O default". Also see this discussion: https://github.com/rui314/mold/issues/162#issuecomment-2552723377 And this blog: https://tratt.net/laurie/blog/2022/whats_the_most_portable_way_to_include_binary_blobs_in_an_executable.html ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120578] [lldb-dap] Trying to temporarily disable the function breakpoint deletes it entirely
Issue 120578 Summary [lldb-dap] Trying to temporarily disable the function breakpoint deletes it entirely Labels new issue Assignees Reporter HolyBlackCat Not sure if it's the issue with lldb-dap itself or the VSCode plugin. When I create a function breakpoint and try to temporarily disable it (in VSCode, by unchecking the checkbox to the left of it), the breakpoint disappears entirely. This is unlike source code breakpoints, which can be disabled and reenabled later. There's a separate button on the right for deleting a breakpoint. Only that should delete the breakpoint, not the checkbox. Testing this on Linux, with LLVM 19. How to repro: 1. Start debugging. Navigate to the breakpoints list. 2. Press `+` and type something (I tried `dlopen`). 3. Press the checkbox to the left of the newly added breakpoint. 4. I expected only the checkbox to become unticked, but instead the checkpoint itself disappears from the list. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120586] [analyzer] Wrong warning location of memory leak
Issue
120586
Summary
[analyzer] Wrong warning location of memory leak
Labels
new issue
Assignees
Reporter
mvpant
```c
// clang --analyze -Xanalyzer -analyzer-output=text
#include
#include
#include
void leak(bool v1) {
void* v3 = malloc(1);
if (v3 != NULL) {
int v5 = 0; // <--- warning: Potential leak of memory pointed to by 'v3' [unix.Malloc]
if (v1) {
return; // <--- Expected warning location
}
}
return;
}
void leak2(bool v1) {
void* v3 = malloc(1);
if (v3 != NULL) {
if (v1) { // <--- warning: Potential leak of memory pointed to by 'v3' [unix.Malloc]
return; // <--- Expected warning location
}
}
return;
}
void caller() {
leak(1);
leak2(1);
return;
}
```
[Godbolt example](https://godbolt.org/z/8qGP347Yv)
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120552] lld: syntax error in linker script triggers a sef-fault
Issue
120552
Summary
lld: syntax error in linker script triggers a sef-fault
Labels
lld
Assignees
Reporter
nickclifton
I was experimenting with a change to a linker script when I encountered a segmentation fault triggered by a syntax error:
ld.lld: error: kernel.ld:3: ( expected, but got 0
>>> .data : { LONG 0; }
>>> ^
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0. Program arguments: ld.lld -melf_i386 -static -o lld.elf --emit-relocs -Tkernel.ld tst.o
#0 0x1465ce217b7a llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/lib64/libLLVM.so.19.1+0x217b7a)
#1 0x1465ce214b24 llvm::sys::RunSignalHandlers() (/lib64/libLLVM.so.19.1+0x214b24)
#2 0x1465ce2182eb (/lib64/libLLVM.so.19.1+0x2182eb)
#3 0x1465cda25dd0 __restore_rt (/lib64/libc.so.6+0x19dd0)
#4 0x1465d61a96a0 (/lib64/liblldELF.so.19.1+0x1a96a0)
#5 0x1465d61a71e4 (/lib64/liblldELF.so.19.1+0x1a71e4)
#6 0x1465d618dfc5 lld::elf::readLinkerScript(llvm::MemoryBufferRef) (/lib64/liblldELF.so.19.1+0x18dfc5)
#7 0x1465d6068ce6 lld::elf::LinkerDriver::createFiles(llvm::opt::InputArgList&) (/lib64/liblldELF.so.19.1+0x68ce6)
#8 0x1465d605cc73 lld::elf::LinkerDriver::linkerMain(llvm::ArrayRef) (/lib64/liblldELF.so.19.1+0x5cc73)
#9 0x1465d605c0da lld::elf::link(llvm::ArrayRef, llvm::raw_ostream&, llvm::raw_ostream&, bool, bool) (/lib64/liblldELF.so.19.1+0x5c0da)
#10 0x1465d5d22c5e lld::unsafeLldMain(llvm::ArrayRef, llvm::raw_ostream&, llvm::raw_ostream&, llvm::ArrayRef, bool) (/lib64/liblldCommon.so.19.1+0x3c5e)
#11 0x556d45ff8937 lld_main(int, char**, llvm::ToolContext const&) (/usr/bin/lld+0x1937)
#12 0x556d45ff8f32 main (/usr/bin/lld+0x1f32)
#13 0x1465cda0f248 __libc_start_call_main (/lib64/libc.so.6+0x3248)
#14 0x1465cda0f30b __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x330b)
#15 0x556d45ff86c5 _start (/usr/bin/lld+0x16c5)
Segmentation fault (core dumped)
This was with LLD 19.1.5 running on Fedora 41.
The full linker script looks like this:
SECTIONS
{
.data : { LONG 0; }
TTT = .;
_LGROUP = .;
. = SIZEOF_HEADERS;
. = ALIGN(0x100);
.text : {
*(TEXT)
. = ALIGN(0x100);
}
}
Obviously I should have written "LONG (0)" instead of "LONG 0", but I figured that you might wish to fix the seg-fault anyway.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120553] [RISC-V] epilogue_begin is set incorrectly
Issue
120553
Summary
[RISC-V] epilogue_begin is set incorrectly
Labels
bug,
backend:RISC-V,
debuginfo,
new issue
Assignees
RamNalamothu
Reporter
RamNalamothu
For the following test,
```
int main(int argc, char **argv)
{
int foo = 1;
return 0;
}
```
GCC (riscv32) generates (https://godbolt.org/z/Wqze6n8Gs):
```
main:
.LFB0:
.file 1 "/app/example.c"
.loc 1 2 1
.cfi_startproc
addisp,sp,-48
.cfi_def_cfa_offset 48
sw ra,44(sp)
sw s0,40(sp)
.cfi_offset 1, -4
.cfi_offset 8, -8
addis0,sp,48
.cfi_def_cfa 8, 0
sw a0,-36(s0)
sw a1,-40(s0)
.loc 1 3 7
li a5,1
sw a5,-20(s0)
.loc 1 5 10
li a5,0
.loc 1 6 1
mv a0,a5
lw ra,44(sp)
.cfi_restore 1
lw s0,40(sp)
.cfi_restore 8
.cfi_def_cfa 2, 48
addisp,sp,48
.cfi_def_cfa_offset 0
jr ra
.cfi_endproc
.LFE0:
.size main, .-main
```
and Clang riscv32 generates (https://godbolt.org/z/TMGPsr44s):
```
main:
.Lfunc_begin0:
.file 0 "/app" "/app/example.c" md5 0x8aa04db627be45b3215ab92eac2e23c5
.file 1 "example.c" md5 0x8aa04db627be45b3215ab92eac2e23c5
.loc1 2 0
.cfi_sections .debug_frame
.cfi_startproc
addisp, sp, -32
.cfi_def_cfa_offset 32
sw ra, 28(sp)
sw s0, 24(sp)
.cfi_offset ra, -4
.cfi_offset s0, -8
addis0, sp, 32
.cfi_def_cfa s0, 0
mv a2, a0
li a0, 0
sw a0, -12(s0)
sw a2, -16(s0)
sw a1, -20(s0)
li a1, 1
.Ltmp0:
.loc1 3 7 prologue_end
sw a1, -24(s0)
.cfi_def_cfa sp, 32
lw ra, 28(sp) <<
lw s0, 24(sp)
.cfi_restore ra
.cfi_restore s0
.loc1 5 3 epilogue_begin <<
addisp, sp, 32
.cfi_def_cfa_offset 0
ret
.Ltmp1:
.Lfunc_end0:
.size main, .Lfunc_end0-main
```
As can be seen from the Clang's output, the _epilogue_begin_ is set after the epilogue has actually begun. This creates a problem if we single step from line 3, or set a breakpoint on line 5, the FP has been restored to the parent frame's FP, and accessing variables goes to the wrong place.
$ gdb main.gcc
```
(gdb) b main
Breakpoint 1 at 0x10444: file main.c, line 3.
(gdb) c
Continuing.
Breakpoint 1, main (argc=1, argv=0x4084) at main.c:3
3 int foo = 1;
(gdb) si
0x00010446 3 int foo = 1;
(gdb) p foo
$1 = 0
(gdb) si
5 return 0;
(gdb) p foo
$2 = 1
(gdb) s
6 }
(gdb) p foo
$3 = 1
(gdb)
```
$ gdb main.llvm
```
(gdb) b main
Breakpoint 1 at 0x10496: file main.c, line 3.
(gdb) c
Continuing.
Breakpoint 1, main (argc=1, argv=0x4074) at main.c:3
3 int foo = 1;
(gdb) si
0x0001049a 3 int foo = 1;
(gdb) p foo
$1 = 1
(gdb) si
0x0001049c 3 int foo = 1;
(gdb) p foo
$2 = 1
(gdb) s
5 return 0;
(gdb) p foo
$3 = -1242739775
(gdb)
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120559] [lld][MachO] llvm::upper_bound called on not correctly sorted input
Issue
120559
Summary
[lld][MachO] llvm::upper_bound called on not correctly sorted input
Labels
Assignees
Reporter
karka228
When building llvm-project with -DLLVM_ENABLE_EXPENSIVE_CHECKS=ON with a recent libstdc++ (e.g. from gcc 13.3.0) the testcases:
```
lld :: MachO/local-alias-to-weak.s
lld :: MachO/symtab.s
lld :: MachO/weak-definition-gc.s
```
fail with the message:
```
.../include/c++/13.3.0/bits/stl_algo.h:2100:
In function:
_ForwardIterator std::upper_bound(_ForwardIterator, _ForwardIterator,
const _Tp &, _Compare) [_ForwardIterator = lld::macho::Defined **, _Tp =
unsigned long, _Compare = (lambda at
../../lld/MachO/SymbolTable.cpp:77:15)]
Error: elements in iterator range [first, last) are not partitioned by the
predicate __comp and value __val.
Objects involved in the operation:
iterator "first" @ 0x7ffc2bfd9af8 {
}
iterator "last" @ 0x7ffc2bfd9af0 {
}
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0. Program arguments: /repo/llvm-project/llvm/build/bin/ld64.lld -arch x86_64 -platform_version macos 11.0 11.0 -syslibroot /repo/llvm-project/lld/test/MachO/Inputs/MacOSX.sdk -lSystem -fatal_warnings -lSystem -dylib /repo/llvm-project/llvm/build/tools/lld/test/MachO/Output/local-alias-to-weak.s.tmp/no-subsections.o /repo/llvm-project/llvm/build/tools/lld/test/MachO/Output/local-alias-to-weak.s.tmp/local-then-weak.o -o /repo/llvm-project/llvm/build/tools/lld/test/MachO/Output/local-alias-to-weak.s.tmp/nosub-sub
#0 0x55af1d9c8706 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/repo/llvm-project/llvm/build/bin/ld64.lld+0x4d89706)
#1 0x55af1d9c60ce llvm::sys::RunSignalHandlers() (/repo/llvm-project/llvm/build/bin/ld64.lld+0x4d870ce)
#2 0x55af1d9c8f79 SignalHandler(int) Signals.cpp:0:0
#3 0x7efebf8c7cf0 __restore_rt (/lib64/libpthread.so.0+0x12cf0)
#4 0x7efebe980acf raise (/lib64/libc.so.6+0x4eacf)
#5 0x7efebe953ea5 abort (/lib64/libc.so.6+0x21ea5)
#6 0x55af223cfa43 (/repo/llvm-project/llvm/build/bin/ld64.lld+0x9790a43)
#7 0x55af1df2aab1 transplantSymbolsAtOffset(lld::macho::InputSection*, lld::macho::InputSection*, lld::macho::Defined*, unsigned long, unsigned long) SymbolTable.cpp:0:0
#8 0x55af1df29519 lld::macho::SymbolTable::addDefined(llvm::StringRef, lld::macho::InputFile*, lld::macho::InputSection*, unsigned long, unsigned long, bool, bool, bool, bool, bool) (/repo/llvm-project/llvm/build/bin/ld64.lld+0x52ea519)
#9 0x55af1de8a33e void lld::macho::ObjFile::parseSymbols(llvm::ArrayRef, llvm::ArrayRef, char const*, bool) (/repo/llvm-project/llvm/build/bin/ld64.lld+0x524b33e)
#10 0x55af1de78214 void lld::macho::ObjFile::parse() (/repo/llvm-project/llvm/build/bin/ld64.lld+0x5239214)
#11 0x55af1de77cc8 lld::macho::ObjFile::ObjFile(llvm::MemoryBufferRef, unsigned int, llvm::StringRef, bool, bool, bool, bool) (/repo/llvm-project/llvm/build/bin/ld64.lld+0x5238cc8)
#12 0x55af1de492dc lld::macho::ObjFile* lld::make(llvm::MemoryBufferRef&, unsigned int&&, char const (&) [1], bool&) (/repo/llvm-project/llvm/build/bin/ld64.lld+0x520a2dc)
#13 0x55af1de43090 addFile(llvm::StringRef, LoadType, bool, bool, bool, bool) Driver.cpp:0:0
#14 0x55af1de40cdd lld::macho::link(llvm::ArrayRef, llvm::raw_ostream&, llvm::raw_ostream&, bool, bool) (/repo/llvm-project/llvm/build/bin/ld64.lld+0x5201cdd)
#15 0x55af1d9cafbe lld::unsafeLldMain(llvm::ArrayRef, llvm::raw_ostream&, llvm::raw_ostream&, llvm::ArrayRef, bool) (/repo/llvm-project/llvm/build/bin/ld64.lld+0x4d8bfbe)
#16 0x55af1d8f6f1b lld_main(int, char**, llvm::ToolContext const&) (/repo/llvm-project/llvm/build/bin/ld64.lld+0x4cb7f1b)
#17 0x55af1d8f76a6 main (/repo/llvm-project/llvm/build/bin/ld64.lld+0x4cb86a6)
#18 0x7efebe96cd85 __libc_start_main (/lib64/libc.so.6+0x3ad85)
#19 0x55af1d8f6cae _start (/repo/llvm-project/llvm/build/bin/ld64.lld+0x4cb7cae)
Aborted (core dumped)
```
The reason for this is that the requirement for calling llvm::upper_bound (std::upper_bound) in function transplantSymbolsAtOffset() in file lld/MachO/SymbolTable.cpp is not fulfilled. The input to std::upper_bound needs sorted vector because it implements binary search to find the value.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120558] External symbol linker errors with std::shared_ptr in lambda
Issue 120558 Summary External symbol linker errors with std::shared_ptr in lambda Labels new issue Assignees Reporter kamrann The linked reproduction has had a lot of code removed so is somewhat nonsensical, but produces linker errors with clang (19 & trunk) whilst compiling successfully with gcc and MSVC. Similar errors result across both Windows (with MS STL) and Linux (both libc++ and libstdc++), seemingly relating to symbols of virtual functions initially declared pure. https://godbolt.org/z/oK1dhPMhh ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120568] How does llvm-project print the CFG for the machine code stage?
Issue 120568 Summary How does llvm-project print the CFG for the machine code stage? Labels new issue Assignees Reporter StevenYangCC How does llvm-project print the CFG for the machine code stage? ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120636] [HLSL] Fix global resource initialization
Issue 120636 Summary [HLSL] Fix global resource initialization Labels HLSL Assignees Reporter llvm-beanz Currently we connect global resource initialization in `GenerateCXXGlobalInitFunc` (https://github.com/llvm/llvm-project/blob/main/clang/lib/CodeGen/CGDeclCXX.cpp#L1087), but this is really not the right place. This function can be called multiple times throughout compilation to generate different initializer functions. Clang has a mechanism for collecting global initializer functions and including them in the final module initializer, we should instead use that mechanism by adding our initializer to CodeGenModule's CXXGlobalInits list. We could either generate an initializer function per-resource (which I think is preferred), or we could generate a single initializer late, but either way we should not have a hook in the place it is today. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120637] Clang crashes on invalid program
Issue
120637
Summary
Clang crashes on invalid program
Labels
clang
Assignees
Reporter
beached
Clang trunk/19.1.0 crash on the following curse
https://gcc.godbolt.org/z/T1cjEdcE5
```cpp
#include
static std::jmp_buf buff{};
static const auto x = [](auto&& b) { return setjmp(b); }(buff);
void foo(std::jmp_buf b, int s ) {
[[clang::musttail]] return std::longjmp(b, s );
}
int main( int argc, char** argv ) {
foo( buff, argc == 2 );
}
```
```
fatal error: error in backend: failed to perform tail call elimination on a call site marked musttail
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: /opt/compiler-explorer/clang-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++23 -O3 -isystem/app/boost/include
1. parser at end of file
2. Code generation
3. Running pass 'Function Pass Manager' on module ''.
4. Running pass 'X86 DAG->DAG Instruction Selection' on function '@_Z3fooP13__jmp_buf_tagi'
#0 0x03a26c78 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x3a26c78)
#1 0x03a24dc4 llvm::sys::CleanupOnSignal(unsigned long) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x3a24dc4)
#2 0x039758f3 llvm::CrashRecoveryContext::HandleExit(int) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x39758f3)
#3 0x03a1c7fe llvm::sys::Process::Exit(int, bool) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x3a1c7fe)
#4 0x00cfd2db LLVMErrorHandler(void*, char const*, bool) cc1_main.cpp:0:0
#5 0x0397f9c3 llvm::report_fatal_error(llvm::Twine const&, bool) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x397f9c3)
#6 0x0397fb28 (/opt/compiler-explorer/clang-trunk/bin/clang+++0x397fb28)
#7 0x0263ad18 llvm::X86TargetLowering::LowerCall(llvm::TargetLowering::CallLoweringInfo&, llvm::SmallVectorImpl&) const (/opt/compiler-explorer/clang-trunk/bin/clang+++0x263ad18)
#8 0x04c08101 llvm::TargetLowering::LowerCallTo(llvm::TargetLowering::CallLoweringInfo&) const (/opt/compiler-explorer/clang-trunk/bin/clang+++0x4c08101)
#9 0x04c09f8d llvm::SelectionDAGBuilder::lowerInvokable(llvm::TargetLowering::CallLoweringInfo&, llvm::BasicBlock const*) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x4c09f8d)
#10 0x04c29704 llvm::SelectionDAGBuilder::LowerCallTo(llvm::CallBase const&, llvm::SDValue, bool, bool, llvm::BasicBlock const*, llvm::TargetLowering::PtrAuthInfo const*) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x4c29704)
#11 0x04c42128 llvm::SelectionDAGBuilder::visitCall(llvm::CallInst const&) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x4c42128)
#12 0x04c55e17 llvm::SelectionDAGBuilder::visit(llvm::Instruction const&) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x4c55e17)
#13 0x04cd5b1c llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator_w_bits, false, true>, llvm::ilist_iterator_w_bits, false, true>, bool&) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x4cd5b1c)
#14 0x04cd7044 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x4cd7044)
#15 0x04cd8c2f llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x4cd8c2f)
#16 0x04cc5161 llvm::SelectionDAGISelLegacy::runOnMachineFunction(llvm::MachineFunction&) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x4cc5161)
#17 0x02e40245 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (.part.0) MachineFunctionPass.cpp:0:0
#18 0x03394c52 llvm::FPPassManager::runOnFunction(llvm::Function&) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x3394c52)
#19 0x03394ee1 llvm::FPPassManager::runOnModule(llvm::Module&) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x3394ee1)
#20 0x03396849 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x3396849)
#21 0x03cc587e 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*) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x3cc587e)
#22 0x0435e1fc clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x435e1fc)
#2
[llvm-bugs] [Bug 120621] [GlobalISel][AArch64] LLVM ERROR: unable to legalize instruction: %37:_(s32) = G_ZEXT %11:_(s1)
Issue
120621
Summary
[GlobalISel][AArch64] LLVM ERROR: unable to legalize instruction: %37:_(s32) = G_ZEXT %11:_(s1)
Labels
backend:AArch64,
llvm:globalisel,
llvm:crash,
crash-on-valid
Assignees
Reporter
fhahn
`llc -global-isel` on the IR below crashes with `LLVM ERROR: unable to legalize instruction: %37:_(s32) = G_ZEXT %11:_(s1) `
https://llvm.godbolt.org/z/bYKo9eTvc
```
target datalayout = "e-m:o-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-n32:64-S128-Fn32"
target triple = "arm64-apple-macosx15.0.0"
define fastcc i32 @foo(<4 x double> %x) {
entry:
%0 = fcmp ogt <4 x double> %x, zeroinitializer
%1 = bitcast <4 x i1> %0 to i4
%2 = zext i4 %1 to i32
ret i32 %2
}
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120630] [DirectX] Transform fast math flags to LLVM 3.7 for bitcode writer
Issue
120630
Summary
[DirectX] Transform fast math flags to LLVM 3.7 for bitcode writer
Labels
backend:DirectX
Assignees
Reporter
llvm-beanz
The DXIL bitcode writer is currently encoding modern LLVM fast math flags instead of LLVM 3.7's equivalent. The patch below is probably a starting point, but is likely not everything that needs to change to address this problem.
```diff
diff --git a/llvm/lib/Target/DirectX/DXILWriter/DXILBitcodeWriter.cpp b/llvm/lib/Target/DirectX/DXILWriter/DXILBitcodeWriter.cpp
index 45aadac86194..4ea31dde3e00 100644
--- a/llvm/lib/Target/DirectX/DXILWriter/DXILBitcodeWriter.cpp
+++ b/llvm/lib/Target/DirectX/DXILWriter/DXILBitcodeWriter.cpp
@@ -749,20 +749,14 @@ uint64_t DXILBitcodeWriter::getOptimizationFlags(const Value *V) {
if (PEO->isExact())
Flags |= 1 << bitc::PEO_EXACT;
} else if (const auto *FPMO = dyn_cast(V)) {
-if (FPMO->hasAllowReassoc())
- Flags |= bitc::AllowReassoc;
+if (FPMO->hasAllowReassoc() || FPMO->hasAllowContract())
+ Flags |= bitc::UnsafeAlgebra;
if (FPMO->hasNoNaNs())
Flags |= bitc::NoNaNs;
if (FPMO->hasNoInfs())
Flags |= bitc::NoInfs;
if (FPMO->hasNoSignedZeros())
Flags |= bitc::NoSignedZeros;
- if (FPMO->hasAllowReciprocal())
- Flags |= bitc::AllowReciprocal;
- if (FPMO->hasAllowContract())
- Flags |= bitc::AllowContract;
-if (FPMO->hasApproxFunc())
- Flags |= bitc::ApproxFunc;
}
return Flags;
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120616] Xtensa: error: 'class llvm::SDUse' has no member named 'getOpcode'; did you mean 'getNode'?
Issue 120616 Summary Xtensa: error: 'class llvm::SDUse' has no member named 'getOpcode'; did you mean 'getNode'? Labels build-problem, backend:Xtensa Assignees Reporter sylvestre On linux, failed recently: ``` FAILED: lib/Target/Xtensa/CMakeFiles/LLVMXtensaCodeGen.dir/XtensaISelLowering.cpp.o /opt/sccache//sccache /usr/bin/g++ -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/Target/Xtensa -I/build/source/llvm/lib/Target/Xtensa -Iinclude -I/build/source/llvm/include -fstack-protector-strong -Wformat -Werror=format-security -Wno-unused-command-line-argument -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time -fno-lifetime-dse -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-uninitialized -Wno-nonnull -Wno-class-memaccess -Wno-redundant-move -Wno-pessimizing-move -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wsuggest-override -Wno-comment -Wno-misleading-indentation -fdiagnostics-color -ffunction-sections -fdata-sections -fdebug-prefix-map=/build/source/build-llvm=../ -fdebug-prefix-map=/build/source/= -no-canonical-prefixes -ffile-prefix-map=/build/source/build-llvm=../ -ffile-prefix-map=/build/source/= -no-canonical-prefixes -O3 -DNDEBUG -fvisibility=hidden -fno-exceptions -funwind-tables -std=c++17 -MD -MT lib/Target/Xtensa/CMakeFiles/LLVMXtensaCodeGen.dir/XtensaISelLowering.cpp.o -MF lib/Target/Xtensa/CMakeFiles/LLVMXtensaCodeGen.dir/XtensaISelLowering.cpp.o.d -o lib/Target/Xtensa/CMakeFiles/LLVMXtensaCodeGen.dir/XtensaISelLowering.cpp.o -c /build/source/llvm/lib/Target/Xtensa/XtensaISelLowering.cpp /build/source/llvm/lib/Target/Xtensa/XtensaISelLowering.cpp: In member function 'llvm::SDValue llvm::XtensaTargetLowering::LowerImmediate(llvm::SDValue, llvm::SelectionDAG&) const': /build/source/llvm/lib/Target/Xtensa/XtensaISelLowering.cpp:750:52: error: 'class llvm::SDUse' has no member named 'getOpcode'; did you mean 'getNode'? 750 | if ((OpNode.hasOneUse() && OpNode.use_begin()->getOpcode() == ISD::ADD) && | ^ | getNode At global scope: ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120615] [SCEV] Segfault in SCEV LoopGuards
Issue
120615
Summary
[SCEV] Segfault in SCEV LoopGuards
Labels
llvm:crash,
llvm:SCEV,
crash-on-valid
Assignees
Reporter
danilaml
For the following IR:
```llvm
target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128-ni:1-p2:32:8:8:32-ni:2"
target triple = "x86_64-unknown-linux-gnu"
define void @foo() {
.split.us120:
br label %.split.us120.split.split.us.split.split.us.split.split.us.split
.split.us120.split.split.us.split.split.us.split.split.us.split: ; preds = %.noexc7.us.us.us.us.us, %.split.us120
br label %.noexc7.us.us.us.us.us
.lr.ph.us.us.us.us407: ; No predecessors!
switch i32 0, label %.split142.us.split.us.split.us [
i32 0, label %.split160.us.split.us.split.us
i32 1, label %.noexc7.us.us.us.us.us
]
.noexc7.us.us.us.us.us: ; preds = %.noexc7.us.us.us.us.us, %.lr.ph.us.us.us.us407, %.split.us120.split.split.us.split.split.us.split.split.us.split
%0 = phi i32 [ %1, %.noexc7.us.us.us.us.us ], [ 0, %.lr.ph.us.us.us.us407 ], [ 0, %.split.us120.split.split.us.split.split.us.split.split.us.split ]
%1 = add i32 %0, 1
%.not.i3.us.us.us.us384.us = icmp slt i32 %0, 0
br i1 %.not.i3.us.us.us.us384.us, label %.noexc7.us.us.us.us.us, label %.split.us120.split.split.us.split.split.us.split.split.us.split
.split142.us.split.us.split.us: ; preds = %.lr.ph.us.us.us.us407
ret void
.split160.us.split.us.split.us: ; preds = %.lr.ph.us.us.us.us407
ret void
}
```
`opt` crashes when run using `-passes=nary-reassociate --scalar-evolution-use-expensive-range-sharpening`
godbolt: https://godbolt.org/z/xPv4TMMo8
Backtrace (truncated due to length limits):
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/opt -o /app/output.s -S -passes=nary-reassociate --scalar-evolution-use-expensive-range-sharpening
1. Running pass "function(nary-reassociate)" on module ""
2. Running pass "nary-reassociate" on function "foo"
#0 0x05257198 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x5257198)
#1 0x05254b9c SignalHandler(int) Signals.cpp:0:0
#2 0x7f9ab9c42520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#3 0x051640cb llvm::hash_value(llvm::APInt const&) (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x51640cb)
#4 0x051641a9 llvm::DenseMapInfo::getHashValue(llvm::APInt const&) (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x51641a9)
#5 0x04ed726b bool llvm::DenseMapBase>, llvm::DenseMapInfo, llvm::detail::DenseMapPair>>>, llvm::APInt, std::unique_ptr>, llvm::DenseMapInfo, llvm::detail::DenseMapPair>>>::LookupBucketFor(llvm::APInt const&, llvm::detail::DenseMapPair>>*&) (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x4ed726b)
#6 0x04edb996 llvm::ConstantInt::get(llvm::LLVMContext&, llvm::APInt const&) (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x4edb996)
#7 0x04eeba30 llvm::ConstantInt::get(llvm::Type*, llvm::APInt const&) (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x4eeba30)
#8 0x04eb6172 llvm::ConstantFoldBinaryInstruction(unsigned int, llvm::Constant*, llvm::Constant*) (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x4eb6172)
#9 0x04ee9f2e llvm::ConstantExpr::get(unsigned int, llvm::Constant*, llvm::Constant*, unsigned int, llvm::Type*) (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x4ee9f2e)
#10 0x049427fb llvm::ScalarEvolution::getNegativeSCEV(llvm::SCEV const*, llvm::SCEV::NoWrapFlags) (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x49427fb)
#11 0x049429c4 llvm::ScalarEvolution::getMinusSCEV(llvm::SCEV const*, llvm::SCEV const*, llvm::SCEV::NoWrapFlags, unsigned int) (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x49429c4)
#12 0x04950e7a llvm::ScalarEvolution::LoopGuards::collectFromBlock(llvm::ScalarEvolution&, llvm::ScalarEvolution::LoopGuards&, llvm::BasicBlock const*, llvm::BasicBlock const*, llvm::SmallPtrSetImpl&, unsigned int) (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x4950e7a)
#13 0x049524c2 llvm::ScalarEvolution::LoopGuards::collectFromPHI(llvm::ScalarEvolution&, llvm::ScalarEvolution::LoopGuards&, llvm::PHINode const&, llvm::SmallPtrSetImpl&, llvm::SmallDenseMap, llvm::detail::DenseMapPair>&, unsigned int)::'lambda'(unsigned int)::operator()(unsigned int) const ScalarEvolution.cpp:0:0
#14 0x04952702 llvm::ScalarEvolution::LoopGuards::collectFromPHI(llvm::ScalarEvolution&, llvm::ScalarEvolution::LoopGuards&, llvm::PHINode const&, llvm::SmallPtrSetImpl&, ll
[llvm-bugs] [Bug 120657] In LTO builds, PostOrderFunctionAttrsPass can infer that `__cxa_throw` is `nounwind`
Issue
120657
Summary
In LTO builds, PostOrderFunctionAttrsPass can infer that `__cxa_throw` is `nounwind`
Labels
Assignees
Reporter
ilovepi
When trying to enable LTO/FatLTO in the runtimes build, I hit a single test failure in RTSan, ThrowingAnExceptionDiesWhenRealtime(.
After some investigation, I've found that the test, which has a trivial try/catch w/ an explicit `throw` is miscompiled.
Before GlobalOpt the IR has a an invoke to `__cxa_throw` and some code to catch the exception in one of its successors
```llvm
; Function Attrs: cold mustprogress noinline uwtable
define dso_local void @func() #0 personality ptr @__gxx_personality_v0 {
%1 = tail call ptr @__cxa_allocate_exception(i64 8) #6
store ptr getelementptr inbounds nuw inrange(-16, 24) (i8, ptr @_ZTVSt9exception, i64 16), ptr %1, align 8, !tbaa !4478
invoke void @__cxa_throw(ptr nonnull %1, ptr nonnull @_ZTISt9exception, ptr nonnull @_ZNSt9exceptionD1Ev) #7
to label %11 unwind label %2
2: ; preds = %0
%3 = landingpad { ptr, i32 }
catch ptr @_ZTISt9exception
%4 = extractvalue { ptr, i32 } %3, 1
%5 = tail call i32 @llvm.eh.typeid.for.p0(ptr nonnull @_ZTISt9exception) #6
%6 = icmp eq i32 %4, %5
br i1 %6, label %7, label %10
7:; preds = %2
%8 = extractvalue { ptr, i32 } %3, 0
%9 = tail call ptr @__cxa_begin_catch(ptr %8) #6
tail call void @__cxa_end_catch()
ret void
10: ; preds = %2
resume { ptr, i32 } %3
11: ; preds = %0
unreachable
}
After GlobalOpt runs the catch handling is removed:
```llvm
; Function Attrs: cold mustprogress noinline uwtable
define dso_local void @func() local_unnamed_addr #0 personality ptr @__gxx_personality_v0 {
%1 = tail call ptr @__cxa_allocate_exception(i64 8) #4
store ptr getelementptr inbounds nuw inrange(-16, 24) (i8, ptr @_ZTVSt9exception, i64 16), ptr %1, align 8, !tbaa !4478
call void @__cxa_throw(ptr nonnull %1, ptr nonnull @_ZTISt9exception, ptr nonnull @_ZNSt9exceptionD1Ev) #5
unreachable
}
```
This happens because w/in GlobalOpt the analysis checks if the ivoke instruction's callee is marked `nounwind`, and in this case it is. I've run the change of attributes for `__cxa_throw` back to the attribute inference in FunctionAttrs.cpp. Specifically, it seems that the logic in `IstrBreaksNonThrowing` is incomplete, since its determining that `__cxa_throw` is `nounwind`
```llvm
; *** IR Dump After PGOIndirectCallPromotion on [module] ***
; Function Attrs: mustprogress noreturn uwtable
define dso_local void @__cxa_throw(ptr noundef initializes((-120, -80), (-32, -16)) %0, ptr noundef %1, ptr noundef %2) #24 !dbg !51606 {
#dbg_value(ptr %0, !51610, !DIExpression(), !51615)
#dbg_value(ptr %1, !51611, !DIExpression(), !51615)
#dbg_value(ptr %2, !51612, !DIExpression(), !51615)
%4 = tail call ptr @__cxa_get_globals(), !dbg !51616
#dbg_value(ptr %4, !51613, !DIExpression(), !51615)
%5 = getelementptr inbounds nuw i8, ptr %4, i64 8, !dbg !51617
%6 = load i32, ptr %5, align 8, !dbg !51618, !tbaa !51457
%7 = add i32 %6, 1, !dbg !51618
store i32 %7, ptr %5, align 8, !dbg !51618, !tbaa !51457
%8 = tail call ptr @__cxa_init_primary_exception(ptr noundef %0, ptr noundef %1, ptr noundef %2) #59, !dbg !51619
#dbg_value(ptr %8, !51614, !DIExpression(), !51615)
%9 = getelementptr inbounds nuw i8, ptr %8, i64 8, !dbg !51620
store i64 1, ptr %9, align 8, !dbg !51621, !tbaa !51495
%10 = getelementptr inbounds nuw i8, ptr %8, i64 96, !dbg !51622
%11 = tail call i32 @_Unwind_RaiseException(ptr noundef nonnull %10), !dbg !51623
tail call fastcc void @_ZN10__cxxabiv1L12failed_throwEPNS_15__cxa_exceptionE(ptr noundef nonnull %8) #60, !dbg !51624
unreachable, !dbg !51624
}
; *** IR Dump After PostOrderFunctionAttrsPass on (__cxa_throw) ***
; Function Attrs: cold mustprogress noreturn nounwind uwtable
define dso_local void @__cxa_throw(ptr noundef initializes((-120, -80), (-32, -16)) %0, ptr noundef %1, ptr noundef %2) #36 !dbg !8793 {
#dbg_value(ptr %0, !8798, !DIExpression(), !8803)
#dbg_value(ptr %1, !8799, !DIExpression(), !8803)
#dbg_value(ptr %2, !8800, !DIExpression(), !8803)
%4 = tail call ptr @__cxa_get_globals(), !dbg !8804
#dbg_value(ptr %4, !8801, !DIExpression(), !8803)
%5 = getelementptr inbounds nuw i8, ptr %4, i64 8, !dbg !8805
%6 = load i32, ptr %5, align 8, !dbg !8806, !tbaa !8807
%7 = add i32 %6, 1, !dbg !8806
store i32 %7, ptr %5, align 8, !dbg !8806, !tbaa !8807
%8 = tail call ptr @__cxa_init_primary_exception(ptr noundef %0, ptr noundef %1, ptr noundef %2) #60, !dbg !8814
#dbg_value(ptr %8, !8802, !DIExpression(), !8803)
%9 = getelementptr inbounds nuw i8, ptr %8, i64 8, !dbg !8815
store i64 1, ptr %9, align 8, !dbg !8816, !tbaa !8817
[llvm-bugs] [Bug 120676] The memref dialect cannot be converted to the emitc dialect
Issue
120676
Summary
The memref dialect cannot be converted to the emitc dialect
Labels
new issue
Assignees
Reporter
pyl3000
When I use` mlir-opt .\matmul-emitc2.mlir --convert-memref-to-emitc -o matmul-emitc3.mlir` to drop the memref dialect to the emitc dialect with the error:
Input mlir as follow：
```
module {
func.func @main() {
%0 = "emitc.constant"() <{value = 0.00e+00 : f64}> : () -> f64
%1 = "emitc.constant"() <{value = 6.00e+00 : f64}> : () -> f64
%2 = "emitc.constant"() <{value = 5.00e+00 : f64}> : () -> f64
%3 = "emitc.constant"() <{value = 4.00e+00 : f64}> : () -> f64
%4 = "emitc.constant"() <{value = 3.00e+00 : f64}> : () -> f64
%5 = "emitc.constant"() <{value = 2.00e+00 : f64}> : () -> f64
%6 = "emitc.constant"() <{value = 1.00e+00 : f64}> : () -> f64
%alloc = memref.alloc() : memref<2x2xf64>
%alloc_0 = memref.alloc() : memref<2x3xf64>
%7 = "emitc.constant"() <{value = 0 : index}> : () -> !emitc.size_t
%8 = builtin.unrealized_conversion_cast %7 : !emitc.size_t to index
%9 = "emitc.constant"() <{value = 0 : index}> : () -> !emitc.size_t
%10 = builtin.unrealized_conversion_cast %9 : !emitc.size_t to index
memref.store %6, %alloc_0[%8, %10] : memref<2x3xf64>
%11 = "emitc.constant"() <{value = 0 : index}> : () -> !emitc.size_t
%12 = builtin.unrealized_conversion_cast %11 : !emitc.size_t to index
%13 = "emitc.constant"() <{value = 1 : index}> : () -> !emitc.size_t
%14 = builtin.unrealized_conversion_cast %13 : !emitc.size_t to index
memref.store %5, %alloc_0[%12, %14] : memref<2x3xf64>
%15 = "emitc.constant"() <{value = 0 : index}> : () -> !emitc.size_t
%16 = builtin.unrealized_conversion_cast %15 : !emitc.size_t to index
%17 = "emitc.constant"() <{value = 2 : index}> : () -> !emitc.size_t
%18 = builtin.unrealized_conversion_cast %17 : !emitc.size_t to index
memref.store %4, %alloc_0[%16, %18] : memref<2x3xf64>
%19 = "emitc.constant"() <{value = 1 : index}> : () -> !emitc.size_t
%20 = builtin.unrealized_conversion_cast %19 : !emitc.size_t to index
%21 = "emitc.constant"() <{value = 0 : index}> : () -> !emitc.size_t
%22 = builtin.unrealized_conversion_cast %21 : !emitc.size_t to index
memref.store %3, %alloc_0[%20, %22] : memref<2x3xf64>
%23 = "emitc.constant"() <{value = 1 : index}> : () -> !emitc.size_t
%24 = builtin.unrealized_conversion_cast %23 : !emitc.size_t to index
%25 = "emitc.constant"() <{value = 1 : index}> : () -> !emitc.size_t
%26 = builtin.unrealized_conversion_cast %25 : !emitc.size_t to index
memref.store %2, %alloc_0[%24, %26] : memref<2x3xf64>
%27 = "emitc.constant"() <{value = 1 : index}> : () -> !emitc.size_t
%28 = builtin.unrealized_conversion_cast %27 : !emitc.size_t to index
%29 = "emitc.constant"() <{value = 2 : index}> : () -> !emitc.size_t
%30 = builtin.unrealized_conversion_cast %29 : !emitc.size_t to index
memref.store %1, %alloc_0[%28, %30] : memref<2x3xf64>
%31 = "emitc.constant"() <{value = 0 : index}> : () -> !emitc.size_t
%32 = builtin.unrealized_conversion_cast %31 : !emitc.size_t to index
%33 = "emitc.constant"() <{value = 2 : index}> : () -> !emitc.size_t
%34 = builtin.unrealized_conversion_cast %33 : !emitc.size_t to index
%35 = "emitc.constant"() <{value = 1 : index}> : () -> !emitc.size_t
%36 = builtin.unrealized_conversion_cast %35 : !emitc.size_t to index
emitc.for %arg0 = %32 to %34 step %36 {
%37 = "emitc.constant"() <{value = 0 : index}> : () -> !emitc.size_t
%38 = builtin.unrealized_conversion_cast %37 : !emitc.size_t to index
%39 = "emitc.constant"() <{value = 2 : index}> : () -> !emitc.size_t
%40 = builtin.unrealized_conversion_cast %39 : !emitc.size_t to index
%41 = "emitc.constant"() <{value = 1 : index}> : () -> !emitc.size_t
%42 = builtin.unrealized_conversion_cast %41 : !emitc.size_t to index
emitc.for %arg1 = %38 to %40 step %42 {
memref.store %0, %alloc[%arg1, %arg0] : memref<2x2xf64>
%43 = "emitc.constant"() <{value = 0 : index}> : () -> !emitc.size_t
%44 = builtin.unrealized_conversion_cast %43 : !emitc.size_t to index
%45 = "emitc.constant"() <{value = 3 : index}> : () -> !emitc.size_t
%46 = builtin.unrealized_conversion_cast %45 : !emitc.size_t to index
%47 = "emitc.constant"() <{value = 1 : index}> : () -> !emitc.size_t
%48 = builtin.unrealized_conversion_cast %47 : !emitc.size_t to index
emitc.for %arg2 = %44 to %46 step %48 {
%49 = memref.load %alloc_0[%arg0, %arg2] : memref<2x3xf64>
%
[llvm-bugs] [Bug 120631] Codegen Crash: UNREACHABLE executed at llvm/lib/CodeGen/SelectionDAG/InstrEmitter.cpp:1247!
Issue 120631 Summary Codegen Crash: UNREACHABLE executed at llvm/lib/CodeGen/SelectionDAG/InstrEmitter.cpp:1247! Labels new issue Assignees Reporter allight If one attempts to codegen this llvm IR (generated from https://github.com/google/xls/issues/1776 optimized with opt -O3 and then reduced using llvm-reduce) the codegenerator will crash (on x86-64) [sample.reduced.ll](https://github.com/user-attachments/files/18202728/sample.reduced.ll.txt) [sample.ir.opt.ll](https://github.com/user-attachments/files/18202757/sample.ir.opt.ll.txt) ``` % opt /tmp/sample.ir.ll -o /tmp/sample.ir.opt.ll -O3 % llc /tmp/sample.ir.opt.ll -o /tmp/a.out -O3 t802: ch = <> This target-independent node should have been selected! UNREACHABLE executed at third_party/llvm/llvm-project/llvm/lib/CodeGen/SelectionDAG/InstrEmitter.cpp:1247! PLEASE submit a bug report to http://go/llvm-crash-bug and include the crash backtrace. Stack dump: 0. Program arguments: /.../blaze-out/k8-fastbuild/bin/third_party/llvm/llvm-project/llvm/llc /tmp/sample.ir.opt.ll -o /tmp/a.out -O3 1. Running pass 'Function Pass Manager' on module '/tmp/sample.ir.opt.ll'. 2. Running pass 'X86 DAG->DAG Instruction Selection' on function '@sample__main_partition_0' % llc --version LLVM (http://llvm.org/): LLVM version google3-trunk 59890c13343af9e308281b3c76bac425087f4f8a Optimized build with assertions. Default target: x86_64-grtev4-linux-gnu Host CPU: skylake-avx512 Registered Targets: aarch64- AArch64 (little endian) aarch64_32 - AArch64 (little endian ILP32) aarch64_be - AArch64 (big endian) amdgcn - AMD GCN GPUs arm- ARM arm64 - ARM64 (little endian) arm64_32 - ARM64 (little endian ILP32) armeb - ARM (big endian) bpf- BPF (host endian) bpfeb - BPF (big endian) bpfel - BPF (little endian) hexagon- Hexagon lanai - Lanai nvptx - NVIDIA PTX 32-bit nvptx64- NVIDIA PTX 64-bit ppc32 - PowerPC 32 ppc32le- PowerPC 32 LE ppc64 - PowerPC 64 ppc64le- PowerPC 64 LE r600 - AMD GPUs HD2XXX-HD6XXX riscv32- 32-bit RISC-V riscv64- 64-bit RISC-V thumb - Thumb thumbeb- Thumb (big endian) wasm32 - WebAssembly 32-bit wasm64 - WebAssembly 64-bit x86- 32-bit X86: Pentium-Pro and above x86-64 - 64-bit X86: EM64T and AMD64 ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120671] Missed detection of aliasing violaion with tysan
Issue
120671
Summary
Missed detection of aliasing violaion with tysan
Labels
new issue
Assignees
Reporter
thesamesam
This comes from a (invalid) testcase reported at https://gcc.gnu.org/PR118141.
```c
#include
typedef unsigned int v8u32 __attribute__((vector_size(32)));
typedef unsigned short v8b16 __attribute__((vector_size(16)));
// Function to convert 8 fp32 values to 8 bfloat16 values
// We assume that subnormal numbers are not passed. i.e. The CPU is set to do FTZ.
void convert_fp32_to_bfloat16(void* input, unsigned short* output) {
v8u32 input_vec;
for (int i = 0; i < 8; i++) {
input_vec[i] = ((unsigned int*) input)[i];
}
v8u32 shifted_vec = input_vec >> 16;
v8b16 result_vec = __builtin_convertvector(shifted_vec, v8b16);
for (int i = 0; i < 8; i++) {
output[i] = result_vec[i];
}
}
int main() {
float input[8] = {
1.0f, 2.0f, 3.0f, 4.0f,
5.0f, 6.0f, 7.8f, 8.0f
};
unsigned short output[8];
// Convert fp32 to bfloat16
convert_fp32_to_bfloat16(input, output);
// Print output (bfloat16 values as hex)
for (int i = 0; i < 8; i++) {
printf("bfloat16 value %d: 0x%04x\n", i, output[i]);
}
return 0;
}
```
```
$ clang -O3 -march=x86-64-v3 -fsanitize=type
bfloat16 value 0: 0x3f80
bfloat16 value 1: 0x4000
bfloat16 value 2: 0x4040
bfloat16 value 3: 0x4080
bfloat16 value 4: 0x40a0
bfloat16 value 5: 0x40c0
bfloat16 value 6: 0x40f9
bfloat16 value 7: 0x4100
```
godbolt link: https://godbolt.org/z/jd41as4EW
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120668] Semantics of `std::move` and `std::forward` changed in D123345 and now allow invalid code to compile
Issue
120668
Summary
Semantics of `std::move` and `std::forward` changed in D123345 and now allow invalid code to compile
Labels
Assignees
Reporter
graphitemaster
GCC and clang both treat `std::move` and `std::forward` specially in their frontend now as a result of
https://reviews.llvm.org/D123345
and (for GCC) https://gcc.gnu.org/bugzilla/attachment.cgi?id=51732
This change has now enabled `std::move` and `std::forward` to work on incomplete types when they wouldn't usually and allows invalid code to compile on both gcc and clang.
Consider this trivial example
```cpp
template struct pair { T1 first; T2 second; };
template struct array {};
struct incomplete; // incomplete type
struct test {
test(test&& t) : data{std::move(t.data)} {} // This compiles but shouldn't
array> data; // T1 is complete, T2 is incomplete
};
```
If you implement your own `std::move` as can be seen here
```cpp
template
constexpr std::remove_reference_t&& move(T&& t) noexcept {
return static_cast&&>(t);
}
struct test {
test(test&& t) : data{move(t.data)} {}
array> data;
};
```
When compiled this will produce the correct error
```
: In instantiation of 'struct pair':
:14:44: required from here
14 | test(test&& other) : data{move(other.data)} {}
| ^
:3:26: error: 'pair::second' has incomplete type
3 | struct pair { T1 first; T2 second; };
| ^
:12:8: note: forward declaration of 'struct incomplete'
12 | struct incomplete;
|^~
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
