[llvm-bugs] [Bug 128622] LLVM fails to optimize (a & b) + (a & b) + (a ^ b) down to a + b
Issue 128622 Summary LLVM fails to optimize (a & b) + (a & b) + (a ^ b) down to a + b Labels new issue Assignees Reporter johnplatts According to a snippet over at https://alive2.llvm.org/ce/z/w7xLPL, LLVM fails to optimize `(a & b) + (a & b) + (a ^ b)` down to ` a + b`. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128627] libc++ hardening mode doesn't detect
Issue
128627
Summary
libc++ hardening mode doesn't detect
Labels
libc++
Assignees
Reporter
thesamesam
Noticed when reading https://jacko.io/smart_pointers.html.
libc++'s hardening mode doesn't detect the following, even with `-D_LIBCPP_HARDENING_MODE=_LIBCPP_HARDENING_MODE_DEBUG`, while `-D_GLIBCXX_DEBUG` (though not `-D_GLIBCXX_ASSERTIONS` does):
```c++
#include
int main() {
std::vector my_vector = {1, 2, 3};
for (auto element : my_vector) {
if (element == 2) {
my_vector.push_back(4);
/* The next loop iteration reads a dangling pointer. */
}
}
}
```
godbolt: https://godbolt.org/z/jKaYPY3vb
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128650] AMDGPU GlobalIsel mishandles readfirstlane lowering with 64-bit element vectors
Issue 128650 Summary AMDGPU GlobalIsel mishandles readfirstlane lowering with 64-bit element vectors Labels backend:AMDGPU, llvm:globalisel, crash-on-valid Assignees vikramRH Reporter arsenm d7903c9f28bdfd17fcc2d5be1096c504b6a94ec1 added commented out tests which fail with globalisel. The vector construction assumes 32-bit elements: ``` RUN: at line 3: /Users/matt/src/llvm-project/build_rel_with_debinfo/bin/llc -mtriple=amdgcn--amdhsa -mcpu=fiji -verify-machineinstrs -global-isel -global-isel-abort=2 < /Users/matt/src/llvm-project/llvm/test/CodeGen/AMDGPU/llvm.amdgcn.readfirstlane.ll | /Users/matt/src/llvm-project/build_rel_with_debinfo/bin/FileCheck -check-prefix=CHECK-GISEL -enable-var-scope /Users/matt/src/llvm-project/llvm/test/CodeGen/AMDGPU/llvm.amdgcn.readfirstlane.ll + /Users/matt/src/llvm-project/build_rel_with_debinfo/bin/llc -mtriple=amdgcn--amdhsa -mcpu=fiji -verify-machineinstrs -global-isel -global-isel-abort=2 + /Users/matt/src/llvm-project/build_rel_with_debinfo/bin/FileCheck -check-prefix=CHECK-GISEL -enable-var-scope /Users/matt/src/llvm-project/llvm/test/CodeGen/AMDGPU/llvm.amdgcn.readfirstlane.ll # After Legalizer # Machine code for function test_readfirstlane_v2i64: IsSSA, TracksLiveness, Legalized Function Live Ins: $sgpr4_sgpr5 in %2, $sgpr6_sgpr7 in %3, $sgpr8_sgpr9 in %4, $sgpr10_sgpr11 in %5, $sgpr12 in %6, $sgpr13 in %7, $sgpr14 in %8, $sgpr15 in %9 bb.1 (%ir-block.0): liveins: $vgpr0, $vgpr1, $vgpr2, $vgpr3, $vgpr4, $vgpr5 %12:_(s32) = COPY $vgpr2 %13:_(s32) = COPY $vgpr3 %14:_(s32) = COPY $vgpr4 %15:_(s32) = COPY $vgpr5 %24:_(s32) = G_INTRINSIC_CONVERGENT intrinsic(@llvm.amdgcn.readfirstlane), %12:_(s32) %25:_(s32) = G_INTRINSIC_CONVERGENT intrinsic(@llvm.amdgcn.readfirstlane), %13:_(s32) %26:_(s32) = G_INTRINSIC_CONVERGENT intrinsic(@llvm.amdgcn.readfirstlane), %14:_(s32) %27:_(s32) = G_INTRINSIC_CONVERGENT intrinsic(@llvm.amdgcn.readfirstlane), %15:_(s32) %18:_(<2 x s64>) = G_BUILD_VECTOR %24:_(s32), %25:_(s32), %26:_(s32), %27:_(s32) %19:sgpr_128 = COPY %18:_(<2 x s64>) INLINEASM &"; use $0" [sideeffect] [attdialect], $0:[reguse:SGPR_128], %19:sgpr_128 SI_RETURN # End machine code for function test_readfirstlane_v2i64. *** Bad machine code: G_BUILD_VECTOR result element type must match source type *** - function: test_readfirstlane_v2i64 - basic block: %bb.1 (0x151098440) - instruction: %18:_(<2 x s64>) = G_BUILD_VECTOR %24:_(s32), %25:_(s32), %26:_(s32), %27:_(s32) *** Bad machine code: G_BUILD_VECTOR must have an operand for each elemement *** - function:test_readfirstlane_v2i64 - basic block: %bb.1 (0x151098440) - instruction: %18:_(<2 x s64>) = G_BUILD_VECTOR %24:_(s32), %25:_(s32), %26:_(s32), %27:_(s32) LLVM ERROR: Found 2 machine code errors. PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the c ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128643] [libc] Link error in libc overlay mode
Issue
128643
Summary
[libc] Link error in libc overlay mode
Labels
libc
Assignees
Reporter
jun-shibata
I linked a static archive (libllvmlibc.a) in the overlay mode of libc and built the code containing fileno.
```c
#include
int main(int argc, char *argv[]) {
return fileno(stderr);
}
```
Then a following link error occurred.
```script
$ clang a.c -L lib/libllvmlibc.a -lllvmlibc
/usr/bin/ld: lib/aarch64-unknown-linux-gnu/libllvmlibc.a(file.cpp.o): in function `__llvm_libc_21_0_0_git::RawMutex::lock_slow(__llvm_libc_21_0_0_git::cpp::optional<__llvm_libc_21_0_0_git::internal::AbsTimeout>, bool, unsigned int)':
file.cpp:(.text._ZN22__llvm_libc_21_0_0_git8RawMutex9lock_slowENS_3cpp8optionalINS_8internal10AbsTimeoutEEEbj[_ZN22__llvm_libc_21_0_0_git8RawMutex9lock_slowENS_3cpp8optionalINS_8internal10AbsTimeoutEEEbj]+0xb8): undefined reference to `__llvm_libc_21_0_0_git::internal::clock_gettime(int, timespec*)'
/usr/bin/ld: file.cpp:(.text._ZN22__llvm_libc_21_0_0_git8RawMutex9lock_slowENS_3cpp8optionalINS_8internal10AbsTimeoutEEEbj[_ZN22__llvm_libc_21_0_0_git8RawMutex9lock_slowENS_3cpp8optionalINS_8internal10AbsTimeoutEEEbj]+0xc4): undefined reference to `__llvm_libc_21_0_0_git::internal::clock_gettime(int, timespec*)'
/usr/bin/ld: a.out: hidden symbol `_ZN22__llvm_libc_21_0_0_git8internal13clock_gettimeEiP8timespec' isn't defined
/usr/bin/ld: final link failed: bad value
clang: error: linker command failed with exit code 1 (use -v to see invocation)
```
I used libc for AArch64 that was built followed official manual.
https://libc.llvm.org/overlay_mode.html#building-the-static-archive-as-part-of-the-bootstrap-build
llvm-project: a3dc77c00a012bb613cb08e669dab4fadf88e935
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128644] powerpc: clang build with -fPIC corrupts link stack
Issue
128644
Summary
powerpc: clang build with -fPIC corrupts link stack
Labels
clang
Assignees
Reporter
chleroy
Explanation copied from linux kernel commit c974809a26a1 ("powerpc/vdso: Avoid link stack corruption in __get_datapage()"):
_powerpc has a link register (lr) used for calling functions. We "bl
" to call a function, and "blr" to return back to the call site._
_The lr is only a single register, so if we call another function from
inside this function (ie. nested calls), software must save away the
lr on the software stack before calling the new function. Before
returning (ie. before the "blr"), the lr is restored by software from
the software stack._
_This makes branch prediction quite difficult for the processor as it
will only know the branch target just before the "blr"._
_To help with this, modern powerpc processors keep a (non-architected)
hardware stack of lr called a "link stack". When a "bl " is
run, the lr is pushed onto this stack. When a "blr" is called, the
branch predictor pops the lr value from the top of the link stack, and
uses it to predict the branch target. Hence the processor pipeline
knows a lot earlier the branch target._
_This works great but there are some cases where you call "bl" but
without a matching "blr". Once such case is when trying to determine
the program counter (which can't be read directly). Here you "bl+4;
mflr" to get the program counter. If you do this, the link stack will
get out of sync with reality, causing the branch predictor to
mis-predict subsequent function returns._
_To avoid this, modern micro-architectures have a special case of bl.
Using the form "bcl 20,31,+4", ensures the processor doesn't push to
the link stack._
Lets take the following test function:
```
char val;
char test(void)
{
return val;
}
```
When built with GCC (ppc-linux-gcc -O2 -fPIC -c test.c), we get:
```
0004 :
4: 94 21 ff f0 stwur1,-16(r1)
8: 7c 08 02 a6 mflrr0
c: 42 9f 00 05 bcl 20,4*cr7+so,10 <== bcl 20,31,.+4
10: 93 c1 00 08 stw r30,8(r1)
14: 7f c8 02 a6 mflrr30
18: 90 01 00 14 stw r0,20(r1)
1c: 80 1e ff f0 lwz r0,-16(r30)
20: 7f c0 f2 14 add r30,r0,r30
24: 81 3e 80 00 lwz r9,-32768(r30)
28: 80 01 00 14 lwz r0,20(r1)
2c: 88 69 00 00 lbz r3,0(r9)
30: 83 c1 00 08 lwz r30,8(r1)
34: 7c 08 03 a6 mtlrr0
38: 38 21 00 10 addir1,r1,16
3c: 4e 80 00 20 blr
```
But when building with clang (clang --target=ppc-linux -O2 -fPIC -c test.c), we get:
```
0004 :
4: 7c 08 02 a6 mflrr0
8: 94 21 ff f0 stwur1,-16(r1)
c: 93 c1 00 08 stw r30,8(r1)
10: 90 01 00 14 stw r0,20(r1)
14: 48 00 00 05 bl 18 <== bl .+4
18: 7f c8 02 a6 mflrr30
1c: 80 7e ff e8 lwz r3,-24(r30)
20: 7f c3 f2 14 add r30,r3,r30
24: 80 7e 80 00 lwz r3,-32768(r30)
28: 88 63 00 00 lbz r3,0(r3)
2c: 80 01 00 14 lwz r0,20(r1)
30: 83 c1 00 08 lwz r30,8(r1)
34: 38 21 00 10 addir1,r1,16
38: 7c 08 03 a6 mtlr r0
3c: 4e 80 00 20 blr
```
As you can see, gcc uses the expected special form `bcl 20,31,+.4` but clang uses `bl .+4` instead hence corrupting the link stack.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128625] Cannot match add instruction with BinaryOperator
Issue
128625
Summary
Cannot match add instruction with BinaryOperator
Labels
new issue
Assignees
Reporter
cctry
I am writing a simple pass to capture all add instructions.
This is the code within the BB/Inst loop.
```
auto *BinOp = dyn_cast(Inst);
if (!BinOp) {
llvm::errs() << "Skipping non-binary instruction: " << *Inst << "\n";
llvm::errs() << "isBinaryOp: " << Inst->isBinaryOp() << "\n";
continue;
}
```
I am testing it with this function.
```
int8_t foo(int8_t a, int8_t b, int8_t c, int8_t d) {
int8_t e = c + d;
int8_t f = a + b;
return e + f;
}
```
The IR file is like
```
define dso_local noundef signext i8 @foo(i8 noundef signext %0, i8 noundef signext %1, i8 noundef signext %2, i8 noundef signext %3) local_unnamed_addr #0 {
%5 = add i8 %1, %0
%6 = add i8 %5, %2
%7 = add i8 %6, %3
ret i8 %7
}
```
However, the logging shows that no add instructions pass the filter.
```
Skipping non-binary instruction: %5 = add i8 %1, %0
isBinaryOp: 0
Skipping non-binary instruction: %6 = add i8 %5, %2
isBinaryOp: 0
Skipping non-binary instruction: %7 = add i8 %6, %3
isBinaryOp: 0
Skipping non-binary instruction: ret i8 %7
isBinaryOp: 0
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128638] Support USubb/IMul/UMul/UDiv in the DirectX backend
Issue 128638 Summary Support USubb/IMul/UMul/UDiv in the DirectX backend Labels new issue Assignees Reporter farzonl The plan for the frontend changes is still open for DXC so no frontend change is needed just yet for HLSL: https://github.com/microsoft/DirectXShaderCompiler/issues/6727 What is defined is we need a way to lower llvmir to these DXIL opcodes: ID | Name | Description -- | -- | -- 41 |[IMul](https://github.com/microsoft/DirectXShaderCompiler/blob/main/docs/DXIL.rst#imul) | multiply of 32-bit operands to produce the correct full 64-bit result. 42 | [UMul](https://github.com/microsoft/DirectXShaderCompiler/blob/main/docs/DXIL.rst#umul) | multiply of 32-bit operands to produce the correct full 64-bit result. 43 | [UDiv](https://github.com/microsoft/DirectXShaderCompiler/blob/main/docs/DXIL.rst#udiv) | unsigned divide of the 32-bit operand src0 by the 32-bit operand src1. 45 | [USubb](https://github.com/microsoft/DirectXShaderCompiler/blob/main/docs/DXIL.rst#usubb) | unsigned subtract of 32-bit operands with the borrow DXILOP | LLVM Intrinsic -- | -- USubb | Intrinsic::usub_with_overflow UMul | Intrinsic::umul_with_overflow IMul | Intrinsic::smul_with_overflow UDiv | TBD ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128547] [mlir][spirv] Non-deterministic structurization in SPIR-V deserializer
Issue 128547 Summary [mlir][spirv] Non-deterministic structurization in SPIR-V deserializer Labels mlir Assignees Reporter IgWod-IMG Currently when the MLIR code is being structured inside the SPIR-V deserializer (run with: `mlir-translate --deserialize-spirv example.spv`) the order in which regions are structured is non-deterministic. This is because the `DenseMap` that holds block merge information (`blockMergeInfo`) uses a pointer to `Block` as a key. Then when `structurizeControlFlow` iterates over the map, the order elements are seen across different runs may vary, as pointer will have different addresses across different runs. So far this doesn't negatively affect supported shaders (or at least not to my knowledge), but it makes debugging harder. Reported as discussed in #127639 ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128562] [DirectX] DXILPrettyPrinter fails to print cbuffers
Issue 128562 Summary [DirectX] DXILPrettyPrinter fails to print cbuffers Labels backend:DirectX Assignees bogner Reporter bogner DXILPrettyPrinter crashes when trying to print cbuffers because of an `unreachable` that is reached during FormatResourceDimension. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128557] Regression in instcombine
Issue
128557
Summary
Regression in instcombine
Labels
new issue
Assignees
Reporter
gbaraldi
While debugging a reggression in julia we found that some code that used to vectorize no longer does. Digging deeper it looks like it's a reggression in instcombine from LLVM 18 to LLVM 19 (still there on trunk)
```llvm
define swiftcc float @julia_perf_sum_1108(ptr nonnull swiftself %0, ptr noundef nonnull align 8 dereferenceable(16) %1) local_unnamed_addr #0 {
%8 = load i64, ptr %1, align 8, !tbaa !9, !alias.scope !12, !noalias !15
%9 = icmp slt i64 %8, 1
br i1 %9, label %26, label %10
10: ; preds = %2
%11 = getelementptr inbounds i8, ptr %1, i64 8
%12 = load ptr, ptr %11, align 8, !tbaa !20, !alias.scope !12, !noalias !15, !nonnull !8
%13 = getelementptr inbounds [1 x i32], ptr %12, i64 %8
br label %14
14: ; preds = %14, %10
%15 = phi i64 [ 0, %10 ], [ %17, %14 ]
%16 = phi float [ 0.00e+00, %10 ], [ %24, %14 ]
%17 = add nuw nsw i64 %15, 1
%18 = getelementptr inbounds [1 x i32], ptr %12, i64 %15
%19 = getelementptr inbounds i8, ptr %13, i64 %15
%20 = load i8, ptr %19, align 1, !tbaa !22, !range !24, !alias.scope !12, !noalias !15
%21 = load float, ptr %18, align 4, !tbaa !25, !alias.scope !28, !noalias !29
%22 = icmp eq i8 %20, 0
%23 = fadd float %16, %21
%24 = select i1 %22, float %16, float %23 ; this select
%25 = icmp eq i64 %17, %8
br i1 %25, label %26, label %14, !llvm.loop !30
26: ; preds = %14, %2
%27 = phi float [ 0.00e+00, %2 ], [ %24, %14 ]
ret float %27
}
```
The select highlighted used to be able to be folded into `%24 = select i1 %23, float -0.00e+00, float %22` which allowed a sequence of loop-simplify + LCSSA + vectorize to vectorize the loop. The sequence still works, but the instcombine change makes it not vectorize
https://godbolt.org/z/GE369hEcr (Just the instcombine)
https://godbolt.org/z/5YWo5WPY8 (Whole sequence)
https://godbolt.org/z/zz6c6s547
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128560] [DirectX] DXILBindingMap is incorrectly populated if we have cbuffers but no UAVs or SRVs.
Issue 128560 Summary [DirectX] DXILBindingMap is incorrectly populated if we have cbuffers but no UAVs or SRVs. Labels backend:DirectX, HLSL Assignees bogner Reporter bogner In `DXILBindingMap::populate` we set up FirstUAV, FirstCBuffer, and FirstCBuffer variables in order to get iterators over just the specific type of resource. However, if we have cbuffers and no uavs, FirstUAV is set to `size()` but `FirstCBuffer` is zero, which causes our iterators to return garbage. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128545] -ffp-contract difference for runtime / compile-time operations
Issue
128545
Summary
-ffp-contract difference for runtime / compile-time operations
Labels
new issue
Assignees
Reporter
jcarreira
I have a piece of code that computes different floating point results depending on whether the computation happens at compilation time or at runtime (see [https://godbolt.org/z/q65q4f7c3](url) ).
When the values are known at compile time the compiler contracts the operation and computes the result. When they are not known, the _expression_ is computed at runtime without contraction.
```
#include
#include
#include
int main() {
double x = 30.508474576271183309;
double y = 6.1016949152542370172;
double r = (x-std::trunc(x/y)*y);
std::cout << std::setprecision(17);
std::cout << "compile time (w/ fma): " << r << std::endl;
volatile double *xx = &x;
volatile double *yy = &y;
r = (*xx-std::trunc(*xx/(*yy))*(*yy));
std::cout << "runtime (w/o fma): " << r << std::endl;
r = std::fma(std::trunc(*xx/(*yy)),-(*yy),*xx);
std::cout << "runtime (w/ explicit fma): " << r << std::endl;
return 0;
}
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128567] [lldb-dap] TestDAP_output test is flaky
Issue 128567 Summary [lldb-dap] TestDAP_output test is flaky Labels lldb-dap Assignees ashgti Reporter ashgti The TestDAP_output test is flaky about ~3-5% of the time. The failure is that the final output from stdout or stderr is not sent before the disconnect call. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128587] Missed optimization: malloc + memcpy + free => realloc
Issue
128587
Summary
Missed optimization: malloc + memcpy + free => realloc
Labels
missed-optimization
Assignees
Reporter
Kmeakin
https://godbolt.org/z/YWxW7h8sP
```c++
#include
#include
#include
extern "C" {
auto src1(void* p1, size_t old_len, size_t new_len) -> void* {
void* p2 = malloc(new_len);
memcpy(p2, p1, old_len);
free(p1);
return p2;
}
auto tgt1(void* p1, size_t old_len, size_t new_len) -> void* {
return realloc(p1, new_len);
}
}
```
alive proof: https://alive2.llvm.org/ce/z/RwPKVk
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128598] DirectX codegen tests failing when ran under hwasan
Issue 128598 Summary DirectX codegen tests failing when ran under hwasan Labels new issue Assignees Reporter Icohedron After the merging of a PR (#128556) fix to DirectX build breaks, 28 DirectX tests are failing when ran under my hwasan build of this PR's branch. See this log: https://gist.github.com/Icohedron/54739cbd0ab952d666bf376e76c9bb85 Similar to issue #124045, it appears to be related to the use of `-o /dev/null` with `llc` ``` /workspace/llvm-project/build/bin/llc /workspace/llvm-project/llvm/test/CodeGen/DirectX/BufferStore-errors.ll -o /dev/null 2>&1 error: :0:0: in function storetoomany void (<5 x float>, i32): typedBufferStore data must be a vector of 4 elements error: :0:0: in function storetoofew void (<3 x i32>, i32): typedBufferStore data must be a vector of 4 elements pure virtual method called terminate called without an active exception Aborted ``` Replacing `-o /dev/null` with `-o -` makes the tests pass. This is odd because @vitalybuka supposedly patched a similar issue w.r.t. a SPIRV codegen error test (see https://github.com/llvm/llvm-project/pull/125599#discussion_r1966650839 ) ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128607] [Flang] Compilation error for the same type of two data elements declared with reference to the same derived type definition
Issue 128607 Summary [Flang] Compilation error for the same type of two data elements declared with reference to the same derived type definition Labels flang:frontend Assignees Reporter ohno-fj ``` Version of flang : 21.0.0(f75126eeabba13ce2aab53c2e4296fca12b9da0d)/AArch64 ``` The attached program has the same `derived type (ty)` definitions in the `specification-part` and `module-subprogram-part` in `module`, and data elements declared with reference to these `derived types`. The data elements are of the same type, as described in `Fortran standard 2023: 7.5.2.4 Determination of derived types`. So this program seems to be correct, but it results in a compilation error. The following are the test program, Flang, Gfortran and ifx compilation/execution result. sngg430l_32.f90: ```fortran module m type ty integer::x end type ty interface assignment(=) procedure operator_overload end interface assignment(=) contains subroutine operator_overload(t1,p1) type ty integer::x end type ty type(ty),intent(inout)::t1 integer,intent(in)::p1 t1%x=p1 write(6,*) "t1%x = ", t1%x, " p1 = ", p1 end subroutine operator_overload end module m program main use m integer::x type(ty)::obj x=10 obj= x write(6,*) "obj%x = ", obj%x if(obj%x .ne. 10)print*,"100" print*,"pass" end program main ``` ``` $ flang sngg430l_32.f90 error: Semantic errors in sngg430l_32.f90 ./sngg430l_32.f90:25:3: error: No intrinsic or user-defined ASSIGNMENT(=) matches operand types TYPE(ty) and INTEGER(4) obj= x ^^ $ ``` ``` $ gfortran sngg430l_32.f90 sngg430l_32.f90:25:7: 25 | obj= x | 1 Error: Cannot convert INTEGER(4) to TYPE(ty) at (1) $ ``` ``` $ ifx sngg430l.f90_32; ./a.out t1%x = 10 p1 = 10 obj%x = 10 pass $ ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128606] [flang][debug] Unexpected Assertion `!attr.getIsRecSelf() && "unbound DI recursive self reference"' failure
Issue 128606 Summary [flang][debug] Unexpected Assertion `!attr.getIsRecSelf() && "unbound DI recursive self reference"' failure Labels flang Assignees Reporter akuhlens This seems to be another case of #122024. The example code is a lot more complicated and I wasn't able to reduce it to a single file. I can delete a fair amount of code, but deleting the [switch case for `type(TestCase)`](https://github.com/Goddard-Fortran-Ecosystem/pFUnit/blob/cbe21b95eff70804acfd7f5a9b68dec291781c4a/src/funit/core/TestSuite.F90#L164). Allows this file to compile and then gets stuck on the next file with the same error. ``` $ git clone g...@github.com:Goddard-Fortran-Ecosystem/pFUnit.git $ cd pFUnit $ mkdir build $ cd build $ flang --version flang version 21.0.0git (https://github.com/llvm/llvm-project f6a30021249c3b6aac20f108559915e74943540f) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: Build config: +assertions $ export FC=flang $ cmake -DCMAKE_INSTALL_PREFIX=../install -DENABLE_TESTS=ON -DSKIP_MPI=YES .. $ make test ... [ 14%] Building Fortran object src/funit/core/CMakeFiles/funit-core.dir/TestSuite.F90.o flang-21: warning: OpenMP support in flang is still experimental [-Wexperimental-option] flang: /proj/build/llvm/Linux_x86_64/mlir/lib/Target/LLVMIR/DebugTranslation.cpp:276: llvm::DINode* mlir::LLVM::detail::DebugTranslation::translateRecursive(mlir::LLVM::DIRecursiveTypeAttrInterface): Assertion `!attr.getIsRecSelf() && "unbound DI recursive self reference"' failed. PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. Stack dump: 0. Program arguments: /proj/nv/llvm/Linux_x86_64/llvm-4477/bin/flang -fc1 -triple x86_64-unknown-linux-gnu -emit-obj -D Robust -I /home/akuhlenschmi/tmp/pFUnit/build/src/funit/mod -I /home/akuhlenschmi/tmp/pFUnit/include -I /home/akuhlenschmi/tmp/pFUnit/build/src/funit/core -I /local/home/akuhlenschmi/tmp/install/GFTL-1.15/include/v2 -I /local/home/akuhlenschmi/tmp/install/GFTL_SHARED-1.10/include/v2 -I /local/home/akuhlenschmi/tmp/install/FARGPARSE-1.9/include -cpp -mrelocation-model pic -pic-level 2 -pic-is-pie -target-cpu x86-64 -module-dir ../mod -debug-info-kind=standalone -fopenmp -resource-dir /proj/nv/llvm/Linux_x86_64/llvm-4477/lib/clang/21 -mframe-pointer=all -O0 -o CMakeFiles/funit-core.dir/TestSuite.F90.o -x f95-cpp-input /home/akuhlenschmi/tmp/pFUnit/src/funit/core/TestSuite.F90 #0 0x556097d9d13b llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/proj/nv/llvm/Linux_x86_64/llvm-4477/bin/flang+0x450713b) #1 0x556097d9a954 SignalHandler(int, siginfo_t*, void*) Signals.cpp:0:0 #2 0x7ff69983e520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520) #3 0x7ff6998929fc __pthread_kill_implementation ./nptl/pthread_kill.c:44:76 #4 0x7ff6998929fc __pthread_kill_internal ./nptl/pthread_kill.c:78:10 #5 0x7ff6998929fc pthread_kill ./nptl/pthread_kill.c:89:10 #6 0x7ff69983e476 gsignal ./signal/../sysdeps/posix/raise.c:27:6 #7 0x7ff6998247f3 abort ./stdlib/abort.c:81:7 #8 0x7ff69982471b _nl_load_domain ./intl/loadmsgcat.c:1177:9 #9 0x7ff699835e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96) #10 0x55609bb56359 mlir::LLVM::detail::DebugTranslation::translateRecursive(mlir::LLVM::DIRecursiveTypeAttrInterface) (/proj/nv/llvm/Linux_x86_64/llvm-4477/bin/flang+0x82c0359) #11 0x55609bb565ed mlir::LLVM::detail::DebugTranslation::translate(mlir::LLVM::DINodeAttr) (/proj/nv/llvm/Linux_x86_64/llvm-4477/bin/flang+0x82c05ed) #12 0x55609bb579c4 mlir::LLVM::detail::DebugTranslation::translateImpl(mlir::LLVM::DIDerivedTypeAttr) (/proj/nv/llvm/Linux_x86_64/llvm-4477/bin/flang+0x82c19c4) #13 0x55609bb569bb mlir::LLVM::detail::DebugTranslation::translate(mlir::LLVM::DINodeAttr) (/proj/nv/llvm/Linux_x86_64/llvm-4477/bin/flang+0x82c09bb) #14 0x55609bb579c4 mlir::LLVM::detail::DebugTranslation::translateImpl(mlir::LLVM::DIDerivedTypeAttr) (/proj/nv/llvm/Linux_x86_64/llvm-4477/bin/flang+0x82c19c4) #15 0x55609bb569bb mlir::LLVM::detail::DebugTranslation::translate(mlir::LLVM::DINodeAttr) (/proj/nv/llvm/Linux_x86_64/llvm-4477/bin/flang+0x82c09bb) #16 0x55609bb58b70 mlir::LLVM::detail::DebugTranslation::getMDTupleOrNull(llvm::ArrayRef) (/proj/nv/llvm/Linux_x86_64/llvm-4477/bin/flang+0x82c2b70) #17 0x55609bb5995b mlir::LLVM::detail::DebugTranslation::translateImpl(mlir::LLVM::DICompositeTypeAttr) (/proj/nv/llvm/Linux_x86_64/llvm-4477/bin/flang+0x82c395b) ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128608] [Flang] Compilation error when using the type is statement in select type construct
Issue 128608 Summary [Flang] Compilation error when using the type is statement in select type construct Labels flang:frontend Assignees Reporter ohno-fj ``` Version of flang : 21.0.0(f75126eeabba13ce2aab53c2e4296fca12b9da0d)/AArch64 ``` In the attached program, the `type is` statement is defined in `select type` construct, and the type of variable `x` is treated as `integer` instead of `polyphasic` in subsequent blocks. This is mentioned in `Fortran standard 2023: 11.1.11.2 Execution of the SELECT TYPE construct`, so it seems correct that this should not result in a compilation error. However, this program results in compilation error in Flang. The following are the test program, Flang, Gfortran and ifx compilation/execution result. sngtatm013_2.f90: ```fortran subroutine ss2 class(*),allocatable::x(:) allocate(x,source=[1]) select type(x) type is(integer) do concurrent(ii=1:1:1,.true.) x(ii)=ii end do end select end subroutine ss2 ``` ``` $ flang -c sngtatm013_2.f90 error: Semantic errors in sngtatm013_2.f90 ./sngtatm013_2.f90:7:9: error: Deallocation of a polymorphic entity caused by assignment not allowed in DO CONCURRENT x(ii)=ii ^ ./sngtatm013_2.f90:2:25: Declaration of 'x' class(*),allocatable::x(:) ^ $ ``` ``` $ gfortran -c sngtatm013_2.f90 $ ``` ``` $ ifx -c sngtatm013_2.f90 $ ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128610] [Flang] Compile error when argument keyword is used as argument to an extension sizeof intrinsic function
Issue 128610 Summary [Flang] Compile error when argument keyword is used as argument to an extension sizeof intrinsic function Labels flang:frontend Assignees Reporter ohno-fj ``` Version of flang : 21.0.0(f75126eeabba13ce2aab53c2e4296fca12b9da0d)/AArch64 ``` When `argument keyword (X=)` is used as argument to an extension `sizeof` intrinsic function, a compilation error occurs. The following are the test program, Flang, Gfortran and ifx compilation/execution result. sngts014_22.f90: ```fortran program main call s2 print *,'pass' contains subroutine s2 integer,parameter::pi41=sizeof(X=1) integer::i41 if(pi41/=sizeof(X=i41)) print *,'err11' end subroutine s2 end program main ``` ``` $ flang sngts014_22.f90; ./a.out error: Semantic errors in sngts014_22.f90 ./sngts014_22.f90:6:36: error: unknown keyword argument to intrinsic 'sizeof' integer,parameter::pi41=sizeof(X=1) ^ ./sngts014_22.f90:8:21: error: unknown keyword argument to intrinsic 'sizeof' if(pi41/=sizeof(X=i41)) print *,'err11' ^ $ ``` ``` $ gfortran sngts014_22.f90; ./a.out pass $ ``` ``` $ ifx sngts014_22.f90; ./a.out pass $ ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128609] [Flang] The value of c_intmax_t defined in iso_c_binding is different for Flang and Gfortran/ifx.
Issue 128609 Summary [Flang] The value of c_intmax_t defined in iso_c_binding is different for Flang and Gfortran/ifx. Labels flang Assignees Reporter ohno-fj ``` Version of flang : 21.0.0(f75126eeabba13ce2aab53c2e4296fca12b9da0d)/AArch64 ``` While running the attached program, I noticed that the value of `c_intmax_t` defined in `iso_c_binding` is different for Flang and Gfortran/ifx. Flang is 16 and Gfortran/ifx is 8. ``` $ grep c_intmax_t /work/groups/ssoft/compiler/llvm/aarch64/main-latest/include/flang/iso_c_binding.mod integer(4),parameter::c_intmax_t=16_4 $ ``` Is there no problem that the value of flang is different from the value of gfortran/ifx? The following are the test program, Flang, Gfortran and ifx compilation/execution result. snfg1101_err077_2.f90: ```fortran program main use , intrinsic :: iso_c_binding call csub1() contains subroutine csub1() logical(c_intmax_t):: i_c_intmax_t i_c_intmax_t = .TRUE. print *,i_c_intmax_t print *,c_sizeof(i_c_intmax_t) end subroutine csub1 end program main ``` ``` $ flang snfg1101_err077_2.f90 error: Semantic errors in snfg1101_err077_2.f90 ./snfg1101_err077_2.f90:6:5: error: LOGICAL(KIND=16) is not a supported type logical(c_intmax_t):: i_c_intmax_t ^^ $ ``` ``` $ gfortran snfg1101_err077_2.f90; ./a.out snfg1101_err077_2.f90:6:11: 6 | logical(c_intmax_t) :: i_c_intmax_t | 1 Warning: C kind type parameter is for type INTEGER but type at (1) is LOGICAL T 8 $ ``` ``` $ ifx snfg1101_err077_2.f90; ./a.out T 8 $ ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128596] [Hexagon] Correct the default compilation target to V68
Issue 128596 Summary [Hexagon] Correct the default compilation target to V68 Labels bug, backend:Hexagon Assignees Reporter iajbar Correct the default compilation target to V68 if no Hexagon processor is specified at the command-line. Add the missing elf header changes for v81/v83/v85 architectures. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128600] [Clang] Optimization LoopFuse.cpp crashes on valid LLVM IR. Assertion `!verifyFunction(*FC0.Header->getParent(), &errs())' failed.
Issue
128600
Summary
[Clang] Optimization LoopFuse.cpp crashes on valid LLVM IR. Assertion `!verifyFunction(*FC0.Header->getParent(), &errs())' failed.
Labels
clang
Assignees
Reporter
zitongzhoueric
To reproduce: https://godbolt.org/z/zMEsM448G
`opt -passes=mem2reg,loop-rotate,loop-fusion {test}` crashes on the LLVMIR generated from `clang -O0` because of an assertion failure.
Stack Dump:
```
PHI node entries do not match predecessors!
%sum1.0.lcssa = phi i32 [ %add, %for.inc ]
label %for.inc
label %for.inc6
opt: /root/llvm-project/llvm/lib/Transforms/Scalar/LoopFuse.cpp:1759: llvm::Loop* {anonymous}::LoopFuser::performFusion(const {anonymous}::FusionCandidate&, const {anonymous}::FusionCandidate&): Assertion `!verifyFunction(*FC0.Header->getParent(), &errs())' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0. Program arguments: /opt/compiler-explorer/clang-assertions-trunk/bin/opt -o /app/output.s -S -passes=mem2reg,loop-rotate,loop-fusion
1. Running pass "function(mem2reg,loop(loop-rotate),loop-fusion)" on module ""
2. Running pass "loop-fusion" on function "main"
#0 0x054498e8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x54498e8)
#1 0x054472a4 SignalHandler(int, siginfo_t*, void*) Signals.cpp:0:0
#2 0x704d50642520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#3 0x704d506969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
#4 0x704d50642476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
#5 0x704d506287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
#6 0x704d5062871b (/lib/x86_64-linux-gnu/libc.so.6+0x2871b)
#7 0x704d50639e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96)
#8 0x0402a593 (anonymous namespace)::LoopFuser::performFusion((anonymous namespace)::FusionCandidate const&, (anonymous namespace)::FusionCandidate const&) LoopFuse.cpp:0:0
#9 0x0402cab5 (anonymous namespace)::LoopFuser::fuseCandidates() LoopFuse.cpp:0:0
#10 0x0402e5c1 llvm::LoopFusePass::run(llvm::Function&, llvm::AnalysisManager&) (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x402e5c1)
#11 0x031828ae llvm::detail::PassModel>::run(llvm::Function&, llvm::AnalysisManager&) (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x31828ae)
#12 0x05243e40 llvm::PassManager>::run(llvm::Function&, llvm::AnalysisManager&) (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x5243e40)
#13 0x00e6e23e llvm::detail::PassModel>, llvm::AnalysisManager>::run(llvm::Function&, llvm::AnalysisManager&) (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0xe6e23e)
#14 0x0524275b llvm::ModuleToFunctionPassAdaptor::run(llvm::Module&, llvm::AnalysisManager&) (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x524275b)
#15 0x00e6d54e llvm::detail::PassModel>::run(llvm::Module&, llvm::AnalysisManager&) (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0xe6d54e)
#16 0x05242160 llvm::PassManager>::run(llvm::Module&, llvm::AnalysisManager&) (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x5242160)
#17 0x00935dda llvm::runPassPipeline(llvm::StringRef, llvm::Module&, llvm::TargetMachine*, llvm::TargetLibraryInfoImpl*, llvm::ToolOutputFile*, llvm::ToolOutputFile*, llvm::ToolOutputFile*, llvm::StringRef, llvm::ArrayRef, llvm::ArrayRef>, llvm::opt_tool::OutputKind, llvm::opt_tool::VerifierKind, bool, bool, bool, bool, bool, bool, bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x935dda)
#18 0x0092944c optMain (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x92944c)
#19 0x704d50629d90 (/lib/x86_64-linux-gnu/libc.so.6+0x29d90)
#20 0x704d50629e40 __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x29e40)
#21 0x00920d25 _start (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x920d25)
Program terminated with signal: SIGSEGV
Compiler returned: 139
```
The Test IR causing the failure:
```
@.str = private unnamed_addr constant [7 x i8] c"%d %d\0A\00", align 1
define dso_local i32 @main() #0 {
entry:
%retval = alloca i32, align 4
%sum1 = alloca i32, align 4
%sum2 = alloca i32, align 4
%i = alloca i32, align 4
%i1 = alloca i32, align 4
store i32 0, ptr %retval, align 4
store i32 0, ptr %sum1, align 4
store i32 0, ptr %sum2, align 4
store i32 0, ptr %i, align 4
br label %for.cond
for.cond:
%0 = load i32, ptr %i, align 4
%cmp = icmp slt i32 %0, 10
br i1 %cmp, label %for.body, label %for.end
for.body:
%1 = load i32, ptr %i, align 4
%2 = load i32, ptr %sum1, align 4
%add = add nsw i32 %2, %1
store i32 %add, ptr %sum1, align 4
br label %for.inc
for.inc:
%3 = load
[llvm-bugs] [Bug 128488] LLVM fails to recognize the same condition sometimes
Issue
128488
Summary
LLVM fails to recognize the same condition sometimes
Labels
missed-optimization
Assignees
Reporter
philnik777
In libc++ we have the following string representation:
```c++
namespace std {
using size_t = __SIZE_TYPE__;
struct string {
union {
struct {
size_t __is_long_ : 1;
size_t __long_cap_ : 63;
size_t __long_size_;
char* __long_data_;
};
struct {
unsigned char : 1;
unsigned char __short_size_ : 7;
char __short_data_[23];
};
};
void __set_size(size_t __s) {
if (__is_long_) {
__long_size_ = __s;
} else {
__short_size_ = __s;
__is_long_ = false;
}
}
char* __get_pointer() {
return __is_long_ ? __long_data_ : &__short_data_[0];
}
};
}
auto test1(std::string& str, std::size_t size) {
str.__set_size(size);
return str.__get_pointer();
}
auto test2(std::string& str, std::size_t size) {
auto __ptr = str.__get_pointer();
str.__set_size(size);
return __ptr;
}
```
I've noticed recently that the code generated for the two functions above are significantly different, even though they are semantically equivalent. For some reason `test1` generates significantly worse code than `test2`. https://godbolt.org/z/15czrP69d
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128501] A problem about the precision of float variable printed by lldb.
Issue 128501 Summary A problem about the precision of float variable printed by lldb. Labels new issue Assignees Reporter IOVOVHS func0 is a function template, and the parameter types passed in are all float. There is a problem with the precision of the result output by variable var4. The result printed by lldb is 2030314.63, and the correct value should be 2030314.625, which is the value of var4 in memory.This doesn't look like rounding is the cause. ``` (lldb) b func0 Breakpoint 1: where = test_case4`double func0(float, float) + 20 at test_case4.cpp:44:12, address = 0x000134d8 (lldb) r ... (lldb) Process 66813 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = step over frame #0: 0x00013508 test_case4`double func0(p_0=100015.5, p_1=3.141) at test_case4.cpp:47:15 44 double var1 = 10.5, var2 = 20.3; 45 46 double var3 = var1 + var2; -> 47 T1 var4 = p_0 * var2; (lldb) Process 66813 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = step over frame #0: 0x00013520 test_case4`double func0(p_0=100015.5, p_1=3.141) at test_case4.cpp:48:15 45 46 double var3 = var1 + var2; 47 T1 var4 = p_0 * var2; -> 48 std::cout << std::fixed << std::setprecision(10) << var4 << std::endl; 49 var2 = var1 * var3; 50 var3 = var1 * var2 + var3; 51 var1 = var2 * var3 + var1; (lldb) p var4 (float) 2030314.63 (lldb) n 2030314.625000 (lldb) p p_0 * var2 (double) 2030314.650001 ``` So is this a bug or normal precision error? clang++ test_case4.cpp -o test_case4 -g clang++ --version Homebrew clang version 19.1.6 Target: arm64-apple-darwin24.1.0 lldb : 19.1.6 [test_case4.zip](https://github.com/user-attachments/files/18941575/test_case4.zip) ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128507] lldb only list is not working, but list -number is correct
Issue
128507
Summary
lldb only list is not working, but list -number is correct
Labels
new issue
Assignees
Reporter
Guo-yyds
ubuntu 20.04
clang 18.1.8
lldb 18.1.8
This is the c source code.
```c
#include
int main()
{
printf("Hello World\n");
return 0;
}
```
I use the compile
```sh
clang -g -O0 test.c
```
then, lldb list isnot working
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128510] [clang-tidy] narrowing conversion should highlight the last function name in the call chain
Issue
128510
Summary
[clang-tidy] narrowing conversion should highlight the last function name in the call chain
Labels
clang-tidy
Assignees
Reporter
maxim-banaev
In this example, `size()` should be highlighted instead of `vec`.
```
#include
int main()
{
std::vector vec{1, 2, 3};
int a = vec.size();
return 0;
}
```
clang-tidy output:
```
clang-tidy main.cpp -checks="-*,*-narrowing-conversions"
.../main.cpp:6:13: warning: narrowing conversion from 'size_type' (aka 'unsigned long') to signed type 'int' is implementation-defined [bugprone-narrowing-conversions,cppcoreguidelines-narrowing-conversions]
6 | int a = vec.size();
| ^
```
clang-tidy version is 21.0.0
llvm-project revision: 2b71df5a74cb5bd67f3f34277749dc920fd35105
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128522] [clang-tidy] compile_commands.json parsing error resulting in file not found [clang-diagnostic-error]
Issue 128522 Summary [clang-tidy] compile_commands.json parsing error resulting in file not found [clang-diagnostic-error] Labels clang-tidy Assignees Reporter MrZaus When command field in compile_commands.json begins with /usr/share/arm-gnu-toolchain-12.3.rel1-x86_64-arm-none-eabi/bin/arm-none-eabi-g++ include flags are not parsed as expected resulting in errors 'file not found [clang-diagnostic-error]'. I suspect JSONCompilationDatabase.cpp unwrapCommand. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128528] [clang] Miscompilation at -O2/3
Issue
128528
Summary
[clang] Miscompilation at -O2/3
Labels
clang
Assignees
Reporter
cardigan1008
This code prints at -O0/1 and -2147483648 at -O2/3:
```c
int printf(const char *, ...);
int a, b, c;
long double d;
int f(int g, int i) {
int e = g + i;
e++;
return e;
}
int j() {
int h = -1;
if (b)
return h;
return 0;
}
void k(int g) { a = -66 + g - 38; }
int main() {
int l, m = j();
l = f(m + 34, m + 80) + m - 112 + m;
k(l + 38 - 37 + 38);
d = 4 + a - -66;
a = c = d * 4.1019e02;
printf("%d\n", c);
}
```
Compiler Explorer: https://godbolt.org/z/TnK1bWcGd
Bisected to https://github.com/llvm/llvm-project/commit/15a7de697ae5ad88fd96ef7dc39ac479cc6e2eaf, which was committed by @goldsteinn
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128531] [clang] No warning for a memcpy from an uninitialized local variable
Issue
128531
Summary
[clang] No warning for a memcpy from an uninitialized local variable
Labels
clang
Assignees
Reporter
isbadawi
I encountered a bug that boiled down to something like this, passing the address of an uninitialized local variable as the source for memcpy:
```c
#include
void foo(int *out) {
int x;
memcpy(out, &x, sizeof(x));
}
```
The bug was only discovered after upgrading to a more recent clang happened to expose a runtime issue, there was no diagnostic. I found that latest gcc warns about this, but latest clang doesn't, see https://godbolt.org/z/7rd84W7sc
Output from gcc 14.2
```
: In function 'main':
:7:3: warning: 'x' is used uninitialized [-Wuninitialized]
7 | memcpy(&y, &x, sizeof(x));
| ^
:4:7: note: 'x' declared here
4 | int x;
|
```
It seems like gcc also more generally emits either `-Wuninitialized` or `-Wmaybe-uninitialized` when passing pointers to uninitialized local variables to functions, which is partly driven by parameters marked `const` or annotated using attribute `access`, but at least the memcpy case seems like it would be useful to cover.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128532] Assertion `!rvalue.isAggregate() || rvalue.getAggregateAddress().getElementType() == dest.getAddress().getElementType()' failed
Issue 128532 Summary Assertion `!rvalue.isAggregate() || rvalue.getAggregateAddress().getElementType() == dest.getAddress().getElementType()' failed Labels new issue Assignees Reporter bi6c Compiler Explorer: https://godbolt.org/z/hMrzf6TWj ```console clang: /root/llvm-project/clang/lib/CodeGen/CGAtomic.cpp:1986: void clang::CodeGen::CodeGenFunction::EmitAtomicStore(clang::CodeGen::RValue, clang::CodeGen::LValue, llvm::AtomicOrdering, bool, bool): Assertion `!rvalue.isAggregate() || rvalue.getAggregateAddress().getElementType() == dest.getAddress().getElementType()' 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 -fno-verbose-asm -c --gcc-toolchain=/opt/compiler-explorer/gcc-snapshot -fcolor-diagnostics -fno-crash-diagnostics 1. parser at end of file 2. Per-file LLVM IR generation 3. :2:13: Generating code for declaration 'test_simple_assign' #0 0x03e46dd8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x3e46dd8) #1 0x03e44a94 llvm::sys::CleanupOnSignal(unsigned long) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x3e44a94) #2 0x03d90ec8 CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0 #3 0x79e1f4042520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520) #4 0x79e1f40969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc) #5 0x79e1f4042476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476) #6 0x79e1f40287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3) #7 0x79e1f402871b (/lib/x86_64-linux-gnu/libc.so.6+0x2871b) #8 0x79e1f4039e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96) #9 0x0452344f clang::CodeGen::CodeGenFunction::EmitAtomicStore(clang::CodeGen::RValue, clang::CodeGen::LValue, llvm::AtomicOrdering, bool, bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x452344f) #10 0x041c670c (anonymous namespace)::AggExprEmitter::VisitBinAssign(clang::BinaryOperator const*) CGExprAgg.cpp:0:0 #11 0x041c5c4b (anonymous namespace)::AggExprEmitter::Visit(clang::Expr*) CGExprAgg.cpp:0:0 #12 0x041c5571 (anonymous namespace)::AggExprEmitter::Visit(clang::Expr*) CGExprAgg.cpp:0:0 #13 0x041c6260 clang::CodeGen::CodeGenFunction::EmitAggExpr(clang::Expr const*, clang::CodeGen::AggValueSlot) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x41c6260) #14 0x041c6af8 (anonymous namespace)::AggExprEmitter::VisitBinAssign(clang::BinaryOperator const*) CGExprAgg.cpp:0:0 #15 0x041c5c4b (anonymous namespace)::AggExprEmitter::Visit(clang::Expr*) CGExprAgg.cpp:0:0 #16 0x041c6260 clang::CodeGen::CodeGenFunction::EmitAggExpr(clang::Expr const*, clang::CodeGen::AggValueSlot) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x41c6260) #17 0x0418a231 clang::CodeGen::CodeGenFunction::EmitAnyExpr(clang::Expr const*, clang::CodeGen::AggValueSlot, bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x418a231) #18 0x041b075d clang::CodeGen::CodeGenFunction::EmitIgnoredExpr(clang::Expr const*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x41b075d) #19 0x0431f53e clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*, llvm::ArrayRef) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x431f53e) #20 0x043276fc clang::CodeGen::CodeGenFunction::EmitCompoundStmtWithoutScope(clang::CompoundStmt const&, bool, clang::CodeGen::AggValueSlot) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x43276fc) #21 0x0438cd4c clang::CodeGen::CodeGenFunction::EmitFunctionBody(clang::Stmt const*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x438cd4c) #22 0x0439fe4e clang::CodeGen::CodeGenFunction::GenerateCode(clang::GlobalDecl, llvm::Function*, clang::CodeGen::CGFunctionInfo const&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x439fe4e) #23 0x04408d0a clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::GlobalDecl, llvm::GlobalValue*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x4408d0a) #24 0x04403f64 clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl, llvm::GlobalValue*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x4403f64) #25 0x0441004d clang::CodeGen::CodeGenModule::EmitDeferred() (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x441004d) #26 0x04412333 clang::CodeGen::CodeGenModule::Release() (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x4412333) #27 0x00
[llvm-bugs] [Bug 128536] [AVR] clang: Arduino program breaks when Serial functions are used
Issue
128536
Summary
[AVR] clang: Arduino program breaks when Serial functions are used
Labels
clang
Assignees
Reporter
dakkshesh07
**LLVM Version:** 20.1.0-rc2
**Description:**
I'm trying to compile Arduino AVR programs using Clang, but I’ve encountered an issue with the Blink example sketch. When `Serial` functions are used, the LED remains stuck in the ON position, even with LTO disabled globally. Removing the serial-related code allows the LED to blink normally.
**Test Code:**
Failing Example (LED stuck ON):
```cpp
#include
void setup() {
pinMode(LED_BUILTIN, OUTPUT);
Serial.begin(9600);
Serial.println();
Serial.println("Hello world. I was built with clang!");
}
void loop() {
digitalWrite(LED_BUILTIN, HIGH);
delay(1000);
digitalWrite(LED_BUILTIN, LOW);
delay(1000);
}
```
Working Example (without Serial functions):
```cpp
#include
void setup() {
pinMode(LED_BUILTIN, OUTPUT);
}
void loop() {
digitalWrite(LED_BUILTIN, HIGH);
delay(1000);
digitalWrite(LED_BUILTIN, LOW);
delay(1000);
}
```
**Additional Info:**
- The same code works correctly when compiled with AVR GCC.
- The Arduino AVR core fork used during compilation: [ClangBuiltArduino/core_arduino_avr](https://github.com/ClangBuiltArduino/core_arduino_avr/tree/9602bbb2523eedbe1e8c7459659e3eb00781b000/cores/arduino)
Please let me know if any additional information would be helpful for diagnosing this issue — I can provide assembly files, compiler flags, or any other relevant details as needed.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
