[llvm-bugs] [Bug 82964] Backport "[GVN] Drop nsw/nuw flags when replacing the result of a with.overflow intrinsic with a overflowing binary operator" to release/18.x
Issue 82964 Summary Backport "[GVN] Drop nsw/nuw flags when replacing the result of a with.overflow intrinsic with a overflowing binary operator" to release/18.x Labels release:backport Assignees Reporter dtcxzyw /cherry-pick 892b4beeac50920e630f10905b2916295e2eb6d8 ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 82961] [MC] __FUNCTION__ not in symtab
Issue
82961
Summary
[MC] __FUNCTION__ not in symtab
Labels
new issue
Assignees
Reporter
CoTinker
test.c
```
#include
int main() {
printf("%s\n", __FUNCTION__);
}
```
compile command:
```
clang test.c -o test.o -c
```
https://godbolt.org/z/PPaGT3j46
```
// X86 backend
% clang test.c -o test.o -c
% llvm-readelf -s test.o
Symbol table '.symtab' contains 7 entries:
Num:Value Size TypeBind Vis Ndx Name
0: 0 NOTYPE LOCAL DEFAULT UND
1: 0 FILELOCAL DEFAULT ABS test.c
2: 0 SECTION LOCAL DEFAULT 2 .text
3: 4 OBJECT LOCAL DEFAULT 4 .L.str
4: 0004 5 OBJECT LOCAL DEFAULT 4 .L__FUNCTION__.main
5: 29 FUNCGLOBAL DEFAULT 2 main
6: 0 NOTYPE GLOBAL DEFAULT UND printf
// AArch64 backend
% clang test.c -o test.o -c
% llvm-readelf -s test.o
Symbol table '.symtab' contains 10 entries:
Num:Value Size TypeBind Vis Ndx Name
0: 0 NOTYPE LOCAL DEFAULT UND
1: 0 FILELOCAL DEFAULT ABS test.c
2: 0 SECTION LOCAL DEFAULT 2 .text
3: 0 NOTYPE LOCAL DEFAULT 2 $x.0
4: 0 SECTION LOCAL DEFAULT 4 .rodata.str1.1
5: 0 NOTYPE LOCAL DEFAULT 4 $d.1
6: 0 NOTYPE LOCAL DEFAULT 5 $d.2
7: 0 NOTYPE LOCAL DEFAULT 7 $d.3
8: 40 FUNCGLOBAL DEFAULT 2 main
9: 0 NOTYPE GLOBAL DEFAULT UND printf
```
I don't known why symbol `.L__FUNCTION__.main` is in symtab in X86 but not in AArch64
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 82960] clang-diagnostics: -Wswitch-default and -Wcovered-switch-default contradictory warnings
Issue
82960
Summary
clang-diagnostics: -Wswitch-default and -Wcovered-switch-default contradictory warnings
Labels
new issue
Assignees
Reporter
FalcoGer
When having both `-Wswitch-default` and `-Wcovered-switch-default` this generates contradictory warnings.
[Example](https://godbolt.org/#g:!((g:!((g:!((h:codeEditor,i:(filename:'1',fontScale:14,fontUsePx:'0',j:1,lang:c%2B%2B,selection:(endColumn:5,endLineNumber:9,positionColumn:5,positionLineNumber:9,selectionStartColumn:5,selectionStartLineNumber:9,startColumn:5,startLineNumber:9),source:'%23include+%3Ccstdint%3E%0A%0Aenum+class+ETest+:+std::uint8_t%0A%7B%0ATEST1,%0ATEST2,%0A%7D%3B%0A%0Aauto+main()+-%3E+int%0A%7B%0AETest+test+%3D+ETest::TEST2%3B%0A%5B%5Bmaybe_unused%5D%5D%0Aint+++a+%7B%7D%3B%0A%0Aswitch+(test)%0A%7B%0Acase+ETest::TEST1:+a+%3D+1%3B+break%3B%0Acase+ETest::TEST2:+a+%3D+2%3B+break%3B%0A//+default:+++a+%3D+99%3B+break%3B%0A%7D%0A%0Areturn+0%3B%0A%7D'),l:'5',n:'0',o:'C%2B%2B+source+%231',t:'0')),k:33.336,l:'4',n:'0',o:'',s:0,t:'0'),(g:!((h:compiler,i:(compiler:clang_trunk,filters:(b:'0',binary:'1',binaryObject:'1',commentOnly:'0',debugCalls:'1',demangle:'0',directives:'0',execute:'1',intel:'0',libraryCode:'0',trim:'1'),flagsViewOpen:'1',fontScale:14,fontUsePx:'0',j:1,lang:c%2B%2B,libs:!(),options:'-std%3Dc%2B%2B23+-Wall+-Wextra+-Wpedantic+-Wswitch-default+-Wcovered-switch-default',overrides:!(),selection:(endColumn:1,endLineNumber:1,positionColumn:1,positionLineNumber:1,selectionStartColumn:1,selectionStartLineNumber:1,startColumn:1,startLineNumber:1),source:1),l:'5',n:'0',o:'+x86-64+clang+(trunk)+(Editor+%231)',t:'0')),k:33.336,l:'4',n:'0',o:'',s:0,t:'0'),(g:!((h:output,i:(compilerName:'AVR+gcc+13.2.0',editorid:1,fontScale:14,fontUsePx:'0',j:1,wrap:'1'),l:'5',n:'0',o:'Output+of+x86-64+clang+(trunk)+(Compiler+%231)',t:'0')),k:33.33,l:'4',n:'0',o:'',s:0,t:'0')),l:'2',n:'0',o:'',t:'0')),version:4)
```c++
#include
enum class ETest : std::uint8_t
{
TEST1,
TEST2,
};
auto main() -> int
{
ETest test = ETest::TEST2;
[[maybe_unused]]
int a {};
switch (test)
{
case ETest::TEST1: a = 1; break;
case ETest::TEST2: a = 2; break;
// default: a = 99; break;
}
return 0;
}
```
What I would expect is that `-Wswitch-default` is suppressed when dealing with enums and every case is covered, but active otherwise.
The way it is now, you will miss out on at least one of those three possible cases that require a warning:
- A switch statement that is not handling an enum doesn't have a default case (which is bad)
- A switch statement that is dealing with an enum is fully defined but has a default case (which is bad)
- A switch statement that is dealing with an enum is not fully defined and doesn't have a default case (which is bad)
This was not the case in earlier versions of clang, which handled this correctly.
My version is
```text
Ubuntu clang version 19.0.0 (++20240222031214+307409a8872f-1~exp1~20240222151237.1514)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 82959] [Clang][RISCV]fasynchronous-unwind-tables option enlarge code size
Issue 82959 Summary [Clang][RISCV]fasynchronous-unwind-tables option enlarge code size Labels clang Assignees Reporter Yunzezhu94 According to patch https://reviews.llvm.org/D145164, option fasynchronous-unwind-tables is enabled by default on RISCV and Linux. However, there are situations code size matters that when has -Oz or -Os, and fasynchronous-unwind-tables is still enabled by default, which will generate eh_frame section and enlarge code size. In my opinion disabling fasynchronous-unwind-tables by default on these optimization levels fits idea of reducing code size better. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 82949] [Flang][OpenMP] Incorrect execution result when common block name is specified in copyin clause
Issue
82949
Summary
[Flang][OpenMP] Incorrect execution result when common block name is specified in copyin clause
Labels
openmp,
flang:frontend
Assignees
Reporter
ohno-fj
```
Version of flang-new : 19.0.0(dd7386d85f11cf6ad911b9827c7018fb08c6c205)
```
When `common block` is specified in `copyin` clause, the execution result is incorrect.
The copyin directive appears to be invalid.
The above program is the first program (ompgal036_5.f90).
If a statement referencing an array declared in `common block` is added to `parallel do` construct with `copyin` clause that specifies `common block`, the execution result is correct.
The above program is the second program (ompgal036_52.f90).
The following are the test program, Flang-new, Gfortran and ifort compilation/execution result.
ompgal036_5.f90:
```fortran
program main
integer err
real,dimension(2):: a, b, c
common /blk/ a, b
!$omp threadprivate(/blk/)
a = (/(i,i=1,2)/)
b = (/(i*(i+1)/2,i=1,2)/)
c = 0
!$omp parallel do private(sum), copyin(/blk/)
do i=1, 2
sum = i
call sub(sum, i, c(i))
end do
!$omp end parallel do
err = 0
do i=1, 2
if(c(i) .ne. b(i)) err = err+1
end do
if(err .ne. 0) then
write(6,*) "NG"
else
write(6,*) "OK"
end if
end program main
subroutine sub(sum, i, c)
real,dimension(2):: a, b
common /blk/ a, b
real c
!$omp threadprivate(/blk/)
c = b(i)-a(i)+sum
write(6,*) "sub : b(",i,") = ",b(i), " a(",i,") = ", a(i)
end subroutine sub
```
```
$ export OMP_NUM_THREADS=2; flang-new -fopenmp ompgal036_5.f90; ./a.out
sub : b( 1 ) = 1. a( 1 ) = 1.
sub : b( 2 ) = 0. a( 2 ) = 0.
NG
$
```
```
$ export OMP_NUM_THREADS=2; gfortran -fopenmp ompgal036_5.f90; ./a.out
sub : b( 1 ) =1. a( 1 ) =1.
sub : b( 2 ) =3. a( 2 ) =2.
OK
$
```
```
$ export OMP_NUM_THREADS=2; ifort -qopenmp -diag-disable=10448 ompgal036_5.f90; ./a.out
sub : b( 1 ) =1.00 a( 1 ) = 1.00
sub : b( 2 ) =3.00 a( 2 ) = 2.00
OK
$
```
ompgal036_52.f90:
```fortran
program main
integer err
real,dimension(2):: a, b, c
common /blk/ a, b
!$omp threadprivate(/blk/)
a = (/(i,i=1,2)/)
b = (/(i*(i+1)/2,i=1,2)/)
c = 0
!$omp parallel do private(sum), copyin(/blk/)
do i=1, 2
write(6,*) "main : b(",i,") = ",b(i), " a(",i,") = ", a(i) ! add
sum = i
call sub(sum, i, c(i))
end do
!$omp end parallel do
err = 0
do i=1, 2
if(c(i) .ne. b(i)) err = err+1
end do
if(err .ne. 0) then
write(6,*) "NG"
else
write(6,*) "OK"
end if
end program main
subroutine sub(sum, i, c)
real,dimension(2):: a, b
common /blk/ a, b
real c
!$omp threadprivate(/blk/)
c = b(i)-a(i)+sum
write(6,*) "sub : b(",i,") = ",b(i), " a(",i,") = ", a(i)
end subroutine sub
```
```
$ export OMP_NUM_THREADS=2; flang-new -fopenmp ompgal036_52.f90; ./a.out
main : b( 1 ) = 1. a( 1 ) = 1.
sub : b( 1 ) = 1. a( 1 ) = 1.
main : b( 2 ) = 3. a( 2 ) = 2.
sub : b( 2 ) = 3. a( 2 ) = 2.
OK
$
```
```
$ export OMP_NUM_THREADS=2; gfortran -fopenmp ompgal036_52.f90; ./a.out
main : b( 1 ) =1. a( 1 ) =1.
sub : b( 1 ) =1. a( 1 ) =1.
main : b( 2 ) =3. a( 2 ) = 2.
sub : b( 2 ) =3. a( 2 ) =2.
OK
$
```
```
$ export OMP_NUM_THREADS=2; ifort -qopenmp -diag-disable=10448 ompgal036_52.f90; ./a.out
main : b( 1 ) =1.00 a( 1 ) =1.00
sub : b( 1 ) =1.00 a( 1 ) =1.00
main : b( 2 ) =3.00 a( 2 ) =2.00
sub : b( 2 ) =3.00 a( 2 ) =2.00
OK
$
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 82945] [clang][Diagnostics] Highlighted code snippets render diagnostics unusable
Issue 82945 Summary [clang][Diagnostics] Highlighted code snippets render diagnostics unusable Labels clang Assignees Reporter nabijaczleweli I just got this:  How do I make it not be that? I see no tunable to disable this in 718aac9f7a19227b5c5ec85819a3a5ae24ce32e1 and the thread under #66514 would imply there is, by design, no way! it suggests `-fno-color-diagnostics` which yields  which is also wrong. How does one get normal, usable, diagnostics? Even if you would, for some reason, want this to be the default, why is there seemingly *no way* to disable this? Why was this not a question anyone asked before? ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 82944] [Flang] Abnormal termination of compilation without the error message for wrong initialization for pointer components of derived types
Issue 82944 Summary [Flang] Abnormal termination of compilation without the error message for wrong initialization for pointer components of derived types Labels flang:frontend Assignees Reporter yus3710-fj This is an issue from Fujitsu testsuite. Flang-new terminates abnormally when compiling pointer components initialized with an array pointer. According to Fortran 2018 Standard, the component which has POINTER attribute can't be initialized with a pointer. > C766 A designator that is an initial-data-target shall designate a nonallocatable, noncoindexed variable that has the TARGET and SAVE attributes and does not have a vector subscript. Every subscript, section subscript, substring starting point, and substring ending point in designator shall be a constant _expression_. The following are the test program and the compilation results of flang-new and gfortran. (I believe this program is incorrect, but gfortran-13.2 seems to accept it.) ```fortran ! test.f90 type ty1 integer::tar integer,pointer::ta(:) end type type(ty1),target::obj type ty integer,pointer::ptr3(:)=>obj%ta(2:4) integer,pointer::ptr4=>obj%ta(2) end type ty allocate(obj%ta(5)) obj%ta = [1,2,3,4,5] end ``` ```console $ flang-new -v test.f90 flang-new version 19.0.0git (https://github.com/llvm/llvm-project.git db8b76dbb07d4053a4e44baf1518c9ea0d84c844) Target: aarch64-unknown-linux-gnu Thread model: posix InstalledDir: /path/to/install/bin Found candidate GCC installation: /opt/rh/gcc-toolset-12/root/usr/lib/gcc/aarch64-redhat-linux/12 Selected GCC installation: /opt/rh/gcc-toolset-12/root/usr/lib/gcc/aarch64-redhat-linux/12 Candidate multilib: .;@m64 Selected multilib: .;@m64 "/path/to/install/bin/flang-new" -fc1 -triple aarch64-unknown-linux-gnu -emit-obj -fcolor-diagnostics -mrelocation-model pic -pic-level 2 -pic-is-pie -target-cpu generic -target-feature +outline-atomics -target-feature +v8a -target-feature +fp-armv8 -target-feature +neon -mframe-pointer=non-leaf -o /tmp/test-2173b0.o -x f95-cpp-input test.f90 flang-new: /path/to/llvm-project/llvm/include/llvm/Support/Casting.h:662: decltype(auto) llvm::dyn_cast(From*) [with To = mlir::omp::OutlineableOpenMPOpInterface; From = mlir::Operation]: Assertion `detail::isPresent(Val) && "dyn_cast on a non-existent value"' failed. PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. Stack dump: 0. Program arguments: /path/to/install/bin/flang-new -fc1 -triple aarch64-unknown-linux-gnu -emit-obj -fcolor-diagnostics -mrelocation-model pic -pic-level 2 -pic-is-pie -target-cpu generic -target-feature +outline-atomics -target-feature +v8a -target-feature +fp-armv8 -target-feature +neon -mframe-pointer=non-leaf -o /tmp/test-38fefe.o -x f95-cpp-input test.f90 #0 0xa8076dc8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/path/to/install/lib/libLLVMSupport.so.19git+0x1a6dc8) #1 0xa8074cf8 llvm::sys::RunSignalHandlers() (/path/to/install/lib/libLLVMSupport.so.19git+0x1a4cf8) #2 0xa8074e7c SignalHandler(int) Signals.cpp:0:0 #3 0xaaa407a0 (linux-vdso.so.1+0x7a0) #4 0xa7ac6274 raise (/lib64/libc.so.6+0x36274) #5 0xa7ab0a2c abort (/lib64/libc.so.6+0x20a2c) #6 0xa7abfba0 __assert_fail_base (/lib64/libc.so.6+0x2fba0) #7 0xa7abfc18 __assert_perror_fail (/lib64/libc.so.6+0x2fc18) #8 0x9ef1eb78 (anonymous namespace)::FIROpConversion::getBlockForAllocaInsert(mlir::Operation*) CodeGen.cpp:0:0 #9 0x9ef1eb24 (anonymous namespace)::FIROpConversion::getBlockForAllocaInsert(mlir::Operation*) CodeGen.cpp:0:0 #10 0x9ef1eb24 (anonymous namespace)::FIROpConversion::getBlockForAllocaInsert(mlir::Operation*) CodeGen.cpp:0:0 #11 0x9ef2da94 LoadOpConversion::matchAndRewrite(fir::LoadOp, fir::LoadOpAdaptor, mlir::ConversionPatternRewriter&) const crtstuff.c:0:0 #12 0x9ef238d4 mlir::ConvertOpToLLVMPattern::matchAndRewrite(mlir::Operation*, llvm::ArrayRef, mlir::ConversionPatternRewriter&) const crtstuff.c:0:0 #13 0x98c35018 mlir::ConversionPattern::matchAndRewrite(mlir::Operation*, mlir::PatternRewriter&) const (/path/to/install/lib/libMLIRTransformUtils.so.19git+0x35018) #14 0x98b99b28 mlir::PatternApplicator::matchAndRewrite(mlir::Operation*, mlir::PatternRewriter&, llvm::function_ref, llvm::function_ref, llvm::function_ref) (/path/to/install/lib/libMLIRRewrite.so.19git+0x9b28) #15 0x98c405b0 (anonymous namespace)::OperationLegalizer::legalize(mlir::Operation*, mlir::ConversionPatternRewriter&) DialectConversion.cpp:0:0 #16 0x98c42158 (anonymous namespace)::OperationConverter::convertOperations(llvm::ArrayRef, llvm::function_ref) DialectConversion.cpp:0:0 #17 0x98c437a4 mlir::applyFullCon
[llvm-bugs] [Bug 82941] "1st argument ('__restrict int') would lose restrict qualifier" when passing (this restrict *)->int to int& argument
Issue
82941
Summary
"1st argument ('__restrict int') would lose restrict qualifier" when passing (this restrict *)->int to int& argument
Labels
new issue
Assignees
Reporter
nabijaczleweli
```cpp
void f(int& x) {
(void)x;
}
class C {
int x;
void g() __restrict;
};
void C::g() __restrict {
f(this->x);
}
```
(same for `void f(int const& x)`) compiles fine on GCC, but Clang 17 and 19.0.0 (++20240212105217+93cdd1b5cfa3-1\~exp1\~20240212225341.524) rejects it with
```
a.cpp:11:5: error: no matching function for call to 'f'
11 | f(this->x);
| ^
a.cpp:1:6: note: candidate function not viable: 1st argument ('__restrict int') would lose restrict qualifier
1 | void f(int& x) {
| ^ ~~
1 error generated.
```
I don't think this is valid – this looks like `this` is of type `C restrict *`, and thus `x` is compatible with `int restrict &`, and it's treating restrict like a cv-qualifier, which I don't think it is, and even if it were I haven't found a position where you *could* make f take an `int restrict &` (which I don't think makes much sense given reference validity semantics and the C++ object model).
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 82939] Merge 9e7c0b1385baa1acffb62e0589ff100dd972cc0d into 18.x
Issue 82939 Summary Merge 9e7c0b1385baa1acffb62e0589ff100dd972cc0d into 18.x Labels new issue Assignees Reporter brad0 [OpenMP] Implement __kmp_is_address_mapped on DragonFlyBSD. (https://github.com/llvm/llvm-project/pull/82895) implement internal __kmp_is_address_mapped. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 82937] AMDGPU: Wrong code for fcanonicalize
Issue
82937
Summary
AMDGPU: Wrong code for fcanonicalize
Labels
new issue
Assignees
Reporter
hvdijk
Please consider this minimal LLVM IR:
```llvm
define half @f(half %x) {
%canonicalized = call half @llvm.canonicalize.f16(half %x)
ret half %canonicalized
}
```
Run with `llc -mtriple=amdgcn` and we get:
```asm
f: ; @f
s_waitcnt vmcnt(0) expcnt(0) lgkmcnt(0)
s_setpc_b64 s[30:31]
```
The `canonicalize` operation has been entirely optimised away.
The reason for this is we get during ISel:
```
t0: ch,glue = EntryToken
t2: f32,ch = CopyFromReg # D:1 t0, Register:f32 %0
t4: f16 = fp_round # D:1 t2, TargetConstant:i64<1>
t5: f16 = fcanonicalize # D:1 t4
t6: f32 = fp_extend # D:1 t5
t8: ch,glue = CopyToReg # D:1 t0, Register:f32 $vgpr0, t6
t9: ch = RET_GLUE # D:1 t8, Register:f32 $vgpr0, t8:1
```
Here, `fcanonicalize` is optimised away because `SITargetLowering::isCanonicalized` determines that `fp_round` is guaranteed to return an already-canonicalised result, so no work is needed, but that then leaves us with `fp_extend (fp_round x, /*strict=*/1)` which is optimised to a no-op.
This prevents another optimisation from going in (#80520) which makes this problem show up in more cases than it currently does, and sadly I struggle to find a good way of ensuring we get correct code for this case without also making codegen for other tests worse.
@llvm/pr-subscribers-backend-amdgpu
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 82936] simd vectorization regression starting with clang 14
Issue 82936 Summary simd vectorization regression starting with clang 14 Labels clang Assignees Reporter nschaeff A simple loop multiplying two arrays, with different multiplicity fails to vectorize efficiently on clang 14+, while it worked with clang 13.0.1 The loop is the following, where 4 consecutive values in data are multiplied by the same factor : ```C 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 82926] [Clang] Crash in Itanium mangler
Issue
82926
Summary
[Clang] Crash in Itanium mangler
Labels
clang:frontend,
crash-on-valid
Assignees
Reporter
philnik777
```c++
template
using __simd_vector __attribute__((__ext_vector_type__(1))) = _Tp;
template
using __simd_vector_underlying_type_t
= decltype([](__simd_vector<_Tp>) {}(_VecT {}), 1);
template
void temp()
{
[](__simd_vector_underlying_type_t<_VecT>) {};
}
void call()
{
::temp<::__simd_vector>();
}
```
This causes Clang to crash, but I'm not really sure why. (https://godbolt.org/z/Tz9vEq4h5)
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 82924] Backport "[FlattenCFG] Fix the miscompilation where phi nodes exist in the merge point" to release/18.x
Issue 82924 Summary Backport "[FlattenCFG] Fix the miscompilation where phi nodes exist in the merge point" to release/18.x Labels release:backport, llvm:transforms Assignees arsenm, tstellar, nikic Reporter dtcxzyw /cherry-pick f920b746ea818f1d21f317116cbb105e3e85979a ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 82918] [clang] Captured structured binding is wrongly considered a bitfield
Issue
82918
Summary
[clang] Captured structured binding is wrongly considered a bitfield
Labels
clang
Assignees
Reporter
Rajveer100
```C++
struct S {
unsigned short i:2;
};
int main() {
auto [i] = S();
(void) [i]() mutable { i = 42; };
}
```
In the above snippet, assignment `i = 42` produces a false warning:
```
warning: implicit truncation from 'int' to bit-field changes value from 42 to 2 [-Wbitfield-constant-conversion]
6 | (void) [i]() mutable { i = 42; };
| ^ ~~
```
The `i` being assigned is the captured binding as the lambda function's parameter.
[GodBolt](https://godbolt.org/z/dTbneKG46)
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 82917] Clang crashes when having destructor called inside `__except` block with`--async-exceptions`
Issue 82917 Summary Clang crashes when having destructor called inside `__except` block with`--async-exceptions` Labels clang Assignees Reporter m4arhz Here is the code and options I used to reproduce the problem: https://godbolt.org/z/8r8TYsbq7 While the code crashes at `calculateSEHStateForAsynchEH` I believe the actual problem is at `EHScopeStack`. There are two type of `SEH` scopes, `llvm.seh.try` and `llvm.seh.scope`, the problem seem to be that the scope of the temporary starts with `llvm.seh.scope.begin` and ends with `llvm.seh.try.end` which causes the crash. Anyone knows which type of `SEH` scope should the temporary have? ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 65993 in oss-fuzz: llvm: Fuzzing build failure
Comment #6 on issue 65993 by ClusterFuzz-External: llvm: Fuzzing build failure https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=65993#c6 Friendly reminder that the build is still failing. Please try to fix this failure to ensure that fuzzing remains productive. Latest build log: https://oss-fuzz-build-logs.storage.googleapis.com/log-fc0d2006-d934-4677-8be8-62556f5537a7.txt -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 82916] [AArch64] llvm has more add intructions to update the array index
Issue
82916
Summary
[AArch64] llvm has more add intructions to update the array index
Labels
new issue
Assignees
Reporter
vfdff
* https://gcc.godbolt.org/z/8rcKrrr33
``
#include
#include
using namespace std;
void cmul2 (complex * __restrict a,
complex * __restrict b,
complex * __restrict c) {
for (int i=0; i<1000; i++) {
c[i] = a[i] * b[i];
}
}`
```
* gcc:
```
cmul2(std::complex*, std::complex*, std::complex*):
mov x3, 16000
add x3, x2, x3
.L2:
ld2 {v30.2d - v31.2d}, [x0], 32
ld2 {v28.2d - v29.2d}, [x1], 32
fmulv27.2d, v31.2d, v28.2d
fmulv26.2d, v30.2d, v28.2d
fmlav27.2d, v30.2d, v29.2d
fmlsv26.2d, v29.2d, v31.2d
st2 {v26.2d - v27.2d}, [x2], 32
cmp x3, x2
bne .L2
ret
```
*llvm:
```
cmul2(std::complex*, std::complex*, std::complex*): // @cmul2(std::complex*, std::complex*, std::complex*)
mov x8, #-16000 // =0xc180
mov w9, #16000 // =0x3e80
.LBB0_1:// =>This Inner Loop Header: Depth=1
add x10, x0, x8
add x11, x1, x8
add x10, x10, x9
add x11, x11, x9
ld2 { v0.2d, v1.2d }, [x10]
ld2 { v2.2d, v3.2d }, [x11]
add x10, x2, x8
add x10, x10, x9
addsx8, x8, #32
fmulv4.2d, v2.2d, v0.2d
fmul v5.2d, v2.2d, v1.2d
fmlsv4.2d, v3.2d, v1.2d
fmla v5.2d, v3.2d, v0.2d
st2 { v4.2d, v5.2d }, [x10]
b.ne.LBB0_1
ret
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 82915] Help: Error reported for a thousand times, literally: IMPORTED_IMPLIB not set for imported target
Issue 82915 Summary Help: Error reported for a thousand times, literally: IMPORTED_IMPLIB not set for imported target Labels Assignees Reporter Stehsaer ## Behavior 1. Configure LLVM with cmake 2. `Configuring done (90.7s)` is reported 3. Reports error ``` CMake Error in CMakeLists.txt: IMPORTED_IMPLIB not set for imported target "zstd::libzstd_shared" configuration "Release". ``` for **A THOUSAND TIMES**, literally 4. Reports `Generating done (35.3s)`, then reports `CMake Generate step failed. Build files cannot be regenerated correctly.` ## Additional Info ### Command args ```bat C:\Program Files\CMake\bin\cmake.EXE" --no-warn-unused-cli "-DLLVM_ENABLE_PROJECTS=clang;clang-tools-extra" -DLLVM_TARGETS_TO_BUILD=X86 -DLLVM_USE_LINKER=lld -DCLANG_ENABLE_CLANGD=1 -DLLVM_HOST_TRIPLE=x86_64 -DCMAKE_BUILD_TYPE:STRING=Release -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE -DCMAKE_TOOLCHAIN_FILE:STRING=D:/Tools/vcpkg/scripts/buildsystems/vcpkg.cmake -DVCPKG_TARGET_TRIPLET:STRING=x64-windows -DCMAKE_C_COMPILER:FILEPATH=C:\Users\Lenovo\mingw64\bin\gcc.exe -DCMAKE_CXX_COMPILER:FILEPATH=C:\Users\Lenovo\mingw64\bin\g++.exe -SE:/git-proj/llvm-project-release-18.x/llvm -Be:/git-proj/llvm-project-release-18.x/build -G "MinGW Makefiles" ``` ### System Info Windows 11 Professional 64-bit, x86_64 arch cpu ### Weird thing The codebase is modified, but only 2 source files of `clangd` sub-project. No CMake-related file was modified. It could be configured successfully 2 weeks ago, but now it is generating errors. I don't know why and feel confused. ### Full Log [log.txt](https://github.com/llvm/llvm-project/files/14395999/log.txt) ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 82913] [Flang][OpenMP] fatal internal error: SemanticsContext::FindScope(): invalid source location for 'end subroutine'
Issue 82913 Summary [Flang][OpenMP] fatal internal error: SemanticsContext::FindScope(): invalid source location for 'end subroutine' Labels flang Assignees Reporter k-arrows Compiling the following program with `-fopenmp` causes a crash. ```console $ cat test.f90 impure elemental module subroutine e() end subroutine ``` Compile with: `flang-new -fopenmp test.f90` Output: ```console fatal internal error: SemanticsContext::FindScope(): invalid source location for 'end subroutine' ``` Stack dump (see Godbolt: https://godbolt.org/z/bzY8xPz7Y) ```console #0 0x0355b248 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-llvmflang-trunk-20240225/bin/flang-new+0x355b248) #1 0x03558bbc SignalHandler(int) Signals.cpp:0:0 #2 0x7f0e69e42520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520) #3 0x7f0e69e969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc) #4 0x7f0e69e42476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476) #5 0x7f0e69e287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3) #6 0x049f4339 (/opt/compiler-explorer/clang-llvmflang-trunk-20240225/bin/flang-new+0x49f4339) #7 0x03e87dd9 (/opt/compiler-explorer/clang-llvmflang-trunk-20240225/bin/flang-new+0x3e87dd9) #8 0x040b2b16 Fortran::semantics::ResolveOmpTopLevelParts(Fortran::semantics::SemanticsContext&, Fortran::parser::Program const&) (/opt/compiler-explorer/clang-llvmflang-trunk-20240225/bin/flang-new+0x40b2b16) #9 0x03e67c78 Fortran::semantics::ResolveNames(Fortran::semantics::SemanticsContext&, Fortran::parser::Program const&, Fortran::semantics::Scope&) (/opt/compiler-explorer/clang-llvmflang-trunk-20240225/bin/flang-new+0x3e67c78) #10 0x03ebe491 Fortran::semantics::Semantics::Perform() (/opt/compiler-explorer/clang-llvmflang-trunk-20240225/bin/flang-new+0x3ebe491) #11 0x0359e097 Fortran::frontend::FrontendAction::runSemanticChecks() (/opt/compiler-explorer/clang-llvmflang-trunk-20240225/bin/flang-new+0x359e097) #12 0x038bfe00 Fortran::frontend::CodeGenAction::beginSourceFileAction() (/opt/compiler-explorer/clang-llvmflang-trunk-20240225/bin/flang-new+0x38bfe00) #13 0x0359d695 Fortran::frontend::FrontendAction::beginSourceFile(Fortran::frontend::CompilerInstance&, Fortran::frontend::FrontendInputFile const&) (/opt/compiler-explorer/clang-llvmflang-trunk-20240225/bin/flang-new+0x359d695) #14 0x0358d437 Fortran::frontend::CompilerInstance::executeAction(Fortran::frontend::FrontendAction&) (/opt/compiler-explorer/clang-llvmflang-trunk-20240225/bin/flang-new+0x358d437) #15 0x035a38fd Fortran::frontend::executeCompilerInvocation(Fortran::frontend::CompilerInstance*) (/opt/compiler-explorer/clang-llvmflang-trunk-20240225/bin/flang-new+0x35a38fd) #16 0x01d6bfa8 fc1_main(llvm::ArrayRef, char const*) (/opt/compiler-explorer/clang-llvmflang-trunk-20240225/bin/flang-new+0x1d6bfa8) #17 0x01c7124d main (/opt/compiler-explorer/clang-llvmflang-trunk-20240225/bin/flang-new+0x1c7124d) #18 0x7f0e69e29d90 (/lib/x86_64-linux-gnu/libc.so.6+0x29d90) #19 0x7f0e69e29e40 __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x29e40) #20 0x01d6aeee _start (/opt/compiler-explorer/clang-llvmflang-trunk-20240225/bin/flang-new+0x1d6aeee) flang-new: error: unable to execute command: Aborted (core dumped) flang-new: error: flang frontend command failed due to signal (use -v to see invocation) flang-new version 19.0.0git (https://github.com/llvm/llvm-project.git 1e98d4883d78ac2c65b87e24694e8b2f1dc9f02d) Target: x86_64-unknown-linux-gnu Thread model: posix ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
