[llvm-bugs] [Bug 115595] Unable to vectorize loop with connectivity table on result index
Issue
115595
Summary
Unable to vectorize loop with connectivity table on result index
Labels
new issue
Assignees
Reporter
bemichel
Hi,
I try to find if there is already an issue on the subject, but I did not find any.
I work on loop like this (https://godbolt.org/z/fchd4e54e), where the final index on the result array `y` is given by the integer table `face_cell` :
```c++
void compute_local_extrema(
const intnface,
const int ncell,
const int*__restrict face_cell,
const double* __restrict x,
double* __restrict y) {
int il, ir;
#pragma clang loop distribute(enable) vectorize(enable) interleave(enable)
for (int iface=0; iface
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115589] LLD linker script link non stantard sections at address 0x0
Issue
115589
Summary
LLD linker script link non stantard sections at address 0x0
Labels
lld
Assignees
Reporter
AntoninRuan
I was trying to link using a custom linker script that contains a non stantards sections for the output. And this sections always ends up at address ``0x0`` no matters where I put it in the script. Linking using gnu ld doesn't have this behavior and gives what seems the logical output for me. I realized I may not need these custom sections but I'm still curious why is it happening and if I'm missing something or if it is a bug
Here's my linking command
```
ld.lld -n -T kernel/arch/x86-64/linker.ld -o sysroot/boot/colibri.kernel--Map build/kernel.map
```
My linker script
```
ENTRY(_start)
SECTIONS
{
. = 2M;
.protected_mode :
{
*(.protected_mode)
}
.text ALIGN(4K) :
{
*(.multiboot)
*(.text)
}
/* Read-only data. */
.rodata ALIGN(4K) :
{
*(.rodata)
}
/* Read-write data (initialized) */
.data ALIGN(4K) :
{
*(.data)
}
/* Read-write data (uninitialized) and stack */
.bss ALIGN(4K) :
{
*(COMMON)
*(.bss)
}
}
```
Here the memory map output of both lld and gnu ld:
[lld.txt](https://github.com/user-attachments/files/17686350/lld.txt)
[gnu_ld.txt](https://github.com/user-attachments/files/17686349/gnu_ld.txt)
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115585] delete[] does not call the destructor correctly
Issue
115585
Summary
delete[] does not call the destructor correctly
Labels
new issue
Assignees
Reporter
tangpanyu
```#include
using namespace std;
class A {
private:
int a;
public:
A(int a): a(a) {
cout << "A::A() at " << this << endl;
}
virtual ~A() { // 声明为虚函数
cout << "A::~A() at " << this << endl;
}
};
class B : public A {
private:
int* b;
public:
B() : A(0) {
b = new int(2);
cout << "B::B() at " << this << endl;
}
~B() {
delete b;
cout << "B::~B() at " << this << endl;
}
};
int main() {
A* b = new B[3];
delete[] b;
return 0;
}
```
output:
```A::A() at 0x558244795eb8
B::B() at 0x558244795eb8
A::A() at 0x558244795ed0
B::B() at 0x558244795ed0
A::A() at 0x558244795ee8
B::B() at 0x558244795ee8
A::~A() at 0x558244795ed8
A::~A() at 0x558244795ec8
A::~A() at 0x558244795eb8
```
delete[] does not call the destructor correctly
clang++ version:
clang version 19.0.0git (https://github.com/llvm/llvm-project.git ce80c80dca45c7b4636a3e143973e2c6cbdb2884)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/llvm/bin
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115584] [lit] Lit's builtin `env` command fails to match environment variables case insensitively on Windows
Issue 115584 Summary [lit] Lit's builtin `env` command fails to match environment variables case insensitively on Windows Labels Assignees Reporter tahonermann LLVM's lit utility includes a builtin implementation of the `env` command in `llvm/utils/lit/lit/TestRunner.py`; see [here](https://github.com/llvm/llvm-project/blob/26a9f3f5906c62cff7f2245b98affa432b504a87/llvm/utils/lit/lit/TestRunner.py#L734-L754) and [here](https://github.com/llvm/llvm-project/blob/26a9f3f5906c62cff7f2245b98affa432b504a87/llvm/utils/lit/lit/TestRunner.py#L300-L323). The builtin implementation does not match the case-insensitive behavior that would be expected on Windows. The issue can be demonstrated by adding the following test to an llvm-project workspace and running it as shown. A couple of notes about the test: 1. The test uses `cmd /c set` as a workaround for https://github.com/llvm/llvm-project/issues/115578. Once that issue is fixed, the `cmd /c set` portion of the command line can be removed and the builtin `env` functionality should suffice. 2. The test is specific to Windows. I tried adding `REQUIRES: system-windows` to it, but that didn't work; the test was still skipped as unsupported for me. I'm guessing there is some relevant `lit.cfg` magic that is necessary to make that work right. More work will be necessary for this test to be checked in as a regression test. 3. If this test does end up getting used as a regression test, `llvm/utils/lit/tests/shtest-env-positive.py` should be updated to validate it in the same manner it does for other tests. 4. Setting an environment variable that is already set changes the case of the variable. This differs from the behavior of the `cmd.exe` `set` command and is related to why the unset case doesn't work. The builtin implementation uses a Python dictionary keyed by the (case-sensitive) variable name. Unsetting by a case-mismatched name fails because the code doesn't attempt to match case; the preset variable therefore remains in the dictionary. ``` > type llvm/utils/lit/tests/Inputs/shtest-env-positive/env-case-insensitive.txt ## Tests env command for preset variables and case sensitive handling. ## Check and make sure preset environment variable were set in lit.cfg. # # RUN: env cmd /c set | FileCheck --check-prefix=CHECK-ENV-PRESET %s # ## Check set of environment variable by lowercase name. # # RUN: env foo=changed cmd /c set | FileCheck --check-prefix=CHECK-ENV-SET-LC %s ## Check unset of environment variable by lowercase name. # # RUN: env -u foo cmd /c set | FileCheck --check-prefix=CHECK-ENV-UNSET-LC %s # CHECK-ENV-PRESET: FOO=1 # CHECK-ENV-PRESET: BAR=2 # CHECK-ENV-SET-LC-NOT: FOO= # CHECK-ENV-SET-LC: foo=changed # CHECK-ENV-SET-LC: BAR=2 # CHECK-ENV-UNSET-LC-NOT: FOO= # CHECK-ENV-UNSET-LC: BAR=2 > python llvm-lit.py -a llvm/utils/lit/tests/Inputs/shtest-env-positive/env-case-insensitive.txt -- Testing: 1 tests, 1 workers -- FAIL: shtest-env :: env-case-insensitive.txt (1 of 1) TEST 'shtest-env :: env-case-insensitive.txt' FAILED Exit Code: 1 ... # RUN: at line 9 env foo=changed cmd /c set | FileCheck --check-prefix=CHECK-ENV-SET-LC C:\Users\thonerma\llvm-project\llvm\utils\lit\tests\Inputs\shtest-env-positive\env-case-insensitive.txt # executed command: env foo=changed cmd /c set # executed command: FileCheck --check-prefix=CHECK-ENV-SET-LC 'C:\Users\thonerma\llvm-project\llvm\utils\lit\tests\Inputs\shtest-env-positive\env-case-insensitive.txt' # .---command stderr # | C:\Users\thonerma\llvm-project\llvm\utils\lit\tests\Inputs\shtest-env-positive\env-case-insensitive.txt:17:25: error: CHECK-ENV-SET-LC-NOT: excluded string found in input # | # CHECK-ENV-SET-LC-NOT: FOO= # | ^ # | :13:1: note: found here # | FOO=1 # | ^~~~ ... # | Input was: # | << ... # |13: FOO=1 # | not:17 !~~~ error: no match expected ... # | >> # `- # error: command failed with exit status: 1 ... Failed Tests (1): shtest-env :: env-case-insensitive.txt ... ``` Emulating case insensitive matching is important for testing some environment variables. For example, MSVC environments have an environment variable named `VCToolsInstallDir` that Clang consults (see `findVCToolChainViaEnvironment()` [here](https://github.com/llvm/llvm-project/blob/26a9f3f5906c62cff7f2245b98affa432b504a87/llvm/lib/WindowsDriver/MSVCPaths.cpp#L512-L519). Lit's testing configuration allows this environment variable to be observed in tests, but for some reason, it spells the variable name as `VCToolsinstallDir` (note the lowercase "i" in "install"); see [here](https://github.com/llvm/llvm-project/blob/26a9f3f5906c62cff7f2245b98affa432b504a87/llvm/utils/lit/lit/TestingConfig.py#L60). When `l
[llvm-bugs] [Bug 115578] [lit] Lit command pipelines are broken when the builtin implementation of `env` is used without a subcommand
Issue 115578 Summary [lit] Lit command pipelines are broken when the builtin implementation of `env` is used without a subcommand Labels new issue Assignees Reporter tahonermann LLVM's `lit` utility includes a builtin implementation of the `env` command in `llvm/utils/lit/lit/TestRunner.py`; see [here](https://github.com/llvm/llvm-project/blob/26a9f3f5906c62cff7f2245b98affa432b504a87/llvm/utils/lit/lit/TestRunner.py#L734-L754). When the `env` command is used without a subcommand argument, the behavior is to print the (possibly augmented) environment to stdout. Lit's builtin implementation does this, but further processing of the command pipeline is then skipped. The existing `llvm/utils/lit/tests/shtest-env-positive.py` test (in conjunction with `llvm/utils/lit/tests/Inputs/shtest-env-positive/env-no-subcommand.txt`) appears to exercise this situation, but the test actually passes spuriously. This can be demonstrated in several ways. First by observing that "executed command" log output is not generated for commands that follow the `env` command in a pipeline, and second by augmenting the test in a way that should cause the test to fail, but doesn't. To demonstrate the issue, here first is an invocation of the `llvm/utils/lit/tests/shtest-env-positive.py` test (on Linux) that shows that "execute command" log output should appear for each command in the pipeline. Note that the command pipeline to run in this case is of the form `env ... python ... | FileCheck ...` and the log output reflects both commands from the pipeline. ``` $ llvm-lit -a llvm/utils/lit/tests/shtest-env-positive.py ... # RUN: at line 3 env -u FILECHECK_OPTS "/usr/bin/python3.9" /iusers/thonerma/llvm-project/llvm/utils/lit/lit.py -j1 --order=lexical -a -v Inputs/shtest-env-positive | FileCheck -match-full-lines /localdisk2/thonerma/build-llvm-project-main-Release-On/utils/lit/tests/shtest-env-positive.py # executed command: env -u FILECHECK_OPTS /usr/bin/python3.9 /iusers/thonerma/llvm-project/llvm/utils/lit/lit.py -j1 --order=lexical -a -v Inputs/shtest-env-positive # executed command: FileCheck -match-full-lines /localdisk2/thonerma/build-llvm-project-main-Release-On/utils/lit/tests/shtest-env-positive.py ... Total Discovered Tests: 1 Passed: 1 (100.00%) ``` The following demonstrates an independent run of the `llvm/utils/lit/tests/Inputs/shtest-env-positive/env-no-subcommand.txt` test. Note that the output does not include "executed command" logs for the `FileCheck` portions of the pipelines in that test. The test exercises five distinct scenarios but I've only included output from the first. Note that the command to run in the pipeline is of the form `env | FileCheck ...`, but the log output only reflects the `env` command from the pipeline; the `FileCheck` command is skipped. ``` $ llvm-lit -a llvm/utils/lit/tests/Inputs/shtest-env-positive/env-no-subcommand.txt ... # RUN: at line 4 env | FileCheck -check-prefix=NO-ARGS /localdisk2/thonerma/llvm-project/llvm/utils/lit/tests/Inputs/shtest-env-positive/env-no-subcommand.txt # executed command: env # .---command stdout ... # `- # RUN: at line 11 ... ``` The following demonstrates that a modification to the test that should cause it to fail does not do so. Apply the following diff (or make similar changes) and observe that the test still passes. ``` $ git diff diff --git a/llvm/utils/lit/tests/Inputs/shtest-env-positive/env-no-subcommand.txt b/llvm/utils/lit/tests/Inputs/shtest-env-positive/env-no-subcommand.txt index 761a8061a0b0..f17eeb01c2c2 100644 --- a/llvm/utils/lit/tests/Inputs/shtest-env-positive/env-no-subcommand.txt +++ b/llvm/utils/lit/tests/Inputs/shtest-env-positive/env-no-subcommand.txt @@ -3,9 +3,9 @@ ## Check default environment. # RUN: env | FileCheck -check-prefix=NO-ARGS %s # -# NO-ARGS: BAR=2 -# NO-ARGS: FOO=1 -# NO-ARGS: QUX=3 +# NO-ARGS: BAR=This can be anything! +# NO-ARGS: FOO=So can this! +# NO-ARGS: QUX=And this! ## Set environment variables. # RUN: env FOO=2 BAR=1 | FileCheck -check-prefix=SET-VAL %s $ llvm-lit llvm/utils/lit/tests/Inputs/shtest-env-positive/env-no-subcommand.txt -- Testing: 1 tests, 1 workers -- PASS: shtest-env :: env-no-subcommand.txt (1 of 1) Testing Time: 0.01s Total Discovered Tests: 1 Passed: 1 (100.00%) ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115575] [VectorCombine] UB triggered after optimization
Issue
115575
Summary
[VectorCombine] UB triggered after optimization
Labels
new issue
Assignees
Reporter
bongjunj
https://github.com/llvm/llvm-project/blob/c93e001ca695e905cb965b36d63f7a348d1dd809/llvm/lib/Transforms/Vectorize/VectorCombine.cpp#L1013-L1031
Alive2 report: https://alive2.llvm.org/ce/z/78CM4x
```llvm
define <2 x i8> @sdiv_constant_op1_not_undef_lane.2(i8 %x) {
#0:
%ins = insertelement <2 x i8> poison, i8 %x, i32 3
%bo = sdiv <2 x i8> %ins, { 5, 2 }
ret <2 x i8> %bo
}
=>
define <2 x i8> @sdiv_constant_op1_not_undef_lane.2(i8 %x) {
#0:
%bo.scalar = sdiv i8 %x, poison
%bo = insertelement <2 x i8> poison, i8 %bo.scalar, i64 3
ret <2 x i8> %bo
}
Transformation doesn't verify!
ERROR: Source is more defined than target
Example:
i8 %x = poison
Source:
<2 x i8> %ins = < poison, poison >
<2 x i8> %bo = < poison, poison >
Target:
i8 %bo.scalar = UB triggered!
define <2 x i64> @urem_constant_op1_not_undef_lane.2(i64 %x) {
#0:
%ins = insertelement <2 x i64> poison, i64 %x, i32 4294967295
%bo = urem <2 x i64> %ins, { 5, 2 }
ret <2 x i64> %bo
}
=>
define <2 x i64> @urem_constant_op1_not_undef_lane.2(i64 %x) {
#0:
%bo.scalar = urem i64 %x, poison
%bo = insertelement <2 x i64> poison, i64 %bo.scalar, i64 4294967295
ret <2 x i64> %bo
}
Transformation doesn't verify!
ERROR: Source is more defined than target
Example:
i64 %x = poison
Source:
<2 x i64> %ins = < poison, poison >
<2 x i64> %bo = < poison, poison >
Target:
i64 %bo.scalar = UB triggered!
Summary:
0 correct transformations
2 incorrect transformations
0 failed-to-prove transformations
0 Alive2 errors
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115574] [InstSimplify] wrong folding of pointer comparison `select (icmp eq ptr ...)`
Issue
115574
Summary
[InstSimplify] wrong folding of pointer comparison `select (icmp eq ptr ...)`
Labels
new issue
Assignees
Reporter
bongjunj
Alive2 report: https://alive2.llvm.org/ce/z/aux2zY
```llvm
define ptr @smin_test8.2(ptr %a, ptr %b, ptr %c) {
#0:
%cmp1 = icmp eq ptr %a, %b
%umin1 = select i1 %cmp1, ptr %a, ptr %b
%cmp2 = icmp slt ptr %b, %c
%umin2 = select i1 %cmp2, ptr %b, ptr %c
%cmp3 = icmp ult ptr %umin2, %a
%umin3 = select i1 %cmp3, ptr %umin2, ptr %a
%cmp4 = icmp slt ptr %c, %umin3
%res = select i1 %cmp4, ptr %umin1, ptr %umin3
ret ptr %res
}
=>
define ptr @smin_test8.2(ptr %a, ptr %b, ptr %c) {
#0:
%cmp2 = icmp slt ptr %b, %c
%umin2 = select i1 %cmp2, ptr %b, ptr %c
%cmp3 = icmp ult ptr %umin2, %a
%umin3 = select i1 %cmp3, ptr %umin2, ptr %a
%cmp4 = icmp slt ptr %c, %umin3
%res = select i1 %cmp4, ptr %b, ptr %umin3
ret ptr %res
}
Transformation doesn't verify!
ERROR: Value mismatch
Example:
ptr %a = pointer(non-local, block_id=0, offset=1) / Address=#x1
ptr %b = pointer(non-local, block_id=1, offset=0) / Address=#x1
ptr %c = pointer(non-local, block_id=0, offset=-8) / Address=#x8
Source:
i1 %cmp1 = #x1 (1)
ptr %umin1 = pointer(non-local, block_id=0, offset=1) / Address=#x1
i1 %cmp2 = #x0 (0)
ptr %umin2 = pointer(non-local, block_id=0, offset=-8) / Address=#x8
i1 %cmp3 = #x0 (0)
ptr %umin3 = pointer(non-local, block_id=0, offset=1) / Address=#x1
i1 %cmp4 = #x1 (1)
ptr %res = pointer(non-local, block_id=0, offset=1) / Address=#x1
SOURCE MEMORY STATE
===
NON-LOCAL BLOCKS:
Block 0 > size: 0 align: 1 alloc type: 0 alive: false address: 0
Block 1 > size: 1 align: 1 alloc type: 0 alive: true address: 1
Block 2 > size: 1 align: 1 alloc type: 0 alive: true address: 2
Block 3 > size: 3 align: 1 alloc type: 0 alive: true address: 8
Target:
i1 %cmp2 = #x0 (0)
ptr %umin2 = pointer(non-local, block_id=0, offset=-8) / Address=#x8
i1 %cmp3 = #x0 (0)
ptr %umin3 = pointer(non-local, block_id=0, offset=1) / Address=#x1
i1 %cmp4 = #x1 (1)
ptr %res = pointer(non-local, block_id=1, offset=0) / Address=#x1
Source value: pointer(non-local, block_id=0, offset=1) / Address=#x1
Target value: pointer(non-local, block_id=1, offset=0) / Address=#x1
Summary:
0 correct transformations
1 incorrect transformations
0 failed-to-prove transformations
0 Alive2 errors
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115562] [AMDGPU] Compiler crash in `AMDGPUAsmPrinter` with circular function call involvement
Issue
115562
Summary
[AMDGPU] Compiler crash in `AMDGPUAsmPrinter` with circular function call involvement
Labels
backend:AMDGPU
Assignees
shiltian
Reporter
shiltian
```
; RUN: llc -mtriple=amdgcn-amd-amdhsa -mcpu=gfx900 small.ll %s -o -
define amdgpu_kernel void @kernel() {
entry:
call void @callee1()
ret void
}
define void @callee1() #0 {
entry:
call void @callee2()
ret void
}
define void @callee2() #0 {
entry:
call void @callee1()
ret void
}
attributes #0 = { noinline }
```
The crash is because of stack overflow. `evaluateAsRelocatable -> evaluateAsRelocatableImpl -> evaluateAsRelocatableImpl -> evaluateAsRelocatable -> ...`.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115564] Missing extension attributes in tests
Issue 115564 Summary Missing extension attributes in tests Labels mlir Assignees Reporter JonPsson1 As argument extensions are needed for correctness, I have been working on going through the code base for cases where they are missing. In mlir, I have now found a few, that I would need help with. In particular, I don't know where these functions are emitted, or how to add the proper Attributes (CreateRuntimeFunction? /.td file?). These are the tests that fail, with the problematic function printed as well: ``` FAIL: MLIR-Unit :: ExecutionEngine/./MLIRExecutionEngineTests/6/12 (11 of 2540) TEST 'MLIR-Unit :: ExecutionEngine/./MLIRExecutionEngineTests/6/12' FAILED [==] Running 1 test from 1 test suite. [--] Global test environment set-up. [--] 1 test from MLIRExecutionEngine [ RUN ] MLIRExecutionEngine.AddInteger ERROR: Missing extension attribute of returned value from function: // and arg i32 @foo(i32) ``` ``` FAIL: MLIR :: CAPI/execution_engine.c (12 of 2540) TEST 'MLIR :: CAPI/execution_engine.c' FAILED Running test 'testSimpleExecution' ERROR: Missing extension attribute of returned value from function: // and arg range(i32 0, -1) i32 @add(i32) ``` ``` FAIL: MLIR :: mlir-cpu-runner/simple.mlir (13 of 2540) TEST 'MLIR :: mlir-cpu-runner/simple.mlir' FAILED # | ERROR: Missing extension attribute of returned value from function: # | i32 @int32_main() ``` ``` FAIL: MLIR-Unit :: ExecutionEngine/./MLIRExecutionEngineTests/11/12 (15 of 2540) TEST 'MLIR-Unit :: ExecutionEngine/./MLIRExecutionEngineTests/11/12' FAILED ERROR: Missing extension attribute of passed value in call to function: Callee: void @_mlir_ciface_callback(ptr, i32) Caller: void @callback(ptr, ptr, i64, i64, i64, i64, i64, i32) ``` Thanks for any help here. Adding people I find in the logs: @shahidact @dcaballe @banach-space @ienkovich @tblah @paulwalker-arm @brod4910 @CoTinker @Groverkss ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115547] [clang] "Member access into incomplete type" error is issued by clang but not gcc/MSVC
Issue
115547
Summary
[clang] "Member access into incomplete type" error is issued by clang but not gcc/MSVC
Labels
clang
Assignees
Reporter
aelovikov-intel
I don't know if clang or gcc/MSVC is correct here, so submitting the issue against the compiler that rejects the code. Godbolt link: https://godbolt.org/z/cMbo3drWa.
Same copy-pasted here:
```
#include
template
struct key_tag {};
template
struct property_base : key_tag {
constexpr auto get_property_impl(key_tag) {
return *static_cast(this);
}
};
template
struct properties : property_tys... {
properties(property_tys... props) : property_tys(props)... {}
using property_tys::get_property_impl...;
template
using prop_t = decltype(std::declval().get_property_impl(key_tag{}));
template
static constexpr auto get_property()
-> std::enable_if_t>, prop_t> {
return prop_t{};
}
template
constexpr auto get_property(int = 0 /* Only needed for MSVC, gcc/clang are fine witout this */)
-> std::enable_if_t>, prop_t> {
return get_property_impl(key_tag{});
}
};
struct foo : property_base {};
struct bar : property_base { int x; };
int main() {
properties pl{foo{}, bar{}};
}
```
clang's error:
```
:19:55: error: member access into incomplete type 'properties'
19 | using prop_t = decltype(std::declval().get_property_impl(key_tag{}));
| ^
:18:5: note: in instantiation of template type alias 'prop_t' requested here
18 | template
| ^
:37:16: note: in instantiation of template class 'properties' requested here
37 | properties pl{foo{}, bar{}};
|^
:13:8: note: definition of 'properties' is not complete until the closing '}'
13 | struct properties : property_tys... {
|^
1 error generated.
Compiler returned: 1
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115540] [clang-tidy] `bugprone-throw-keyword-missing` false negatives from `hasAncestor` skipping too much
Issue
115540
Summary
[clang-tidy] `bugprone-throw-keyword-missing` false negatives from `hasAncestor` skipping too much
Labels
clang-tidy,
false-negative
Assignees
Reporter
5chmidti
The matcher is using `hasAncestor` and could be skipping many different issues, simply because they have an ancestor node (e.g., `VarDecl`) but that node is not closely related to the construct _expression_ itself.
```c++
struct RegularException {
RegularException(int);
};
void foo() {
const auto var = []() {
RegularException{0}; // FN, ignored because of `hasAncestor(varDecl())`
return 0;
};
}
struct Bar {
Bar() : v{0} {
RegularException{0}; // FN, ignored because of `hasAncestor(cxxConstructorDecl())`
}
int v;
};
```
https://godbolt.org/z/6br6f91vc
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115529] [libc] __STDC_NO_THREADS__ is no longer necessary for VS 2022 17.8
Issue 115529 Summary [libc] __STDC_NO_THREADS__ is no longer necessary for VS 2022 17.8 Labels libc Assignees Reporter latal-1 Starting with [VS 2022 17.8](https://learn.microsoft.com/en-us/visualstudio/releases/2022/release-notes-v17.8), the `__STDC_NO_THREADS__` is no longer relevant due to the addition of thread library Сommit with the addition of a macro https://github.com/llvm/llvm-project/commit/bbc690c57213054907284d8964dc0487d38fc57a ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115521] Incorrect mangling of __bf16 in template parameter with nested namespaces.
Issue
115521
Summary
Incorrect mangling of __bf16 in template parameter with nested namespaces.
Labels
new issue
Assignees
Reporter
SagarMaheshwari99
```
namespace NS1 {
namespace NS2 {
struct NS2_struct1 {};
}
template
class Class1 {};
template
using Name1 = Class1;
}
template
void MyFunc(NS1::Name1& input) {}
typedef __bf16 bfloat16;
struct bf16_struct {
short a;
};
int main() {
NS1::Class1 input;
MyFunc(input);
NS1::Class1 input1;
MyFunc(input1);
return 0;
}
```
For __bf16 case the mangling comes out to be -
`_Z6MyFuncIu6__bf16EvRN3NS16Class1IT_NS0_3NS211NS2_struct1EEE`
which demangled comes out to be -
`void MyFunc<__bf16>(NS1::Class1<__bf16, __bf16::NS2::NS2_struct1>&)`
which is incorrect, as __bf16 is treated as a namespace here.
For bf16_struct, right mangling is produced -
`_Z6MyFuncI11bf16_structEvRN3NS16Class1IT_NS1_3NS211NS2_struct1EEE`
and the demangling comes out to be -
`void MyFunc(NS1::Class1&)`
https://godbolt.org/z/dTWxYbqhM
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115520] compile time regression introduced by Sema checking for __builtin_counted_by_ref
Issue 115520 Summary compile time regression introduced by Sema checking for __builtin_counted_by_ref Labels clang:bounds-safety Assignees rapidsna Reporter rapidsna As reported by @nikic https://github.com/llvm/llvm-project/pull/114495#issuecomment-2464318302 This is likely because the checks are currently implemented to walk through the whole child nodes for every single assignments. We may be able to remove the overhead by rolling up the information about usage of `counted_by` or `__builtin_counted_by_ref` to the assignment, instead of re-visiting child nodes. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115515] llvm-gsymutil: Symbol lost after DWARF -> GSYM conversion
Issue 115515 Summary llvm-gsymutil: Symbol lost after DWARF -> GSYM conversion Labels new issue Assignees Reporter javierhonduco ## The issue An address that symbolizes without issues on DWARF with GNU's `addr2line` does not yield any result on the converted GSYM file. Happy to help with anything, let me know! ## Repro Fetch the DWARF debug info Which belongs to a Fedora kernel ``` $ wget https://debuginfod.fedoraproject.org/buildid/b8d70cf519fac5a5cccdda1a61c38995bd9b3059/debuginfo ``` `addr2line` on the DWARF file works without issues ``` $ addr2line -fe debuginfo 0x8220012f entry_SYSCALL_64_after_hwframe /usr/src/debug/kernel-6.9.11/linux-6.9.11-200.fc40.x86_64/arch/x86/entry/entry_64.S:130 ``` After converting it ``` $ llvm-gsymutil --convert=debuginfo --out-file=debuginfo.gsym ``` `llvm-gsymutil` fails to find the symbol for that same address ``` $ llvm-gsymutil --address=0x8220012f debuginfo.gsym Looking up addresses in "/tmp/nix-shell.K7SvqT/.tmpcNXLtG": 0x8220012f: error: address 0x8220012f is not in GSYM ``` ### Environmental information ``` $ llvm-gsymutil --version llvm-gsymutil LLVM (http://llvm.org/): LLVM version 18.1.6 Optimized build. ``` But this also fails on a recent commit: ``` $ git show commit 9f8c3d3796ebf7ddd4a85134ff109cf03a0b9b5e (grafted, HEAD -> main, origin/main, origin/HEAD) Author: David Spickett Date: Wed Nov 6 10:42:11 2024 + [lldb][test] Correct typo in breakpoint test file name Added by https://github.com/llvm/llvm-project/pull/114896. ``` ``` /home/javierhonduco/src/llvm-project/build/bin/llvm-gsymutil LLVM (http://llvm.org/): LLVM version 20.0.0git Optimized build. ``` The conversion output: https://gist.github.com/javierhonduco/7d32feaff1b0d04365c6deb1c3a53b8c Thanks! ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115514] [clang] Instruction referencing instruction not embedded in a basic block!
Issue
115514
Summary
[clang] Instruction referencing instruction not embedded in a basic block!
Labels
clang:codegen,
crash-on-valid,
clang:frontend:fuzzer
Assignees
Reporter
yijan4845
**This testcase is generated by a fuzzer.**
Compiler Explorer: [https://godbolt.org/z/8ob4qjW47](https://godbolt.org/z/8ob4qjW47)
This valid code will crash on clang assertion trunk:
```cpp
class S{
public:
~S() __attribute__((noreturn));
void f();
};
extern bool check(const S&);
int test(bool value) {
if (check(S()); check(S())) {
return 1;
}
return 0;
}
```
It seems that this goes back to clang-3.8.
Stack dump:
```
Instruction referencing instruction not embedded in a basic block!
%ref.tmp1 = alloca %class.S, align 1
%call = invoke noundef zeroext addrspace(0) i1 @_Z5checkRK1S(ptr noundef nonnull align 1 dereferenceable(1) %ref.tmp1)
to label %invoke.cont3 unwind label %lpad2, !dbg !22
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-assertions-trunk/bin/clang++ -gdwarf-4 -g -o /app/output.s -mllvm --x86-asm-syntax=intel -fno-verbose-asm -S --gcc-toolchain=/opt/compiler-explorer/gcc-snapshot -fcolor-diagnostics -fno-crash-diagnostics
1. parser at end of file
2. Optimizer
3. Running pass "verify" on module ""
#0 0x03bf66c8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x3bf66c8)
#1 0x03bf43cc llvm::sys::CleanupOnSignal(unsigned long) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x3bf43cc)
#2 0x03b419c8 CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0
#3 0x7cb33e842520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#4 0x035d9a21 (anonymous namespace)::Verifier::visitEHPadPredecessors(llvm::Instruction&) Verifier.cpp:0:0
#5 0x035f48ab (anonymous namespace)::Verifier::visitLandingPadInst(llvm::LandingPadInst&) Verifier.cpp:0:0
#6 0x035fcdcd llvm::InstVisitor<(anonymous namespace)::Verifier, void>::visit(llvm::Instruction&) Verifier.cpp:0:0
#7 0x03600d1d void llvm::InstVisitor<(anonymous namespace)::Verifier, void>::visit, false, false>>(llvm::ilist_iterator, false, false>, llvm::ilist_iterator, false, false>) Verifier.cpp:0:0
#8 0x03602797 (anonymous namespace)::Verifier::verify(llvm::Function const&) Verifier.cpp:0:0
#9 0x03604181 llvm::verifyModule(llvm::Module const&, llvm::raw_ostream*, bool*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x3604181)
#10 0x0360420d llvm::VerifierAnalysis::run(llvm::Module&, llvm::AnalysisManager&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x360420d)
#11 0x0524753c llvm::detail::AnalysisPassModel::Invalidator>::run(llvm::Module&, llvm::AnalysisManager&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x524753c)
#12 0x035a7471 llvm::AnalysisManager::getResultImpl(llvm::AnalysisKey*, llvm::Module&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x35a7471)
#13 0x035d9134 llvm::VerifierPass::run(llvm::Module&, llvm::AnalysisManager&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x35d9134)
#14 0x03e927ee llvm::detail::PassModel>::run(llvm::Module&, llvm::AnalysisManager&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x3e927ee)
#15 0x035a7e70 llvm::PassManager>::run(llvm::Module&, llvm::AnalysisManager&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x35a7e70)
#16 0x03ea38eb (anonymous namespace)::EmitAssemblyHelper::RunOptimizationPipeline(clang::BackendAction, std::unique_ptr>&, std::unique_ptr>&, clang::BackendConsumer*) BackendUtil.cpp:0:0
#17 0x03ea7115 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-assertions-trunk/bin/clang+++0x3ea7115)
#18 0x045721de clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x45721de)
#19 0x06718dac clang::ParseAST(clang::Sema&, bool, bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6718dac)
#20 0x045725c8 clang::CodeGenAction::ExecuteAction() (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x45725c8)
#21 0x0482d559 clang::FrontendAction::Execute() (/opt/compiler-explorer/clang-assertions-trunk
[llvm-bugs] [Bug 115513] [clang] Assertion `!isExprSubstitutionFailure() && "ExprRequirement has no expression because there has been a " "substitution failure."' failed.
Issue
115513
Summary
[clang] Assertion `!isExprSubstitutionFailure() && "ExprRequirement has no _expression_ because there has been a " "substitution failure."' failed.
Labels
c++20,
clang:frontend,
crash-on-invalid,
clang:frontend:fuzzer
Assignees
Reporter
yijan4845
**This testcase is generated by a fuzzer.**
Compiler Explorer: [https://godbolt.org/z/rKPxYf1MW](https://godbolt.org/z/rKPxYf1MW)
This invalid code will crash on clang assertion trunk with `-std=c++20`:
```cpp
template
constexpr bool is_same_v = false;
template
constexpr bool is_same_v = true;
template
concept Same = is_same_v;
int foo1() {
error;error;error;error;error;error;
error;error;error;error;error;error;
error;error;error;error;error;error;
error;error;error;error;error;error;
}
template
requires requires (int b) {
{ a } -> Same;
{ b } -> Same;
} void f1() {}
```
It seems that this goes back to clang-10.
Stack dump:
```
clang++: /root/llvm-project/clang/include/clang/AST/ExprConcepts.h:416: clang::Expr* clang::concepts::ExprRequirement::getExpr() const: Assertion `!isExprSubstitutionFailure() && "ExprRequirement has no _expression_ because there has been a " "substitution failure."' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments: /opt/compiler-explorer/clang-assertions-trunk/bin/clang++ -gdwarf-4 -g -o /app/output.s -mllvm --x86-asm-syntax=intel -fno-verbose-asm -S --gcc-toolchain=/opt/compiler-explorer/gcc-snapshot -fcolor-diagnostics -fno-crash-diagnostics -std=c++20
1. :21:3: current parser token 'void'
#0 0x03bf66c8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x3bf66c8)
#1 0x03bf43cc llvm::sys::CleanupOnSignal(unsigned long) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x3bf43cc)
#2 0x03b419c8 CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0
#3 0x7e2f27042520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#4 0x7e2f270969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
#5 0x7e2f27042476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
#6 0x7e2f270287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
#7 0x7e2f2702871b (/lib/x86_64-linux-gnu/libc.so.6+0x2871b)
#8 0x7e2f27039e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96)
#9 0x07bb76ad clang::RequiresExpr::RequiresExpr(clang::ASTContext&, clang::SourceLocation, clang::RequiresExprBodyDecl*, clang::SourceLocation, llvm::ArrayRef, clang::SourceLocation, llvm::ArrayRef, clang::SourceLocation) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x7bb76ad)
#10 0x07bb77c0 clang::RequiresExpr::Create(clang::ASTContext&, clang::SourceLocation, clang::RequiresExprBodyDecl*, clang::SourceLocation, llvm::ArrayRef, clang::SourceLocation, llvm::ArrayRef, clang::SourceLocation) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x7bb77c0)
#11 0x06df9657 clang::Sema::ActOnRequiresExpr(clang::SourceLocation, clang::RequiresExprBodyDecl*, clang::SourceLocation, llvm::ArrayRef, clang::SourceLocation, llvm::ArrayRef, clang::SourceLocation) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6df9657)
#12 0x067a55cd clang::Parser::ParseRequiresExpression() (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x67a55cd)
#13 0x06793811 clang::Parser::ParseCastExpression(clang::Parser::CastParseKind, bool, bool&, clang::Parser::TypeCastState, bool, bool*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6793811)
#14 0x06794df7 clang::Parser::ParseCastExpression(clang::Parser::CastParseKind, bool, clang::Parser::TypeCastState, bool, bool*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6794df7)
#15 0x067a000a clang::Parser::ParseConstraintLogicalAndExpression(bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x67a000a)
#16 0x067a047d clang::Parser::ParseConstraintLogicalOrExpression(bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x67a047d)
#17 0x06834fde clang::Parser::ParseTemplateDeclarationOrSpecialization(clang::DeclaratorContext, clang::SourceLocation&, clang::ParsedAttributes&, clang::AccessSpecifier) (.part.0) ParseTemplate.cpp:0:0
#18 0x0683517a clang::Parser::ParseDeclarationStartingWithTemplate(clang::DeclaratorContext, clang::SourceLocation&, clang::ParsedAttributes&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x683517a)
#19 0x067667a3 clang::Parser::ParseDeclaration(clang::DeclaratorContext, clang::SourceLocation&, clang::ParsedAttributes&, c
[llvm-bugs] [Bug 115512] [AArch64][GlobalISel] Improve i128 mul generation
Issue 115512 Summary [AArch64][GlobalISel] Improve i128 mul generation Labels backend:AArch64, llvm:globalisel Assignees Reporter davemgreen i128 multiplies under GlobalISel could be producing more madds if it reassociated the add. https://godbolt.org/z/Wr1r5ez1G SDAG ``` umulh x8, x0, x2 maddx8, x0, x3, x8 mul x0, x0, x2 maddx1, x1, x2, x8 ret ``` GISel ``` mul x9, x0, x3 mul x8, x0, x2 umulh x10, x0, x2 maddx9, x1, x2, x9 mov x0, x8 add x1, x9, x10 ret ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115510] LLVM doesn't properly optimize swap of larger structs
Issue
115510
Summary
LLVM doesn't properly optimize swap of larger structs
Labels
llvm:optimizations,
missed-optimization
Assignees
Reporter
philnik777
This code gets properly optimized to load the values into registers and then stores them back. When changing the buffer size to e.g. 16 bytes the data is moved to the stack instead, even though it could be swapped in the same way with XMM registers, which are used anyways.
```c++
struct S {
char buffer[8];
};
auto test(S& lhs, S& rhs) {
S tmp(lhs);
lhs = rhs;
rhs = tmp;
}
```
(https://godbolt.org/z/o5vYY7Ea5)
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115508] [clang] Assertion `Constructor->getInheritedConstructor() && !Constructor->doesThisDeclarationHaveABody() && !Constructor->isDeleted()' failed.
Issue
115508
Summary
[clang] Assertion `Constructor->getInheritedConstructor() && !Constructor->doesThisDeclarationHaveABody() && !Constructor->isDeleted()' failed.
Labels
clang:frontend,
crash-on-invalid,
clang:frontend:fuzzer,
regression:17
Assignees
Reporter
yijan4845
**This testcase is generated by a fuzzer.**
Compiler Explorer: [https://godbolt.org/z/sGb19e95M](https://godbolt.org/z/sGb19e95M)
This invalid code will crash on clang assertion trunk:
```cpp
struct A {
template A(T &&);
};
struct B : A {
using A::A;
B(B &&) = default;
struct X { X(X &&) = delete; } x;
};
B b2 = B {0};
```
It seems that this goes back to clang-17.
Stack dump:
```
clang++: /root/llvm-project/clang/lib/Sema/SemaDeclCXX.cpp:14044: void clang::Sema::DefineInheritingConstructor(clang::SourceLocation, clang::CXXConstructorDecl*): Assertion `Constructor->getInheritedConstructor() && !Constructor->doesThisDeclarationHaveABody() && !Constructor->isDeleted()' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments: /opt/compiler-explorer/clang-assertions-trunk/bin/clang++ -gdwarf-4 -g -o /app/output.s -mllvm --x86-asm-syntax=intel -fno-verbose-asm -S --gcc-toolchain=/opt/compiler-explorer/gcc-snapshot -fcolor-diagnostics -fno-crash-diagnostics
1. :9:13: current parser token ';'
#0 0x03bf66c8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x3bf66c8)
#1 0x03bf43cc llvm::sys::CleanupOnSignal(unsigned long) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x3bf43cc)
#2 0x03b419c8 CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0
#3 0x79bdc4e42520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#4 0x79bdc4e969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
#5 0x79bdc4e42476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
#6 0x79bdc4e287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
#7 0x79bdc4e2871b (/lib/x86_64-linux-gnu/libc.so.6+0x2871b)
#8 0x79bdc4e39e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96)
#9 0x06c0c0d7 clang::Sema::DefineInheritingConstructor(clang::SourceLocation, clang::CXXConstructorDecl*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6c0c0d7)
#10 0x06d12cc3 void llvm::function_ref::callback_fn(long) SemaExpr.cpp:0:0
#11 0x08200551 clang::StackExhaustionHandler::runWithSufficientStackSpace(clang::SourceLocation, llvm::function_ref) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x8200551)
#12 0x06d0763f clang::Sema::MarkFunctionReferenced(clang::SourceLocation, clang::FunctionDecl*, bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6d0763f)
#13 0x06f5ea70 PerformConstructorInitialization(clang::Sema&, clang::InitializedEntity const&, clang::InitializationKind const&, llvm::MutableArrayRef, clang::InitializationSequence::Step const&, bool&, bool, bool, clang::SourceLocation, clang::SourceLocation) SemaInit.cpp:0:0
#14 0x06f6daaa clang::InitializationSequence::Perform(clang::Sema&, clang::InitializedEntity const&, clang::InitializationKind const&, llvm::MutableArrayRef, clang::QualType*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6f6daaa)
#15 0x06e0ba7f clang::Sema::BuildCXXTypeConstructExpr(clang::TypeSourceInfo*, clang::SourceLocation, llvm::MutableArrayRef, clang::SourceLocation, bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6e0ba7f)
#16 0x06eb244d clang::Sema::ActOnCXXTypeConstructExpr(clang::OpaquePtr, clang::SourceLocation, llvm::MutableArrayRef, clang::SourceLocation, bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6eb244d)
#17 0x067b0fb6 clang::Parser::ParseCXXTypeConstructExpression(clang::DeclSpec const&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x67b0fb6)
#18 0x067942ca clang::Parser::ParseCastExpression(clang::Parser::CastParseKind, bool, bool&, clang::Parser::TypeCastState, bool, bool*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x67942ca)
#19 0x06792f0e clang::Parser::ParseCastExpression(clang::Parser::CastParseKind, bool, bool&, clang::Parser::TypeCastState, bool, bool*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6792f0e)
#20 0x06794df7 clang::Parser::ParseCastExpression(clang::Parser::CastParseKind, bool, clang::Parser::TypeCastState, bool, bool*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6794df7)
#21 0x06794e89 clang::Parser::ParseAssignmentExpression(clang::Parser::TypeCastState) (/op
[llvm-bugs] [Bug 115493] [InstCombine] folding add and compare can negatively effect codegen for loops.
Issue 115493 Summary [InstCombine] folding add and compare can negatively effect codegen for loops. Labels new issue Assignees Reporter SpencerAbson The following transform, `icmp sgt/slt (add nsw X, C2), C --> icmp sgt/slt X, (C - C2)` which was introduced in https://github.com/llvm/llvm-project/commit/45b7e69fefae98ad3c747fd090e6aafcf2cba94f, can have a negative effect on codegen where the icmp serves as the exiting condition of a loop. Please see https://godbolt.org/z/9hMWo6b58 For an ARM target, we would expect: ``` .test cmp w2, #1 b.lt .LBB0_2 .LBB0_1: ldrbw8, [x0], #1 subsw2, w2, #1 strbw8, [x1], #1 b.hi .LBB0_1 .LBB0_2: ret ``` But instead, we have: ``` .test cmp w2, #1 b.lt .LBB0_3 add w8, w2, #1 .LBB0_2: ldrbw9, [x0], #1 sub w8, w8, #1 cmp w8, #1 strbw9, [x1], #1 b.hi.LBB0_2 .LBB0_3: ret ``` In this case, two things have poorly effected codegen - The the possibility for a target to combine the add and compare with zero into a single CC-writing operation is sacrificed in favor of removing a use of the add, even if this add has other users. - The post-inc exiting condition is transformed into a pre-inc exiting condition. LSR has the ability to rectify this, but it's use of SCEVExpander can only do so by inserting an add into the pre-header. A similar issue (https://github.com/llvm/llvm-project/issues/54558) was fixed by https://github.com/llvm/llvm-project/commit/5f8c2b884d4288617138114ebd2fdb235452c8ce. I'm considering a few options to fix this, and I'd really appreciate some feedback on what would be preferred. - Implementing a similar restriction as in https://github.com/llvm/llvm-project/commit/5f8c2b884d4288617138114ebd2fdb235452c8ce. - Allowing IndVarSimplify to perform LFTR on loops with a stride of -1, which would convert the terminating condition into an equality and allow LSR to treat this as an `ICmpZero` (see line 3554 of LoopStrengthReduce.cpp). Thanks ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115490] clang-20 crashed with no_caller_saved_registers attribute. Assertion `At && "Received null Attr object!"' failed.
Issue 115490 Summary clang-20 crashed with no_caller_saved_registers attribute. Assertion `At && "Received null Attr object!"' failed. Labels new issue Assignees Reporter iamanonymouscs clang-20 crashed with ```no_caller_saved_registers``` attribute . Compiler explorer: https://godbolt.org/z/bKoP3zT4j ``` $cat mutant.c int a(); int __attribute__((no_caller_saved_registers)) b(); __typeof(b) a; Reduced by Creduce. Also crashed on clang-19. $clang-19 mutant.c PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script. Stack dump: 0. Program arguments: /usr/lib/llvm-19/bin/clang -cc1 -triple x86_64-pc-linux-gnu -emit-obj -dumpdir a- -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name mutant.c -mrelocation-model pic -pic-level 2 -pic-is-pie -mframe-pointer=all -fmath-errno -ffp-contract=on -fno-rounding-math -mconstructor-aliases -funwind-tables=2 -target-cpu x86-64 -tune-cpu generic -debugger-tuning=gdb -fdebug-compilation-dir=/home/code/reduce -fcoverage-compilation-dir=/home/code/reduce -resource-dir /usr/lib/llvm-19/lib/clang/19 -internal-isystem /usr/lib/llvm-19/lib/clang/19/include -internal-isystem /usr/local/include -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/11/../../../../x86_64-linux-gnu/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -ferror-limit 19 -fgnuc-version=4.2.1 -fskip-odr-check-in-gmf -fcolor-diagnostics -faddrsig -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o /tmp/mutant-bb858a.o -x c mutant.c 1. mutant.c:3:14: current parser token ';' #0 0x7fa81efce246 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/usr/lib/llvm-19/bin/../lib/libLLVM.so.19.0+0xea7246) #1 0x7fa81efcbe20 llvm::sys::RunSignalHandlers() (/usr/lib/llvm-19/bin/../lib/libLLVM.so.19.0+0xea4e20) #2 0x7fa81efce90b (/usr/lib/llvm-19/bin/../lib/libLLVM.so.19.0+0xea790b) #3 0x7fa81dc06520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520) #4 0x7fa826b720d1 clang::Attr::getSpelling() const (/usr/lib/llvm-19/bin/../lib/libclang-cpp.so.19.0+0xeb90d1) #5 0x7fa826a299c8 clang::FormatASTNodeDiagnosticArgument(clang::DiagnosticsEngine::ArgumentKind, long, llvm::StringRef, llvm::StringRef, llvm::ArrayRef>, llvm::SmallVectorImpl&, void*, llvm::ArrayRef) (/usr/lib/llvm-19/bin/../lib/libclang-cpp.so.19.0+0xd709c8) #6 0x7fa826766752 clang::Diagnostic::FormatDiagnostic(char const*, char const*, llvm::SmallVectorImpl&) const (/usr/lib/llvm-19/bin/../lib/libclang-cpp.so.19.0+0xaad752) #7 0x7fa8289cf44c clang::TextDiagnosticPrinter::HandleDiagnostic(clang::DiagnosticsEngine::Level, clang::Diagnostic const&) (/usr/lib/llvm-19/bin/../lib/libclang-cpp.so.19.0+0x2d1644c) #8 0x7fa82676c3f4 clang::DiagnosticIDs::ProcessDiag(clang::DiagnosticsEngine&) const (/usr/lib/llvm-19/bin/../lib/libclang-cpp.so.19.0+0xab33f4) #9 0x7fa8267660b2 clang::DiagnosticsEngine::EmitCurrentDiagnostic(bool) (/usr/lib/llvm-19/bin/../lib/libclang-cpp.so.19.0+0xaad0b2) #10 0x7fa82722080e clang::Sema::EmitCurrentDiagnostic(unsigned int) (/usr/lib/llvm-19/bin/../lib/libclang-cpp.so.19.0+0x156780e) #11 0x7fa8272abfb9 clang::SemaBase::ImmediateDiagBuilder::~ImmediateDiagBuilder() (/usr/lib/llvm-19/bin/../lib/libclang-cpp.so.19.0+0x15f2fb9) #12 0x7fa82722133b clang::SemaBase::SemaDiagnosticBuilder::~SemaDiagnosticBuilder() (/usr/lib/llvm-19/bin/../lib/libclang-cpp.so.19.0+0x156833b) #13 0x7fa8273b01c8 clang::Sema::MergeFunctionDecl(clang::FunctionDecl*, clang::NamedDecl*&, clang::Scope*, bool, bool) (/usr/lib/llvm-19/bin/../lib/libclang-cpp.so.19.0+0x16f71c8) #14 0x7fa8273cc8c3 clang::Sema::CheckFunctionDeclaration(clang::Scope*, clang::FunctionDecl*, clang::LookupResult&, bool, bool) (/usr/lib/llvm-19/bin/../lib/libclang-cpp.so.19.0+0x17138c3) #15 0x7fa8273bf8eb clang::Sema::ActOnFunctionDeclarator(clang::Scope*, clang::Declarator&, clang::DeclContext*, clang::TypeSourceInfo*, clang::LookupResult&, llvm::MutableArrayRef, bool&) (/usr/lib/llvm-19/bin/../lib/libclang-cpp.so.19.0+0x17068eb) #16 0x7fa8273bb438 clang::Sema::HandleDeclarator(clang::Scope*, clang::Declarator&, llvm::MutableArrayRef) (/usr/lib/llvm-19/bin/../lib/libclang-cpp.so.19.0+0x1702438) #17 0x7fa8273ba918 clang::Sema::ActOnDeclarator(clang::Scope*, clang::Declarator&) (/usr/lib/llvm-19/bin/../lib/libclang-cpp.so.19.0+0x1701918) #18 0x7fa826901390 clang::Parser::ParseDeclarationAfterDeclaratorAndAttributes(clang::Declarator&, clang::Parser::ParsedTemplateInfo const&, clang::Parser::ForRangeInit*) (/usr/lib/llvm-19/bin/../lib/libclang-cpp.so.19.0+0xc48390) #19 0x7fa8268ff0e6 clang::Parser:
[llvm-bugs] [Bug 115488] [llvm] - Stack dump without symbol names
Issue
115488
Summary
[llvm] - Stack dump without symbol names
Labels
new issue
Assignees
Reporter
eredotpkfr
I have following github action workflow for my rust project, to get coverage of my tests I'm currently using `cargo-llvm-cov` package with rust nightly toolchain.
```yml
jobs:
cargo-llvm-cov:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: dtolnay/rust-toolchain@nightly
- uses: taiki-e/install-action@cargo-llvm-cov
- uses: Swatinem/rust-cache@v2
- name: Generate code coverage
run: |
cargo +nightly llvm-cov \
--all-features \
--workspace \
--doctests \
--lcov \
--output-path lcov.info
- name: Upload coverage to Codecov
uses: codecov/codecov-action@v4
with:
token: ${{ secrets.CODECOV_TOKEN }}
files: lcov.info
fail_ci_if_error: true
```
Couple of my doctests are not compiling as expected and getting following error on my actions
```
error: aborting due to 1 previous error
Couldn't compile the test.
src/utilities/regex.rs - utilities::regex::generate_subdomain_regex (line 9) stdout
error: linking with `cc` failed: exit status: 1
= note: PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it):
0 libLLVM.so.19.1-rust-1.84.0-nightly 0x7f90c7f4f637 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 39
1 libLLVM.so.19.1-rust-1.84.0-nightly 0x7f90c7f4fa4c
2 libc.so.6 0x7f90c3c42520
3 libc.so.6 0x7f90c3da07e5
4 rust-lld0x5647db2c0c08
5 rust-lld0x5647db30e7e3
6 libLLVM.so.19.1-rust-1.84.0-nightly 0x7f90c7f00f02
7 libLLVM.so.19.1-rust-1.84.0-nightly 0x7f90c7f002ba
8 libLLVM.so.19.1-rust-1.84.0-nightly 0x7f90c7e7b900
9 libc.so.6 0x7f90c3c94ac3
10 libc.so.6 0x7f90c3d26850
collect2: fatal error: ld terminated with signal 7 [Bus error], core dumped
compilation terminated.
```
I don't have any idea, just thinking that rust nightly version and llvm tools chains are not compatible. My versions are as following
```shell
$ cargo +nightly --version
cargo 1.84.0-nightly (cf53cc54b 2024-10-18)
$ cargo llvm-cov --version
cargo-llvm-cov 0.6.13
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115486] InstCombineCompares
Issue 115486 Summary InstCombineCompares Labels new issue Assignees Reporter SpencerAbson This has the side-effect of converting a post-inc IV into a pre-inc IV. LSR has the ability to rectify this, but it's use of SCEVExpander can only do so by inserting instructions into the pre-header. A similar issue (https://github.com/llvm/llvm-project/issues/54558) was fixed by https://github.com/llvm/llvm-project/commit/5f8c2b884d4288617138114ebd2fdb235452c8ce - but I'm hesitant to apply a similar fix here unless it is the only option. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115466] [InstCombine] Missed optimization: icmp pred (ext X), (ext_inreg Y) -> icmp pred X, trunc nsw/nuw (ext_inreg Y)
Issue
115466
Summary
[InstCombine] Missed optimization: icmp pred (ext X), (ext_inreg Y) -> icmp pred X, trunc nsw/nuw (ext_inreg Y)
Labels
llvm:instcombine,
missed-optimization
Assignees
dtcxzyw
Reporter
dtcxzyw
Alive2: https://alive2.llvm.org/ce/z/7xRX6r
```
define i1 @src(i16 %v19, i64 %v20) {
entry:
%0 = trunc i64 %v20 to i32
%conv2 = and i32 %0, 65535
%conv3 = zext i16 %v19 to i32
%cmp = icmp ugt i32 %conv2, %conv3
ret i1 %cmp
}
define i1 @tgt(i16 %v19, i64 %v20) {
entry:
%0 = trunc i64 %v20 to i16
%cmp = icmp ugt i16 %0, %v19
ret i1 %cmp
}
```
This pattern exists in qemu/linux/spike/...
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115465] [InstCombine] folded select produces different result on a shuffled vector
Issue
115465
Summary
[InstCombine] folded select produces different result on a shuffled vector
Labels
new issue
Assignees
Reporter
bongjunj
Alive2 report: https://alive2.llvm.org/ce/z/73v-ug
```llvm
define <4 x i8> @sel_shuf_commute3.2(<4 x i8> %x, <4 x i8> %y, i1 %cmp) {
#0:
%blend = shufflevector <4 x i8> { 0, 0, 0, 0 }, <4 x i8> %y, 0, 5, 2, 3
%r = select i1 %cmp, <4 x i8> %y, <4 x i8> %blend
%#1 = select <4 x i1> { 0, 1, 0, 1 }, <4 x i8> { 0, 1, 2, 3 }, <4 x i8> %r
ret <4 x i8> %#1
}
=>
define <4 x i8> @sel_shuf_commute3.2(<4 x i8> %x, <4 x i8> %y, i1 %cmp) {
#0:
%#1 = shufflevector <4 x i8> %y, <4 x i8> { poison, 1, poison, 3 }, 0, 5, 2, 7
%#2 = select i1 %cmp, <4 x i8> %#1, <4 x i8> { 0, 1, 0, 3 }
ret <4 x i8> %#2
}
Transformation doesn't verify!
ERROR: Target is more poisonous than source
Example:
<4 x i8> %x = < poison, poison, poison, poison >
<4 x i8> %y = < poison, poison, poison, poison >
i1 %cmp = poison
Source:
<4 x i8> %blend = < #x00 (0), poison, #x00 (0), #x00 (0) >
<4 x i8> %r = < poison, poison, poison, poison >
<4 x i8> %#1 = < poison, #x01 (1), poison, #x03 (3) >
Target:
<4 x i8> %#1 = < poison, #x01 (1), poison, #x03 (3) >
<4 x i8> %#2 = < poison, poison, poison, poison >
Source value: < poison, #x01 (1), poison, #x03 (3) >
Target value: < poison, poison, poison, poison >
Summary:
0 correct transformations
1 incorrect transformations
0 failed-to-prove transformations
0 Alive2 errors
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115459] [RISC-V] Segment Load-Store Intrinsics Change Values in Non-operational Memory
Issue
115459
Summary
[RISC-V] Segment Load-Store Intrinsics Change Values in Non-operational Memory
Labels
new issue
Assignees
Reporter
Yibo-He
Similar to case [115446](https://github.com/llvm/llvm-project/issues/115446)
In the following code with rvv intrinsics, I load data from a to b, and from a to c.
However, values of vector a are not equal to values in vector c after the for loop.
(data in c is changed by operation of vector b)
```
#include
#define dataLen 20
uint8_t idx[dataLen];
double a[dataLen]; double b[dataLen]; double c[dataLen];
int main(){
for (int i = 0; i < dataLen; ++i) { a[i] = i * 10.0; }
for (int i = 0; i < dataLen; ++i) { b[i] = 0; c[i] = 0;}
int placeholder0 = dataLen;
double* ptr_a = a;
double* ptr_b = b;
double* ptr_c = c;
for (size_t vl; placeholder0 > 0; placeholder0 -= vl * 7){
vl = __riscv_vsetvl_e64m1(placeholder0);
vfloat64m1x7_t va = __riscv_vlseg7e64_v_f64m1x7(ptr_a, vl);
vuint8mf8_t vidx = __riscv_vsll_vx_u8mf8(__riscv_vid_v_u8mf8(vl), 3, vl);
__riscv_vsoxseg7ei8_v_f64m1x7(ptr_b, vidx, va, vl);
__riscv_vsseg7e64_v_f64m1x7(ptr_c, va, vl);
ptr_a += vl * 7;
ptr_b += vl * 7;
ptr_c += vl * 7;
}
for(int i=0; i
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115454] [InstCombine] miscompilation
Issue
115454
Summary
[InstCombine] miscompilation
Labels
new issue
Assignees
Reporter
bongjunj
Alive2 report: https://alive2.llvm.org/ce/z/ym5WV-
```llvm
define i32 @abs_abs_x18.2(i32 %x, i32 %y) {
#0:
%a = sub nsw i32 %x, %y
%b = sub nsw nuw i32 %y, %x
%cmp = icmp sgt i32 %x, 4294967295
%cond = select i1 %cmp, i32 %a, i32 %b
%sub16 = sub nsw i32 0, %cond
ret i32 %sub16
}
=>
define i32 @abs_abs_x18.2(i32 %x, i32 %y) {
#0:
%a = sub nsw i32 %x, %y
%b = sub nsw nuw i32 %y, %x
%cmp1 = icmp slt i32 %x, 0
%#1 = select i1 %cmp1, i32 %a, i32 %b
ret i32 %#1
}
Transformation doesn't verify!
ERROR: Target is more poisonous than source
Example:
i32 %x = #x000d (13)
i32 %y = #x (0)
Source:
i32 %a = #x000d (13)
i32 %b = poison
i1 %cmp = #x1 (1)
i32 %cond = #x000d (13)
i32 %sub16 = #xfff3 (4294967283, -13)
Target:
i32 %a = #x000d (13)
i32 %b = poison
i1 %cmp1 = #x0 (0)
i32 %#1 = poison
Source value: #xfff3 (4294967283, -13)
Target value: poison
Summary:
0 correct transformations
1 incorrect transformations
0 failed-to-prove transformations
0 Alive2 errors
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115458] [InstCombine] miscompilation
Issue
115458
Summary
[InstCombine] miscompilation
Labels
new issue
Assignees
Reporter
bongjunj
Alive2 report: https://alive2.llvm.org/ce/z/GmGpRE
```llvm
define i8 @sext_multi_uses.2(i8 %a, i1 %b, i8 %x) {
#0:
%#1 = sext i1 %b to i8
%#2 = mul nsw i8 %a, %#1
%#3 = select i1 %b, i8 %#2, i8 %a
%#4 = sub i8 %#1, %#3
%f = mul nuw i8 %x, %#1
%r = add i8 %f, %#4
ret i8 %r
}
=>
define i8 @sext_multi_uses.2(i8 %a, i1 %b, i8 %x) {
#0:
%#1 = sub nsw i8 0, %a
%#2 = xor i8 %x, 255
%#3 = add i8 %a, %#2
%r = select i1 %b, i8 %#3, i8 %#1
ret i8 %r
}
Transformation doesn't verify!
ERROR: Target is more poisonous than source
Example:
i8 %a = #x80 (128, -128)
i1 %b = #x0 (0)
i8 %x = #x00 (0)
Source:
i8 %#1 = #x00 (0)
i8 %#2 = #x00 (0)
i8 %#3 = #x80 (128, -128)
i8 %#4 = #x80 (128, -128)
i8 %f = #x00 (0)
i8 %r = #x80 (128, -128)
Target:
i8 %#1 = poison
i8 %#2 = #xff (255, -1)
i8 %#3 = #x7f (127)
i8 %r = poison
Source value: #x80 (128, -128)
Target value: poison
Summary:
0 correct transformations
1 incorrect transformations
0 failed-to-prove transformations
0 Alive2 errors
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115456] [InstCombine] miscompilation
Issue
115456
Summary
[InstCombine] miscompilation
Labels
new issue
Assignees
Reporter
bongjunj
https://github.com/llvm/llvm-project/blob/6de5305b3d7a4a19a29b35d481a8090e2a6d3a7e/llvm/lib/Transforms/InstCombine/InstCombineMulDivRem.cpp#L360-L363
Alive2 report: https://alive2.llvm.org/ce/z/Rq5DNd
```llvm
define i32 @test1.2(i32 %b, i32 %z) {
#0:
%c = sub i32 0, %z
%#1 = sdiv i32 %z, %c
%d = mul nsw i32 %#1, %b
%e = mul i32 %c, %d
ret i32 %e
}
=>
define i32 @test1.2(i32 %b, i32 %z) {
#0:
%#1 = icmp eq i32 %z, 2147483648
%#2 = sub nsw i32 0, %b
%#3 = select i1 %#1, i32 %#2, i32 %b
%.neg = mul i32 %#3, %z
ret i32 %.neg
}
Transformation doesn't verify!
ERROR: Target is more poisonous than source
Example:
i32 %b = #x8000 (2147483648, -2147483648)
i32 %z = #x8000 (2147483648, -2147483648)
Source:
i32 %c = #x8000 (2147483648, -2147483648)
i32 %#1 = #x0001 (1)
i32 %d = #x8000 (2147483648, -2147483648)
i32 %e = #x (0)
Target:
i1 %#1 = #x1 (1)
i32 %#2 = poison
i32 %#3 = poison
i32 %.neg = poison
Source value: #x (0)
Target value: poison
Summary:
0 correct transformations
1 incorrect transformations
0 failed-to-prove transformations
0 Alive2 errors
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115446] [RISC-V] Possible Miscompilation by Indexed Segment Load-Store Intrinsics
Issue
115446
Summary
[RISC-V] Possible Miscompilation by Indexed Segment Load-Store Intrinsics
Labels
Assignees
Reporter
Yibo-He
In the following code with rvv intrinsics, I load data from a to b.
The index of `__riscv_vsoxseg5ei8_v_f64m1x5` is obtained from the result of `__riscv_vid_v_u8mf8`(*=8), and i think the result should be the same with `__riscv_vsseg5e64_v_f64m1x5` (if this is a misunderstanding, please tell me).
However, values of vector a are not equal to values in vector b after the for loop.
```
#include
#define dataLen 20
uint8_t idx[dataLen];
double a[dataLen]; double b[dataLen];
int main(){
for (int i = 0; i < dataLen; ++i) { a[i] = i * 10.0; }
for (int i = 0; i < dataLen; ++i) { b[i] = 0; }
int placeholder0 = dataLen;
double* ptr_a = a;
double* ptr_b = b;
for (size_t vl; placeholder0 > 0; placeholder0 -= vl * 5){
vl = __riscv_vsetvl_e64m1(placeholder0);
vfloat64m1x5_t va = __riscv_vlseg5e64_v_f64m1x5(ptr_a, vl);
vuint8mf8_t vidx = __riscv_vsll_vx_u8mf8(__riscv_vid_v_u8mf8(vl), 3, vl);
__riscv_vsoxseg5ei8_v_f64m1x5(ptr_b, vidx, va, vl);
ptr_a += vl * 5;
ptr_b += vl * 5;
}
for(int i=0; i
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115444] [RISCV] Suboptimal switch code generation
Issue
115444
Summary
[RISCV] Suboptimal switch code generation
Labels
new issue
Assignees
Reporter
WojciechMula
Version `clang version 20.0.0git (https://github.com/llvm/llvm-project.git 5b697ef5dd6b3e29e257e6099014bf8d8e77ac9a)`
Arguments: `-O3`
The following switch is nicely compiled:
```c++
bool one_of(int num) {
switch (num) {
case 0:
case 1:
case 3:
case 4:
case 6:
case 10:
return true;
default:
return false;
}
```
```asm
one_of(int):
sltiu a1, a0, 11
li a2, 1115
srl a0, a2, a0
and a0, a0, a1
ret
```
However, changing the return type from `bool` to `int` changes the generated code dramatically.
```c++
int one_of_int(int num) {
switch (num) {
case 0:
case 1:
case 3:
case 4:
case 6:
case 10:
return 1;
default:
return 0;
}
}
```
```asm
one_of_int(int):
li a1, 10
bltua1, a0, .LBB1_2
sllia0, a0, 2
.Lpcrel_hi0:
auipc a1, %pcrel_hi(.Lswitch.table.one_of_int(int))
addia1, a1, %pcrel_lo(.Lpcrel_hi0)
add a0, a0, a1
lw a0, 0(a0)
ret
.LBB1_2:
li a0, 0
ret
.Lswitch.table.one_of_int(int):
.word 1
.word 1
.word 0
.word 1
.word 1
.word 0
.word 1
.word 0
.word 0
.word 0
.word 1
```
godbolt: https://godbolt.org/z/jqs1zr385
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115437] [mlir][CallGraph] Missed visibility for CallGraphNode to construct AbstractEdge
Issue 115437 Summary [mlir][CallGraph] Missed visibility for CallGraphNode to construct AbstractEdge Labels mlir Assignees Reporter Luhaocong Hi River @River707 @tensorflower-gardener ，In `CallGraph Analysis`, I find a `AbstractEdge` will always be added to target `CallGraphNode` from `externalCallerNode`, no matter the target is a public or private `FunctionOpInterface` (which is subclass of `CallOpInterface`) . https://github.com/llvm/llvm-project/blob/c17a914675f8fcadbf0ef440aae7e0ab6c49ec0c/mlir/lib/Analysis/CallGraph.cpp#L125-L131 Is there any plan to add visibility for `CallOpInterface` to get better analysis result ？Or could you please give me some advice, I can try to fix this problem? ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115422] [libclang] Header files of CXUnsavedFile can not be found while clang_parseTranslationUnit
Issue 115422 Summary [libclang] Header files of CXUnsavedFile can not be found while clang_parseTranslationUnit Labels new issue Assignees Reporter sainimu78 As a contrast, if I save my headers in memory to disk, clang_parseTranslationUnit works fine. This seems an issue of not treating files finding in a common way for the location of both CXUnsavedFile file and the regular disk file. Some details: I try to create a series of STL header, like this `CXUnsavedFile memSrc; memSrc.Filename = "Source/BypassSTL/string" memsrc.Contents = "..." ` and compiler opts pass to clang_parseTranslationUnit contains "-ISource/BypassSTL" ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115418] [clang] [clangd] Missing information about explicit instantiation of function template
Issue
115418
Summary
[clang] [clangd] Missing information about explicit instantiation of function template
Labels
Assignees
Reporter
16bit-ykiko
```cpp
namespace test {
template
void foo() {}
}
struct X {};
template void test::f^oo();
```
Currently, if trigger go-to-definition at the location of `^`, clangd will give no response. And the tokens in the explicit instantiation are
also not highlighted. After some investigation, I found that the underlying cause is that the Clang frontend doesn't store the information about explicit instantiation of function templates.
Dump the AST of above code
```cpp
|-NamespaceDecl 0xd083678 <:1:1, line:4:1> line:1:11 test
| `-FunctionTemplateDecl 0xd0838e8 col:6 foo
| |-TemplateTypeParmDecl 0xd083708 col:20 typename depth 0 index 0 T
| |-FunctionDecl 0xd083838 col:6 foo 'void ()'
| | `-CompoundStmt 0xd0839c8
| `-FunctionDecl 0xd083d18 col:6 foo 'void ()' explicit_instantiation_definition
| |-TemplateArgument type 'X'
| | `-RecordType 0xd083aa0 'X'
| | `-CXXRecord 0xd0839f8 'X'
| `-CompoundStmt 0xd0839c8
`-CXXRecordDecl 0xd0839f8 col:8 referenced struct X definition
```
As you can see, the decl from explicit instantiation is only added to its semantic context but not to its lexical context.
If use a visitor to further explore:
```cpp
bool VisitFunctionTemplateDecl(clang::FunctionTemplateDecl* decl) {
for(auto spec: decl->specializations()) {
spec->getLocation().dump(srcMgr);
spec->getFunctionTypeLoc().getReturnLoc().getLocalSourceRange().dump(srcMgr)
spec->getQualifierLoc().getSourceRange().dump(srcMgr);
auto info = spec->getTemplateSpecializationInfo();
info->PointOfInstantiation.dump(srcMgr);
llvm::outs() << info->TemplateArguments << "\n";
llvm::outs() << info->TemplateArgumentsAsWritten << "\n";
}
return true;
}
```
The output is
```
test.cpp:3:6
<>
test.cpp:8:21
0x564cf04d7560
0x0
```
Only instantiation point is recorded correctly, all other information is from primary template. But for explicit specializations, the information is recorded properly.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115411] clang-20 crashed with optnone attribute at -O1 and above. error in backend: Cannot select: intrinsic %llvm.expect.with.probability.
Issue
115411
Summary
clang-20 crashed with optnone attribute at -O1 and above. error in backend: Cannot select: intrinsic %llvm.expect.with.probability.
Labels
new issue
Assignees
Reporter
iamanonymouscs
clang-20 crashed with ```optnone``` attribute at ```-O1``` and above.
Compiler explorer: https://godbolt.org/z/4dP5xGxnx
```
$cat mutant.c
int a;
void __attribute__((optnone)) b() {
int c = __builtin_expect_with_probability(a, 0, 0.8);
}
Also crashed on clang-19.
$clang-19 -O1 mutant.c
fatal error: error in backend: Cannot select: intrinsic %llvm.expect.with.probability
clang: error: clang frontend command failed with exit code 70 (use -v to see invocation)
Ubuntu clang version 19.0.0 (++20240722031324+65825cd5431c-1~exp1~20240722151445.1819)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/lib/llvm-19/bin
clang: note: diagnostic msg:
PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /tmp/mutant-b18d19.c
clang: note: diagnostic msg: /tmp/mutant-b18d19.sh
clang: note: diagnostic msg:
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115412] [HLSL] Refactor resource buffers AST tests
Issue 115412 Summary [HLSL] Refactor resource buffers AST tests Labels new issue Assignees Reporter hekota See comment in this PR: https://github.com/llvm/llvm-project/pull/113643#discussion_r1833370629_ ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115410] [analyzer] False negative in ArrayBoundV2 and TaintPropagation
Issue
115410
Summary
[analyzer] False negative in ArrayBoundV2 and TaintPropagation
Labels
new issue
Assignees
Reporter
z1nke
Example code: https://godbolt.org/z/xhbsaYex6
```cpp
// clang-19 --analyze -Xanalyzer -analyzer-checker="alpha.security,optin.taint" test.c // clang-19 and above
// clang-18 --analyze -Xanalyzer -analyzer-checker="alpha.security" test.c // clang-18 and below
#include
#include
void foo1() {
char buf[20];
if (fgets(buf, sizeof(buf), stdin) == NULL)
return;
int idx = atoi(buf);
buf[idx] = '\0'; // expect-warning
}
void foo2() {
char buf[20];
fgets(buf, sizeof(buf), stdin);
int idx = atoi(buf);
buf[idx] = '\0'; // expect-warning
}
```
Results:
```
// clang-19 and above
:17:3: warning: Potential out of bound access to 'buf' with tainted index [alpha.security.ArrayBoundV2]
17 | buf[idx] = '\0'; // expect-warning
| ^~~~
1 warning generated.
```
```
// clang-18 and below
:10:3: warning: Potential out of bound access to 'buf' with tainted index [alpha.security.ArrayBoundV2]
10 | buf[idx] = '\0'; // expect-warning
| ^~~~
:17:3: warning: Potential out of bound access to 'buf' with tainted index [alpha.security.ArrayBoundV2]
17 | buf[idx] = '\0'; // expect-warning
| ^~~~
2 warnings generated.
```
I found that clang-19 version had a false negative in the `foo1` test case.
After some debugging, I found there might be problem with the modeling of `fgets` in `StdLibraryFunctionsChecker`.
https://github.com/llvm/llvm-project/blob/ab51eccf88f5321e7c60591c5546b254b6afab99/clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp#L2267-L2280
I am not very familiar with function summary modeling. Should we add the following case for the `fgets` function here?
```cpp
.Case({NotNull(Ret)}, ErrnoMustNotBeChecked, GenericSuccessMsg)
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115409] 'mov , ' produces an error where imm is 0-255 and -march=armv8m.base is used
Issue
115409
Summary
'mov , ' produces an error where imm is 0-255 and -march=armv8m.base is used
Labels
new issue
Assignees
Reporter
jonathonpenix
Assembly such as `mov r0, #0` fails to build with clang but is accepted by GCC under `-march=armv8m.base`. I'm not entirely sure if my understanding is correct, but it seems like this is might be a bug in LLVM.
Small example (https://godbolt.org/z/3Y1jqWjvs):
```
void foo(void) {
// Fails to build with clang, accepted by GCC
__asm__ volatile("\n\
.syntax unified\n\
mov r0, #0");
// Clang and GCC are both happy with this
__asm__ volatile("\n\
.syntax unified\n\
mov r0, #256");
}
```
When building for Arm with `-march=armv8m.base`, Clang errors on the top `__asm__` statement as below (output is abbreviated):
```
:6:1: error: invalid instruction, any one of the following would fix this:
6 | mov r0, #0");
| ^
:3:23: note: instantiated into assembly here
3 | mov r0, #0
|
...
```
Looking at section C2.4.119 in the Armv8-M arch manual, my understanding is that:
- T1 isn't feasible because we 1) aren't in an IT block and 2) used `mov` in the inline asm (rather than `movs`) so we'd look for a flag-preserving variant instead.
- T2 isn't feasible because we're looking at Armv8-M baseline (not mainline).
- T3 should be feasible (and, this is what GCC seems to do, IIUC).
I'm again not entirely sure if I'm misunderstanding something above, but it seems like we should be "selecting" T3 here rather than erroring, similar to GCC.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115403] Clang: __PRETTY_FUNCTION__ does not show enum label
Issue
115403
Summary
Clang: __PRETTY_FUNCTION__ does not show enum label
Labels
clang
Assignees
Reporter
alexolog
Please see the following code:
Code
#include
template struct S1 { enum class E { A }; };
template struct S2 { enum class E { A }; };
using E1 = S1::E;
using E2 = S2::E;
template
constexpr auto f() noexcept {
#ifdef _MSC_VER
return std::string_view{__FUNCSIG__, sizeof(__FUNCSIG__)};
#else
return std::string_view{__PRETTY_FUNCTION__, sizeof(__PRETTY_FUNCTION__)};
#endif
}
int main() {
std::println("Straight: {}", f(0)>());
(void) E2::A; // Now it suddenly works
std::println("Workaround: {}", f(0)>());
}
Results
Clang:
Straight: auto f() [v = (S1::E)0]
Workaround: auto f() [v = S2::E::A]
GCC:
Straight: constexpr auto f() [with auto v = S1::E::A]
Workaround: constexpr auto f() [with auto v = S2::E::A]
MSVC:
Straight: auto __cdecl f::E::A>(void) noexcept
Workaround: auto __cdecl f::E::A>(void) noexcept
The problem manifests with a scoped enum wrapped in a templated struct.
GCC and MSVC do not exhibit the issue.
This issue interferes with the "Magic enums" library
See https://github.com/Neargye/magic_enum/issues/164
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115394] [libc] Clean up unnecessary function pointers in scanf
Issue 115394 Summary [libc] Clean up unnecessary function pointers in scanf Labels good first issue, libc Assignees Reporter michaelrj-google The scanf reader is the abstraction that scanf uses to read from either a file or a string, similar to printf's writer. Unlike printf, however, there are only two variants of scanf: `fscanf` and `sscanf` (just `scanf` is the same as `fscanf(stdin, ...)`). This means that the `stream_getc` and `stream_ungetc` functions don't need to be pointers, they can be declared with `using` statements based on the current platform. Files you'll need to edit: [libc/src/stdio/scanf_core/vfscanf_internal.h](https://github.com/llvm/llvm-project/blob/main/libc/src/stdio/scanf_core/vfscanf_internal.h) [libc/src/stdio/scanf_core/reader.h](https://github.com/llvm/llvm-project/blob/main/libc/src/stdio/scanf_core/reader.h) What to do: Move the definitions of `getc` and `ungetc` in `vfscanf_internal` into `reader.h` (along with the associated `#if defined` logic for each target). Define the `stream_getc` and `stream_ungetc` functions with `using` statements inside of `class Reader` (or do something equivalent). Clean up the relevant code. If you have questions or need help, feel free to comment on this issue or reach out via the LLVM discord. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115393] Missing `LLVM_CallIntrinsicOp` support for `elementtype`
Issue 115393 Summary Missing `LLVM_CallIntrinsicOp` support for `elementtype` Labels mlir:llvm Assignees Reporter bcardosolopes In order to lower ARM64 intrinsics down from ClangIR to LLVM, we found that we cannot lower to LLVM intrinsics that might need a `elementtype`, one example is LLVM intrinsic `aarch64.ldxr`, which requires `elementtype`. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115392] Missing function pointer (e.g. `void (ptr)`) support in `mlir::LLVM::GlobalOp`
Issue
115392
Summary
Missing function pointer (e.g. `void (ptr)`) support in `mlir::LLVM::GlobalOp`
Labels
mlir:llvm
Assignees
Reporter
bcardosolopes
While working on ClangIR to LLVM lowering, we want to generate this kind of LLVM IR code:
```
@_ZN1BD1Ev = dso_local unnamed_addr alias void (ptr), ptr @_ZN1BD2Ev
@_ZN1CD2Ev = dso_local unnamed_addr alias void (ptr), ptr @_ZN1BD2Ev
@_ZN1CD1Ev = dso_local unnamed_addr alias void (ptr), ptr @_ZN1BD2Ev
define dso_local void @_ZN1BD2Ev(ptr noundef nonnull align 8 dereferenceable(9) %this) unnamed_addr #0 {
```
However, one of the issues is that `llvm.mlir.global`s don't seem to accept anything besides `!llvm.ptr` as their types and there are no existing casts to use in its initializers that can allows us to load `llvm.mlir.addressof` as `void (ptr)`. I tried several combinations but didn't get successful, let me know if I'm missing anything. The other reason we can't generate this is the missing `alias`, tracked in https://github.com/llvm/llvm-project/issues/115390
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115390] Missing `alias` support in `mlir::LLVM::GlobalOp`
Issue
115390
Summary
Missing `alias` support in `mlir::LLVM::GlobalOp`
Labels
mlir:llvm
Assignees
Reporter
bcardosolopes
While working on ClangIR to LLVM lowering, we want to generate this kind of LLVM IR code:
```
@_ZN1BD1Ev = dso_local unnamed_addr alias void (ptr), ptr @_ZN1BD2Ev
@_ZN1CD2Ev = dso_local unnamed_addr alias void (ptr), ptr @_ZN1BD2Ev
@_ZN1CD1Ev = dso_local unnamed_addr alias void (ptr), ptr @_ZN1BD2Ev
define dso_local void @_ZN1BD2Ev(ptr noundef nonnull align 8 dereferenceable(9) %this) unnamed_addr #0 {
```
One of the reasons it's not possible it's because there's no support for `alias` (the other one will be filed in another issue)
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115389] libcxx: stderr/stdout/stdin not exported from std.compat
Issue
115389
Summary
libcxx: stderr/stdout/stdin not exported from std.compat
Labels
libc++
Assignees
Reporter
tomboehmer
stderr/stdout/stdin are not exported as part of the std.compat module. But I very much expected the below code to compile without issue.
```c++
//#include // Do I really need to include this just to get at `stderr`?
import std.compat;
auto main() -> int {
std::println(stderr, "I expected this to work.");
return 0;
}
```
I believe this is because they are technically defined to be macros. But in both glibc and musl they are actually `extern FILE*`. So maybe there is a way to provide them on a best-effort basis?
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115378] [libc] unused function `clear_x87_exceptions`
Issue
115378
Summary
[libc] unused function `clear_x87_exceptions`
Labels
libc
Assignees
Reporter
nickdesaulniers
While working on the i386 port and debugging an issue with my fenv_t support, I noticed that we're never issuing a `fnclex` instruction.
It looks like 9474ddc3ac8637596f87dd796864353317622672 removed the only call to `clearX87Exceptions`, which was later renamed to `clear_x87_exceptions` in 1c92911e9e1d503c0dfc4367da7f15d0dff50587.
I don't strictly know if `fnclex` is necessary.
Bionic's i386 impl is based on freebsd seems to do so in `fesetexceptflag`, `feholdexcept`, and `feclearexcept` before each `fldenv`.
Bionic's x86_64 impl is based on netbsd and seems to only do so in `feholdexcept`.
musl's i386 and x86_64 impls seems to only do so for `feclearexcept`.
It's not clear to me that it is even necessary? Perhaps the unused function should simply be deleted? Otherwise:
```diff
diff --git a/libc/src/__support/FPUtil/x86_64/FEnvImpl.h b/libc/src/__support/FPUtil/x86_64/FEnvImpl.h
index b77178ea69ea..3f227ef75459 100644
--- a/libc/src/__support/FPUtil/x86_64/FEnvImpl.h
+++ b/libc/src/__support/FPUtil/x86_64/FEnvImpl.h
@@ -122,7 +122,7 @@ LIBC_INLINE uint16_t get_x87_status_word() {
}
LIBC_INLINE void clear_x87_exceptions() {
- __asm__ __volatile__("fnclex" : : :);
+ asm("fnclex");
}
LIBC_INLINE uint32_t get_mxcsr() {
@@ -207,6 +207,7 @@ LIBC_INLINE int clear_except(int excepts) {
internal::get_x87_state_descriptor(state);
state.status_word &=
static_cast(~internal::get_status_value_for_except(excepts));
+ internal::clear_x87_exceptions();
internal::write_x87_state_descriptor(state);
uint32_t mxcsr = internal::get_mxcsr();
@@ -230,6 +231,7 @@ LIBC_INLINE int set_except(int excepts) {
internal::X87StateDescriptor state;
internal::get_x87_state_descriptor(state);
state.status_word |= status_value;
+ internal::clear_x87_exceptions();
internal::write_x87_state_descriptor(state);
uint32_t mxcsr = internal::get_mxcsr();
```
would do what freebsd does.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115366] [libc] Fix or delete automemcpy
Issue 115366 Summary [libc] Fix or delete automemcpy Labels libc Assignees gchatelet Reporter vonosmas The auto-generated code includes headers ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115352] clang-format: Generalize BAS_AlwaysBreak to all delimiter types
Issue
115352
Summary
clang-format: Generalize BAS_AlwaysBreak to all delimiter types
Labels
clang-format
Assignees
Reporter
dabrahams
The setting `AlignAfterOpenBracket: AlwaysBreak` eliminates most cases of [endline layout (vertically coupled alignment)](https://softwareengineering.stackexchange.com/a/453510/457643), but unfortunately not all. For example, when it's set, with a 50-column limit, I get the following:
```c++
template <
class SomethingLong, class SomethingElse>
void a_long_function_name(
int x, int y, std::string z,
std::vector q) {
int a[] = {1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1};
int b = a_very_long_name
[some + very + very + long + _expression_ +
that + causes + wrapping];
}
```
Notice that it isn't applied to initializer lists or subscript expressions. There should be a way to apply it to everything, to help avoid the problems of needlessly large diffs (and thus merge conflicts) that tend to result.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115311] [clang] Assertion `ArgIdx < Args.size() && "no argument for this arg conversion"' failed.
Issue
115311
Summary
[clang] Assertion `ArgIdx < Args.size() && "no argument for this arg conversion"' failed.
Labels
clang:frontend,
crash-on-invalid,
clang:frontend:fuzzer,
regression:18
Assignees
Reporter
yijan4845
**This testcase is generated by a fuzzer.**
Compiler Explorer: [https://godbolt.org/z/T4W7jxvMT](https://godbolt.org/z/T4W7jxvMT)
This invalid code will crash on Clang Assertion Trunk.
```cpp
struct B {};
float &operator++(B);
class b {
void operator++() = delete;
};
void foo() {
b bb; ++ bb;
}
```
It seems that this goes back to clang-18. Maybe related: [88532](https://github.com/llvm/llvm-project/issues/88532)
Stack dump:
```
clang++: /root/llvm-project/clang/lib/Sema/SemaOverload.cpp:12547: void CompleteNonViableCandidate(clang::Sema&, clang::OverloadCandidate*, llvm::ArrayRef, clang::OverloadCandidateSet::CandidateSetKind): Assertion `ArgIdx < Args.size() && "no argument for this arg conversion"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments: /opt/compiler-explorer/clang-assertions-trunk/bin/clang++ -gdwarf-4 -g -o /app/output.s -mllvm --x86-asm-syntax=intel -fno-verbose-asm -S --gcc-toolchain=/opt/compiler-explorer/gcc-snapshot -fcolor-diagnostics -fno-crash-diagnostics
1. :8:14: current parser token ';'
2. :7:12: parsing function body 'foo'
3. :7:12: in compound statement ('{}')
#0 0x03bf66c8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x3bf66c8)
#1 0x03bf43cc llvm::sys::CleanupOnSignal(unsigned long) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x3bf43cc)
#2 0x03b419c8 CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0
#3 0x766161042520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#4 0x7661610969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
#5 0x766161042476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
#6 0x7661610287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
#7 0x76616102871b (/lib/x86_64-linux-gnu/libc.so.6+0x2871b)
#8 0x766161039e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96)
#9 0x071c12d4 clang::OverloadCandidateSet::CompleteCandidates(clang::Sema&, clang::OverloadCandidateDisplayKind, llvm::ArrayRef, clang::SourceLocation, llvm::function_ref) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x71c12d4)
#10 0x071c390e clang::OverloadCandidateSet::NoteCandidates(std::pair, clang::Sema&, clang::OverloadCandidateDisplayKind, llvm::ArrayRef, llvm::StringRef, clang::SourceLocation, llvm::function_ref) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x71c390e)
#11 0x071c79a2 clang::Sema::CreateOverloadedUnaryOp(clang::SourceLocation, clang::UnaryOperatorKind, clang::UnresolvedSetImpl const&, clang::Expr*, bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x71c79a2)
#12 0x06d21d6d clang::Sema::BuildUnaryOp(clang::Scope*, clang::SourceLocation, clang::UnaryOperatorKind, clang::Expr*, bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6d21d6d)
#13 0x0679421b clang::Parser::ParseCastExpression(clang::Parser::CastParseKind, bool, bool&, clang::Parser::TypeCastState, bool, bool*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x679421b)
#14 0x06794df7 clang::Parser::ParseCastExpression(clang::Parser::CastParseKind, bool, clang::Parser::TypeCastState, bool, bool*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6794df7)
#15 0x06794e89 clang::Parser::ParseAssignmentExpression(clang::Parser::TypeCastState) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6794e89)
#16 0x067998a9 clang::Parser::ParseExpression(clang::Parser::TypeCastState) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x67998a9)
#17 0x0681c2e9 clang::Parser::ParseExprStatement(clang::Parser::ParsedStmtContext) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x681c2e9)
#18 0x068125ce clang::Parser::ParseStatementOrDeclarationAfterAttributes(llvm::SmallVector&, clang::Parser::ParsedStmtContext, clang::SourceLocation*, clang::ParsedAttributes&, clang::ParsedAttributes&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x68125ce)
#19 0x06813520 clang::Parser::ParseStatementOrDeclaration(llvm::SmallVector&, clang::Parser::ParsedStmtContext, clang::SourceLocation*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6813520)
#20 0x068143e4 clang::Parser::ParseCompoundStatementBody(bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/cla
[llvm-bugs] [Bug 115308] [clang] Assertion `DD && "queried property of class with no definition"' failed. Crash at HasAccess(clang::Sema&, (anonymous namespace)::EffectiveContext const&, clang::CXXRec
Issue
115308
Summary
[clang] Assertion `DD && "queried property of class with no definition"' failed. Crash at HasAccess(clang::Sema&, (anonymous namespace)::EffectiveContext const&, clang::CXXRecordDecl const*, clang::AccessSpecifier, (anonymous namespace)::AccessTarget const&)
Labels
clang:frontend,
crash-on-invalid,
clang:frontend:fuzzer
Assignees
Reporter
yijan4845
**This testcase is generated by a fuzzer.**
Compiler Explorer: [https://godbolt.org/z/a4o6eoPb6](https://godbolt.org/z/a4o6eoPb6)
This invalid code will crash on both Clang Trunk and Clang Assertion Trunk.
```cpp
template
class S {
protected:
F();
class bar;
class G : public bar {
bool foo() {
F();
}
};
};
```
It seems that this goes back to clang-3(or earlier).
Stack dump:
```
clang++: /root/llvm-project/clang/include/clang/AST/DeclCXX.h:465: clang::CXXRecordDecl::DefinitionData& clang::CXXRecordDecl::data() const: Assertion `DD && "queried property of class with no definition"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments: /opt/compiler-explorer/clang-assertions-trunk/bin/clang++ -gdwarf-4 -g -o /app/output.s -mllvm --x86-asm-syntax=intel -fno-verbose-asm -S --gcc-toolchain=/opt/compiler-explorer/gcc-snapshot -fcolor-diagnostics -fno-crash-diagnostics
1. :8:9: at annotation token
2. :2:1: parsing struct/union/class body 'S'
3. :7:18: parsing function body 'S::G::foo'
4. :7:18: in compound statement ('{}')
#0 0x03bf66c8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x3bf66c8)
#1 0x03bf43cc llvm::sys::CleanupOnSignal(unsigned long) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x3bf43cc)
#2 0x03b419c8 CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0
#3 0x79e466c42520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#4 0x79e466c969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
#5 0x79e466c42476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
#6 0x79e466c287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
#7 0x79e466c2871b (/lib/x86_64-linux-gnu/libc.so.6+0x2871b)
#8 0x79e466c39e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96)
#9 0x068fdd9a (anonymous namespace)::ProtectedFriendContext::findFriendship(clang::CXXRecordDecl const*, unsigned int) SemaAccess.cpp:0:0
#10 0x068fda2d (anonymous namespace)::ProtectedFriendContext::findFriendship(clang::CXXRecordDecl const*, unsigned int) SemaAccess.cpp:0:0
#11 0x068ffdd5 HasAccess(clang::Sema&, (anonymous namespace)::EffectiveContext const&, clang::CXXRecordDecl const*, clang::AccessSpecifier, (anonymous namespace)::AccessTarget const&) SemaAccess.cpp:0:0
#12 0x069006f4 IsAccessible(clang::Sema&, (anonymous namespace)::EffectiveContext const&, (anonymous namespace)::AccessTarget&) SemaAccess.cpp:0:0
#13 0x06900c4e CheckEffectiveAccess(clang::Sema&, (anonymous namespace)::EffectiveContext const&, clang::SourceLocation, (anonymous namespace)::AccessTarget&) SemaAccess.cpp:0:0
#14 0x0690261c CheckAccess(clang::Sema&, clang::SourceLocation, (anonymous namespace)::AccessTarget&) SemaAccess.cpp:0:0
#15 0x06906596 clang::Sema::CheckLookupAccess(clang::LookupResult const&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6906596)
#16 0x0691c912 clang::LookupResult::~LookupResult() (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x691c912)
#17 0x06a7def4 clang::Sema::ActOnNameClassifiedAsOverloadSet(clang::Scope*, clang::Expr*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6a7def4)
#18 0x06794957 clang::Parser::ParseCastExpression(clang::Parser::CastParseKind, bool, bool&, clang::Parser::TypeCastState, bool, bool*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6794957)
#19 0x06794df7 clang::Parser::ParseCastExpression(clang::Parser::CastParseKind, bool, clang::Parser::TypeCastState, bool, bool*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6794df7)
#20 0x06794e89 clang::Parser::ParseAssignmentExpression(clang::Parser::TypeCastState) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6794e89)
#21 0x067998a9 clang::Parser::ParseExpression(clang::Parser::TypeCastState) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x67998a9)
#22 0x0681c2e9 clang::Parser::ParseExprStatement(clang::Parser::ParsedStmtContext) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x681c2e9)
#23 0x068125ce clang::Parser::ParseStatementOrDeclarationAfterAttribu
[llvm-bugs] [Bug 115350] Name lookup of friend names is wrong on clang-cl
Issue
115350
Summary
Name lookup of friend names is wrong on clang-cl
Labels
new issue
Assignees
Reporter
csimon-bambecksystems
Names introduced as friends do not participate in name lookup [as explained here on cpprefererence](https://en.cppreference.com/w/cpp/language/namespace#Namespaces), so the problem with the following ill-formed code:
```
class foo {
friend class bar;
using baz = bar; // Error! Name lookup does not find bar.
};
```
is the name `bar` has not been introduced for name-lookup purposes. MSVC acceps it (that's their problem) but weirdly, clang-cl accepts it and does not warn about a "microsoft extension." I can reproduce it on godbolt with either x86 msvc v19.latest or clang-cl 18.1.0 as the compiler. I know that clang-cl accepts some non-standard name lookup for class templates but this is not a class template, just a regular class. Fun story: I wrote a whole boatload of classes relying on this, uh, "idiom" that I thought I discovered, and I was feeling so good about myself. Then I confidently fed it to another compiler, just another clang with different configuration actually, and *sound of world crashing down.*
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115299] clang-20 crashed with cpu_specific attribute. Assertion `V != this && "Illegal call to this->takeName(this)!"' failed.
Issue
115299
Summary
clang-20 crashed with cpu_specific attribute. Assertion `V != this && "Illegal call to this->takeName(this)!"' failed.
Labels
new issue
Assignees
Reporter
iamanonymouscs
clang-20 crashed with ```cpu_specific``` attribute.
Compiler explorer: https://godbolt.org/z/e7dxPjYd9
```
$cat mutant.c
void __attribute__((cpu_specific(ivybridge))) a (__UINTPTR_TYPE__ x) {}
void b (void)
{
a ((__UINTPTR_TYPE__) a);
}
Also crashed on clang-19.
$clang-19 mutant.c
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments: /usr/lib/llvm-19/bin/clang -cc1 -triple x86_64-pc-linux-gnu -emit-obj -dumpdir a- -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name mutant.c -mrelocation-model pic -pic-level 2 -pic-is-pie -mframe-pointer=all -fmath-errno -ffp-contract=on -fno-rounding-math -mconstructor-aliases -funwind-tables=2 -target-cpu x86-64 -tune-cpu generic -debugger-tuning=gdb -fdebug-compilation-dir=/home/code/reduce -fcoverage-compilation-dir=/home/code/reduce -resource-dir /usr/lib/llvm-19/lib/clang/19 -internal-isystem /usr/lib/llvm-19/lib/clang/19/include -internal-isystem /usr/local/include -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/11/../../../../x86_64-linux-gnu/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -ferror-limit 19 -fgnuc-version=4.2.1 -fskip-odr-check-in-gmf -fcolor-diagnostics -faddrsig -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o /tmp/mutant-922ea3.o -x c mutant.c
1. parser at end of file
2. Code generation
3. Running pass 'Function Pass Manager' on module 'mutant.c'.
4. Running pass 'X86 DAG->DAG Instruction Selection' on function '@b'
#0 0x7f42ff9e0246 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/usr/lib/llvm-19/bin/../lib/libLLVM.so.19.0+0xea7246)
#1 0x7f42ff9dde20 llvm::sys::RunSignalHandlers() (/usr/lib/llvm-19/bin/../lib/libLLVM.so.19.0+0xea4e20)
#2 0x7f42ff9e090b (/usr/lib/llvm-19/bin/../lib/libLLVM.so.19.0+0xea790b)
#3 0x7f42fe618520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#4 0x7f42ffb89b33 llvm::Value::stripPointerCasts() const (/usr/lib/llvm-19/bin/../lib/libLLVM.so.19.0+0x1050b33)
#5 0x7f42ffac1577 llvm::diagnoseDontCall(llvm::CallInst const&) (/usr/lib/llvm-19/bin/../lib/libLLVM.so.19.0+0xf88577)
#6 0x7f43000fd6ec llvm::FastISel::lowerCall(llvm::CallInst const*) (/usr/lib/llvm-19/bin/../lib/libLLVM.so.19.0+0x15c46ec)
#7 0x7f43000f8e26 llvm::FastISel::selectOperator(llvm::User const*, unsigned int) (/usr/lib/llvm-19/bin/../lib/libLLVM.so.19.0+0x15bfe26)
#8 0x7f43000ff5b2 llvm::FastISel::selectInstruction(llvm::Instruction const*) (/usr/lib/llvm-19/bin/../lib/libLLVM.so.19.0+0x15c65b2)
#9 0x7f43002796a8 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) (/usr/lib/llvm-19/bin/../lib/libLLVM.so.19.0+0x17406a8)
#10 0x7f4300277e12 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) (/usr/lib/llvm-19/bin/../lib/libLLVM.so.19.0+0x173ee12)
#11 0x7f430027693a llvm::SelectionDAGISelLegacy::runOnMachineFunction(llvm::MachineFunction&) (/usr/lib/llvm-19/bin/../lib/libLLVM.so.19.0+0x173d93a)
#12 0x7f42ffdc0738 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (/usr/lib/llvm-19/bin/../lib/libLLVM.so.19.0+0x1287738)
#13 0x7f42ffb2e6f4 llvm::FPPassManager::runOnFunction(llvm::Function&) (/usr/lib/llvm-19/bin/../lib/libLLVM.so.19.0+0xff56f4)
#14 0x7f42ffb33fe3 llvm::FPPassManager::runOnModule(llvm::Module&) (/usr/lib/llvm-19/bin/../lib/libLLVM.so.19.0+0xffafe3)
#15 0x7f42ffb2ee4e llvm::legacy::PassManagerImpl::run(llvm::Module&) (/usr/lib/llvm-19/bin/../lib/libLLVM.so.19.0+0xff5e4e)
#16 0x7f43084ebc7e 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*) (/usr/lib/llvm-19/bin/../lib/libclang-cpp.so.19.0+0x1e20c7e)
#17 0x7f4308891132 clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) (/usr/lib/llvm-19/bin/../lib/libclang-cpp.so.19.0+0x21c6132)
#18 0x7f43072fa739 clang::ParseAST(clang::Sema&, bool, bool) (/usr/lib/llvm-19/bin/../lib/libclang-cpp.so.19.0+0xc2f739)
#19 0x7f430938d0b5 clang::FrontendAction::Execute() (/usr/lib/llvm-19/bin/../lib/libclang-cpp.so.19.0+0x2cc20b5)
#20 0x7f43092fd2f4 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/usr/lib/llvm-19/bin/../lib/libclang
[llvm-bugs] [Bug 115348] [mlir] Consider moving away from linking LLVM IR for host and device code in SPIR-V CPU Runner flow
Issue 115348 Summary [mlir] Consider moving away from linking LLVM IR for host and device code in SPIR-V CPU Runner flow Labels mlir Assignees Reporter andfau-amd See this discussion for more details: https://github.com/llvm/llvm-project/pull/114563#discussion_r1831742718 One possible outcome is we simply keep things as they are, but there may be a better option. In particular, if "device" CPU compilation/execution could be offloaded in a similar way as for GPU devices, there would be a better alignment between the SPIR-V CPU Runner and e.g. the Vulkan Runner. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115347] Unsafe buffer usage: constructing [[clang::unsafe_buffer_usage]] fields are not warned on
Issue
115347
Summary
Unsafe buffer usage: constructing [[clang::unsafe_buffer_usage]] fields are not warned on
Labels
clang:diagnostics
Assignees
Reporter
danakj
Similar to https://github.com/llvm/llvm-project/issues/80482 but splitting this off as it's about fields annotated with `[[clang::unsafe_buffer_usage]]`.
Godbolt example: https://godbolt.org/z/9v9EsPej6
```cc
struct S {
[[clang::unsafe_buffer_usage]] int i;
};
class C {
public:
C() : i(1) {} // no error?
C(int j) : i(j) {} // no error?
private:
[[clang::unsafe_buffer_usage]] int i;
};
int main(){
S s = { .i = 1 }; // no error?
s.i = 2; // error ^_^b
S s2(1); // no error?
C c;
C c2(1);
}
```
In the above example only `s.i = 2` causes an unsafe-buffer-usage warning. Constructing a type with `[[unsafe_buffer_usage]]` fields does not produce any warning.
cc: @haoNoQ @ziqingluo-90
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115345] [Clang] `switch` statement: an enum value does not always have to equal one of the enumerators.
Issue 115345 Summary [Clang] `switch` statement: an enum value does not always have to equal one of the enumerators. Labels clang Assignees Reporter bjacob In this [compiler explorer experiment](https://godbolt.org/z/4ro4ncTzo), GCC warns "warning: control reaches end of non-void function", while Clang does not. In this instance, GCC is making an important point: the function `f` cannot assume that its parameter of enum type has a value that is one of the enumerator values, because this enumerator has a a fixed underlying type (the `: int` in the enum declaration) and the standard says that in that case, any integer of that underlying type may be casted to this enum type: https://eel.is/c++draft/expr.static.cast#9 Currently, GCC always warns regardless of having a specified underlying type in the enum declaration ; Clang never warns. If my understanding of the spec is correct then the reachability of the end of the function (and therefore, the rationale for generating a warning) is when there is no specified underlying type. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115341] [DSE] Missed optimization
Issue
115341
Summary
[DSE] Missed optimization
Labels
new issue
Assignees
Reporter
omern1
```ll
; Build with opt --passes='dse' -debug
; Function Attrs: mustprogress nounwind uwtable
define dso_local void @_Z9eaot_testv() {
store i32 3267512, ptr inttoptr (i64 68719476864 to ptr), align 4
%1 = load i32, ptr inttoptr (i64 68719476812 to ptr), align 4
store i32 %1, ptr inttoptr (i64 137438953472 to ptr), align 4
store i32 3267516, ptr inttoptr (i64 68719476864 to ptr), align 4
ret void
}
```
The first store and the load `%1` don't actually alias but DSE fails to delete redundant stores (first and last).
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115339] JIT compilation does not terminate
Issue
115339
Summary
JIT compilation does not terminate
Labels
Assignees
Reporter
pascalginter
I am trying to jit compile C++ code using libclang. I am mostly following this tutorial https://blog.memzero.de/llvm-orc-jit/ with some modifications to support C++ instead of C and linking the standard library.
My approach works fine for some cases but encounters issues when calling insert on an unordered map. The encountered issue is that a lookup with the mangled function name does not terminate as the compilation of the generated llvm code seems to happen lazily and gets stuck. There is no error message, simply what seems like an endless loop/deadlock.
A minimal example to produce the issue is jit compiling the following code:
Note that it works when replacing unordered_map with map. The code the gets compiled and can be executed.
```cpp
#include
#include
void* __dso_handle = (void*) &__dso_handle;
void std::__libcpp_verbose_abort(char const* format, ...) noexcept {std::abort();}"
void jitted(){\n"
std::unordered_map map;"
map.insert({2, 3});"
std::cout << map[2] << std::endl;
}
```
Curiously I managed to get a more complicated example working with unordered_map, tuple> insert but did not manage to produce a simple working version.
Stack trace when interrupting execution
```
0x57340fd3 in bool llvm::DenseMapBase >, llvm::DenseMapInfo, llvm::detail::DenseMapPair > > >, llvm::APFloat, std::unique_ptr >, llvm::DenseMapInfo, llvm::detail::DenseMapPair > > >::LookupBucketFor(llvm::APFloat const&, llvm::detail::DenseMapPair > >*&) ()
(gdb) where
#0 0x57340fd3 in bool llvm::DenseMapBase >, llvm::DenseMapInfo, llvm::detail::DenseMapPair > > >, llvm::APFloat, std::unique_ptr >, llvm::DenseMapInfo, llvm::detail::DenseMapPair > > >::LookupBucketFor(llvm::APFloat const&, llvm::detail::DenseMapPair > >*&) ()
#1 0x57343f10 in llvm::ConstantFP::get(llvm::LLVMContext&, llvm::APFloat const&) ()
#2 0x5627b0e4 in llvm::SelectionDAG::getConstantFP(llvm::APFloat const&, llvm::SDLoc const&, llvm::EVT, bool) ()
#3 0x56270031 in llvm::SelectionDAG::FoldConstantArithmetic(unsigned int, llvm::SDLoc const&, llvm::EVT, llvm::ArrayRef, llvm::SDNodeFlags) ()
#4 0x56273cd6 in llvm::SelectionDAG::getNode(unsigned int, llvm::SDLoc const&, llvm::EVT, llvm::SDValue, llvm::SDNodeFlags) ()
#5 0x55b781d6 in llvm::X86TargetLowering::LowerFP_TO_INT(llvm::SDValue, llvm::SelectionDAG&) const ()
#6 0x561c6f2e in (anonymous namespace)::SelectionDAGLegalize::LegalizeOp(llvm::SDNode*) ()
#7 0x561ca086 in llvm::SelectionDAG::Legalize() ()
#8 0x562ab4fa in llvm::SelectionDAGISel::CodeGenAndEmitDAG() ()
#9 0x562adeea in llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) ()
#10 0x562afb74 in llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) ()
#11 0x5629eb29 in llvm::SelectionDAGISelLegacy::runOnMachineFunction(llvm::MachineFunction&) ()
#12 0x5656281c in llvm::MachineFunctionPass::runOnFunction(llvm::Function&) [clone .part.0] ()
#13 0x57438c31 in llvm::FPPassManager::runOnFunction(llvm::Function&) ()
#14 0x57438dc4 in llvm::FPPassManager::runOnModule(llvm::Module&) ()
#15 0x57437f5f in llvm::legacy::PassManagerImpl::run(llvm::Module&) ()
#16 0x55d7c896 in llvm::orc::SimpleCompiler::operator()(llvm::Module&) ()
#17 0x55d7cd1e in llvm::orc::ConcurrentIRCompiler::operator()(llvm::Module&) ()
#18 0x55dbfa43 in llvm::orc::IRCompileLayer::emit(std::unique_ptr >, llvm::orc::ThreadSafeModule) ()
#19 0x55dc376c in llvm::orc::BasicIRLayerMaterializationUnit::materialize(std::unique_ptr >) ()
#20 0x55d99b8a in llvm::orc::MaterializationTask::run() ()
#21 0x55d9a182 in llvm::orc::ExecutionSession::dispatchOutstandingMUs() ()
#22 0x55d9a54a in llvm::orc::ExecutionSession::OL_completeLookup(std::unique_ptr >, std::shared_ptr, std::function >, llvm::DenseMapInfo, llvm::detail::DenseMapPair > > > const&)>) ()
#23 0x55d9b8f2 in llvm::orc::InProgressFullLookupState::complete(std::unique_ptr >) ()
#24 0x55d9dd82 in llvm::orc::ExecutionSession::OL_applyQueryPhase1(std::unique_ptr >, llvm::Error) ()
#25 0x55d9e3f9 in llvm::orc::ExecutionSession::lookup(llvm::orc::LookupKind, std::vector, std::allocator > > const&, llvm::orc::SymbolLookupSet, llvm::orc::SymbolState, llvm::unique_function, llvm::detail::DenseMapPair > >)>, std::function >, llvm::DenseMapInfo, llvm::detail::DenseMapPair > > > const&)>) ()
#26 0x55d9e63d in llvm::orc::ExecutionSession::lookup(std::vector, std::allocator > > const&, llvm::orc::SymbolLookupSet, llvm::orc::LookupKind, llvm::orc::SymbolState, std::function >, llvm::DenseMap
[llvm-bugs] [Bug 115329] [lldb-dap] vscode - ability to launch lldb as root
Issue 115329 Summary [lldb-dap] vscode - ability to launch lldb as root Labels new issue Assignees Reporter qkdreyer we could use https://github.com/golang/vscode-go/commit/a807c61f45d27f1c30fd0fa8691b4230ef211de7 as base ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115333] [AArch64] BOLT does not support SPE branch data
Issue
115333
Summary
[AArch64] BOLT does not support SPE branch data
Labels
BOLT
Assignees
Reporter
paschalis-mpeis
## Purpose
In some upcoming Linux kernel release, perf will gain the ability to process additional branch entries of
Arm's Statistical Profiling Extension ([SPE](https://developer.arm.com/documentation/101136/22-1-3/MAP/Arm-Statistical-Profiling-Extension--SPE-)). ATM, those changes are part of [perf-tools-next](https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/log/?h=perf-tools-next).
The purpose of this issue is to raise awareness to the community that BOLT will need some changes to be able to take advantage of this additional information. Below, I briefly explain what this extra information is, how to check one is on the right version, and some pointers of how it may be used in the future.
## What extra branch information will be provided
With the upcoming update, perf will gain the ability to process [all sampled branches](https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/commit/?h=perf-tools-next&id=c1b67c85108f99af0a80aa9e59a2b94ad95428d7) and not just the branch misses. Each branch sample will be pointing to the [correct target](https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/commit/?h=perf-tools-next&id=19966d792b9e6b055aeb2f0e573b4d4573d5e15b) (ip → to_ip).
In short, with SPE one can get a statistical sample of the branches, where each event will have a Source and a Destination (fields ip → addr).
## Ensuring the updated perf version is used
Currently, one can use the updated perf by compiling [perf-tools-next](https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/log/?h=perf-tools-next).
The relevant patches are merged, which are: [#patch1](https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/commit/?h=perf-tools-next&id=19966d792b9e6b055aeb2f0e573b4d4573d5e15b), [#patch2](https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/commit/?h=perf-tools-next&id=c1b67c85108f99af0a80aa9e59a2b94ad95428d7), [#patch3](https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/commit/?h=perf-tools-next&id=edff8dad3f9a483259140fb814586b39da430a38), [#patch4](https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/commit/?h=perf-tools-next&id=35f5aa9ccc83f4a4171cdb6ba023e514e2b2ecff).
A couple of checks need to be done:
1. Verify if the machine has SPE available. If not, enable SPE (see [guide](https://developer.arm.com/documentation/ka005362/1-0)).
2. Confirm perf is on the correct version and can process all branches. It should report 'branch' instead of 'branch-miss' events.
Both checks can be performed using:
```bash
perf record -e arm_spe/branch_filter=1/u 2>/dev/null -- ls . \
&& (perf script -F event,ip,addr 2> /dev/null | grep -v branch-miss -q \
&& echo "SUCCESS: perf can process all SPE branch samples" \
|| echo "FAILURE: perf cannot process all SPE branch samples") \
|| echo "FAILURE: SPE is not available"
```
## How the additional information may be used
There can be two approaches of supporting SPE in BOLT. Some relevant points of how this information may be aligned to existing BOLT infrastructure are discussed briefly below.
### Using the BasicAggregation format:
For this format, one could parse the source and destination branches and create two simple events. Those can then be processed by BOLT as normal, under the `-nl` flag. They will use an accurate sample of branch locations with hotness counts for the source and the destination blocks.
### Using the LBR format:
For this format, one could convert the source and destination branches into the LBR format. The trace will have a pretty shallow depth of 2, being: { 'destination', 'source' }, matching the expected branch history.
The `flags` field in `perf script` could be toggled on to distinguish between branch misses and hits. There seems to be no point in using the branch fall-through information, due to how SPE operates: in contrast with LBR, SPE is a non-contiguous statistical sampling. In other words, ignoring fall-throughs would be dropping information that BOLT cannot infer.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115323] `sincos` args may get clobbered after #108401 when passed on the stack
Issue
115323
Summary
`sincos` args may get clobbered after #108401 when passed on the stack
Labels
compiler-rt:asan,
llvm:SelectionDAG
Assignees
MacDue
Reporter
zmodem
Consider this program on 32-bit x86, where arguments are passed on the stack:
```
$ cat /tmp/a.cc
#include
#include
double __attribute__((noinline)) g(double a, double b) { return a + b; }
double __attribute__((noinline)) f(double a) {
double foo = sin(a);
double bar = cos(a);
double z = g(bar + 3.14, foo);
return z;
}
int main() {
printf("%f\n", f(3.14));
return 0;
}
```
After 3073c3c2290a6d9b12fbaefa40dd22eef6312895, it fails under ASan:
```
$ build/bin/clang.bad -target i386-unknown-linux-gnu -lm -fsanitize=address -fno-math-errno -O2 /tmp/a.cc && ASAN_OPTIONS=external_symbolizer_path=$PWD/build/bin/llvm-symbolizer ./a.out
AddressSanitizer:DEADLYSIGNAL
=
==3898196==ERROR: AddressSanitizer: SEGV on unknown address 0x27eb4300 (pc 0x566160ed bp 0xffab1898 sp 0xffab1470 T0)
==3898196==The signal is caused by a READ memory access.
#0 0x566160ed in QuickCheckForUnpoisonedRegion /work/llvm-project/compiler-rt/lib/asan/asan_interceptors_memintrinsics.h:37:7
#1 0x566160ed in sincos /work/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:5167:12
#2 0x566b25b1 in f(double) (/work/llvm-project/a.out+0x1085b1)
#3 0x566b25f3 in main (/work/llvm-project/a.out+0x1085f3)
#4 0xf7c29b84 (/lib/i386-linux-gnu/libc.so.6+0x23b84) (BuildId: d16f2b0239d79fbec67438094f9a9443121ab72d)
#5 0xf7c29c47 in __libc_start_main (/lib/i386-linux-gnu/libc.so.6+0x23c47) (BuildId: d16f2b0239d79fbec67438094f9a9443121ab72d)
#6 0x565c43a6 in _start (/work/llvm-project/a.out+0x1a3a6)
==3898196==Register values:
eax = 0x27eb4300 ebx = 0x27eb4303 ecx = 0x27eb4300 edx = 0x3f5a1819
edi = 0x07eb4303 esi = 0x07eb4302 ebp = 0xffab1898 esp = 0xffab1470
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/work/llvm-project/a.out+0x1085b1) in f(double)
==3898196==ABORTING
```
The calls to `sin` and `cos` will get folded to a `sincos` call. After 3073c3c2290a6d9b12fbaefa40dd22eef6312895, the call looks like this:
```
37: 89 e6 mov%esp,%esi
39: 8d 44 24 18 lea0x18(%esp),%eax
3d: 89 44 24 0c mov%eax,0xc(%esp)// <-- cos
41: 8d 46 08 lea0x8(%esi),%eax
44: 89 44 24 08 mov %eax,0x8(%esp)// <-- sin
48: f2 0f 11 04 24 movsd %xmm0,(%esp) // <-- x
4d: e8 fc ff ff ff call 4e <_Z1fd+0x2e>
4e: R_386_PLT32 sincos
```
Look at the value of the `sin` argument: it's `0x8(%esi) = 0x8(%esp)` which is the stack slot for `foo` in the following call to `g`. But it's also the stack slot used for `sin` in the `sincos` call. This seems dangerous.
Since it's a 64-bit value, when `sincos` does `*sin = ...` it will clobber both the `sin` and `cos` arguments. ASan happens to notice, because it intercepts `sincos` and checks the validity of the pointers afterwards.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115326] [libc++] Rejects-valid on unexpected(1) == unexpected(1L)
Issue 115326 Summary [libc++] Rejects-valid on unexpected(1) == unexpected(1L) Labels libc++ Assignees frederick-vs-ja Reporter ldionne Minimal reproducer: ``` #include static_assert(std::unexpected(1) == std::unexpected(1L)); ``` Output: ``` __expected/unexpected.h:111:31: error: '__unex_' is a private member of 'std::unexpected' 111 | return __x.__unex_ == __y.__unex_; | ^ ``` Godbolt: https://godbolt.org/z/a8rPnKz1Y The fix is to use `__y.error()` instead of `__y.__unex_`. This was originally discovered in https://github.com/Quuxplusone/llvm-project/issues/40. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115303] [analyzer] Assert failed when analyzing compound literal in C++
Issue
115303
Summary
[analyzer] Assert failed when analyzing compound literal in C++
Labels
new issue
Assignees
Reporter
z1nke
Example: https://godbolt.org/z/G675h4q8r
Standard C++ does not have compound literals, and I'm not sure whether it needs to be fixed.
I accidentally found this crash during testing and posted it here.
```cpp
// clang --analyze -Xclang -analyzer-checker=core test.cpp
const char *foo(void) {
return (const char[]) { "abc" };
}
```
```
clang++: /root/llvm-project/clang/lib/StaticAnalyzer/Core/ExprEngine.cpp:343: clang::ento::ProgramStateRef clang::ento::ExprEngine::createTemporaryRegionIfNeeded(clang::ento::ProgramStateRef, const clang::LocationContext*, const clang::Expr*, const clang::Expr*, const clang::ento::SubRegion**): Assertion `!isa(InitValWithAdjustments) || Loc::isLocType(Result->getType()) || Result->getType()->isMemberPointerType()' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments: /opt/compiler-explorer/clang-assertions-19.1.0/bin/clang++ -gdwarf-4 -g -o /app/output.s -fno-verbose-asm -S --gcc-toolchain=/opt/compiler-explorer/gcc-14.2.0 -fcolor-diagnostics -fno-crash-diagnostics --analyze -Xclang -analyzer-checker=core
1. parser at end of file
2. While analyzing stack:
#0 Calling foo()
3. :2:10: Error evaluating statement
4. :2:10: Error evaluating statement
#0 0x03ae9978 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-assertions-19.1.0/bin/clang+++0x3ae9978)
#1 0x03ae766c llvm::sys::CleanupOnSignal(unsigned long) (/opt/compiler-explorer/clang-assertions-19.1.0/bin/clang+++0x3ae766c)
#2 0x03a308f8 CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0
#3 0x7a076d642520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#4 0x7a076d6969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
#5 0x7a076d642476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
#6 0x7a076d6287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
#7 0x7a076d62871b (/lib/x86_64-linux-gnu/libc.so.6+0x2871b)
#8 0x7a076d639e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96)
#9 0x06388a85 clang::ento::ExprEngine::createTemporaryRegionIfNeeded(llvm::IntrusiveRefCntPtr, clang::LocationContext const*, clang::Expr const*, clang::Expr const*, clang::ento::SubRegion const**) (/opt/compiler-explorer/clang-assertions-19.1.0/bin/clang+++0x6388a85)
#10 0x063b3b18 clang::ento::ExprEngine::CreateCXXTemporaryObject(clang::MaterializeTemporaryExpr const*, clang::ento::ExplodedNode*, clang::ento::ExplodedNodeSet&) (/opt/compiler-explorer/clang-assertions-19.1.0/bin/clang+++0x63b3b18)
#11 0x06398846 clang::ento::ExprEngine::Visit(clang::Stmt const*, clang::ento::ExplodedNode*, clang::ento::ExplodedNodeSet&) (/opt/compiler-explorer/clang-assertions-19.1.0/bin/clang+++0x6398846)
#12 0x0639af75 clang::ento::ExprEngine::ProcessStmt(clang::Stmt const*, clang::ento::ExplodedNode*) (/opt/compiler-explorer/clang-assertions-19.1.0/bin/clang+++0x639af75)
#13 0x063a30fa clang::ento::ExprEngine::processCFGElement(clang::CFGElement, clang::ento::ExplodedNode*, unsigned int, clang::ento::NodeBuilderContext*) (/opt/compiler-explorer/clang-assertions-19.1.0/bin/clang+++0x63a30fa)
#14 0x063557fb clang::ento::CoreEngine::HandlePostStmt(clang::CFGBlock const*, unsigned int, clang::ento::ExplodedNode*) (/opt/compiler-explorer/clang-assertions-19.1.0/bin/clang+++0x63557fb)
#15 0x06355c3b clang::ento::CoreEngine::dispatchWorkItem(clang::ento::ExplodedNode*, clang::ProgramPoint, clang::ento::WorkListUnit const&) (/opt/compiler-explorer/clang-assertions-19.1.0/bin/clang+++0x6355c3b)
#16 0x06355d7a clang::ento::CoreEngine::ExecuteWorkList(clang::LocationContext const*, unsigned int, llvm::IntrusiveRefCntPtr) (/opt/compiler-explorer/clang-assertions-19.1.0/bin/clang+++0x6355d7a)
#17 0x05d35621 (anonymous namespace)::AnalysisConsumer::HandleCode(clang::Decl*, unsigned int, clang::ento::ExprEngine::InliningModes, llvm::DenseSet>*) AnalysisConsumer.cpp:0:0
#18 0x05d5c842 (anonymous namespace)::AnalysisConsumer::HandleDeclsCallGraph(unsigned int) AnalysisConsumer.cpp:0:0
#19 0x05d5dee6 (anonymous namespace)::AnalysisConsumer::HandleTranslationUnit(clang::ASTContext&) AnalysisConsumer.cpp:0:0
#20 0x064cc55c clang::ParseAST(clang::Sema&, bool, bool) (/opt/compiler-explorer/clang-assertions-19.1.0/bin/clang+++0x64cc55c)
#21 0x04684f59 clang::FrontendAction::Execute() (/opt/compiler-explorer/clang-assertions-19.1.0/bin/clang+++0x4684f59)
#22 0x04609f8e clang::CompilerInstance::Execute
[llvm-bugs] [Bug 115301] [GVN] mishandle of `phi`
Issue
115301
Summary
[GVN] mishandle of `phi`
Labels
new issue
Assignees
Reporter
bongjunj
Alive2 report: https://alive2.llvm.org/ce/z/yDrndK
```llvm
define double @fcmp_une_not_zero.2(double %x, double %y) {
entry:
%cmp = fcmp une double %y, 2.00
br i1 %cmp, label %return, label %else
else:
br label %return
return:
%retval = phi double [ undef, %else ], [ %x, %entry ]
ret double %retval
}
=>
define double @fcmp_une_not_zero.2(double %x, double %y) {
entry:
%cmp = fcmp une double %y, 2.00
br i1 %cmp, label %return, label %else
else:
br label %return
return:
ret double %x
}
Transformation doesn't verify!
ERROR: Target is more poisonous than source
Example:
double %x = poison
double %y = #x4000 (2)
Source:
i1 %cmp = #x0 (0)
>> Jump to %else
>> Jump to %return
double %retval = #x (+0.0) [based on undef value]
Target:
i1 %cmp = #x0 (0)
>> Jump to %else
>> Jump to %return
Source value: #x (+0.0)
Target value: poison
Summary:
0 correct transformations
1 incorrect transformations
0 failed-to-prove transformations
0 Alive2 errors
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115294] [mlir] Inconsistent results and crash for vector.bitcast
Issue
115294
Summary
[mlir] Inconsistent results and crash for vector.bitcast
Labels
mlir
Assignees
Reporter
wangyongj1a
I have the following MLIR program:
test.mlir:
```
module {
func.func @func1() -> f32{
%idx0 = index.constant 0
%cst_6 = arith.constant -0.0 : f32
%173 = vector.broadcast %cst_6 : f32 to vector<5x1xf32>
%176 = vector.bitcast %173 : vector<5x1xf32> to vector<5x1xi32>
%554 = vector.shape_cast %176 : vector<5x1xi32> to vector<5xi32>
%555 = vector.extract %554[%idx0] : i32 from vector<5xi32>
vector.print %555 : i32
%0 = arith.sitofp %555 : i32 to f32
return %0 : f32
}
}
```
When I ran ```/data/tmp/v1107/llvm-project/build/bin/mlir-opt --convert-vector-to-llvm --convert-index-to-llvm --convert-arith-to-llvm --convert-scf-to-cf --convert-func-to-llvm --reconcile-unrealized-casts test.mlir | /data/tmp/v1107/llvm-project/build/bin/mlir-cpu-runner -e func1 --shared-libs=/data/tmp/v1107/llvm-project/build/lib/libmlir_runner_utils.so,/data/tmp/v1107/llvm-project/build/lib/libmlir_c_runner_utils.so``` on the program, I got the result of:
```
0
0.00e+00
```
However, when I ran ```/data/tmp/v1107/llvm-project/build/bin/mlir-opt --test-vector-linearize --convert-vector-to-llvm --convert-index-to-llvm --convert-arith-to-llvm --convert-scf-to-cf --convert-func-to-llvm --reconcile-unrealized-casts test.mlir | /data/tmp/v1107/llvm-project/build/bin/mlir-cpu-runner -e func1 --shared-libs=/data/tmp/v1107/llvm-project/build/lib/libmlir_runner_utils.so,/data/tmp/v1107/llvm-project/build/lib/libmlir_c_runner_utils.so``` on the program, I got the result of:
```
-2147483648
-2.147484e+09
```
The above two results seem to be inconsistent. I'm not sure if there is any bug in my program or if the wrong usage of the above passes caused these results.
Besides, if I change the test.mlir to :
```
module {
func.func @func1() -> f32{
%idx0 = index.constant 0
%cst_6 = arith.constant -0.0 : f32
%173 = vector.broadcast %cst_6 : f32 to vector<5x1xf32>
%176 = vector.bitcast %173 : vector<5x1xf32> to vector<5x1xi32>
%555 = vector.extract %176[%idx0] : i32 from vector<5x1xi32>
vector.print %555 : i32
%0 = arith.sitofp %555 : i32 to f32
return %0 : f32
}
}
```
The above MLIR program will cause a crash when using the following command:
```
mlir-opt --convert-vector-to-llvm test.mlir
```
And the crash backtrace is:
```
incompatible with LLVM vector type
UNREACHABLE executed at /data/tmp/v1107/llvm-project/mlir/lib/Dialect/LLVMIR/IR/LLVMTypes.cpp:897!
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0. Program arguments: /data/tmp/v1107/llvm-project/build/bin/mlir-opt --convert-vector-to-llvm test.mlir
#0 0x5564ab6437af llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/data/tmp/v1107/llvm-project/build/bin/mlir-opt+0x15d17af)
#1 0x5564ab640834 SignalHandler(int) Signals.cpp:0:0
#2 0x7f232257d420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420)
#3 0x7f232204a00b raise (/lib/x86_64-linux-gnu/libc.so.6+0x4300b)
#4 0x7f2322029859 abort (/lib/x86_64-linux-gnu/libc.so.6+0x22859)
#5 0x5564ab66859e (/data/tmp/v1107/llvm-project/build/bin/mlir-opt+0x15f659e)
#6 0x5564ac987f8f mlir::LLVM::getVectorElementType(mlir::Type) (/data/tmp/v1107/llvm-project/build/bin/mlir-opt+0x2915f8f)
#7 0x5564ac7b5f47 mlir::LLVM::ExtractElementOp::build(mlir::OpBuilder&, mlir::OperationState&, mlir::Value, mlir::Value) (/data/tmp/v1107/llvm-project/build/bin/mlir-opt+0x2743f47)
#8 0x5564ae2758b4 (anonymous namespace)::VectorExtractOpConversion::matchAndRewrite(mlir::vector::ExtractOp, mlir::vector::ExtractOpAdaptor, mlir::ConversionPatternRewriter&) const ConvertVectorToLLVM.cpp:0:0
#9 0x5564ae2581b2 mlir::ConvertOpToLLVMPattern::matchAndRewrite(mlir::Operation*, llvm::ArrayRef, mlir::ConversionPatternRewriter&) const (/data/tmp/v1107/llvm-project/build/bin/mlir-opt+0x41e61b2)
#10 0x5564aea0052a mlir::ConversionPattern::matchAndRewrite(mlir::Operation*, mlir::PatternRewriter&) const (/data/tmp/v1107/llvm-project/build/bin/mlir-opt+0x498e52a)
#11 0x5564b1c335c0 mlir::PatternApplicator::matchAndRewrite(mlir::Operation*, mlir::PatternRewriter&, llvm::function_ref, llvm::function_ref, llvm::function_ref) (/data/tmp/v1107/llvm-project/build/bin/mlir-opt+0x7bc15c0)
#12 0x5564aea0889b (anonymous namespace)::OperationLegalizer::legalize(mlir::Operation*, mlir::ConversionPatternRewriter&) DialectConversion.cpp:0:0
#13 0x5564aea09efe mlir::OperationConverter::convert(mlir::ConversionPatternRewriter&, mlir::Operation*) (/data/tmp/v1107/llvm-project/build/bin/mlir-opt+0x4997efe)
#14 0x5564aea0d8eb mlir::Operat
[llvm-bugs] [Bug 115293] [mlir] Inconsistent results for arith.ceildivsi
Issue
115293
Summary
[mlir] Inconsistent results for arith.ceildivsi
Labels
mlir
Assignees
Reporter
wangyongj1a
I have the following MLIR program:
test.mlir:
```
module {
func.func @func1() -> f32 {
%c1189465982_i64 = arith.constant 1189465982 : i64
%c-9223372036854775808_i64 = arith.constant -9223372036854775808 : i64
%156 = arith.ceildivsi %c-9223372036854775808_i64, %c1189465982_i64 : i64
vector.print %156 : i64
%0 = arith.sitofp %156 : i64 to f32
return %0 : f32
}
}
```
When I ran ```/data/tmp/v1107/llvm-project/build/bin/mlir-opt --int-range-optimizations --arith-expand --convert-arith-to-llvm --convert-vector-to-llvm --convert-func-to-llvm --reconcile-unrealized-casts test.mlir | /data/tmp/v1107/llvm-project/build/bin/mlir-cpu-runner -e func1 --shared-libs=/data/tmp/v1107/llvm-project/build/lib/libmlir_runner_utils.so,/data/tmp/v1107/llvm-project/build/lib/libmlir_c_runner_utils.so``` on the program, I got the result of:
```
-7754212542
-7.754212e+09
```
However, when I ran ```/data/tmp/v1107/llvm-project/build/bin/mlir-opt --arith-expand --convert-arith-to-llvm --convert-vector-to-llvm --convert-func-to-llvm --reconcile-unrealized-casts test.mlir | /data/tmp/v1107/llvm-project/build/bin/mlir-cpu-runner -e func1 --shared-libs=/data/tmp/v1107/llvm-project/build/lib/libmlir_runner_utils.so,/data/tmp/v1107/llvm-project/build/lib/libmlir_c_runner_utils.so``` on the program, I got the result of:
```
7754212542
7.754212e+09
```
The above two results seem to be inconsistent. I'm not sure if there is any bug in my program or if the wrong usage of the above passes caused these results.
My git version is 1469d82e1cb3edc939d6b93089046edfef0cf36c.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115290] [TableGen] TableGen doesn't support multiple indepedent output values
Issue 115290 Summary [TableGen] TableGen doesn't support multiple indepedent output values Labels tablegen Assignees Reporter RKSimon Raised on #114425: > Ah sorry, what I was actually talking about is having multiple output instructions with no data dependency between them. IIRC we can have multiple output results, or even multiple instructions in the output pattern as long as the output from one depends on the other. Without this most targets have had to implement a sometimes large number of instructions in their DAGToDAGISel::Select implementations - which in the case of #114425 is causing build time issues on MSVC due to the sheer number of inlined functions. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115289] Clang rejects valid implicit capture of constexpr variables
Issue
115289
Summary
Clang rejects valid implicit capture of constexpr variables
Labels
clang
Assignees
Reporter
cgnitash
The following [program](https://godbolt.org/z/shzn8aGTP) is rejected in all versions of Clang:
```
int main() {
constexpr int n{};
[] {
n; // error: variable 'n' cannot be implicitly captured in a lambda with no capture-default specified
};
}
```
Actually using `n` (i.e., reading it's value) makes the error go away.
This looks somewhat related to https://github.com/llvm/llvm-project/issues/57760, though this has nothing to do with `noexcept`, and this one is not a regression; it's been this way for all versions of Clang.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115282] [GlobalOpt] Reduction of global aggregate with alignment constraint unnecessarily propagates alignment to some elements
Issue 115282 Summary [GlobalOpt] Reduction of global aggregate with alignment constraint unnecessarily propagates alignment to some elements Labels new issue Assignees Reporter brunodf-snps When GlobalOpt performs SRA on a global aggregate with an alignment constraint, it seems to propagate the alignment to _some_ of the elements haphazardly. For example: ``` alignas(32) static int params[8]; ``` On a plain 32 bit architecture, the array elements respectively have alignment: 32, 4, 8, 4, 16, 4, 8, 4 GlobalOpt SRA creates individual global variables for the elements with respective alignments: 32, 32, 8, 32, 16, 32, 8, 32 I don't see any benefit to increase the alignments elements 1, 3, 5, 7 from 4 to 32. This is wasteful because the new elements cannot be mapped consecutively in memory anymore. Godbolt demo: https://godbolt.org/z/WjbPjY9Kh ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115280] [clang] Assertion `idx < size()' failed.
Issue
115280
Summary
[clang] Assertion `idx < size()' failed.
Labels
clang:frontend,
crash-on-invalid,
clang:frontend:fuzzer,
regression:17
Assignees
Reporter
yijan4845
**This testcase is generated by a fuzzer.**
Compiler Explorer: [https://godbolt.org/z/azj49bxWW](https://godbolt.org/z/azj49bxWW)
This invalid code will crash on Clang Assertion Trunk.
```cpp
struct s {
int i = 0;
int j = 0;
void m(int i = ^{ static int i = 0; return ++i; }(),
int j = ^{ #line 7
static int i = 0; return ++i; }()) {}
};
```
It seems that this goes back to clang-17. The stack dump is very similar to [112632](https://github.com/llvm/llvm-project/issues/112632).
Stack dump:
```
clang++: /root/llvm-project/llvm/include/llvm/ADT/SmallVector.h:291: T& llvm::SmallVectorTemplateCommon >::operator[](llvm::SmallVectorTemplateCommon >::size_type) [with T = clang::sema::FunctionScopeInfo*; = void; llvm::SmallVectorTemplateCommon >::reference = clang::sema::FunctionScopeInfo*&; llvm::SmallVectorTemplateCommon >::size_type = long unsigned int]: Assertion `idx < size()' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments: /opt/compiler-explorer/clang-assertions-trunk/bin/clang++ -gdwarf-4 -g -o /app/output.s -mllvm --x86-asm-syntax=intel -fno-verbose-asm -S --gcc-toolchain=/opt/compiler-explorer/gcc-snapshot -fcolor-diagnostics -fno-crash-diagnostics
1. :6:38: current parser token ';'
2. :1:1: parsing struct/union/class body 's'
3. :5:18: block literal parsing
4. :5:19: in compound statement ('{}')
#0 0x03bf66c8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x3bf66c8)
#1 0x03bf43cc llvm::sys::CleanupOnSignal(unsigned long) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x3bf43cc)
#2 0x03b419c8 CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0
#3 0x7e05baa42520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#4 0x7e05baa969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
#5 0x7e05baa42476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
#6 0x7e05baa287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
#7 0x7e05baa2871b (/lib/x86_64-linux-gnu/libc.so.6+0x2871b)
#8 0x7e05baa39e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96)
#9 0x06cce9aa clang::Sema::tryCaptureVariable(clang::ValueDecl*, clang::SourceLocation, clang::Sema::TryCaptureKind, clang::SourceLocation, bool, clang::QualType&, clang::QualType&, unsigned int const*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6cce9aa)
#10 0x06cceed1 clang::Sema::getCapturedDeclRefType(clang::ValueDecl*, clang::SourceLocation) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6cceed1)
#11 0x06d0eef2 clang::Sema::BuildDeclarationNameExpr(clang::CXXScopeSpec const&, clang::DeclarationNameInfo const&, clang::NamedDecl*, clang::NamedDecl*, clang::TemplateArgumentListInfo const*, bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6d0eef2)
#12 0x06d0f28f clang::Sema::BuildDeclarationNameExpr(clang::CXXScopeSpec const&, clang::LookupResult&, bool, bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6d0f28f)
#13 0x06d11096 clang::Sema::ActOnIdExpression(clang::Scope*, clang::CXXScopeSpec&, clang::SourceLocation, clang::UnqualifiedId&, bool, bool, clang::CorrectionCandidateCallback*, bool, clang::Token*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6d11096)
#14 0x067940c7 clang::Parser::ParseCastExpression(clang::Parser::CastParseKind, bool, bool&, clang::Parser::TypeCastState, bool, bool*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x67940c7)
#15 0x067933a5 clang::Parser::ParseCastExpression(clang::Parser::CastParseKind, bool, bool&, clang::Parser::TypeCastState, bool, bool*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x67933a5)
#16 0x06794df7 clang::Parser::ParseCastExpression(clang::Parser::CastParseKind, bool, clang::Parser::TypeCastState, bool, bool*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6794df7)
#17 0x06794e89 clang::Parser::ParseAssignmentExpression(clang::Parser::TypeCastState) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6794e89)
#18 0x067998a9 clang::Parser::ParseExpression(clang::Parser::TypeCastState) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x67998a9)
#19 0x0680ebf2 clang::Parser::ParseReturnStatement() (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x680ebf2)
#20 0x000
[llvm-bugs] [Bug 115278] When using `Q_EMIT`, spaces are added around `->` operator
Issue 115278 Summary When using `Q_EMIT`, spaces are added around `->` operator Labels new issue Assignees Reporter nbolton For example, when we format this line: ``` Q_EMIT model()->screensChanged(); ``` Spaces are added around `->` operator: ``` Q_EMIT model() -> screensChanged(); ``` When `Q_EMIT` is removed, the spaces are not added: ``` model()->screensChanged(); ``` `.clang-format` ``` # Important: Use the same version of clang-format as our linter, which is: # # $ ./scripts/install_deps.py --only-python # $ ./.venv/bin/clang-format --version # # Warning: If you use a different version, the formatting will be different. # # To install a specific version of clang-format, use pip: # $ pip install clang-format== BasedOnStyle: LLVM # Turn off LLVM default alignment of params with the opening bracket, # which can be less readable in some cases in our code base. # # Using `BlockIndent` will result in: # void fooBarBazQuxHelloWorld( # int a, # int b # ); # # Instead of: # void fooBarBazQuxHelloWorld(int a, # int b); AlignAfterOpenBracket: BlockIndent # Turn off LLVM default packing of ctor initializers. # This makes it easier to see which members were initialized and in what order. PackConstructorInitializers: CurrentLine # up our limit to 120 ColumnLimit: 120 # Custom Breaking rules BreakBeforeBraces: Custom BraceWrapping: AfterCaseLabel: false AfterClass: true AfterControlStatement: Never AfterEnum: true AfterFunction: true AfterNamespace: false AfterStruct: true AfterUnion: true AfterExternBlock: true BeforeCatch: false BeforeElse: false BeforeLambdaBody: false BeforeWhile: false # no single line functions AllowShortFunctionsOnASingleLine: None ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115266] [LLD] [AVR] ldscripts/avr6.x:115: ) expected, but got (
Issue
115266
Summary
[LLD] [AVR] ldscripts/avr6.x:115: ) expected, but got (
Labels
lld
Assignees
Reporter
dakkshesh07
Trying to cross compile AVR program but the final linking seems to fail due to some syntax error in the linkerscript.
```
clang++ --target=avr -o firmware.elf -mmcu=atmega2560 --sysroot=${SYSROOT_DIR} -I${SYSROOT_DIR}/avr/include -L"${SYSROOT_DIR}/lib" -ffunction-sections -fdata-sections -fpermissive -fno-exceptions -fno-threadsafe-statics -fno-rtti -Wl,--gc-sections out/main/main.cpp.o out/libArduinoCore.a -lm -fuse-linker-plugin -fuse-ld=lld
```
error:
```
ld.lld: error: /mnt/c/Users/chana/Downloads/Arch/sysroot/lib/gcc/avr/14.1.0/../../../../avr/lib/ldscripts/avr6.x:115: ) expected, but got (
>>> KEEP(SORT(*)(.ctors))
>>> ^
clang++: error: avr-ld command failed with exit code 1 (use -v to see invocation)
```
linkerscript snip:
```
/* Internal text space or external memory. */
.text :
{
*(.vectors)
KEEP(*(.vectors))
/* For data that needs to reside in the lower 64k of progmem. */
*(.progmem.gcc*)
/* PR 13812: Placing the trampolines here gives a better chance
that they will be in range of the code that uses them. */
. = ALIGN(2);
__trampolines_start = . ;
/* The jump trampolines for the 16-bit limited relocs will reside here. */
*(.trampolines)
*(.trampolines*)
__trampolines_end = . ;
/* avr-libc expects these data to reside in lower 64K. */
*libprintf_flt.a:*(.progmem.data)
*libc.a:*(.progmem.data)
*(.progmem.*)
. = ALIGN(2);
/* For code that needs to reside in the lower 128k progmem. */
*(.lowtext)
*(.lowtext*)
__ctors_start = . ;
*(.ctors)
__ctors_end = . ;
__dtors_start = . ;
*(.dtors)
__dtors_end = . ;
KEEP(SORT(*)(.ctors))
KEEP(SORT(*)(.dtors))
/* From this point on, we do not bother about whether the insns are
below or above the 16 bits boundary. */
*(.init0) /* Start here after reset. */
KEEP (*(.init0))
*(.init1)
KEEP (*(.init1))
```
Is this because LLD expects it in a different syntax? because all these linkerscripts from gnu binutils have been in use with gcc avr from a long time. Im just trying to fix things and get it working with LLVM as well.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115265] clang-format: Support CBMC-style annotations between after signature and loop
Issue
115265
Summary
clang-format: Support CBMC-style annotations between after signature and loop
Labels
clang-format
Assignees
Reporter
hanno-becker
**Context:** The [C bounded model checker (CBMC)](https://github.com/diffblue/cbmc) uses annotations of the following form to specify function contracts:
```c
type function(...)
REQUIRES(...)
ASSIGNS(...)
ENSURES(...)
;
```
Loop annotations are provided as follows:
```c
for (...)
ASSIGNS(...)
LOOP_INVARIANT(...)
{
...
}
```
I looked through the existing `clang-format` attribute options, but could not find one that would not muddle with those annotations in these unusual places.
**Ask:** Provide a configuration option to `clang-format` similar to `AttributeMacros` which allows to designate macros as expected in the odd position as above, and cause them to not be touched by `clang-format`.
So far, we have to work around the issue by placing `// clang-format on/off` annotations everywhere, which is visually rather annoying.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115255] FileCheck NO-PERMISSION: error: unable to open '[[ARCHIVE]]': [[MSG]]
Issue 115255 Summary FileCheck NO-PERMISSION: error: unable to open '[[ARCHIVE]]': [[MSG]] Labels new issue Assignees Reporter Yurii-huang os: openEuler gcc: 7.3.0 cmake: 3.16.5 ``` [1/2] Preparing lit tests [1/2] Running all regression tests -- Testing: 44875 tests, 16 workers -- Testing: 0.. 10.. 20.. 30.. 40.. 50.. 60.. 70.. FAIL: LLVM :: tools/llvm-ar/error-opening-permission.test (35951 of 44875) TEST 'LLVM :: tools/llvm-ar/error-opening-permission.test' FAILED Script: -- : 'RUN: at line 5'; rm -rf /root/rpmbuild/BUILD/llvm-13.0.1.src/x86_64-openEuler-linux-gnu/test/tools/llvm-ar/Output/error-opening-permission.test.tmp && mkdir -p /root/rpmbuild/BUILD/llvm-13.0.1.src/x86_64-openEuler-linux-gnu/test/tools/llvm-ar/Output/error-opening-permission.test.tmp : 'RUN: at line 6'; echo file1 > /root/rpmbuild/BUILD/llvm-13.0.1.src/x86_64-openEuler-linux-gnu/test/tools/llvm-ar/Output/error-opening-permission.test.tmp/1.txt : 'RUN: at line 9'; /root/rpmbuild/BUILD/llvm-13.0.1.src/x86_64-openEuler-linux-gnu/bin/llvm-ar rc /root/rpmbuild/BUILD/llvm-13.0.1.src/x86_64-openEuler-linux-gnu/test/tools/llvm-ar/Output/error-opening-permission.test.tmp/permission.b /root/rpmbuild/BUILD/llvm-13.0.1.src/x86_64-openEuler-linux-gnu/test/tools/llvm-ar/Output/error-opening-permission.test.tmp/1.txt : 'RUN: at line 10'; chmod 100 /root/rpmbuild/BUILD/llvm-13.0.1.src/x86_64-openEuler-linux-gnu/test/tools/llvm-ar/Output/error-opening-permission.test.tmp/permission.b : 'RUN: at line 11'; not /root/rpmbuild/BUILD/llvm-13.0.1.src/x86_64-openEuler-linux-gnu/bin/llvm-ar p /root/rpmbuild/BUILD/llvm-13.0.1.src/x86_64-openEuler-linux-gnu/test/tools/llvm-ar/Output/error-opening-permission.test.tmp/permission.b 2>&1 | /root/rpmbuild/BUILD/llvm-13.0.1.src/x86_64-openEuler-linux-gnu/bin/FileCheck /root/rpmbuild/BUILD/llvm-13.0.1.src/test/tools/llvm-ar/error-opening-permission.test --check-prefix=NO-PERMISSION -DARCHIVE=/root/rpmbuild/BUILD/llvm-13.0.1.src/x86_64-openEuler-linux-gnu/test/tools/llvm-ar/Output/error-opening-permission.test.tmp/permission.b -DMSG='Permission denied' -- Exit Code: 1 Command Output (stderr): -- /root/rpmbuild/BUILD/llvm-13.0.1.src/test/tools/llvm-ar/error-opening-permission.test:14:18: error: NO-PERMISSION: expected string not found in input # NO-PERMISSION: error: unable to open '[[ARCHIVE]]': [[MSG]] ^ :1:1: note: scanning from here file1 ^ :1:1: note: with "ARCHIVE" equal to "/root/rpmbuild/BUILD/llvm-13\\.0\\.1\\.src/x86_64-openEuler-linux-gnu/test/tools/llvm-ar/Output/error-opening-permission\\.test\\.tmp/permission\\.b" file1 ^ :1:1: note: with "MSG" equal to "Permission denied" file1 ^ Input file: Check file: /root/rpmbuild/BUILD/llvm-13.0.1.src/test/tools/llvm-ar/error-opening-permission.test -dump-input=help explains the following input dump. Input was: << 1: file1 check:14'0 X~ error: no match found check:14'1 with "ARCHIVE" equal to "/root/rpmbuild/BUILD/llvm-13\\.0\\.1\\.src/x86_64-openEuler-linux-gnu/test/tools/llvm-ar/Output/error-opening-permission\\.test\\.tmp/permission\\.b" check:14'2 with "MSG" equal to "Permission denied" >> -- Testing: 0.. 10.. 20.. 30.. 40.. 50.. 60.. 70.. FAIL: LLVM :: tools/llvm-dwarfdump/X86/output.s (36279 of 44875) TEST 'LLVM :: tools/llvm-dwarfdump/X86/output.s' FAILED Script: -- : 'RUN: at line 1'; rm -f /root/rpmbuild/BUILD/llvm-13.0.1.src/x86_64-openEuler-linux-gnu/test/tools/llvm-dwarfdump/X86/Output/output.s.tmp1.txt /root/rpmbuild/BUILD/llvm-13.0.1.src/x86_64-openEuler-linux-gnu/test/tools/llvm-dwarfdump/X86/Output/output.s.tmp2.txt /root/rpmbuild/BUILD/llvm-13.0.1.src/x86_64-openEuler-linux-gnu/test/tools/llvm-dwarfdump/X86/Output/output.s.tmp3.txt : 'RUN: at line 2'; /root/rpmbuild/BUILD/llvm-13.0.1.src/x86_64-openEuler-linux-gnu/bin/llvm-mc /root/rpmbuild/BUILD/llvm-13.0.1.src/test/tools/llvm-dwarfdump/X86/brief.s -filetype obj -triple x86_64-apple-darwin -o /root/rpmbuild/BUILD/llvm-13.0.1.src/x86_64-openEuler-linux-gnu/test/tools/llvm-dwarfdump/X86/Output/output.s.tmp.o : 'RUN: at line 4'; /root/rpmbuild/BUILD/llvm-13.0.1.src/x86_64-openEuler-linux-gnu/bin/llvm-dwarfdump -o=- /root/rpmbuild/BUILD/llvm-13.0.1.src/x86_64-openEuler-linux-gnu/test/tools/llvm-dwarfdump/X86/Output/output.s.tmp.o | /root/rpmbuild/BUILD/llvm-13.0.1.src/x86_64-openEuler-linux-gnu/bin/FileCheck /root/rpmbuild/BUILD/llvm-13.0.1.src/test/tools/llvm-dwarfdump/X86/output.s : 'RUN: at line 6'; /root/rpmbuild/BUILD/llvm-13.0.1.src/x86_64-openEuler-linux-gnu/bin/llvm-dwarfdump -o=/root/rpmbuild/BUILD/llvm-13.0.1.src/x86_64-openEuler-linux-gnu/test/tools/llvm-dwarfdump/X86/Output/output.s.tmp1.txt /root/rpmbuild/BUILD/llvm-13.0.1.src/x
[llvm-bugs] [Bug 115252] Missed strict aliasing optimization between structs with similar layouts
Issue
115252
Summary
Missed strict aliasing optimization between structs with similar layouts
Labels
enhancement,
c,
TBAA
Assignees
Reporter
PiJoules
Given this example:
```
typedef struct {
int i1;
} s1;
typedef struct {
int i1;
} s2_alt;
int f2(s1 *s1p, s2_alt *s2p) {
s1p->i1 = 2;
s2p->i1 = 3;
return s1p->i1 * 3;
}
```
I *think* strict aliasing rules in C should indicate that pointers to `s1` and `s2` shouldn't alias and `f2` can just directly return 6. ToT clang doesn't seem to be doing that (compiling with `-O3 -fstrict-aliasing`):
```
f2:
mov dword ptr [rdi], 2
mov dword ptr [rsi], 3
mov eax, dword ptr [rdi]
lea eax, [rax + 2*rax]
ret
```
whereas ToT gcc seems to give
```
f2:
mov DWORD PTR [rdi], 2
mov eax, 6
mov DWORD PTR [rsi], 3
ret
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115251] Replace `ObjectLinkingLayer::Plugin::notifyMaterializing`.
Issue 115251 Summary Replace `ObjectLinkingLayer::Plugin::notifyMaterializing`. Labels orcjit Assignees Reporter lhames This method was introduced in ef2389235c5de to support ELF debugging, but it's very special purpose and not otherwise a good fit for the `ObjectLinkingLayer::Plugin` interface. We should replace it with a special section, `.jitlink.original_object_content` (or something like that), which could be created by the `ELFLinkGraphBuilder`. The debug plugins could then detect this section and use it to copy out the debug content. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115250] [InstSimplify] simplifyPHINode phi fold incorrect according to alive
Issue 115250 Summary [InstSimplify] simplifyPHINode phi fold incorrect according to alive Labels new issue Assignees Reporter akshayrdeodhar When a phi has `undef` as one of the incoming values, and an SSA value as the other, and the SSA value dominates the phi, replacing the phi with the SSA value is incorrect. https://alive2.llvm.org/ce/z/7RNy3W ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115247] [DebugInfo
Issue 115247 Summary [DebugInfo Labels Assignees Reporter Michael137 ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115246] [lld] AArch64ADRPThunk::writeLong(uint8_t *): Assertion `!mayNeedLandingPad || landingPad != nullptr' failed
Issue 115246 Summary [lld] AArch64ADRPThunk::writeLong(uint8_t *): Assertion `!mayNeedLandingPad || landingPad != nullptr' failed Labels lld Assignees Reporter aeubanks [Reproducer tar](https://drive.google.com/file/d/1eCpNcknuKjzErfjcQDAYUpo3Fl-sS_7N/view?usp=sharing&resourcekey=0-vS9HRMpRA1GI5ntpxlEsvA). It's quite big (6.5GB), and I'll need to give direct access to an email for someone to download it. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115231] arm64ec incorrect mangling instantiating C++ template
Issue
115231
Summary
arm64ec incorrect mangling instantiating C++ template
Labels
new issue
Assignees
Reporter
efriedma-quic
```
template struct Wrapper {
int GetValue(void) const;
};
struct A {
int GetValue(void) const;
};
template int Wrapper::GetValue(void) const { return 3; }
template class Wrapper;
```
clang produces `?GetValue@$$h?$Wrapper@UAQEBAHXZ`, MSVC produces `?GetValue@?$Wrapper@UA$$hQEBAHXZ`. I guess the algorithm in llvm::getArm64ECMangledFunctionName is wrong.
CC @mstorsjo @cjacek @dpaoliello @steplong
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115230] `__attribute__((enable_if(...)))` checked before constraints
Issue 115230 Summary `__attribute__((enable_if(...)))` checked before constraints Labels Assignees Reporter pkasting When using `__attribute__((enable_if(...)))` with a condition that may be ill-formed, you cannot use a `requires` clause to constrain the function to only be considered in the well-formed cases, because apparently the `enable_if` condition is considered first. The workaround is to use SFINAE instead, which is ugly. Sample code: https://godbolt.org/z/x3MjWv1ET IMO, enable_if should be considered after constraint satisfaction (like with SFINAE), not before. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115222] pack indexing addition to clang makes some valid C++11 code no longer compile in C++11-23 modes
Issue
115222
Summary
pack indexing addition to clang makes some valid C++11 code no longer compile in C++11-23 modes
Labels
clang
Assignees
Reporter
pinskia
The example from https://eel.is/c++draft/diff#cpp23.dcl.dcl-2 which describes a different between C++23 and C++26:
```
template
void f(T... [1]);
template
void g(T... ptr[1]);
int main() {
f(nullptr, nullptr); // ill-formed in C++26, but for c++11-23 would be void f(int [1], double [1])
g(nullptr, nullptr); // ok
}
```
No longer compiles in clang 19 with -std=c++11 due to the addition of pack indexing.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115216] [lldb] resolving optional crashes lldb(-dap) (clang/windows/msvc)
Issue 115216 Summary [lldb] resolving optional crashes lldb(-dap) (clang/windows/msvc) Labels clang Assignees Reporter BjornSAIM When debugging from vscode/cursor using lldb-dap. the debugger will crash when trying to resolve an std::optional. switching the std::optional out with an different implementation (like Optional26 by beman) fixes the problem. link to a minimal repro: https://github.com/BjornSAIM/lldb-optional-crash just set a breakpoint anywhere after the assignment to the optional. clang/lldb/... are all on 19.1.1 Visual Studio 2022 version 17.9 ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115210] [lldb] How to disbale `process launch` loading image from local-machine?
Issue 115210 Summary [lldb] How to disbale `process launch` loading image from local-machine? Labels new issue Assignees Reporter Lioncky > While lldb launch a remote-app the `(lldb) image list` command shows load dependence from local-machine. ``` [ 0] 04A3EC8E-A50E-5236-3736-88A9B87E7B85-0DAFD322 0x00555000 C:\Users\BJ\.lldb\module_cache\remote-android\.cache\04A3EC8E-A50E-5236-3736-88A9B87E7B85-0DAFD322\HelloWorld ... [222] F1C0848B-7F4C-2E13-2979-3E79BD5EFD17 0x007fefca C:\Users\BJ\.lldb\module_cache\remote-android\.cache\F1C0848B-7F4C-2E13-2979-3E79BD5EFD17\liboplusplugin.so [223] 26254C2D-AA7A-41CA-FF29-35F579DB33C6 0x007fbc2c C:\Users\BJ\.lldb\module_cache\remote-android\.cache\26254C2D-AA7A-41CA-FF29-35F579DB33C6\libguiextimpl.so [224] AA2B86C9-D5D6-6D0D-0F15-9549804C57DF 0x007fe718 C:\Users\BJ\.lldb\module_cache\remote-android\.cache\AA2B86C9-D5D6-6D0D-0F15-9549804C57DF\android.hardware.graphics.composer3-V2-ndk.so ``` Only the excuteable image is need to be loaded. How to disable it and *do not* using local-machine cache? ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115207] What happened to #106456?
Issue 115207 Summary What happened to #106456? Labels new issue Assignees Reporter dabrahams I filed issue #106456 (clang-format: Generalize BAS_AlwaysBreak to all delimiter types) in April and it is now missing. Can anyone explain why it might be gone? I don't _think_ I put anything offensive in the issue. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115205] [libc] -Winteger-overflow in libc/test/src/math/smoke/LdExpTest.h
Issue
115205
Summary
[libc] -Winteger-overflow in libc/test/src/math/smoke/LdExpTest.h
Labels
libc
Assignees
Reporter
nickdesaulniers
building for i386:
```
[285/319] Building CXX object libc/test/src/math/smoke/CMa...smoke.ldexpl_test.__unit__.__build__.dir/ldexpl_test.cpp.o
In file included from /android0/llvm-project/libc/test/src/math/smoke/ldexpl_test.cpp:9:
/android0/llvm-project/libc/test/src/math/smoke/LdExpTest.h:53:63: warning: overflow in _expression_; result is -2'147'483'648 with type 'long' [-Winteger-overflow]
53 | long long_exp_array[4] = {LONG_MIN, INT_MIN - 1L, INT_MAX + 1L, LONG_MAX};
| ^~~~
/android0/llvm-project/libc/test/src/math/smoke/LdExpTest.h:53:49: warning: overflow in _expression_; result is 2'147'483'647 with type 'long' [-Winteger-overflow]
53 | long long_exp_array[4] = {LONG_MIN, INT_MIN - 1L, INT_MAX + 1L, LONG_MAX};
| ^~~~
/android0/llvm-project/libc/test/src/math/smoke/LdExpTest.h:53:63: warning: overflow in _expression_; result is -2'147'483'648 with type 'long' [-Winteger-overflow]
53 | long long_exp_array[4] = {LONG_MIN, INT_MIN - 1L, INT_MAX + 1L, LONG_MAX};
| ^~~~
/android0/llvm-project/libc/test/src/math/smoke/LdExpTest.h:53:49: warning: overflow in _expression_; result is 2'147'483'647 with type 'long' [-Winteger-overflow]
53 | long long_exp_array[4] = {LONG_MIN, INT_MIN - 1L, INT_MAX + 1L, LONG_MAX};
| ^~~~
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115186] Miscompiled program with `--target=wasm32`
Issue
115186
Summary
Miscompiled program with `--target=wasm32`
Labels
new issue
Assignees
Reporter
tekhnus
Here is a simple C++ program:
```
struct BigClass {
char data[40];
};
struct Class {
char big_data[40];
int value{33};
};
Class glob{};
extern "C" int _start() {
glob.value = 42;
BigClass s1{};
return glob.value;
}
```
When compiled and ran with `wasmer` runtime, it outputs "0" instead of expected "42":
```
+ clang-17 --version
clang version 17.0.6
Target: aarch64-apple-darwin23.6.0
Thread model: posix
InstalledDir: /nix/store/glzjy0xq2xhmwg6pc8c1pdk7gln127wj-clang-17.0.6/bin
+ clang-17 -std=c++20 -pedantic -Wall -Wno-unused-variable --target=wasm32 --no-standard-libraries -mbulk-memory -O0 -o main.wasm main.cpp
+ wasmer main.wasm
0
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115184] [llvm-libc] support for 64b long double (i386-linux-android)
Issue 115184 Summary [llvm-libc] support for 64b long double (i386-linux-android) Labels libc Assignees nickdesaulniers Reporter nickdesaulniers Filing an issue distinct from https://github.com/llvm/llvm-project/issues/110894. Android i386 uses `long double == double`, so `__SIZEOF_LONG_DOUBLE__` is `8`, not `12` as on i386-linux-gnu. https://developer.android.com/ndk/guides/abis#x86 https://godbolt.org/z/e35cEK4fM I'm going to explicitly error for this case in #115084, then revisit that this works as expected in a future patch. Filing a bug for the TODO. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115182] clang 19 raises operator<=>() return type to std::strong_ordering for double
Issue
115182
Summary
clang 19 raises operator<=>() return type to std::strong_ordering for double
Labels
Assignees
Reporter
pkl97
This program compiles with clang 19.1.2 but fails to compile with MSVC 19.41:
```c++
#include
class C
{
double d1;
double d2;
std::strong_ordering operator<=>(const C&) const = default;
};
int main()
{
return 0;
}
```
The MSVC error message:
> main.cpp(7): error C7549: 'C::operator <=>':
> defaulted comparison function cannot be declared to return a comparison
> category stronger than the common category among bases and members which was deduced to be 'std::partial_ordering'
In my opinion MSVC is correct because double by default only supports std::partial_ordering because of NaN values.
See also here: https://en.cppreference.com/w/cpp/utility/compare/partial_ordering
> The built-in operator<=>between floating-point values uses this ordering:
> the positive zero and the negative zero compare equivalent, but can be
> distinguished, and NaN values compare unordered with any other value.
Why does clang compile the code?
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115149] [clang] Miscompile with -O3 and -O0/1/2 since 18.1.0
Issue
115149
Summary
[clang] Miscompile with -O3 and -O0/1/2 since 18.1.0
Labels
clang
Assignees
Reporter
cardigan1008
When I compiled this code with -O0/1/2, its output is 0. However, with -O3, it returned 143:
```c
int printf(const char *, ...);
char a, b;
int c;
char *e = &b;
int f(char *g, int *k) {
char *d = g + *k;
for (; *d && *d <= ' '; d++)
;
if (*d)
return 0;
return 1;
}
int l(int g) {
char h[] = {a, a, a};
int i[] = {g};
int j = f(h, i);
return j;
}
long m() {
*e = 255;
for (; l(b + 1);)
return 0;
for (;;)
;
}
int main() {
m();
printf("%d\n", c);
}
```
Details can be found here: https://godbolt.org/z/MKW3535W6
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115175] [clang-tidy] bugprone-sizeof-expression false positives
Issue
115175
Summary
[clang-tidy] bugprone-sizeof-_expression_ false positives
Labels
clang-tidy
Assignees
Reporter
namniav
```c++
auto foo(auto t) {
return sizeof(t.val) / sizeof(t.val[0]);
}
```
https://godbolt.org/z/4qa1odf5W
> ```c++
> :2:24: warning: suspicious usage of 'sizeof(...)/sizeof(...)'; both expressions have the same type [bugprone-sizeof-_expression_]
> 2 | return sizeof(t.val) / sizeof(t.val[0]);
> | ~ ^
> 1 warning generated.
> ```
> clang version 20.0.0git (https://github.com/llvm/llvm-project.git 4d374479bea4b33c5623ccfedc0870e396fc34cd)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /opt/compiler-explorer/clang-trunk-20241106/bin
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115143] Loading a custom pass via opt in LLVM 18.1.8
Issue 115143 Summary Loading a custom pass via opt in LLVM 18.1.8 Labels new issue Assignees Reporter sec-staff-lilithgames I am a newbie here and I followed several instructions to have built the LLVM 18.1.8. And I cloned a repo from github to build and test myself.  Above is the registry module, I found none of the pass registered there has a name being called, so I added the if-else logic to name the TestMachinePass as "test". I used "cmake" to build up all of things and tried to load the TestMachinePass namely the "test" pass via opt. "opt --load-pass-plugin="./build/skeleton/SkeletonPass.dll" --passes="test" test.ll -S -o test.op.ll" but it just output the "unknown pass name 'test'. I tried to use "opt -print-passes" to print avaliable passes but there is no my pass named "test". anyone has the same problem? ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115169] [VPlan][LoopVectorize] Potential issue in how replicate recipe is lowered to IR
Issue
115169
Summary
[VPlan][LoopVectorize] Potential issue in how replicate recipe is lowered to IR
Labels
miscompilation,
vectorizers
Assignees
fhahn
Reporter
danilaml
It's a bit of a tricky one since I can no longer reproduce it on `main` due to changes in 5a4c6f97997f3cdfa9d98f7f0b546e331ee9cc4a , but I believe they didn't actually fix the underlying problem, but just made it (almost?) impossible to trigger the conditions for it.
As a workaround, I've introduced a cl opt for testing that forces replicate recipe over widen recipe so this can be triggered for regular instructions (since it's not possible to trigger it for loads after above changes):
```patch
--- a/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
+++ b/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
@@ -357,6 +357,11 @@ static cl::opt PreferPredicatedReductionSelect(
cl::desc(
"Prefer predicating a reduction operation over an after loop select."));
;
+static cl::opt ForceReplicateOverWiden(
+ "force-replicate-over-widen", cl::init(false), cl::Hidden,
+ cl::desc("Force replicate recipies over widen recipes."
+ "This flag should only be used for testing."));
+
namespace llvm {
cl::opt EnableVPlanNativePath(
"enable-vplan-native-path", cl::Hidden,
@@ -9148,8 +9153,10 @@ LoopVectorizationPlanner::tryToBuildVPlanWithVPRecipes(VFRange &Range) {
continue;
}
- VPRecipeBase *Recipe =
- RecipeBuilder.tryToCreateWidenRecipe(Instr, Operands, Range, VPBB);
+ VPRecipeBase *Recipe = nullptr;
+ if (!ForceReplicateOverWiden || isa(Instr))
+Recipe =
+ RecipeBuilder.tryToCreateWidenRecipe(Instr, Operands, Range, VPBB);
if (!Recipe)
Recipe = RecipeBuilder.handleReplication(Instr, Range);
```
With this patch and `-force-vector-width=4 -force-replicate-over-widen` options passed on a command line the following IR:
```llvm
define void @src(i1 %arg, i64 %arg1, ptr %arg2) {
bb:
br label %bb3
bb3: ; preds = %bb6, %bb
%phi = phi i64 [ %add, %bb6 ], [ 0, %bb ]
br i1 %arg, label %bb6, label %bb4
bb4: ; preds = %bb3
%load = load i32, ptr %arg2, align 8
%add5 = add i32 %load, 1
br label %bb6
bb6: ; preds = %bb4, %bb3
%phi7 = phi i32 [ %add5, %bb4 ], [ 0, %bb3 ]
%add = add i64 %phi, 1
%icmp = icmp samesign ult i64 %phi, %arg1
br i1 %icmp, label %bb3, label %bb8
bb8: ; preds = %bb6
%phi9 = phi i32 [ %phi7, %bb6 ]
ret void
}
```
Gets optimized to
```llvm
define void @src(i1 %arg, i64 %arg1, ptr %arg2) {
bb:
%0 = add i64 %arg1, 1
%min.iters.check = icmp ult i64 %0, 4
br i1 %min.iters.check, label %scalar.ph, label %vector.ph
vector.ph: ; preds = %bb
%n.mod.vf = urem i64 %0, 4
%n.vec = sub i64 %0, %n.mod.vf
%broadcast.splatinsert = insertelement <4 x i1> poison, i1 %arg, i64 0
%broadcast.splat = shufflevector <4 x i1> %broadcast.splatinsert, <4 x i1> poison, <4 x i32> zeroinitializer
br label %vector.body
vector.body: ; preds = %pred.load.continue6, %vector.ph
%index = phi i64 [ 0, %vector.ph ], [ %index.next, %pred.load.continue6 ]
%1 = xor <4 x i1> %broadcast.splat,
%2 = extractelement <4 x i1> %1, i32 0
br i1 %2, label %pred.load.if, label %pred.load.continue
pred.load.if: ; preds = %vector.body
%3 = load i32, ptr %arg2, align 8
br label %pred.load.continue
pred.load.continue: ; preds = %pred.load.if, %vector.body
%4 = phi i32 [ poison, %vector.body ], [ %3, %pred.load.if ]
%5 = extractelement <4 x i1> %1, i32 1
br i1 %5, label %pred.load.if1, label %pred.load.continue2
pred.load.if1: ; preds = %pred.load.continue
%6 = load i32, ptr %arg2, align 8
br label %pred.load.continue2
pred.load.continue2: ; preds = %pred.load.if1, %pred.load.continue
%7 = phi i32 [ poison, %pred.load.continue ], [ %6, %pred.load.if1 ]
%8 = extractelement <4 x i1> %1, i32 2
br i1 %8, label %pred.load.if3, label %pred.load.continue4
pred.load.if3: ; preds = %pred.load.continue2
%9 = load i32, ptr %arg2, align 8
br label %pred.load.continue4
pred.load.continue4: ; preds = %pred.load.if3, %pred.load.continue2
%10 = phi i32 [ poison, %pred.load.continue2 ], [ %9, %pred.load.if3 ]
%11 = extractelement <4 x i1> %1, i32 3
br i1 %11, label %pred.load.if5, label %pred.load.continue6
pred.load.if5: ; preds = %pred.load.continue4
%12 = load i32, ptr %arg2, align 8
br label %pred.load.continue6
pred.load.continue6: ; preds = %pred.load.if5, %pred.load.continue4
%13 = phi i32 [ poison, %pred.load.continue4 ], [ %12, %pred.load.if5 ]
%14 = add i32 %4, 1
%15 = add i32 %7, 1
%16 = add i32 %10, 1
%17 = add i32 %13, 1
%18 = insertelement <4 x i32> poison, i32 %14, i32 0
%19 = insertelement <4 x i32> %18, i32 %15, i32 1
%20 = insertelement <4 x i32> %19, i32 %16, i32 2
%21 = insertelement <4 x i32> %20, i32 %17, i32 3
[llvm-bugs] [Bug 115154] [BOLT] Lack of support for noreturn functions results in incorrect CFG generation.
Issue
115154
Summary
[BOLT] Lack of support for noreturn functions results in incorrect CFG generation.
Labels
BOLT
Assignees
Reporter
bgergely0
BOLT does not have support for noreturn functions. Because of this, BOLT assumes that the call to the noreturn function will return, and execution will continue, and adds the following BasicBlock to the successors list.
Take this example:
```c++
#include
__attribute__((noinline, noreturn)) void my_error() {
std::abort();
}
int main() {
int a = 10;
if (a < 20) {
my_error();
} else {
std::cout << a << std::endl;
}
return 0;
}
```
Compile it:
```bash
clang++ --target=aarch64-linux-gnu -Wl,--emit-relocs main.cpp -o noreturn_main
```
(I am compiling for aarch64, but the issue is the same regardless of the architecture).
Looking at the BasicBlocks:
BB containing the call to `my_error`
```asm
: bl _Z8my_errorv
```
The following BB, which is in the successors list:
```asm
: ldr w1, [sp, #0x8]
: adrpx0, __BOLT_got_zero+65536
: ldr x0, [x0, :lo12:__BOLT_got_zero+4032]
: bl _ZNSolsEi@PLT
: adrpx1, __BOLT_got_zero+65536
: ldr x1, [x1, :lo12:__BOLT_got_zero+4016]
: bl _ZNSolsEPFRSoS_E@PLT
: b .Ltmp7
```
This is after the call to `my_error`, but it should not be in the successors list.
We can also look at the disassembly of the whole main function:
```asm
0a60 :
a60: d10083ff sub sp, sp, #0x20
a64: a9017bfdstp x29, x30, [sp, #16]
a68: 910043fdadd x29, sp, #0x10
a6c: b81fc3bf sturwzr, [x29, #-4]
a70: 52800148mov w8, #0xa // #10
a74: b9000be8str w8, [sp, #8]
a78: b9400be8ldr w8, [sp, #8]
a7c: 71005108subs w8, w8, #0x14
a80: 546ab.gea8c // b.tcont.// < jump to BB after the BL my_error
a84: 1401 b a88
a88: 97f3bl a54 <_Z8my_errorv>
a8c: b9400be1ldr w1, [sp, #8]
a90: 9080adrpx0, 1 <__FRAME_END__+0xf3cc>
a94: f947e000 ldr x0, [x0, #4032]
a98: 977abl 880 <_ZNSolsEi@plt>
a9c: 9081adrpx1, 1 <__FRAME_END__+0xf3cc>
aa0: f947d821ldr x1, [x1, #4016]
aa4: 9767bl 840 <_ZNSolsEPFRSoS_E@plt>
aa8: 1401 b aac
aac: 2a1f03e0mov w0, wzr
ab0: a9417bfdldp x29, x30, [sp, #16]
ab4: 910083ff add sp, sp, #0x20
ab8: d65f03c0ret
```
We can see that the BB starting at `a8c` is the target of a conditional jump, and it is placed under the `BL` by the compiler on the assumption, that `my_error` does not return.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115166] LLDB crashed with Assertion failed in function GetMaxU64 of file lldb/source/Utility/DataExtractor.cpp
Issue
115166
Summary
LLDB crashed with Assertion failed in function GetMaxU64 of file lldb/source/Utility/DataExtractor.cpp
Labels
new issue
Assignees
Reporter
iamanonymouscs
`$ clang --version`
clang version 16.0.0 (https://mirror.nju.edu.cn/git/llvm-project.git 08d094a0e457360ad8b94b017d2dc277e697ca76)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/llvm-08d094a/bin
`$ lldb --version`
lldb version 16.0.0 (https://mirror.nju.edu.cn/git/llvm-project.git revision 08d094a0e457360ad8b94b017d2dc277e697ca76)
clang revision 08d094a0e457360ad8b94b017d2dc277e697ca76
llvm revision 08d094a0e457360ad8b94b017d2dc277e697ca76
`$ cat small.c`
```
#define NITER 4
#define NVARS 20
#define MULTI(X) \
X( 0), X( 1), X( 2), X( 3), X( 4), X( 5), X( 6), X( 7), X( 8), X( 9), \
X(10), X(11), X(12), X(13), X(14), X(15), X(16), X(17), X(18), X(19)
#define DECLAREI(INDEX) inc##INDEX = incs[INDEX]
#define DECLAREF(INDEX) *ptr##INDEX = ptrs[INDEX], result##INDEX = 0
#define LOOP(INDEX) result##INDEX += *ptr##INDEX, ptr##INDEX += inc##INDEX
#define COPYOUT(INDEX) results[INDEX] = result##INDEX
float *ptrs[NVARS];
float results[NVARS];
int incs[NVARS];
void __attribute__((noinline))
foo (int n)
{
int MULTI (DECLAREI);
float MULTI (DECLAREF);
while (n--)
MULTI (LOOP);
MULTI (COPYOUT);
}
float input[NITER * NVARS];
int
main (void)
{
int i;
for (i = 0; i < NVARS; i++)
ptrs[i] = input + i, incs[i] = i;
for (i = 0; i < NITER * NVARS; i++)
input[i] = i;
foo (NITER);
for (i = 0; i < NVARS; i++)
if (results[i] != i * NITER * (NITER + 1) / 2)
return 1;
return 0;
}
```
`$ cat script.py`
```
# cat script.py
import pickle
def fstep(debugger, command, result, internal_dict):
args = command.split()
step = args[0] if args else 'step'
target = debugger.GetSelectedTarget()
process = target.GetProcess()
thread = process.GetSelectedThread()
target_name = target.GetExecutable().GetFilename()
enter_flag = False
while process.is_alive:
frame = thread.GetSelectedFrame()
if frame.IsValid():
module = frame.GetModule()
if module.IsValid():
module_name = module.GetFileSpec().GetFilename()
if target_name != module_name:
if not enter_flag:
enter_flag = True
if step == 'step':
thread.StepOver()
else:
thread.StepInstruction(False)
else:
enter_flag = False
thread.StepOut()
continue
line_entry = frame.GetLineEntry()
if line_entry.IsValid() and line_entry.GetFileSpec().IsValid():
file = line_entry.file.fullpath
line = line_entry.line
column = line_entry.column
address = hex(frame.GetPC())
varvalue = {f"({var.type}){var.name}": var.value for var in frame.GetVariables(True, True, True, True)}
if step == 'step':
thread.StepOver()
else:
thread.StepInstruction(False)
else:
break
```
`$ clang -Og -g small.c`
`$ lldb a.out`
```
(lldb) target create "a.out"
Current executable set to '/home/devil/a.out' (x86_64).
(lldb) command script import script.py
(lldb) command script add -f script.fstep fstep
(lldb) b main
Breakpoint 1: where = a.out`main + 32 at small.c:34:5, address = 0x16f0
(lldb) run
Process 26967 launched: '/home/devil/a.out' (x86_64)
Process 26967 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
frame #0: 0x56f0 a.out`main at small.c:34:5
31 int i;
32
33 for (i = 0; i < NVARS; i++)
-> 34 ptrs[i] = input + i, incs[i] = i;
35 for (i = 0; i < NITER * NVARS; i++)
36 input[i] = i;
37 foo (NITER);
(lldb) fstep stepi
Assertion failed: (byte_size > 0 && byte_size <= 8 && "GetMaxU64 invalid byte_size!"), function GetMaxU64, file /home/overhead/llvm-project/lldb/source/Utility/DataExtractor.cpp, line 526
backtrace leading to the failure:
#0 0x7f8c51f6b6f6 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/usr/local/llvm-08d094a/bin/../lib/liblldb.so.16+0x18c96f6)
#1 0x7f8c51a74f9c lldb_private::lldb_assert(bool, char const*, char const*, char const*, unsigned int) (/usr/local/llvm-08d094a/bin/../lib/liblldb.so.16+0x13d2f9c)
#2 0x7f8c51a6d6c4 lldb_private::DataExtractor::GetAddress(unsigned long*) const (/usr/local/llvm-08d094a/bin/../lib/liblldb.so.16+0x13cb6c4)
#3 0x7f8c51864578 DerefSizeExtractDataHelper(unsigned char*, unsigned long, lldb
[llvm-bugs] [Bug 115158] Missed optimization: `udiv` and `urem` ignores assumptions, that can help to choose either 'DIV r/m32' or 'DIV r/m64' on x86-64.
Issue
115158
Summary
Missed optimization: `udiv` and `urem` ignores assumptions, that can help to choose either 'DIV r/m32' or 'DIV r/m64' on x86-64.
Labels
new issue
Assignees
Reporter
zheland
Currently `udiv i64 i32` compiles to a preudocode like: `if dividend <= u32::MAX { DIV r/m32 } else { DIV r/m64 }`.
That's great because `DIV r/m32` is typically faster than `DIV r/m64`.
However, in some cases LLVM could compile directly to the optimal variant using specified assumptions.
Examples:
- `udiv i64 i32` should use `DIV r/m64` if the compiler provides the assumption that the dividend won't fit into 32-bit register.
- `udiv i64 i32` should use `DIV r/m32` if the compiler provides the assumption that the quotient will fit into 32-bit register.
Same is applicable for all `udiv`, `sdiv`, `urem`, `srem`, and `div_rem` operations.
Same is applicable for `udiv i32 i16` with choosing between 'DIV r/m16' or 'DIV r/m32' (on x86).
Same is applicable for `udiv i64 i64` and `udiv i128 i64` with choosing between 'DIV r/m64' or (`__udivti3` and `__umodti3`) (see https://github.com/llvm/llvm-project/issues/6769).
As far as I understand it is problematic to optimize such a thing in the language compiler (Clang or Rust) because the LLVM does not provide asymmetric division instructions with different dividend and divisor and quotient types.
### Example on C
https://godbolt.org/z/j3c9KP7cx
```c
#include
#define uint128_t __uint128_t
// Optimized.
uint32_t div_u64_u32_default(uint64_t dividend, uint32_t divisor) {
return (uint32_t)(dividend / (uint64_t)divisor);
}
// Optimized.
uint32_t div_u64_u32_if_div_le_u32_max(uint64_t dividend, uint32_t divisor) {
if (dividend <= (uint64_t)UINT32_MAX) {
return (uint32_t)(dividend / (uint64_t)divisor);
} else {
__builtin_unreachable();
}
}
// Missed optimization.
uint32_t div_u64_u32_if_div_gt_u32_max(uint64_t dividend, uint32_t divisor) {
if (dividend > (uint64_t)UINT32_MAX) {
return (uint32_t)(dividend / (uint64_t)divisor);
} else {
__builtin_unreachable();
}
}
// Missed optimization.
uint32_t div_u64_u32_if_quot_le_u32_max(uint64_t dividend, uint32_t divisor) {
if ((uint32_t)(dividend >> 32) < divisor) {
return (uint32_t)(dividend / (uint64_t)divisor);
} else {
__builtin_unreachable();
}
}
// Optimized.
uint64_t div_u128_u64_default(uint128_t dividend, uint64_t divisor) {
return (uint64_t)(dividend / (uint128_t)divisor);
}
// Optimized.
uint64_t div_u128_u64_if_div_le_u64_max(uint128_t dividend, uint64_t divisor) {
if (dividend <= (uint128_t)UINT32_MAX) {
return (uint64_t)(dividend / (uint128_t)divisor);
} else {
__builtin_unreachable();
}
}
// Missed optimization.
uint64_t div_u128_u64_if_quot_le_u64_max(uint128_t dividend, uint64_t divisor) {
if ((uint64_t)(dividend >> 64) < divisor) {
return (uint64_t)(dividend / (uint128_t)divisor);
} else {
__builtin_unreachable();
}
}
```
Similar example on Rust (click to expand)
https://godbolt.org/z/3qd6qMd7s
```rust
use std::hint::assert_unchecked;
// Optimized.
#[no_mangle]
pub fn div_u64_u32_default(dividend: u64, divisor: u32) -> u32 {
unsafe { assert_unchecked(divisor > 0) };
(dividend / divisor as u64) as u32
}
// Optimized.
#[no_mangle]
pub fn div_u64_u32_if_div_le_u32_max(dividend: u64, divisor: u32) -> u32 {
unsafe { assert_unchecked(divisor > 0) };
unsafe { assert_unchecked(dividend <= u32::MAX as u64) };
(dividend / divisor as u64) as u32
}
// Missed optimization.
#[no_mangle]
pub fn div_u64_u32_if_div_gt_u32_max(dividend: u64, divisor: u32) -> u32 {
unsafe { assert_unchecked(divisor > 0) };
unsafe { assert_unchecked(dividend > u32::MAX as u64) };
(dividend / divisor as u64) as u32
}
// Missed optimization.
#[no_mangle]
pub fn div_u64_u32_if_quot_le_u32_max(dividend: u64, divisor: u32) -> u32 {
unsafe { assert_unchecked(divisor > 0) };
unsafe { assert_unchecked(((dividend >> 32) as u32) < divisor) };
(dividend / divisor as u64) as u32
}
// Optimized.
#[no_mangle]
pub fn div_u128_u64_default(dividend: u128, divisor: u64) -> u64 {
unsafe { assert_unchecked(divisor > 0) };
(dividend / divisor as u128) as u64
}
// Optimized.
#[no_mangle]
pub fn div_u128_u64_if_div_le_u64_max(dividend: u128, divisor: u64) -> u64 {
unsafe { assert_unchecked(divisor > 0) };
unsafe { assert_unchecked(dividend <= u64::MAX as u128) };
(dividend / divisor as u128) as u64
}
// Missed optimization.
#[no_mangle]
pub fn div_u128_u64_if_quot_le_u64_max(dividend: u128, divisor: u64) -> u64 {
unsafe { assert_unchecked(divisor > 0) };
unsafe { assert_unchecked(((dividend >> 64) as u64) < divisor) };
(dividend / divisor as u128) as u64
}
```
### Produced assembly
`x86-64 clang (trunk)` `-O
[llvm-bugs] [Bug 115137] Analyzer warns about an uninitialized value on a structured binding captured in a lambda
Issue
115137
Summary
Analyzer warns about an uninitialized value on a structured binding captured in a lambda
Labels
new issue
Assignees
Reporter
KitsuneRal
In C++17, structured bindings could not be immediately captured in lambdas; in C++20 they can but Clang analyzer didn't seem to catch up with this. This small program:
```cplusplus
#include
#include
int main()
{
std::tuple t{ 1 };
auto&& [a] = t;
[a] {
std::cout << a << std::endl;
}();
}
```
triggers an uninitialised value warning inside the lambda, as can be seen at https://godbolt.org/z/sPsW4Pnr4.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115133] [AArch64][GlobalISel] Overall GISel operation status
Issue 115133 Summary [AArch64][GlobalISel] Overall GISel operation status Labels backend:AArch64, llvm:globalisel Assignees Reporter davemgreen This is a copy of an internal page me and @chuongg3 had when going through each of the operations for AArch64 GISel, making sure they don't fall back. Not all of it is complete yet (and the internal version had a few more details), but it is better to have this upstream. Some of it might now be out of date. A few high level comments - This does not include SVE, we should probably do the same elsewhere. - BF16 still needs to be added, but requires a new way to specify the types / operations. - BigEndian isn't handled yet. - Currently some operations widen, some promote. We should stick to one (probably widen). - Blank spaces usually mean not checked / not supported. We will get to the point where random-testing will start to be more useful. Legend: - Scalar normal = i8/i16/i32/i64 - Vector legal = v8i8/v4i16/v2i32 + v16i8/v8i16/v4i32/v2i64 - Vector larger/smaller = i8/i16/i32/i64 types with non-legal sizes - i128 = scalar/vector - i1 = scalar/vector - Scalar ext = non-power2 sizes, including larger sizes - Vector odd widths = i8/i16/i32/i64 with non-power-2 widths. - Vector odd eltsize = non-power2 elt sizes (or i128, etc). |Operation| Scalar normal| Vector legal| i128| i1 | Vector larger / smaller| Scalar ext| Vector odd widths| Vector odd eltsizes| Additional Notes | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | |load| y | y | | | | | | | |store| y | y | | | | | | | |bitcast? ptrtoint? inttoptr?| y | y | | | | | | | |memcpy? memmove? memset? bzero?| | | | | | | | | |Int Operation| Scalar normal| Vector normal| i128 s/v| i1 s/v| Vector larger / smaller| Scalar non-power-2| Vector odd widths| Vector odd eltsizes| Additional Notes |add| y| y| y/y | | y| y| x | x | https://godbolt.org/z/6c1rfWTK8 |sub| y| y| y/y | | y| y| x | x | |mul| y| y| y/y inefficient | | y| | | | Scalar i128 could be better. https://godbolt.org/z/8Wd8zhezc |sdiv, udiv| y| y| y/y | | y| | | | Scalar i1 could be simpler. https://godbolt.org/z/45qMq6cvh. |srem, urem| y| y| y/y| | y| | | | Scalar i1: |zext, sext, anyext| y| y| | | | | | | ZEXT: Global ISel could be improved to match SDAG by using BIC for |trunc| y| y| y| | | | x Non-pow2 larger than 8| | |and| y| y| y/y | | y| | | | https://godbolt.org/z/6Y98TnYv8 |or| y| y| y/y | | y| | | | |xor| y| y| y/y | | y| | | | | not?| y| y| y| | y| | | | https://godbolt.org/z/rh4ob1be7 |shl| y| y| y| | y (v2i8)| | | x| Scalar i8/i16 unnecessarily clear shift amount. i1 could simplify. |ashr| y| y| y| | y(v2i8)| | | x| Scalar i8/i16 unnecessarily clear shift amount. i1 could simplify. |lshr| y| y| y| | y(v2i8)| | | x| Scalar i8/i16 unnecessarily clear shift amount. i1 could simplify. |icmp| y| y| y (i128 could be better)| x | y(v2i8)| | | | i128 could do a lot better. |select| y| y| y| | y (v2i8)| | | | Scalarl: Unnecessary AND to clear upper lanes of the condition register |abs| y| y| y| | x| y| | | https://godbolt.org/z/Tobs7YeoT |smin/smax/umin/umax| y| y| y| | y| x > i128| | | i1/i128 could do better. https://godbolt.org/z/j7nx789oz. |uaddsat/usubsat/saddsat/ssubsat| y| y| y| | | y| | | https://godbolt.org/z/4MT14bfsv |bitreverse| y| x| y| | | y| | | https://godbolt.org/z/3sd988Mhd |bswap| y| x| y| | x| y| | | |ctlz| y| y| y| | y| x > i128| | | |cttz| y| y| y| | x| x > i128| | | |ctpop| y| y| y| | x| x| | | |fshr/fshl| y| y| y| | x| x NonPow2 > 128| | | Scalar Normal: | rotr/rotl?| y| y| y| | y| y| | | |uaddo, usubo, uadde, usube?| | | | | | | | | |umulo, smulo?| | | | | | | | | |umulh, smulh| | | | | | | | | |ushlsat, sshlsat| | | | | | | | | |smulfix, umulfix| | | | | | | | | |smulfixsat, umulfixsat| | | | | | | | | |sdivfix, udivfix| | | | | | | | | |sdivfixsat, udivfixsat| | | | | | | | | |FP Operation| Scalar normal| Vector legal| f128 s/v| | Vector smaller / larger| bf16 s/v| Vector widths| | Additional Notes |fadd| y| y| y/y| | y| | | | https://godbolt.org/z/bYWfo9v16 |fsub| y| y| y/y| | y| | | | |fmul| y| y| y/y| | y| | | | |fma| y| y| y/y| | y| | | | https://godbolt.org/z/1osE3Whaq |fmuladd| y| y| y/y| | y| | | | |fdiv| y| y| y/y| | y| | | | |frem| y| y| y/y| | y| | | | |fneg| y| y| y/y| | y| | | | https://godbolt.org/z/rz96eh3PW |fpext| y | y | y/y| | y | | | | https://godbolt.org/z/358EG4j7r |fptrunc| y | y| y/y| | y | | | | https://godbolt.org/z/7a7hq6j68 |fptosi, fptoui| y| y| y/y| | y | | | | |fptosisat, fptouisat| | | | | | | | | |sitofp, uitofp| y| y| y/y| | y| | | | https://godbolt.org/z/j7Prz7qj6 |fabs| y| y| y/y| | y| | | | https://godbolt.org/z/o95h4a9es |fsqrt| y| y| y/y| | y| | | | |ceil, floor, trunc, rint, nearbyint| y| y| y/y| | y| | | |
[llvm-bugs] [Bug 115134] The building proccess keeps crashing.
Issue 115134 Summary The building proccess keeps crashing. Labels Assignees Reporter AugustineYang OS: Ubuntu Linux 22.04 GCC&G++: 11.4.0 CMake: 3.22.1 Hardware: i7-12700K with 64GB RAM I'm trying to build llvm 19.1.0 from the source code following the instruction in [Getting Started with the LLVM System](https://llvm.org/docs/GettingStarted.html). I "make" the project with the command `cmake -S llvm -B build -G Ninja -DLLVM_ENABLE_PROJECTS=all -DCMAKE_BUILD_TYPE=Debug -DLLVM_ENABLE_RUNTIME=all -DCMAKE_C_COMPILER=/usr/bin/gcc-11 -DCMAKE_CXX_COMPILER=/usr/bin/g++-11`. I "build" the project with the command `cmake --build build -j16`, But I'm facing steadily crashes after building about 7,000 of over 13,000 tasks with TOTALLY NO error message. The terminal window just crashed and disappeared with no error message or OS error report. Or the VSCode window just crashed if I'm using the integreted terminal of the VSCode. The crash follows a sudden decrease of the CPU usage. "Build" can continue in a new terminal window, but the crash will happen again after about 200 tasks. Changing the GCC compiler to 12.3.0 makes no difference. Does anyone face the same issue? ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115129] compiler-rt/s390x: `error: out-of-line definition of 'patchFunctionEntry' does not match any declaration in namespace '__xray'`
Issue 115129 Summary compiler-rt/s390x: `error: out-of-line definition of 'patchFunctionEntry' does not match any declaration in namespace '__xray'` Labels compiler-rt, backend:SystemZ, build-problem Assignees Reporter sylvestre On ubuntu lunar s390x: https://llvm-jenkins.debian.net/job/llvm-toolchain-lunar-binaries/architecture=s390x,distribution=lunar,label=s390x/1039/console ``` ib/linux/libclang_rt.asan-s390x.a [3/50] Building CXX object compiler-rt/lib/xray/CMakeFiles/RTXray.s390x.dir/xray_s390x.cpp.o FAILED: compiler-rt/lib/xray/CMakeFiles/RTXray.s390x.dir/xray_s390x.cpp.o /build/source/build-llvm/tools/clang/stage2-bins/./bin/clang++ --target=s390x-linux-gnu -DSANITIZER_COMMON_NO_REDEFINE_BUILTINS -DXRAY_HAS_EXCEPTIONS=1 -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/build/source/compiler-rt/lib/xray/.. -I/build/source/compiler-rt/lib/xray/../../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 -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wmisleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color -ffunction-sections -fdata-sections -ffile-prefix-map=/build/source/build-llvm/tools/clang/stage2-bins/runtimes/runtimes-bins=../../../../../../ -ffile-prefix-map=/build/source/= -no-canonical-prefixes -Wall -Wno-unused-parameter -O2 -DNDEBUG -g1 -fPIC -fno-builtin -fno-exceptions -fomit-frame-pointer -funwind-tables -fno-stack-protector -fno-sanitize=safe-stack -fvisibility=hidden -fno-lto -Wthread-safety -Wthread-safety-reference -Wthread-safety-beta -O3 -gline-tables-only -Wno-gnu -Wno-variadic-macros -Wno-c99-extensions -ftrivial-auto-var-init=pattern -Wno-format -fno-rtti -std=c++17 -MD -MT compiler-rt/lib/xray/CMakeFiles/RTXray.s390x.dir/xray_s390x.cpp.o -MF compiler-rt/lib/xray/CMakeFiles/RTXray.s390x.dir/xray_s390x.cpp.o.d -o compiler-rt/lib/xray/CMakeFiles/RTXray.s390x.dir/xray_s390x.cpp.o -c /build/source/compiler-rt/lib/xray/xray_s390x.cpp /build/source/compiler-rt/lib/xray/xray_s390x.cpp:20:14: error: out-of-line definition of 'patchFunctionEntry' does not match any declaration in namespace '__xray' 20 | bool __xray::patchFunctionEntry(const bool Enable, uint32_t FuncId, | ^~ /build/source/compiler-rt/lib/xray/xray_s390x.cpp:44:14: error: out-of-line definition of 'patchFunctionExit' does not match any declaration in namespace '__xray' 44 | bool __xray::patchFunctionExit(const bool Enable, uint32_t FuncId, | ^ /build/source/compiler-rt/lib/xray/xray_s390x.cpp:68:14: error: out-of-line definition of 'patchFunctionTailExit' does not match any declaration in namespace '__xray' 68 | bool __xray::patchFunctionTailExit(const bool Enable, const uint32_t FuncId, | ^ /build/source/compiler-rt/lib/xray/xray_s390x.cpp:71:10: error: no matching function for call to 'patchFunctionExit' 71 | return patchFunctionExit(Enable, FuncId, Sled); | ^ /build/source/compiler-rt/lib/xray/xray_interface_internal.h:144:6: note: candidate function not viable: requires 4 arguments, but 3 were provided 144 | bool patchFunctionExit(bool Enable, uint32_t FuncId, const XRaySledEntry &Sled, | ^ 145 | const XRayTrampolines &Trampolines); | ~~ 4 errors generated. ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 115123] [CorrelatedPropagation] `and X, C` wrongly replaced to `X (!range ...)`
Issue
115123
Summary
[CorrelatedPropagation] `and X, C` wrongly replaced to `X (!range ...)`
Labels
Assignees
Reporter
bongjunj
https://github.com/llvm/llvm-project/blob/84ce230e4298672bb5247170d6183b31aa06fc4b/llvm/lib/Transforms/Scalar/CorrelatedValuePropagation.cpp#L1181-L1202
LHS could be `undef`.
Alive2 report: https://alive2.llvm.org/ce/z/7aNRWo
```llvm
define i16 @foo.2(i16 %x) {
#0:
%#1 = mul i16 %x, 65535
%t1 = and i16 %x, %#1
%t2 = zext i16 %t1 to i32
%t3 = icmp ult i32 %t2, 255
%t4 = select i1 %t3, i32 %t2, i32 255
%t5 = trunc i32 %t4 to i16
%t6 = and i16 %t5, 255
ret i16 %t6
}
=>
define i16 @foo.2(i16 %x) {
#0:
%#1 = mul i16 %x, 65535
%t1 = and i16 %x, %#1
%t2 = zext i16 %t1 to i32
%t3 = icmp ult i32 %t2, 255
%t4 = select i1 %t3, i32 %t2, i32 255
%t5 = trunc i32 %t4 to i16
%#range_0_%t5 = !range i16 %t5, i16 0, i16 256
ret i16 %#range_0_%t5
}
Transformation doesn't verify!
ERROR: Target is more poisonous than source
Example:
i16 %x = undef
Source:
i16 %#1 = #x (0) [based on undef value]
i16 %t1 = #x (0)
i32 %t2 = #x (0)
i1 %t3 = #x1 (1)
i32 %t4 = #x (0) [based on undef value]
i16 %t5 = #x (0)
i16 %t6 = #x (0)
Target:
i16 %#1 = #x (0)
i16 %t1 = #x (0)
i32 %t2 = #x (0)
i1 %t3 = #x1 (1)
i32 %t4 = #x7fff (32767)
i16 %t5 = #x7fff (32767)
i16 %#range_0_%t5 = poison
Source value: #x (0)
Target value: poison
define i16 @foo.3(i16 %x) {
#0:
%#1 = add i16 %x, 255
%t2 = zext i16 %#1 to i32
%t3 = icmp ult i32 %t2, 255
%t4 = select i1 %t3, i32 %t2, i32 255
%t5 = trunc i32 %t4 to i16
%t6 = and i16 %t5, 255
ret i16 %t6
}
=>
define i16 @foo.3(i16 %x) {
#0:
%#1 = add i16 %x, 255
%t2 = zext i16 %#1 to i32
%t3 = icmp ult i32 %t2, 255
%t4 = select i1 %t3, i32 %t2, i32 255
%t5 = trunc i32 %t4 to i16
%#range_0_%t5 = !range i16 %t5, i16 0, i16 256
ret i16 %#range_0_%t5
}
Transformation doesn't verify!
ERROR: Target is more poisonous than source
Example:
i16 %x = undef
Source:
i16 %#1 = #x00ff (255) [based on undef value]
i32 %t2 = #x00ff (255)
i1 %t3 = #x0 (0)
i32 %t4 = #x00ff (255)
i16 %t5 = #x00ff (255)
i16 %t6 = #x00ff (255)
Target:
i16 %#1 = #x007f (127)
i32 %t2 = #x007f (127)
i1 %t3 = #x1 (1)
i32 %t4 = #x0100 (256)
i16 %t5 = #x0100 (256)
i16 %#range_0_%t5 = poison
Source value: #x00ff (255)
Target value: poison
define i16 @foo.4(i16 %x) {
#0:
%#1 = add i16 %x, 255
%#2 = sext i16 %#1 to i32
%t3 = icmp ult i32 %#2, 255
%t4 = select i1 %t3, i32 %#2, i32 255
%t5 = trunc i32 %t4 to i16
%t6 = and i16 %t5, 255
ret i16 %t6
}
=>
define i16 @foo.4(i16 %x) {
#0:
%#1 = add i16 %x, 255
%#2 = sext i16 %#1 to i32
%t3 = icmp ult i32 %#2, 255
%t4 = select i1 %t3, i32 %#2, i32 255
%t5 = trunc i32 %t4 to i16
%#range_0_%t5 = !range i16 %t5, i16 0, i16 256
ret i16 %#range_0_%t5
}
Transformation doesn't verify!
ERROR: Target is more poisonous than source
Example:
i16 %x = undef
Source:
i16 %#1 = #x00ff (255) [based on undef value]
i32 %#2 = #x00ff (255)
i1 %t3 = #x0 (0)
i32 %t4 = #x00ff (255)
i16 %t5 = #x00ff (255)
i16 %t6 = #x00ff (255)
Target:
i16 %#1 = #x007f (127)
i32 %#2 = #x007f (127)
i1 %t3 = #x1 (1)
i32 %t4 = #x0100 (256)
i16 %t5 = #x0100 (256)
i16 %#range_0_%t5 = poison
Source value: #x00ff (255)
Target value: poison
Summary:
0 correct transformations
3 incorrect transformations
0 failed-to-prove transformations
0 Alive2 errors
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
