[llvm-bugs] [Bug 82910] Clang Static Analyzer has issues with handling floating-point numbers
Issue
82910
Summary
Clang Static Analyzer has issues with handling floating-point numbers
Labels
clang
Assignees
Reporter
tianxinghe
version: clang17.0.1
It seems that CSA has problems handling floating-point operations.
https://godbolt.org/z/37T31jzY3
#include
int llvm_fcmp_one(double X, double Y) {
int res = (X != Y && X == X && Y == Y);
return res;
}
int main(int argc, char ** argv) {
int *llvm_cbe_a46 = ((int *)/*NULL*/0);
if (llvm_fcmp_one(744753600, 41) != 0) {
printf("%d\n", *llvm_cbe_a46);
}
return 1;
}
When the formal parameter is of type int, the checker can correctly find the bug.
https://godbolt.org/z/xx769hYjo
#include
int llvm_fcmp_one(int X, int Y) {
int res = (X != Y && X == X && Y == Y);
return res;
}
int main(int argc, char ** argv) {
int *llvm_cbe_a46 = ((int *)/*NULL*/0);
if (llvm_fcmp_one(744753600, 41) != 0) {
printf("%d\n", *llvm_cbe_a46);
}
return 1;
}
___
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
[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 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 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] [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 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 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 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 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 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 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 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 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 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 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 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 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 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 82969] [clang-format] How to obtain the minimum library file or executable file for the clang-format
Issue 82969 Summary [clang-format] How to obtain the minimum library file or executable file for the clang-format Labels clang-format Assignees Reporter Gaochenchang In order to make it more suitable for my project format, I made some customized modifications to the output results of the clang format using Python. But when I was packaging with "pyinstaller", I encountered a problem: the clang was too large, I only needed the clang format feature. How should I do it? 1. May I know why the official library for clang format is not released separately? 2. Can I only build my own clang format for such needs? What should I do if that's the case? ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 82970] clang-tidy: cppcoreguidelines-prefer-member-initializer doesn't understand structured binding
Issue
82970
Summary
clang-tidy: cppcoreguidelines-prefer-member-initializer doesn't understand structured binding
Labels
clang-tidy
Assignees
Reporter
FalcoGer
Consider this code:
```c++
#include
class C
{
private:
int m_data1;
double m_data2;
public:
C(const float f)
{
auto [i, d] = Create(f);
m_data1 = i;
//
// 'm_data1' should be initialized in a member initializer of the constructor (fix available) (clang-tidy cppcoreguidelines-prefer-member-initializer)
m_data2 = d;
//
// 'm_data2' should be initialized in a member initializer of the constructor (fix available) (clang-tidy cppcoreguidelines-prefer-member-initializer)
}
static auto Create(const float f) -> std::tuple
{
return {static_cast(f), static_cast(f)};
}
};
auto main() -> int
{
const float MAGIC = 3.1415F;
C c(MAGIC);
return 0;
}
```
clang tidy flags those members as being able to be done through the initializer list. however that is not true. when applying the quick fix, it will produce something like this:
```c++
C(const float f) : m_data1(i), m_data2(d)
{
auto [i, d] = Create(f);
}
```
Which of course is invalid.
current version:
```text
Ubuntu LLVM version 19.0.0
Optimized build.
```
from
```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 82972] warn/error for "enum-int-mismatch" missing
Issue 82972 Summary warn/error for "enum-int-mismatch" missing Labels new issue Assignees Reporter rscheff I've just been bitten by an issue around implicit type conversion from an enum type to an int(32) type... Apparently, function definitions in clang, where an enum is passed in an int32 variable are implicitly acceptable. However, gcc13 (not gcc12) does bark with -Wenum-int-mismatch when no explicit type conversion is made, or rather, the function definitions need to have the correct type when passing enum along... Would it be possible to enable more strict warning / error checking, when implicit typecasts between enum/int are happening, or when a function header should have an enum, but does define an int where an enum is passed? On gcc13, this seems to be the relevant switch: enum-int-mismatch ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 82974] clang-tidy: cppcoreguidelines-pro-type-member-init doesn't understand initialization through references
Issue
82974
Summary
clang-tidy: cppcoreguidelines-pro-type-member-init doesn't understand initialization through references
Labels
clang-tidy
Assignees
Reporter
FalcoGer
Consider this code:
```c++
#include
class C
{
private:
int m_data1;
double m_data2;
public:
explicit C(const float NUMBER)
//
// Constructor does not initialize these fields: m_data1, m_data2 (fix available) (clang-tidy cppcoreguidelines-pro-type-member-init)
{
std::tie(m_data1, m_data2) = Create(NUMBER);
}
static auto Create(const float NUMBER) -> std::tuple
{
return {static_cast(NUMBER), static_cast(NUMBER)};
}
};
auto main() -> int
{
const float MAGIC = 3.1415F;
C c(MAGIC);
return 0;
}
```
clang-tidy emits a diagnostic that the variables are not initialized, but they are.
clang version
```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 82978] [MLIR] Feature request: Last opeartion accessor in blocks in C API
Issue 82978 Summary [MLIR] Feature request: Last opeartion accessor in blocks in C API Labels Assignees Reporter raviqqe Currently, the C API exposes only the `mlirBlockGetFirstOperation` function which corresponds to the `block->front()` C++ API but not the `mlirBlockGetLastOperation` function which corresponds to `block->back()`. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 82982] COMPILETIME ERROR, llvm-17, vector <8 x i3>, insertelement instruction after load, code emition
Issue
82982
Summary
COMPILETIME ERROR, llvm-17, vector <8 x i3>, insertelement instruction after load, code emition
Labels
new issue
Assignees
Reporter
sidtvera
Compiletime error for vector <8 x i3>
[vec8i3.zip](https://github.com/llvm/llvm-project/files/14403412/vec8i3.zip)
```
$ clang -O1 -S vec8i3.ll
```
In function ScheduleDAGMILive::updatePressureDiffs for test-function @ins2:
```
4 libLLVM-17.so.10x7f4e50cf92f7 llvm::ScheduleDAGMILive::updatePressureDiffs(llvm::ArrayRef) + 1351
5 libLLVM-17.so.10x7f4e50cf9f1a llvm::ScheduleDAGMILive::scheduleMI(llvm::SUnit*, bool) + 1146
6 libLLVM-17.so.10x7f4e50cf98b1 llvm::ScheduleDAGMILive::schedule() + 337
```
Problem test function:
```
define void @ins2( <8 x i3>* %a, i3 %b, i32 %c) {
%x = load <8 x i3>, <8 x i3>* %a
%y = insertelement <8 x i3> %y, i3 %b, i32 %c
store <8 x i3> %y, <8 x i3>* %a
ret void
}
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 82991] clang crashes at -O3 on x86_64-linux-gnu: Assertion `IterCnt++ < 1000 && "Iterative simplification didn't converge!"' failed
Issue 82991 Summary clang crashes at -O3 on x86_64-linux-gnu: Assertion `IterCnt++ < 1000 && "Iterative simplification didn't converge!"' failed Labels clang Assignees Reporter zhendongsu Compiler Explorer: https://godbolt.org/z/TqEef4nqx ``` [513] % clangtk -v clang version 19.0.0git (https://github.com/llvm/llvm-project.git cace477c0b6c3d9494ead66eb725c6e72f27b767) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /local/suz-local/opfuzz/bin Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/10 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/11 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/9 Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/11 Candidate multilib: .;@m64 Selected multilib: .;@m64 [514] % [514] % clangtk -O3 small.c clang-19: /local/suz-local/software/clangbuild/llvm-project/llvm/lib/Transforms/Scalar/SimplifyCFGPass.cpp:240: bool iterativelySimplifyCFG(llvm::Function&, const llvm::TargetTransformInfo&, llvm::DomTreeUpdater*, const llvm::SimplifyCFGOptions&): Assertion `IterCnt++ < 1000 && "Iterative simplification didn't converge!"' 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: /local/suz-local/software/local/clang-trunk/bin/clang-19 -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -dumpdir a- -disable-free -clear-ast-before-backend -main-file-name small.c -mrelocation-model pic -pic-level 2 -pic-is-pie -mframe-pointer=none -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=/local/suz-local/software/emitesting/bugs/20240226-clangtk-m64-O3-Weverything-pipe-fPIC-build-071957/delta -fcoverage-compilation-dir=/local/suz-local/software/emitesting/bugs/20240226-clangtk-m64-O3-Weverything-pipe-fPIC-build-071957/delta -resource-dir /local/suz-local/software/local/clang-trunk/lib/clang/19 -I /usr/local/include -I /local/suz-local/software/local/include -internal-isystem /local/suz-local/software/local/clang-trunk/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 -O3 -ferror-limit 19 -fgnuc-version=4.2.1 -fskip-odr-check-in-gmf -fcolor-diagnostics -vectorize-loops -vectorize-slp -faddrsig -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o /tmp/small-737e6e.o -x c small.c 1. parser at end of file 2. Optimizer #0 0x561f16efdc8f llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/local/suz-local/software/local/clang-trunk/bin/clang-19+0x3f5cc8f) #1 0x561f16efb1b4 SignalHandler(int) Signals.cpp:0:0 #2 0x7f2d5caea420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420) #3 0x7f2d5c4f100b raise /build/glibc-wuryBv/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:51:1 #4 0x7f2d5c4d0859 abort /build/glibc-wuryBv/glibc-2.31/stdlib/abort.c:81:7 #5 0x7f2d5c4d0729 get_sysdep_segment_value /build/glibc-wuryBv/glibc-2.31/intl/loadmsgcat.c:509:8 #6 0x7f2d5c4d0729 _nl_load_domain /build/glibc-wuryBv/glibc-2.31/intl/loadmsgcat.c:970:34 #7 0x7f2d5c4e1fd6 (/lib/x86_64-linux-gnu/libc.so.6+0x33fd6) #8 0x561f16dd66e2 iterativelySimplifyCFG(llvm::Function&, llvm::TargetTransformInfo const&, llvm::DomTreeUpdater*, llvm::SimplifyCFGOptions const&) SimplifyCFGPass.cpp:0:0 #9 0x561f16dd78b0 simplifyFunctionCFGImpl(llvm::Function&, llvm::TargetTransformInfo const&, llvm::DominatorTree*, llvm::SimplifyCFGOptions const&) SimplifyCFGPass.cpp:0:0 #10 0x561f16dd8015 simplifyFunctionCFG(llvm::Function&, llvm::TargetTransformInfo const&, llvm::DominatorTree*, llvm::SimplifyCFGOptions const&) SimplifyCFGPass.cpp:0:0 #11 0x561f16dd81aa llvm::SimplifyCFGPass::run(llvm::Function&, llvm::AnalysisManager&) (/local/suz-local/software/local/clang-trunk/bin/clang-19+0x3e371aa) #12 0x561f14de61f6 llvm::detail::PassModel>::run(llvm::Function&, llvm::AnalysisManager&) (/local/suz-local/software/local/clang-trunk/bin/clang-19+0x1e451f6) #13 0x561f145af12d llvm::detail::PassModel>, llvm::AnalysisManager>::run(llvm::Function&, llvm::AnalysisManager&) (/local/suz-local/software/local/clang-trunk/bin/clang-19+0x160e12d) #14 0x561f15df4551 llvm::CGSCCToFunctionPassAdaptor::run(llvm::LazyCallGraph::SCC&, llvm::AnalysisManager&, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&) (/local/suz-local/software/local/clang-trunk/bin/clang-19+0x2e53551) #15 0x561f14592b26 llvm::detail::PassModel, llvm::LazyCallGraph&,
[llvm-bugs] [Bug 82994] Permitting static constexpr variables in constexpr functions
Issue 82994 Summary Permitting static constexpr variables in constexpr functions Labels new issue Assignees Reporter mpusz It seems that Clang does not support static constexpr variables in constexpr functions properly: https://godbolt.org/z/fx1jTModK The value of a static constexpr variable set in a constexpr function should be available at runtime. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 82995] C++03 mode ignores the arg in [[attribute(arg)]]
Issue
82995
Summary
C++03 mode ignores the arg in [[attribute(arg)]]
Labels
new issue
Assignees
Reporter
AMP999
https://godbolt.org/z/aPKq1sKPT
`[[gnu::assume_aligned(4)]] static void *g() { return p; }`
In `-std=c++11` mode, this code is accepted and works as expected. In `-std=c++03` mode, it seems to ignore the `(4)` argument for some reason, and I get an error:
```
:5:3: error: 'assume_aligned' attribute takes at least 1 argument
5 | [[gnu::assume_aligned(4)]] static void *g() { return p; }
| ^
```
@philnik777 I think you enabled attributes in 874217f99b; is there something missing to enable attributes with arguments?
The problem is these lines in `ParseCXX11AttributeArgs`.
```
// If the attribute isn't known, we will not attempt to parse any
// arguments.
if (Form.getSyntax() != ParsedAttr::AS_Microsoft &&
!hasAttribute(LO.CPlusPlus ? AttributeCommonInfo::Syntax::AS_CXX11
: AttributeCommonInfo::Syntax::AS_C23,
ScopeName, AttrName, getTargetInfo(), getLangOpts())) {
```
This is reusing the return code of `hasAttribute` to ask whether the attribute is recognized (a boolean). But the machine-generated code in `AttrHasAttributeImpl.inc` uses the return code to say what `__has_cpp_attribute` should be set to (an int), and invariably returns `0` in C++03 mode. https://godbolt.org/z/casKPfdez
```
} else if (ScopeName == "gnu") {
return llvm::StringSwitch(Name)
[...]
.Case("assume_aligned", LangOpts.CPlusPlus11 ? 1 : 0)
```
That file is generated by `clang/utils/TableGen/ClangAttrEmitter.cpp`. Maybe a change is needed in that generator?
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83000] [DebugInfo] UnrollAndJam transformation causes "DebugProgramValues must not appear before PHI nodes in a block!"
Issue 83000 Summary [DebugInfo] UnrollAndJam transformation causes "DebugProgramValues must not appear before PHI nodes in a block!" Labels new issue Assignees Reporter mveriksson Related to #74735 [reduced.ll.gz](https://github.com/llvm/llvm-project/files/14404949/reduced.ll.gz) Running loop-unroll-and-jam on the attached file gives: ``` $ opt -passes='loop-unroll-and-jam' -o /dev/null -allow-unroll-and-jam -unroll-and-jam-count=2 reduced.ll DebugProgramValues must not appear before PHI nodes in a block! Invalid configuration of new-debug-info data found LLVM ERROR: Broken module found, compilation aborted! PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. Stack dump: 0. Program arguments: opt -passes=loop-unroll-and-jam -o /dev/null -allow-unroll-and-jam -unroll-and-jam-count=2 reduced.ll #0 0x5610b5bd0c67 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (opt+0x3dbfc67) #1 0x5610b5bce73e llvm::sys::RunSignalHandlers() (opt+0x3dbd73e) #2 0x5610b5bd162f SignalHandler(int) Signals.cpp:0:0 #3 0x7fb90cb53630 __restore_rt sigaction.c:0:0 #4 0x7fb90a29a387 raise (/lib64/libc.so.6+0x36387) #5 0x7fb90a29ba78 abort (/lib64/libc.so.6+0x37a78) #6 0x5610b5bba2a2 llvm::report_fatal_error(llvm::Twine const&, bool) (opt+0x3da92a2) #7 0x5610b5bba0d6 (opt+0x3da90d6) #8 0x5610b61b6a1b (opt+0x43a5a1b) #9 0x5610b6e5b19d llvm::detail::PassModel>::run(llvm::Module&, llvm::AnalysisManager&) NewPMDriver.cpp:0:0 #10 0x5610b5d91aa6 llvm::PassManager>::run(llvm::Module&, llvm::AnalysisManager&) (opt+0x3f80aa6) #11 0x5610b6e543fb 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+0x50433fb) #12 0x5610b5b991e8 optMain (opt+0x3d881e8) #13 0x7fb90a286555 __libc_start_main (/lib64/libc.so.6+0x22555) #14 0x5610b5b92b29 _start (opt+0x3d81b29) Aborted ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83005] AMDGPU backend fails when using O0 (cannot select load)
Issue 83005 Summary AMDGPU backend fails when using O0 (cannot select load) Labels new issue Assignees Reporter mame98 While playing around with different targets, I noticed a crash when using the `amdgcn` target with the `-O0` option. ## Error ``` fatal error: error in backend: Cannot select: 0x55a4f31d1f40: i32,ch = load<(dereferenceable load (s32) from %ir.7)> # D:1 0x55a4f31d1ed0, 0x55a4f31d2410, undef:i64 0x55a4f31d2410: i64 = bitcast 0x55a4f31d1d10 0x55a4f31d1d10: v2i32 = BUILD_VECTOR FrameIndex:i32<1>, 0x55a4f31d22c0 0x55a4f31d1bc0: i32 = FrameIndex<1> 0x55a4f31d22c0: i32,ch = load<(dereferenceable invariant load (s32), addrspace 4)> 0x55a4f31d1d80:1, 0x55a4f31d2250, undef:i64 0x55a4f31d2250: i64 = add nuw 0x55a4f31d1d80, Constant:i64<68> 0x55a4f31d1d80: i64,ch = CopyFromReg 0x55a4f31646e0, Register:i64 %3 0x55a4f31d1b50: i64 = Register %3 0x55a4f31d21e0: i64 = Constant<68> 0x55a4f31d1df0: i64 = undef 0x55a4f31d1df0: i64 = undef In function: add ``` ## Stack Dump ``` 0. Program arguments: clang simple.c -O0 -S -o- -target amdgcn 1. parser at end of file 2. Code generation 3. Running pass 'CallGraph Pass Manager' on module 'simple.c'. 4. Running pass 'AMDGPU DAG->DAG Pattern Instruction Selection' on function '@add' #0 0x7fb97e21f503 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/usr/lib/libLLVM-16.so+0xe1f503) #1 0x7fb97e21c7bf llvm::sys::RunSignalHandlers() (/usr/lib/libLLVM-16.so+0xe1c7bf) #2 0x7fb97e108d9a llvm::CrashRecoveryContext::HandleExit(int) (/usr/lib/libLLVM-16.so+0xd08d9a) #3 0x7fb97e2158d4 llvm::sys::Process::Exit(int, bool) (/usr/lib/libLLVM-16.so+0xe158d4) #4 0x55a4f2032463 (/usr/bin/clang-16+0xf463) #5 0x7fb97e11f002 llvm::report_fatal_error(llvm::Twine const&, bool) (/usr/lib/libLLVM-16.so+0xd1f002) #6 0x7fb97ecfad4a llvm::SelectionDAGISel::CannotYetSelect(llvm::SDNode*) (/usr/lib/libLLVM-16.so+0x18fad4a) #7 0x7fb97ecfd7ba llvm::SelectionDAGISel::SelectCodeCommon(llvm::SDNode*, unsigned char const*, unsigned int) (/usr/lib/libLLVM-16.so+0x18fd7ba) #8 0x7fb97ecf7f5c llvm::SelectionDAGISel::DoInstructionSelection() (/usr/lib/libLLVM-16.so+0x18f7f5c) #9 0x7fb97ed0268c llvm::SelectionDAGISel::CodeGenAndEmitDAG() (/usr/lib/libLLVM-16.so+0x190268c) #10 0x7fb97ed0592d llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) (/usr/lib/libLLVM-16.so+0x190592d) #11 0x7fb97ed079b6 (/usr/lib/libLLVM-16.so+0x19079b6) #12 0x7fb97e6ea945 (/usr/lib/libLLVM-16.so+0x12ea945) #13 0x7fb97e3ab989 llvm::FPPassManager::runOnFunction(llvm::Function&) (/usr/lib/libLLVM-16.so+0xfab989) #14 0x7fb97fc2aefa (/usr/lib/libLLVM-16.so+0x282aefa) #15 0x7fb97e3ac6ac llvm::legacy::PassManagerImpl::run(llvm::Module&) (/usr/lib/libLLVM-16.so+0xfac6ac) #16 0x7fb986ef3fb3 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::Strin gRef, llvm::Module*, clang::BackendAction, std::unique_ptr>) (/usr/lib/libclang-cpp.so.16+0x16f3fb3) #17 0x7fb987219229 (/usr/lib/libclang-cpp.so.16+0x1a19229) #18 0x7fb9860ecfb0 clang::ParseAST(clang::Sema&, bool, bool) (/usr/lib/libclang-cpp.so.16+0x8ecfb0) #19 0x7fb98791e7c9 clang::FrontendAction::Execute() (/usr/lib/libclang-cpp.so.16+0x211e7c9) #20 0x7fb9878c0d2f clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/usr/lib/libclang-cpp.so.16+0x20c0d2f) #21 0x7fb98797bf02 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/usr/lib/libclang-cpp.so.16+0x217bf02) #22 0x55a4f2037a6f cc1_main(llvm::ArrayRef, char const*, void*) (/usr/bin/clang-16+0x14a6f) #23 0x55a4f203bb10 (/usr/bin/clang-16+0x18b10) #24 0x7fb9875ec779 (/usr/lib/libclang-cpp.so.16+0x1dec779) #25 0x7fb97e108c87 llvm::CrashRecoveryContext::RunSafely(llvm::function_ref) (/usr/lib/libLLVM-16.so+0xd08c87) #26 0x7fb9875f30c4 (/usr/lib/libclang-cpp.so.16+0x1df30c4) #27 0x7fb987611431 clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, clang::driver::Command const*&, bool) const (/usr/lib/libclang-cpp.so.16+0x1e11431) #28 0x7fb9876117ed clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&, llvm::SmallVectorImpl>&, bool) const (/usr/lib/libclang-cpp.so.16+0 x1e117ed) #29 0x7fb9876155dc clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&, llvm::SmallVectorImpl>&) (/usr/lib/libclang-cpp.so.16+0x1e155dc) #30 0x55a4f203e99f clang_main(int, char**) (/usr/bin/clang-16+0x1b99f) #31 0x7fb97ce45cd0 (/usr/lib/libc.so.6+0x27cd0) #32 0x7fb97ce45d8a __libc_start_main (/usr/lib/libc
[llvm-bugs] [Bug 83025] clang-tidy ignores #line directives when reporting diagnostics.
Issue
83025
Summary
clang-tidy ignores #line directives when reporting diagnostics.
Labels
clang-tidy
Assignees
Reporter
matt-gretton-dann
`clang-tidy` is ignoring `#line` directives when reporting diagnostics. This is different behaviour to `clang`.
Given the following test-case (foo.cpp):
```cpp
#line 20 "not-the-file-name.cpp"
int foo(void) {
goto bar;
return 10;
bar:
return 20;
}
```
Running clang-tidy as follows:
`./llvm-project/build/bin/clang-tidy --checks '*' foo.cpp`
Produces the following output:
```text
Error while trying to load a compilation database:
Could not auto-detect compilation database for file "foo.cpp"
No compilation database found in /Users/matgre01/repos or any parent directory
fixed-compilation-database: Error while opening fixed database: No such file or directory
json-compilation-database: Error while opening JSON database: No such file or directory
Running without flags.
9 warnings generated.
/Users/matgre01/repos/foo.cpp:2:5: warning: declaration must be enclosed within the 'LIBC_NAMESPACE' namespace [llvmlibc-implementation-in-namespace]
2 | int foo(void) {
| ^
/Users/matgre01/repos/foo.cpp:2:5: warning: use a trailing return type for this function [modernize-use-trailing-return-type]
2 | int foo(void) {
| ~~~ ^
| auto -> int
/Users/matgre01/repos/foo.cpp:2:9: warning: redundant void argument list in function definition [modernize-redundant-void-arg]
2 | int foo(void) {
| ^~~~
/Users/matgre01/repos/foo.cpp:3:3: warning: avoid using 'goto' for flow control [cppcoreguidelines-avoid-goto,hicpp-avoid-goto]
3 | goto bar;
| ^~~~
/Users/matgre01/repos/foo.cpp:5:1: note: label defined here
5 | bar:
| ^
/Users/matgre01/repos/foo.cpp:4:10: warning: 10 is a magic number; consider replacing it with a named constant [cppcoreguidelines-avoid-magic-numbers,readability-magic-numbers]
4 | return 10;
| ^
/Users/matgre01/repos/foo.cpp:6:10: warning: 20 is a magic number; consider replacing it with a named constant [cppcoreguidelines-avoid-magic-numbers,readability-magic-numbers]
6 | return 20;
| ^
```
Note that the errors are reported as being at lines in `.../foo.cpp` and not `not-the-file-name.cpp` as I would expect.
I have tested and observed this behaviour with clang-tidy built from main (commit e521752c04a479e3751003645a728667f3199d24) and v17.0.6 on a Mac (as shipped with Homebrew).
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83028] [clang-repl] VarDecl emitted outside TopLevelStmtDecl
Issue 83028 Summary [clang-repl] VarDecl emitted outside TopLevelStmtDecl Labels new issue Assignees Reporter weliveindetail Works: ``` $ clang-repl clang-repl> int a = 42; clang-repl> int i = 0; clang-repl> for (; i<42; i+=1) a-=1; clang-repl> %quit ``` Fails: ``` $ clang-repl clang-repl> int a = 42; clang-repl> for(int i=0; i<42; i+=1) a-=1; clang-repl: llvm-project/clang/lib/CodeGen/CGDecl.cpp:161: void clang::CodeGen::CodeGenFunction::EmitDecl(const Decl &): Assertion `VD.isLocalVarDecl() && "Should not see file-scope variables inside a function!"' failed. Aborted (core dumped) ``` Other side-effects include incorrect behavior for definitions inside `if` conditions: ``` $ clang-repl -Xcc -Xclang,-ast-dump clang-repl> int *a=nullptr; TranslationUnitDecl 0xd8962468 prev 0xd893e690 <> `-VarDecl 0xd8962518 col:6 a 'int *' cinit `-ImplicitCastExpr 0xd8962590 'int *' `-CXXNullPtrLiteralExpr 0xd8962580 'std::nullptr_t' clang-repl> if (auto *b=a) *b += 1; TranslationUnitDecl 0xd8962608 prev 0xd8962468 <> |-VarDecl 0xd89626c0 col:11 used b 'int *' cinit | `-ImplicitCastExpr 0xd8986b10 'int *' | `-DeclRefExpr 0xd8962728 'int *' lvalue Var 0xd8962518 'a' 'int *' `-TopLevelStmtDecl 0xd8986cb0 col:1 `-IfStmt 0xd8986c70 has_var |-DeclStmt 0xd8986c98 | `-VarDecl 0xd89626c0 col:11 used b 'int *' cinit | `-ImplicitCastExpr 0xd8986b10 'int *' | `-DeclRefExpr 0xd8962728 'int *' lvalue Var 0xd8962518 'a' 'int *' |-ImplicitCastExpr 0xd8986bb8 'bool' | `-ImplicitCastExpr 0xd8986ba0 'int *' | `-DeclRefExpr 0xd8986b80 'int *' lvalue Var 0xd89626c0 'b' 'int *' `-CompoundAssignOperator 0xd8986c40 'int' lvalue '+=' ComputeLHSTy='int' ComputeResultTy='int' |-UnaryOperator 0xd8986c08 'int' lvalue prefix '*' cannot overflow | `-ImplicitCastExpr 0xd8986bf0 'int *' | `-DeclRefExpr 0xd8986bd0 'int *' lvalue Var 0xd89626c0 'b' 'int *' `-IntegerLiteral 0xd8986c20 'int' 1 clang-repl> if (auto *b=a) *b += 1; In file included from <<< inputs >>>:1: input_line_3:1:11: error: redefinition of 'b' 1 | if (auto *b=a) *b += 1; | ^ <<< inputs >>>:1:1: note: '' included multiple times, additional include site here <<< inputs >>>:1:1: note: '' included multiple times, additional include site here error: Parsing failed. clang-repl> %quit ``` I guess the `VarDecl 0xd89626c0` for `b` should be emitted inside the `TopLevelStmtDecl 0xd8986cb0` or even inside `IfStmt 0xd8986c70`. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83030] Multi-precision addition using `__int128`/`i128` doesn't produce optimal code
Issue
83030
Summary
Multi-precision addition using `__int128`/`i128` doesn't produce optimal code
Labels
new issue
Assignees
Reporter
Eisenwave
https://godbolt.org/z/vovWPxexE
## Expected output
Firstly, the expected "canonical" output which we got both for `_BitInt(512)` additions and `__builtin_addcll` looks as follows:
```cpp
using u128 = unsigned __int128;
using u64 = unsigned long long;
void add_adc(u64* __restrict dest, const u64* a, const u64* b)
{
u64 carry = 0;
for (int i = 0; i < 8; ++i) {
dest[i] = __builtin_addcll(a[i], b[i], carry, &carry);
}
}
```
```asm
add_adc(unsigned long long*, unsigned long long const*, unsigned long long const*): # @add_adc(unsigned long long*, unsigned long long const*, unsigned long long const*)
mov rax, qword ptr [rsi]
add rax, qword ptr [rdx]
mov qword ptr [rdi], rax
mov rax, qword ptr [rsi + 8]
adc rax, qword ptr [rdx + 8]
mov qword ptr [rdi + 8], rax
mov rax, qword ptr [rsi + 16]
adc rax, qword ptr [rdx + 16]
mov qword ptr [rdi + 16], rax
mov rax, qword ptr [rsi + 24]
adc rax, qword ptr [rdx + 24]
mov qword ptr [rdi + 24], rax
mov rax, qword ptr [rsi + 32]
adc rax, qword ptr [rdx + 32]
mov qword ptr [rdi + 32], rax
mov rax, qword ptr [rsi + 40]
adc rax, qword ptr [rdx + 40]
mov qword ptr [rdi + 40], rax
mov rax, qword ptr [rsi + 48]
adc rax, qword ptr [rdx + 48]
mov qword ptr [rdi + 48], rax
mov rax, qword ptr [rsi + 56]
adc rax, qword ptr [rdx + 56]
mov qword ptr [rdi + 56], rax
ret
```
We get one `adc` per loop iteration, which is the theoretical optimum here.
## Actual output for 128-bit integers
When attempting to get the same codegen with 128-bit addition, we don't get the optimum:
```cpp
void add_128(u64* __restrict dest, const u64* a, const u64* b)
{
u64 carry = 0;
for (int i = 0; i < 8; ++i) {
auto sum = u128(carry) + a[i] + b[i];
dest[i] = sum;
carry = sum >> 64;
}
}
```
This compiles to:
```asm
add_128(unsigned long long*, unsigned long long const*, unsigned long long const*):
mov rax, qword ptr [rsi]
add rax, qword ptr [rdx]
mov qword ptr [rdi], rax
mov rax, qword ptr [rsi + 8]
adc rax, 0
setb cl
movzx ecx, cl
add rax, qword ptr [rdx + 8]
mov qword ptr [rdi + 8], rax
adc rcx, qword ptr [rsi + 16]
setb al
movzx eax, al
add rcx, qword ptr [rdx + 16]
mov qword ptr [rdi + 16], rcx
adc rax, qword ptr [rsi + 24]
setb cl
movzx ecx, cl
add rax, qword ptr [rdx + 24]
mov qword ptr [rdi + 24], rax
adc rcx, qword ptr [rsi + 32]
setb al
movzx eax, al
add rcx, qword ptr [rdx + 32]
mov qword ptr [rdi + 32], rcx
adc rax, qword ptr [rsi + 40]
setb cl
movzx ecx, cl
add rax, qword ptr [rdx + 40]
mov qword ptr [rdi + 40], rax
adc rcx, qword ptr [rsi + 48]
setb al
movzx eax, al
add rcx, qword ptr [rdx + 48]
mov qword ptr [rdi + 48], rcx
adc rax, qword ptr [rsi + 56]
add rax, qword ptr [rdx + 56]
mov qword ptr [rdi + 56], rax
ret
```
LLVM emits `adc` here, however, two per loop iteration.
Basically, `u128(carry) + a[i] + b[i]` turns into:
```asm
adc rcx, qword ptr [rsi + 16] ; TMP = u128(carry) + a[i]
setb al ; carry = CARRY_FLAG
movzx eax, al ; carry = ZERO_EXTEND(carry)
add rcx, qword ptr [rdx + 16] ; SUM = TMP + b[i]
mov qword ptr [rdi + 16], rcx ; dest[i] = SUM
adc rax, qword ptr [rsi + 24] ; TMP = u128(carry) + a[i]
; ...
```
Well, it doesn't quite translate into that and it's a bit interleaved, but overall, we need two additions per iteration and instead of keeping the carry in the carry CPU flag at all times, it's being "spilled" into a register.
## Relevant passes
Prior to x86 instruction selection, the `adc` variant still uses two additions per iteration:
```llvm
%8 = tail call { i64, i1 } @llvm.uadd.with.overflow.i64(i64 %6, i64 %7)
%9 = extractvalue { i64, i1 } %8, 1
%10 = extractvalue { i64, i1 } %8, 0
%11 = tail call { i64, i1 } @llvm.uadd.with.overflow.i64(i64 %10, i64 %5)
%12 = extractvalue { i64, i1 } %11, 1
%13 = extractvalue { i64, i1 } %11, 0
```
x86-isel combines these into
```llvm
%4:gr64 = ADD64rm %3:gr64(tied-def 0), %2:gr64, 1, $noreg, 0, $noreg, implicit-def $eflags :: (load (s64) from %ir.b); example.cpp:18:19
```
The 128-bit variant prior to instruction selection looks like this, per iteration:
```llvm
%conv.1 = zext i1 %ov to i128
%arrayidx.1 = getelementptr inbounds i8, ptr %a, i64 8
%3 = load i64, ptr %arrayidx.1, align 8
%conv1.1 = zext i64 %3 to i128
%add.1 = add nuw nsw i128 %conv1.1, %conv.1
%arrayidx3.1 = getelementptr inbounds i8, ptr %b, i64 8
%4 = load i64, ptr %arrayidx3.1, align 8
%conv4.1 = zext i64 %4 to i128
```
Presumably, the `i128` addition would already need to be
[llvm-bugs] [Bug 83040] Crash in install_bad_alloc_error_handler
Issue
83040
Summary
Crash in install_bad_alloc_error_handler
Labels
new issue
Assignees
Reporter
fabianbs96
The function `install_bad_alloc_error_handler` asserts that a bad_alloc error handler is not already installed.
However, it actually checks for the fatal-error handler, not for the bad_alloc error handler, causing an assertion failure if a fatal-error handler is already installed.
Correct behavior would be to only crash if a bad_alloc handler is already installed, making it independent from fatal-error handlers.
Minimal working example:
```C++
#include
int main() {
llvm::install_fatal_error_handler([](void*,const char*,bool){});
llvm::install_bad_alloc_error_handler([](void*,const char*,bool){}); // <-- Crash occurs here
}
```
Propsed Fix:
```Diff
diff --git a/llvm/lib/Support/ErrorHandling.cpp b/llvm/lib/Support/ErrorHandling.cpp
index b8b3b7424ac6..c268543eb1fd 100644
--- a/llvm/lib/Support/ErrorHandling.cpp
+++ b/llvm/lib/Support/ErrorHandling.cpp
@@ -130,7 +130,7 @@ void llvm::install_bad_alloc_error_handler(fatal_error_handler_t handler,
#if LLVM_ENABLE_THREADS == 1
std::lock_guard Lock(BadAllocErrorHandlerMutex);
#endif
- assert(!ErrorHandler && "Bad alloc error handler already registered!\n");
+ assert(!BadAllocErrorHandler && "Bad alloc error handler already registered!\n");
BadAllocErrorHandler = handler;
BadAllocErrorHandlerUserData = user_data;
}
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83041] [OpenMP] overloading resolution issue involving namespace
Issue
83041
Summary
[OpenMP] overloading resolution issue involving namespace
Labels
new issue
Assignees
Reporter
yxsamliu
In the following example:
https://godbolt.org/z/eo1hx3a6W
```
#pragma omp begin declare variant match(device = {arch(amdgcn)})
int foo() { return 1;}
#pragma omp end declare variant
//int foo() { return 2;}
namespace FOAM {
int foo() { return 3;}
}
int main(){
using namespace FOAM;
return foo();
}
```
when resolving foo in main, device variant should not be considered candidate. However, when FOAM::foo is introduced, device variant becomes a candidate, which cause ambiguity. This should not happen.
@jhuber6
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83045] clang-cl broken with Microsoft EWDK
Issue
83045
Summary
clang-cl broken with Microsoft EWDK
Labels
new issue
Assignees
Reporter
namazso
Repro:
```
Z:>D:\LaunchBuildEnv.cmd amd64
**
** Enterprise Windows Driver Kit (WDK) build environment
** Version ni_release_svc_prod3.22621.1778
**
** Visual Studio 2022 Developer Command Prompt v17.1.5
** Copyright (c) 2022 Microsoft Corporation
**
Z:>echo int main() { return 0; } >test.c
Z:>"C:\Program Files\LLVM\bin\clang-cl.exe" test.c
LINK : fatal error LNK1104: cannot open file 'kernel32.lib'
clang-cl: error: linker command failed with exit code 1104 (use -v to see invocation)
```
I think the issue lies here: https://github.com/llvm/llvm-project/blob/9de78c4e243e9b1dffb289173a94d6a50421c463/llvm/lib/WindowsDriver/MSVCPaths.cpp#L409-L410
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83046] llvm::sys::fs::access can spuriously fail on Windows when called with AccessMode::Exist
Issue
83046
Summary
llvm::sys::fs::access can spuriously fail on Windows when called with AccessMode::Exist
Labels
new issue
Assignees
Reporter
z2oh
We are regularly seeing this issue surface as a compiler crash on Apple's LLVM fork: https://github.com/apple/llvm-project/issues/8224
https://github.com/llvm/llvm-project/blob/f1bb88bee248fb30e3145a2a19373233b7a59882/llvm/lib/Support/Windows/Path.inc#L617
I've been unable to reproduce this in isolation, but there seems to be some kind of race condition when calling `GetFileAttributesW` such that the fails on a valid path with `ERROR_ACCESS_DENIED`. I've managed to work around this locally by avoiding the call to `GetFileAttributesW` when the requested access mode is `AccessMode::Exist`, and instead calling the shell function `PathFileExistsW`:
```
if (Mode == AccessMode::Exist) {
if (::PathFileExistsW(PathUtf16.begin())) {
return std::error_code();
} else {
return errc::no_such_file_or_directory;
}
}
```
I've added some logging here and verified that this function returns correctly when `GetFileAttributesW` would have failed with `ERROR_ACCESS_DENIED`. This function requires pulling in `shlwapi.h`.
I'm happy to make a PR with this patch, but I wanted to make an issue first to seek alternate solutions, or to see if anyone had insight as to why `GetFileAttributesW` is failing in this way.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83048] llvm-cxxfilt should accept symbols from stdin
Issue 83048 Summary llvm-cxxfilt should accept symbols from stdin Labels enhancement, tools:llvm-cxxfilt Assignees Reporter alanzhao1 GNU's c++filt can accept input from stdin. This is extremely convenient for piping assembly or LLVM IR to c++filt and get back the same input but with the symbols demangled. Currently, llvm-cxxfilt only accepts mangled symbols as command line parameters. llvm-cxxfilt should have the same functionality as c++filt. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83050] [clang] clang hangs when instantiate an array of fixed points.
Issue
83050
Summary
[clang] clang hangs when instantiate an array of fixed points.
Labels
clang
Assignees
PiJoules
Reporter
lntue
clang hangs with:
```
static constexpr unsigned short _Fract A[][] = { 0x1.0p-1uhr, ... };
```
https://godbolt.org/z/rcfe6qa4b
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83066] Improve Bazel support to avoid legacy external links
Issue
83066
Summary
Improve Bazel support to avoid legacy external links
Labels
new issue
Assignees
Reporter
fzakaria
The current lit tests find FileCheck using the legacy way for finding external files in your runfiles structure.
Most lit_tests use [package_path](https://github.com/llvm/llvm-project/blob/15a7de697ae5ad88fd96ef7dc39ac479cc6e2eaf/utils/bazel/llvm-project-overlay/llvm/lit_test.bzl#L41) to find the directory for FileCheck.
[example](https://github.com/llvm/llvm-project/blob/15a7de697ae5ad88fd96ef7dc39ac479cc6e2eaf/utils/bazel/llvm-project-overlay/mlir/test/BUILD.bazel#L32):
```
expand_template(
name = "lit_site_cfg_py",
testonly = True,
out = "lit.site.cfg.py",
substitutions = {
"@LIT_SITE_CFG_IN_HEADER@": LIT_SITE_CFG_IN_HEADER,
"@LLVM_TOOLS_DIR@": package_path("//llvm:BUILD"),
```
This can create a lot of inodes that are unecessary, especially if you use [rules_python](https://github.com/bazelbuild/rules_python) which adds python as a runfile for hermeticness.
The recommended solution by Bazel right now is to do the two settings:
```
# Disabling runfiles links drastically increases performance in slow disk IO situations
# Do not build runfile trees by default. If an execution strategy relies on runfile
# symlink teee, the tree is created on-demand. See: https://github.com/bazelbuild/bazel/issues/6627
# and https://github.com/bazelbuild/bazel/commit/03246077f948f2790a83520e7dccc2625650e6df
build --nobuild_runfile_links
test --nobuild_runfile_links
# https://bazel.build/reference/command-line-reference#flag--legacy_external_runfiles
build --nolegacy_external_runfiles
test --nolegacy_external_runfiles
``
In order to remove the _legacy_external_runfiles_ however we have to change the mapping of LLVM_TOOLS_DIR.
The easy way to do this is as follows:
```
"@LLVM_TOOLS_DIR@": "../llvm-project/llvm",
```
The following wiki has a lot of good information: https://github.com/bazelbuild/bazel/wiki/Updating-the-runfiles-tree-structure
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83070] c++ missing-field-initializer warning regression on trunk/18rc.
Issue 83070 Summary c++ missing-field-initializer warning regression on trunk/18rc. Labels new issue Assignees Reporter pawelsopensource hi, the recent clang-18rc introduces massive warning-regression in c++ code base. it reports warning for fields with default ctor. https://godbolt.org/z/3vsd7G3Kd ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83072] Clang rejects valid friend access
Issue
83072
Summary
Clang rejects valid friend access
Labels
clang
Assignees
Reporter
Boris-Rasin
Rejected by Clang 17.0.1, works with gcc and msvc.
```cpp
struct A
{
template
using type = typename T::type;
};
class B
{
friend class A;
using type = int;
};
A::type a;
```
https://godbolt.org/z/r1E55hn43
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83075] [clang] implement __builtin_clzg
Issue 83075 Summary [clang] implement __builtin_clzg Labels clang, c23 Assignees Reporter nickdesaulniers similar to #82058 and mentioned in #79630. To implement parts of C23 stdbit.h, it would be nice if we exposed a similar builtin to GCC. This is a type agnostic builtin that lowers to an intrinsic I suspect we already have in LLVM. cc @overmighty ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83076] [clang] implement __builtin_ctzg
Issue 83076 Summary [clang] implement __builtin_ctzg Labels clang, c23 Assignees Reporter nickdesaulniers similar to https://github.com/llvm/llvm-project/issues/82058, https://github.com/llvm/llvm-project/issues/83075, and mentioned in https://github.com/llvm/llvm-project/issues/79630. To implement parts of C23 stdbit.h, it would be nice if we exposed a similar builtin to GCC. This is a type agnostic builtin that lowers to an intrinsic I suspect we already have in LLVM. cc @overmighty ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83079] [mlir][arith] `arith.floordivsi -(2^n -1), -1` generates code that crashes
Issue
83079
Summary
[mlir][arith] `arith.floordivsi -(2^n -1), -1` generates code that crashes
Labels
mlir
Assignees
Reporter
pingshiyu
The code below tries to calculate: `arith.floordivsi (1 - 2^63), -1`, which should give a well defined result equalling `2^63 - 1` (as far as I can tell from the documentation). But instead generates code that crashes when compiled with:
`mlir-opt --arith-expand --test-lower-to-llvm out.mlir | mlir-cpu-runner -e main --shared-libs ~/lib/mlir_c_runner --entry-point-result void`
```mlir
"builtin.module"() ({
^bb0():
"func.func"() ({
^bb0():
"func.call"() {callee=@func0} : () -> ()
"func.return"() : () -> ()
}) {sym_name="main", function_type=() -> ()} : () -> ()
"func.func"() ({
^bb0():
%nMaxInt, %n1 = "func.call"() {callee=@func1} : () -> (i64, i64)
vector.print %nMaxInt : i64 // -(2^n - 1)
vector.print %n1 : i64 // -1
%BUG = "arith.floordivsi"(%nMaxInt, %n1) : (i64, i64) -> (i64)
vector.print %BUG : i64 // // should == 2^n - 1, but crashes here
"func.return"() : () -> ()
}) {sym_name="func0", function_type=() -> ()} : () -> ()
"func.func"() ({
^bb0():
%nMaxInt = arith.constant -9223372036854775807 : i64
%n1 = arith.constant -1 : i64
"func.return"(%nMaxInt, %n1) : (i64, i64) -> ()
}) {sym_name="func1", function_type=() -> (i64, i64)} : () -> ()
}) : () -> ()
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83080] [libunwind] Wrong default for LIBUNWIND_ENABLE_FRAME_APIS?
Issue 83080 Summary [libunwind] Wrong default for LIBUNWIND_ENABLE_FRAME_APIS? Labels new issue Assignees Reporter xarblu In short - I recently hit the following issue with >=libunwind-18.1.0_rc1 on Gentoo: _Anything_ using libunwind started failing with `/usr/lib64/libc++abi.so.1: undefined symbol: __deregister_frame_info`. For more info the downstream bugreport is [here](https://bugs.gentoo.org/925024). Eventually I tracked it down to the newly introduced `LIBUNWIND_ENABLE_FRAME_APIS` defaulting to `OFF` (https://github.com/llvm/llvm-project/commit/5eb44df1b64dbd1a86b099128092a7fd2001c0ba). What confuses me is that the commit message clearly says: > Default this to on, so as not to remove the apis from > environments that already have them. but the actual option defaults to `OFF`. (Downstream said to CC author @Sterling-Augustine and reviewer @MaskRay) ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83091] [llvm-cov] Unreachable blocks marked with __builtin_unreachable are still counted as uncovered
Issue
83091
Summary
[llvm-cov] Unreachable blocks marked with __builtin_unreachable are still counted as uncovered
Labels
new issue
Assignees
Reporter
DanShaders
```
$ clang++ -v
clang version 19.0.0git (g...@github.com:llvm/llvm-project.git 62d0c01c2c9adce67f2e1adb9feecd7ba1a97814)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/danklishch/code/llvm-project/build/bin
Found candidate GCC installation: /usr/lib/gcc/x86_64-pc-linux-gnu/12.3.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1
Found candidate GCC installation: /usr/lib64/gcc/x86_64-pc-linux-gnu/12.3.0
Found candidate GCC installation: /usr/lib64/gcc/x86_64-pc-linux-gnu/13.2.1
Selected GCC installation: /usr/lib64/gcc/x86_64-pc-linux-gnu/13.2.1
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64
Found CUDA installation: /opt/cuda, version 12.3
$ clang++ -Wall -O0 -g -fcoverage-mapping -fprofile-instr-generate=test.profraw test.cpp
$ ./a.out
$ llvm-profdata merge test.profraw -o test.profdata
$ llvm-cov show a.out -instr-profile="" test.cpp
1| |bool g_false = false;
2| |
3| 1|int main() {
4| 1|int code = 1;
5| 1|if (!g_false) {
6| 1| code = 0;
7| 1|} else {
8| 0| __builtin_unreachable();
9| 0|}
10| 1|return code;
11| 1|}
```
A real-world example for this would be an exhaustive if-else chain with the last else being provably unreachable.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83094] [PowerPC] missing CFI for ELF32 to unwind cr2, cr3, cr4
Issue
83094
Summary
[PowerPC] missing CFI for ELF32 to unwind cr2, cr3, cr4
Labels
new issue
Assignees
Reporter
kernigh
For PowerPC ELF 32-bit targets, LLVM forgets to provide CFI like `.cfi_offset cr2, -88` for fields cr2, cr3, cr4 in the condition register. Function calls must preserve cr2, cr3, cr4. Because the CFI is missing, an unwinder (like libunwind) can't restore cr2, cr3, cr4, when it unwinds a function call.
I found the bug after OpenBSD/macppc's clang 16.0.6 miscompiled gdb, when a C++ exception crashed gdb by not restoring cr2. I reproduced the bug in 19.0.0git with this example,
```c++
struct flip {
int *p;
flip(int *a): p(a) { if (p) *p = 1; }
~flip() { if (p) *p = 0; }
};
#define N __attribute__((noinline))
int i;
N void flip2(int *p) { flip f(p); throw 0; }
N void flip1(int *p) { flip f(p); flip2(&i); }
int main() { try { flip1(nullptr); } catch(int) {} }
```
I compiled it with clang++ -O2. The example is small enough to optimize out cr2; I added `noinline` to keep cr2 in the code. The functions _flip1_ and _flip2_ each use cr2 to test some pointer _p_, which is null in _flip1_ and non-null in _flip2_. The C++ exception from `throw 0` unwinds _flip2_ without restoring cr2, then runs the C++ destructor _~flip_ in _flip1_ with a wrong cr2, so `if (p) *p = 0` crashes by writing to a null _p_.
I will soon add a pull request.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83096] _BitInt bit size reflection
Issue 83096 Summary _BitInt bit size reflection Labels new issue Assignees Reporter Journeyman1337 The new _BitInt type is awesome! However, I have come across a super annoying issue: its tricky to infer from the type how many bits it actually has. This makes it hard to do things such as get the max or min possible value of a _BitInt. Maybe clang could lead the charge and add a solution for this? ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83101] Clang accepts invalid program invovling function parameter as non-type template argument
Issue
83101
Summary
Clang accepts invalid program invovling function parameter as non-type template argument
Labels
clang
Assignees
Reporter
ranaanoop
The following program is accepted by clang but rejected by both gcc and clang. [Demo](https://godbolt.org/z/M61hq7zv4):
```
#include
auto function(auto s) -> std::array {
return {};
}
int main() {
auto const a = function(std::integral_constant{});
return a.size();
}
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83104] Merge c88beb4112d5bbf07d76a615ab7f13ba2ba023e6 into 18.x
Issue 83104 Summary Merge c88beb4112d5bbf07d76a615ab7f13ba2ba023e6 into 18.x Labels new issue Assignees Reporter brad0 MIPS: Fix asm constraints "f" and "r" for softfloat (#79116) This include 2 fixes: 1. Disallow 'f' for softfloat. 2. Allow 'r' for softfloat. Currently, 'f' is accpeted by clang, then LLVM meets an internal error. 'r' is rejected by LLVM by: couldn't allocate input reg for constraint 'r'. Fixes: #64241, #63632 ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83111] RISC-V ABI break: x7/t2 register is used to pass the 9th argument to a function in certain cases
Issue 83111 Summary RISC-V ABI break: x7/t2 register is used to pass the 9th argument to a function in certain cases Labels new issue Assignees Reporter euspectre According to the RISC-V ABI, the first 8 integer arguments of a function are passed in registers a0-a7, the 9th and subsequent ones go on stack. It seems, clang does not always conform to that. While investigating a crash in the Linux kernel built with clang 17.0.6, I found that x7/t2 register rather than the stack was used to pass the 9th argument, `mpri`, to [__find_rr_leaf() function from net/ipv6/route.c](https://elixir.bootlin.com/linux/v6.8-rc4/source/net/ipv6/route.c#L786). Here is a reduced and simplified version of the preprocessed net/ipv6/route.c that demonstrates the issue: [test-arg9.c](https://github.com/llvm/llvm-project/files/14415823/test-arg9.c.txt) It can be compiled as follows (the options were extracted from the kernel build): ``` clang --target=riscv64-linux-gnu -fintegrated-as \ -Werror=unknown-warning-option -Werror=ignored-optimization-argument -Werror=option-ignored \ -Werror=unused-command-line-argument \ -std=gnu11 -fshort-wchar -funsigned-char -fno-common -fno-PIE \ -fno-strict-aliasing -mabi=lp64 -march=rv64imac_zihintpause \ -mno-save-restore -mcmodel=medany \ -fno-asynchronous-unwind-tables -fno-unwind-tables -fno-delete-null-pointer-checks \ -O2 \ -fstack-protector-strong -fno-omit-frame-pointer -fno-optimize-sibling-calls \ -ftrivial-auto-var-init=zero \ -falign-functions=4 -fpatchable-function-entry=12 \ -fstrict-flex-arrays=3 -fno-strict-overflow -fno-stack-check \ -Wall -Wundef -Werror=implicit-function-declaration \ -Werror=implicit-int -Werror=return-type -Werror=strict-prototypes \ -Wno-format-security -Wno-trigraphs -Wno-frame-address -Wno-address-of-packed-member \ -Wmissing-declarations -Wmissing-prototypes \ -Wframe-larger-than=2048 -Wno-gnu -Wno-unused-but-set-variable -Wno-unused-const-variable \ -Wvla -Wno-pointer-sign -Wcast-function-type -Wimplicit-fallthrough \ -Werror=date-time -Werror=incompatible-pointer-types -Wenum-conversion \ -Wno-unused-but-set-variable -Wno-unused-const-variable -Wno-pointer-to-enum-cast \ -Wno-tautological-constant-out-of-range-compare -Wno-unaligned-access -Wno-cast-function-type-strict \ -Wno-missing-field-initializers -Wno-type-limits -Wno-shift-negative-value -Wno-initializer-overrides \ -Wno-sign-compare -Wno-unused-value -Wno-parentheses-equality -Wno-self-assign \ -g -c -o test-arg9.o test-arg9.c ``` clang: version 17.0.6 (https://github.com/llvm/llvm-project.git 6009708b4367171ccdbf4b5905cb6a803753fe18) Target: riscv64-unknown-linux-gnu A disassembly of test-arg9.o: [test-arg9.disasm](https://github.com/llvm/llvm-project/files/14415827/test-arg9.disasm.txt) Here are the portions of `__find_rr_leaf()` (callee) and `fib6_table_lookup()` (caller) where t2 is used to pass the 9th argument to the function: ``` fib6_table_lookup(): ... 00c4 <.LBB0_9>: c4: 00ccab83 lw s7,12(s9) c8: f8043423 sd zero,-120(s0) cc: f9b42223 sw s11,-124(s0) d0: f8840713 addi a4,s0,-120 d4: f8340893 addi a7,s0,-125 d8: f8440393 addi t2,s0,-124 // <<< here dc: 8566 mv a0,s9 de: 4581 li a1,0 e0: 865e mv a2,s7 e2: 86da mv a3,s6 e4: 87ce mv a5,s3 e6: 884a mv a6,s2 e8: 0097 auipc ra,0x0 e8: R_RISCV_CALL_PLT __find_rr_leaf e8: R_RISCV_RELAX *ABS* ec: 80e7 jalr ra # e8 <.LBB0_9+0x24> ... __find_rr_leaf(): ... 1e2: 891e mv s2,t2 ... 02b2 <.LBB1_16>: 2b2: 00092503 lw a0,0(s2) // <<< "if (m > *mpri)" in find_match() 2b6: 01455063 bge a0,s4,2b6 <.LBB1_16+0x4> 2b6: R_RISCV_BRANCH .LBB1_4 2ba: 0d05 addi s10,s10,1 2bc: 001d3513 seqz a0,s10 2c0: f4843583 ld a1,-184(s0) 2c4: 00a58023 sb a0,0(a1) 2c8: 01492023 sw s4,0(s2) // <<< "*mpri = m;" in find_match() 2cc: a001 j 2cc <.LBB1_16+0x1a> 2cc: R_RISCV_RVC_JUMP .LBB1_3 ... ``` This looks like a RISC-V ABI break. Ftrace, for example, relies on the fact that the temporary registers like t0-t2 can be safely clobbered at the beginning of the function. So, if dynamic Ftrace is enabled for __find_rr_leaf() in the kernel, t2 could contain anything when the function tries dereferencing its 9th argument, `mpri`, hence the kernel crashes. I do not think this issue has security implications, so, I am reporting it here. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83114] [BOLT] Perf2bolt is failing with assertion on AArch64
Issue 83114 Summary [BOLT] Perf2bolt is failing with assertion on AArch64 Labels BOLT Assignees Reporter kaadam Hi Everyone, I've bumped in to an assertion when I tried to convert basic perf.data /without LBR/ to BOLT format on AArch64. I found `` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83117] [Question] Which warning flags do I need for switch enum handling now?
Issue 83117 Summary [Question] Which warning flags do I need for switch enum handling now? Labels new issue Assignees Reporter FalcoGer I want the following behavior: - Error when `switch(enumVal)` and not all cases are covered and also there is no `default`, ie. I want to be able to use default with enums to explicitly allow them without having to fallthrough all the values I don't want special cases for, but have a hard stop when I edit an enum and don't handle all the switch cases without a default because that's most likely a bug. - Warning when `switch(enumVal)` and all cases are covered and there is a `default`, ie. all cases are covered and default is probably wrong because later editing the enum will make this a non-warning and probably produce a bug - Warning when `switch(notEnumValPerhapsAnIntOrSomething)` and there is no `default`, because I probably want to do at lest something, or explicitly nothing to show that I didn't forget anything. How do I achieve this now? ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83122] OOM when compiling a medium size c++ code
Issue 83122 Summary OOM when compiling a medium size c++ code Labels new issue Assignees Reporter niXman hello, I was just trying to compile my hobby project: https://github.com/niXman/cmdargs I was unpleasantly surprised that when using `clang` all available 14Gb memory was used, while when using `GCC` only 1.2 Gb of memory was used! at the same time, the same code when using clang takes three times longer to compile! clang: 1m24,296s gcc: 0m31,485s cmdline used: clang: time clang++15 -std=c++17 main.cpp -I../include -omain gcc: time g++ -std=c++17 main.cpp -I../include -omain clang version: > Ubuntu clang version 15.0.7 > Target: x86_64-pc-linux-gnu > Thread model: posix > InstalledDir: /usr/bin gcc version: > g++ (Ubuntu 12.3.0-1ubuntu1~22.04) 12.3.0 > Copyright (C) 2022 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. any thoughts? best! ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83125] valgrind error in llvm::APInt::setBits
Issue
83125
Summary
valgrind error in llvm::APInt::setBits
Labels
new issue
Assignees
Reporter
dcb314
This C code:
int CoordType;
void Distance_TOR_3D() {
if (CoordType != Distance_TOR_3D)
Distance_TOR_3D();
}
does this with recent clang trunk:
$ valgrind -q --trace-children=yes /home/dcb38/llvm/results/bin/clang -c -O1 bug36.c
bug36.c:3:17: warning: comparison between pointer and integer ('int' and 'void (
*)()') [-Wpointer-integer-compare]
3 | if (CoordType != Distance_TOR_3D)
| ~ ^ ~~~
==1082850== Conditional jump or move depends on uninitialised value(s)
==1082850==at 0xCBACA9: llvm::APInt::setBits(unsigned int, unsigned int) (in
/home/dcb38/llvm/results.20240227/bin/clang-19)
==1082850==by 0x1153296: computeKnownBits(llvm::Value const*, llvm::APInt co
nst&, llvm::KnownBits&, unsigned int, llvm::SimplifyQuery const&) (in /home/dcb3
8/llvm/results.20240227/bin/clang-19)
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83127] [InstCombine] InstCombine gets stuck when simplifying selects
Issue
83127
Summary
[InstCombine] InstCombine gets stuck when simplifying selects
Labels
llvm:instcombine,
llvm:hang
Assignees
dtcxzyw
Reporter
dtcxzyw
Reduced test case: https://godbolt.org/z/ds9eq96db
```
define i16 @func(i16 noundef %p_12) {
entry:
%cmp1 = icmp ult i16 %p_12, 2
%and1 = and i16 %p_12, 1
%and2 = select i1 %cmp1, i16 %and1, i16 0
%cmp2 = icmp eq i16 %and2, %p_12
%and3 = select i1 %cmp2, i16 %and1, i16 0
ret i16 %and3
}
```
```
ADD: %and3 = select i1 %cmp2, i16 %and2, i16 0
ADD: %and2 = select i1 %cmp1, i16 %and1, i16 0
ADD: %and1 = and i16 %p_12, 1
IC: Visiting: %and1 = and i16 %p_12, 1
IC: Visiting: %and2 = select i1 %cmp1, i16 %and1, i16 0
IC: Visiting: %and3 = select i1 %cmp2, i16 %and2, i16 0
ADD DEFERRED: %and2 = select i1 %cmp1, i16 %and1, i16 0
ADD DEFERRED: %cmp2 = icmp eq i16 %and2, %p_12
IC: Mod = %and3 = select i1 %cmp2, i16 %and2, i16 0
New = %and3 = select i1 %cmp2, i16 %and1, i16 0
ADD: %and3 = select i1 %cmp2, i16 %and1, i16 0
ADD: %cmp2 = icmp eq i16 %and2, %p_12
ADD: %and2 = select i1 %cmp1, i16 %and1, i16 0
IC: Visiting: %and2 = select i1 %cmp1, i16 %and1, i16 0
IC: Visiting: %cmp2 = icmp eq i16 %and2, %p_12
IC: Visiting: %and3 = select i1 %cmp2, i16 %and1, i16 0
ADD DEFERRED: %and1 = and i16 %p_12, 1
ADD DEFERRED: %and2 = select i1 %cmp1, i16 %and1, i16 0
IC: Mod = %and3 = select i1 %cmp2, i16 %and1, i16 0
New = %and3 = select i1 %cmp2, i16 %and2, i16 0
ADD: %and3 = select i1 %cmp2, i16 %and2, i16 0
ADD: %and2 = select i1 %cmp1, i16 %and1, i16 0
ADD: %and1 = and i16 %p_12, 1
IC: Visiting: %and1 = and i16 %p_12, 1
IC: Visiting: %and2 = select i1 %cmp1, i16 %and1, i16 0
IC: Visiting: %and3 = select i1 %cmp2, i16 %and2, i16 0
ADD DEFERRED: %and2 = select i1 %cmp1, i16 %and1, i16 0
ADD DEFERRED: %cmp2 = icmp eq i16 %and2, %p_12
IC: Mod = %and3 = select i1 %cmp2, i16 %and2, i16 0
New = %and3 = select i1 %cmp2, i16 %and1, i16 0
ADD: %and3 = select i1 %cmp2, i16 %and1, i16 0
ADD: %cmp2 = icmp eq i16 %and2, %p_12
ADD: %and2 = select i1 %cmp1, i16 %and1, i16 0
IC: Visiting: %and2 = select i1 %cmp1, i16 %and1, i16 0
IC: Visiting: %cmp2 = icmp eq i16 %and2, %p_12
IC: Visiting: %and3 = select i1 %cmp2, i16 %and1, i16 0
ADD DEFERRED: %and1 = and i16 %p_12, 1
ADD DEFERRED: %and2 = select i1 %cmp1, i16 %and1, i16 0
IC: Mod = %and3 = select i1 %cmp2, i16 %and1, i16 0
New = %and3 = select i1 %cmp2, i16 %and2, i16 0
...
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83134] [LLVM][CodeGen][InlineAssembly] Invalid inline assembly for subtarget compiles without error.
Issue
83134
Summary
[LLVM][CodeGen][InlineAssembly] Invalid inline assembly for subtarget compiles without error.
Labels
backend:X86,
accepts-invalid,
inline-asm
Assignees
Reporter
spaits
## Environmet inforamtion
clang version: Ubuntu clang version 14.0.0-1ubuntu1.1
cpu: 12th Gen Intel i7-1265U (12) @ 4.800GHz
## The problem
LLVM backend accepts inline assembly instructions that is not supported by the sub-target. This happens even if the `-mno-<>` flag is used to explicitly disable the feature. I think there should be a compile error here telling the user that the inline assembly is invalid.
## The reproduction of the issue
Let's have the following code that should work on x86-64 CPUs that support the AVX-512 feature:
```cpp
#include
int main() {
double a[8] = {1.0, 2.0, 3.0, 4.0, 5.0, 6.0, 7.0, 8.0};
double b[8] = {1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0};
double c[8] = {0};
asm volatile(
"vmovupd %0, %%zmm0\n\t"
"vmovupd %1, %%zmm1\n\t"
"vaddpd %%zmm0, %%zmm1, %%zmm2\n\t"
"vmovupd %%zmm2, %2"
:
: "m" (a), "m" (b), "m" (c)
: "zmm0", "zmm1", "zmm2"
);
for (int i = 0; i < 8; i++) {
std::cout << c[i] << " ";
}
std::cout << std::endl;
return 0;
}
```
I compile the code with the following command:
```
clang++ --target=x86_64-pc-linux-gnu -mno-avx512f
```
I put the `-mno-avx512f` flag there to NOT use AVX-512 specific features.
The compilation finishes with no error. I get the executable.
When I try to run the executable I get the following error:
```
Illegal instruction (core dumped)
```
I have a `12th Gen Intel i7-1265U` CPU in my machine. This CPU does not support AVX-512 feature.
## Potential cause of this issue
The `MatchInstructionImpl` function that is generated in the `X86GenAsmMatcher.cpp` file returns with the value Match_Success (4) value even if the feature required for the instruction is off. I did some additional debugging: I copied the generated function to `MatchInstruction.cpp`s and debugged it. In my case the instruction does not seem to require the feature.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83135] "missing default label" when all enum values are covered
Issue
83135
Summary
"missing default label" when all enum values are covered
Labels
new issue
Assignees
Reporter
mkmkme
Hi, I have a code snippet containing `switch` statement that always raises a warning: https://gist.github.com/mkmkme/eeb37b9af0869e00e0a2a45ae3c5aa61
Here in the code `switch` statement covers all possible `enum` values, but when I compile it with
```
clang++-18 -std=c++23 -Wall -Wextra -Weverything llvm-test.cpp
```
I'm getting
```
llvm-test.cpp:21:3: warning: 'switch' missing 'default' label [-Wswitch-default]
21 | switch (type) {
| ^
1 warning generated.
```
If I add `default` label there, I'll be getting
```
llvm-test.cpp:55:3: warning: default label in switch which covers all enumeration values [-Wcovered-switch-default]
55 | default: break;
| ^
1 warning generated.
```
I think the first one is false-positive.
My setup:
```
❯ clang-18 -v
Ubuntu clang version 18.1.0 (++20240221023121+bba39443eb91-1~exp1~20240221023233.52)
Target: aarch64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/aarch64-linux-gnu/11
Selected GCC installation: /usr/bin/../lib/gcc/aarch64-linux-gnu/11
Candidate multilib: .;@m64
Selected multilib: .;@m64
```
(reproduced the same behaviour on x86_64)
Ubuntu 22.04. Clang installed via script from apt.llvm.org
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83137] Long double options cannot be enabled
Issue 83137 Summary Long double options cannot be enabled Labels Assignees Reporter cctv130 clang-cl: warning: unknown argument ignored in clang-cl: '-mlong-double-128' [-Wunknown-argument] That means I didn't force it on successfully ，on windows ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83142] [infra] Build CI container workflow failing
Issue 83142 Summary [infra] Build CI container workflow failing Labels infrastructure Assignees Reporter sudonatalie The Build CI container workflow failures in #82687 seem to be fairly consistent and not related to the change in the PR. I created an empty draft PR (#83064) which also has the same failure. It looks like a disk space issue, which might explain why it was transient in the past. ``` build-ci-container-stage2 You are running out of disk space. The runner will stop working when the machine runs out of disk space. Free space left: 54 MB Artifacts Produced during runtime Name Size stage1-toolchain 1.81 GB ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83144] [Flang][OpenMP] verification of lowering to FIR failed with "address must dereference to value type"
Issue 83144 Summary [Flang][OpenMP] verification of lowering to FIR failed with "address must dereference to value type" Labels flang Assignees Reporter k-arrows Reproducible on Godbolt: https://godbolt.org/z/5Wa1bqG7d Reproducer (`flang-new -fopenmp test.f90`): ```console $ cat test.f90 program p implicit none logical :: l !$omp atomic write l = .true. !$omp end atomic end $ flang-new -fopenmp test.f90 error: address must dereference to value type error: verification of lowering to FIR failed ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83148] [Flang][OpenMP][Feature Request] accept `-fno-openmp`
Issue 83148 Summary [Flang][OpenMP][Feature Request] accept `-fno-openmp` Labels flang Assignees Reporter k-arrows I think flang-new should accept `-fno-openmp`. Clang and Gfortran accept this. ```console $ clang -fno-openmp test.c $ gfortran -fno-openmp test.f90 $ flang-new -fno-openmp test.f90 flang-new: error: unknown argument: '-fno-openmp' ``` But I think the priority is not so high because the intended behavior is achieved by not specifying `-fopenmp`. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83157] [Flang] Extension: allow procedure declaration statement to specify return type when a type declaration statement also declares the type for the same entity.
Issue 83157 Summary [Flang] Extension: allow procedure declaration statement to specify return type when a type declaration statement also declares the type for the same entity. Labels flang:frontend Assignees Reporter DanielCChen ``` real :: proc procedure(real) :: proc end ``` Flang currently issues an error ``` error: The type of 'proc' has already been declared procedure(real) :: proc ./t1.f:2:20: Declaration of 'proc' procedure(real) :: proc ``` Both XLF and ifort accept this. This can be a extension candidate. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83164] [Flang] fir.rebox verification failure when passing rank-2 actual to polymorphic assumed-size dummy
Issue
83164
Summary
[Flang] fir.rebox verification failure when passing rank-2 actual to polymorphic assumed-size dummy
Labels
bug,
flang:fir-hlfir
Assignees
Reporter
DanielCChen
Consider the following code:
```
type base
integer :: i
end type
class(base), pointer :: b1(:,:)
call sub(b1)
contains
subroutine sub(arg)
class(base) :: arg(1:*)
end
end
```
Flang currently issues
```
error: loc("t1.f":5:1): 'fir.rebox' op result type and shape operand ranks must match
error: verification of lowering to FIR failed
```
XLF, gfortran and ifort all compile this successfully.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83165] [libc] mark functions [[unsequenced]]
Issue 83165 Summary [libc] mark functions [[unsequenced]] Labels c23, libc Assignees Reporter nickdesaulniers The C spec editor shared a copy of N3220 with me; I noticed a late addition that's not in N3096. stdbit.h function declarations get [[unsequenced]] function attributes. I should audit to see if there were other additions of [[unsequenced]] or [[reproducible]] to other library functions. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83167] Invalid regex literal causes Swift REPL to segfault
Issue 83167 Summary Invalid regex literal causes Swift REPL to segfault Labels new issue Assignees Reporter bbrk24 ``` 1> let rgx = #/(.)(? ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83174] `CGDebugInfo` appends working directory to absolute path converted to relative with `DebugPrefixMap`
Issue
83174
Summary
`CGDebugInfo` appends working directory to absolute path converted to relative with `DebugPrefixMap`
Labels
new issue
Assignees
Reporter
noxwell
### Description
DWARF file entry consists of filename and directory. When `filename` is relative, it is relative to the`directory`, but when `filename` is absolute, `directory` should be empty. However, after being transformed through `CGDebugInfo::remapDIPath`, absolute `filename` may become relative, which leads to a bug, that it becomes relative to the current working directory, and the resulting DWARF file location points to a file that doesn't exist.
### Steps to reproduce
```bash
WORKDIR=$PWD
CC=clang
mkdir -p src
echo "int main() { return 0; }" > src/main.c
mkdir -p out
cd out
$CC -g -ffile-prefix-map="$WORKDIR/=./" -S -emit-llvm -o main.ll "$WORKDIR/src/main.c"
$CC -g -ffile-prefix-map="$WORKDIR/=./" -o main.o -c "$WORKDIR/src/main.c"
cat main.ll | grep 'DIFile' | head -n 1
llvm-dwarfdump main.o | grep 'DW_AT_decl_file'
```
### Expected output
```
!1 = !DIFile(filename: "./src/main.c", directory: "", checksumkind: CSK_MD5, checksum: "5c11ff1def313f2a87eabf3a30f130ad")
DW_AT_decl_file ("./src/main.c")
```
### Actual output
```
!1 = !DIFile(filename: "./src/main.c", directory: "./out", checksumkind: CSK_MD5, checksum: "5c11ff1def313f2a87eabf3a30f130ad")
DW_AT_decl_file ("./out/./src/main.c")
```
### How to fix
This case is already handled in `CGDebugInfo::createFile`. But `CGDebugInfo::CreateCompileUnit` uses `DBuilder.createFile` directly instead of calling `CGDebugInfo::createFile` wrapper, which leads to incorrect file entry.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83177] [DirectX] DXContainer support for SM 6.8 feature flags
Issue 83177 Summary [DirectX] DXContainer support for SM 6.8 feature flags Labels backend:DirectX Assignees Reporter llvm-beanz Shader Model 6.8 adds new feature flags that are exposed in the DX Container: >From DXC: ```c // SM 6.8+ const uint64_t ShaderFeatureInfo_SampleCmpGradientOrBias = 0x8000; const uint64_t ShaderFeatureInfo_ExtendedCommandInfo = 0x1; // Experimental SM 6.9+ - Reserved, not yet supported. // WaveMMA slots in between two SM 6.6 feature bits. const uint64_t ShaderFeatureInfo_WaveMMA = 0x800; ``` The flags get exposed as constants here: https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/BinaryFormat/DXContainerConstants.def We'll need YAML tests that support round tripping the flags in and out of DX Containers like the test here: https://github.com/llvm/llvm-project/blob/main/llvm/test/tools/obj2yaml/DXContainer/ShaderFlags.yaml ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83179] [NVPTX] Assertion "Bad value decomposition" hit while compiling tests
Issue
83179
Summary
[NVPTX] Assertion "Bad value decomposition" hit while compiling tests
Labels
backend:NVPTX
Assignees
Reporter
jhuber6
The NVPTX backend currently crashes when trying to compile this test https://github.com/llvm/llvm-project/blob/main/libc/test/src/__support/uint_test.cpp. I have reduced it down to the following LLVM-IR, or in https://godbolt.org/z/TEbxMz5q1.
```llvm
target triple = "nvptx64-nvidia-cuda"
%"struct.BigInt" = type { %"struct.arr" }
%"struct.arr" = type { [2 x i128] }
define void @foo() {
entry:
%call6 = call %"struct.BigInt" null(ptr null, i64 0)
ret void
}
```
This currently crashes in the backend, while other targets seem to handle it fine without crashing.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83182] Update preprocessor definitions for type detection
Issue 83182 Summary Update preprocessor definitions for type detection Labels libc Assignees gchatelet Reporter gchatelet This is to track the items in https://github.com/llvm/llvm-project/pull/81870#issuecomment-1948099726 i.e., - [ ] Rename `float.h` into `types.h` - [ ] Rename all `#define` in this file to `LIBC_TYPES_HAS_...` `LIBC_TYPES_HAS_INT64` `LIBC_TYPES_HAS_FLOAT16` `LIBC_TYPES_HAS_FLOAT128` - [ ] Don't expose how the type is provided and use `float16` or `float128` solely (i.e. no `LIBC_COMPILER_HAS_FLOAT128_EXTENSION` nor `LIBC_COMPILER_HAS_C23_FLOAT128`). Added benefit of not defining `LIBC_COMPILER_...` outside of the `compiler.h` file. - [ ] Update the documentation ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83185] clangd crashes on initializing union designators
Issue 83185 Summary clangd crashes on initializing union designators Labels new issue Assignees Reporter alirezamoshtaghi See attached test case and fix for it: [fix-clangd-crash-on-designator-init.patch](https://github.com/llvm/llvm-project/files/14425623/fix-clangd-crash-on-designator-init.patch) ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83197] Merge 860b6edfa9b344fbf8c500c17158c8212ea87d1c into 18.x
Issue 83197 Summary Merge 860b6edfa9b344fbf8c500c17158c8212ea87d1c into 18.x Labels new issue Assignees Reporter brad0 MIPS: fix emitDirectiveCpsetup on N32 (#80534) In gas, .cpsetup may expand to one of two code sequences (one is related to `__gnu_local_gp`), depending on -mno-shared and -msym32. Since Clang doesn't support -mno-shared or -msym32, .cpsetup expands to one code sequence. The N32 condition incorrectly leads to the incorrect `__gnu_local_gp` code sequence. ``` : 0: ffbc0008sd gp,8(sp) 4: 3c1clui gp,0x0 4: R_MIPS_HI16 __gnu_local_gp 8: 279caddiu gp,gp,0 8: R_MIPS_LO16 __gnu_local_gp ``` Fixes: #52785 ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83207] Incorrect configuration snippets for some AlignConsecutive... option sets
Issue 83207 Summary Incorrect configuration snippets for some AlignConsecutive... option sets Labels documentation, good first issue, clang-format Assignees Reporter EugeneZelenko [Current documentation](https://clang.llvm.org/docs/ClangFormatStyleOptions.html) has incorrect configuration snippets for `AlignConsecutiveAssignments`, `AlignConsecutiveBitFields`, `AlignConsecutiveDeclarations`, `AlignConsecutiveTableGenCondOperatorColons`, `AlignConsecutiveTableGenDefinitionColons` that refer to `AlignConsecutiveMacros` instead of actual option set. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83210] [libc] convert preprocessor includes to "" for other libc sources
Issue 83210 Summary [libc] convert preprocessor includes to "" for other libc sources Labels code-cleanup, libc Assignees Reporter nickdesaulniers Forking the discussion from https://github.com/llvm/llvm-project/pull/83199#discussion_r1505142721. > all the #includes in /include/ for things in llvm-libc-types or llvm-libc-macros currently use <>. It may be worthwhile to change this, but that should probably be one cleanup patch. So we're pretty inconsistent in our use of `#include` preprocessor statement wrt `<>` vs `""`. I _think_ we should move to the convention (and document it in our coding style): - If the .h file is part of our sources, use `""` - If the .h file is NOT part of our sources, use `<>` https://gcc.gnu.org/onlinedocs/cpp/Search-Path.html is helpful, particularly: > By default, the preprocessor looks for header files included by the quote form of the directive #include "file" first relative to the directory of the current file, and then in a preconfigured list of standard system directories. For example, if /usr/include/sys/stat.h contains #include "types.h", GCC looks for types.h first in /usr/include/sys, then in its usual search path. > For the angle-bracket form #include , the preprocessor’s default behavior is to look only in the standard system directories. > The most commonly-used option is -Idir, which causes dir to be searched after the current directory (for the quote form of the directive) and ahead of the standard system directories. Then I think that will help us refine our clang-tidy lint for this: #82695 ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83225] [InstCombine] Missed optimization: fold select if the user of its select user indicates the condition
Issue
83225
Summary
[InstCombine] Missed optimization: fold select if the user of its select user indicates the condition
Labels
Assignees
Reporter
XChy
Alive2 proof: https://alive2.llvm.org/ce/z/EDjfon
### Motivating example
```llvm
define i32 @src(i32 %a, i1 %c1, i1 %c2){
entry:
%s1 = select i1 %c1, i32 23, i32 45
%s2 = select i1 %c2, i32 666, i32 %s1
%s3 = select i1 %c1, i32 789, i32 %s2
ret i32 %s3
}
```
can be folded to:
```llvm
define i32 @tgt(i32 %a, i1 %c1, i1 %c2){
entry:
%s2 = select i1 %c2, i32 666, i32 45
%s3 = select i1 %c1, i32 789, i32 %s2
ret i32 %s3
}
```
### Real-world motivation
This snippet of IR is derived from [libdeflate/lib/crc32.c@dispatch_crc32](https://github.com/ebiggers/libdeflate/blob/e93127b7e85d8dc65a80ed0ad4883c4b3efbe813/lib/crc32.c#L241) (after O3 pipeline, original IR comes from [llvm-opt-benchmark](https://github.com/dtcxzyw/llvm-opt-benchmark)).
The example above is a reduced version. If you're interested in the original suboptimal IR and optimal IR, see also:https://godbolt.org/z/rjf9zWM81
**Let me know if you can confirm that it's an optimization opportunity, thanks.**
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83226] aarch64: prfm is not treated as an alias to prfum
Issue
83226
Summary
aarch64: prfm is not treated as an alias to prfum
Labels
new issue
Assignees
Reporter
pinskia
Forwarded from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99092 when building GCC with LLVM's assembler.
But can be reproduced with an inline-asm as simple as:
```
void f(void)
{
asm("prfmPLDL1KEEP, [x0, #-8]");
}
```
My analysis of why this is a LLVM assembler issue can be found at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99092#c9 .
The ARM folks specifically wanted to output pfrm from GCC too:
https://gcc.gnu.org/legacy-ml/gcc-patches/2014-07/msg00612.html
```
When it comes to emitting the pattern, always use "prfm" -- the prfum
form can be generated from the prfm mnemonic when the offset implies
this is necessary.
```
So I suspect this should be accepted by the LLVM assembler also.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83228] Is it an UB here? if not, do I need a compiler barrier to save it to be well-defined?
Issue
83228
Summary
Is it an UB here? if not, do I need a compiler barrier to save it to be well-defined?
Labels
new issue
Assignees
Reporter
zegao96
Suppose we have the following code sequence in C:
```
struct A { bool a; /* B if a==1 otherwise A */};
struct B { bool a; /* B if a==1 otherwise A */ int b;}
void foo(struct B *s) {
if (!s)
return;
if (s->a != 1)
return;
//do we need a compiler barrier here
//to make sure the compiler does not
//reorder access of s->b across s->a?
if (s->b != 2);
return;
...
}
void bar()
{
struct A *a = malloc(*a);
struct B *b = (struct B*)a;
foo(b);
}
```
In this case, one thing that is for sure is **s->b is only safe to access given that the condition s->a is true**. So from the compiler's POV:
1) does the type punning case in bar() makes foo() an UB even with -fno-strict-aliasing?
2) if not UB, would it happen to reorder two if branches in foo()?
3) if not UB, is a compiler barrier necessary as commented to restore this foo() to be a well-defined function?
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83232] llvm-cov: wrong line coverage of 0 for c++ macro argument in multi-line
Issue
83232
Summary
llvm-cov: wrong line coverage of 0 for c++ macro argument in multi-line
Labels
Assignees
Reporter
RainMark
```c++
43| 4| BG3_INFO(
44| 0| "logging begin, value: {}. {}",
45| 0| value, tags);
46| |
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83236] -ftime-trace incorrect header hierarchy when a header contains a int symbol
Issue 83236 Summary -ftime-trace incorrect header hierarchy when a header contains a int symbol Labels new issue Assignees Reporter atetubou Following compile shows ``` cat > a.h < b.h < EOF cat > c.cc < ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83241] llvm/lib/TextAPI/TextStub.cpp: 2 * redundant condition ?
Issue 83241 Summary llvm/lib/TextAPI/TextStub.cpp: 2 * redundant condition ? Labels new issue Assignees Reporter dcb314 Static analyser cppcheck says: trunk/llvm/lib/TextAPI/TextStub.cpp:279:18: style: Redundant condition: Ctx. '!Ctx || (Ctx && Ctx->FileKind!=FileType::Invalid)' is equivalent to '!Ctx || Ctx->FileKind!=FileType::Invalid' [redundantCondition] trunk/llvm/lib/TextAPI/TextStub.cpp:301:18: style: Redundant condition: Ctx. '!Ctx || (Ctx && Ctx->FileKind!=FileType::Invalid)' is equivalent to '!Ctx || Ctx->FileKind!=FileType::Invalid' [redundantCondition] ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83243] Incorrect diagnostic message for global named register variable
Issue
83243
Summary
Incorrect diagnostic message for global named register variable
Labels
clang:frontend
Assignees
Reporter
arakawamasahiro-fj
An error occurs if the asm register is specified when declaring a real floating-point type register variable.
(Error occurs regardless of architecture, but register names are architecture-dependent)
Do not throw an error if the register variable type is an integer or a pointer.
gcc produces no errors and compiles normally.
[clang version information]
```
clang version 19.0.0git (https://github.com/llvm/llvm-project.git dd7386d85f11cf6ad911b9827c7018fb08c6c205)
Target: aarch64-unknown-linux-gnu
```
[Sample Plogram for AArch64]
```
register double d1 __asm__ ("d0");
```
// Register "d0" in AArch64 is a floating-point register.
[Diagnostic Messages in an AArch64 Environment]
```
$ clang test.c
test.c:1:1: error: bad type for named register variable
1 | register double d1 __asm__ ("d0");
| ^
1 error generated.
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83245] `PHINode::incoming_values()` does not return a good C++ range...
Issue
83245
Summary
`PHINode::incoming_values()` does not return a good C++ range...
Labels
Assignees
Reporter
natanelh-mobileye
```
auto incoming = map_range(PHI->incoming_values(), [](Use *X) {return X;});
```
gives the following error, under gcc 7.5 :
```
In file included from {...snip...}
llvm-project/llvm/include/llvm/ADT/STLExtras.h: In instantiation of ‘auto llvm::map_range(ContainerTy&&, FuncTy) [with ContainerTy = llvm::iterator_range; FuncTy = isInnermostAccPhi(llvm::Value*)::]’:
llvm-project/llvm/tools/my_pass.cpp:282:77: required from here
llvm-project/llvm/include/llvm/ADT/STLExtras.h:378:33: error: no matching function for call to ‘map_iterator(llvm::Use*, isInnermostAccPhi(llvm::Value*)::&)’
return make_range(map_iterator(std::begin(C), F),
^~
```
Expected behavior:
1. I get range from `->incoming_values()`
2. I use it like normal with whatever function takes an llvm range
Actual behavior:
1. I get a "wannabe range that doesnt work properly"
2. can't use it in any way as a range...
The [docs](https://llvm.org/doxygen/classllvm_1_1PHINode.html#a1f0ff79b64a40d383b891f1baba89c6b) say that it should return a range...
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83252] [MLIR] transform.structured.convert_to_loops does not delete target op
Issue
83252
Summary
[MLIR] transform.structured.convert_to_loops does not delete target op
Labels
mlir
Assignees
Reporter
lhunloh
Minimal example:
```
func.func @gemm(%arg0 : memref, %arg1 : memref,
%arg2 : memref) {
linalg.matmul ins(%arg0, %arg1 : memref, memref)
outs(%arg2 : memref)
return
}
module attributes {transform.with_named_sequence} {
transform.named_sequence @__transform_main(%arg1 : !transform.any_op {transform.readonly}) {
%matmul = transform.structured.match ops{["linalg.matmul"]} in %arg1
: (!transform.any_op) -> !transform.any_op
transform.structured.convert_to_loops %matmul : !transform.any_op
transform.yield
}
}
```
Via `mlir-opt test.mlir --transform-interpreter` this gets transformed into:
```
func.func @gemm(%arg0: memref, %arg1: memref, %arg2: memref) {
// constants abbreviated
scf.for %arg3 = %c0_9 to %dim step %c1_10 {
// constants abbreviated
scf.for %arg4 = %c0_11 to %dim_4 step %c1_12 {
// constants abbreviated
scf.for %arg5 = %c0_13 to %dim_0 step %c1_14 {
// constants abbreviated
%9 = arith.mulf %2, %5 : f32
%10 = arith.addf %8, %9 : f32
%11 = affine.apply #map(%arg3, %arg4, %arg5)
%12 = affine.apply #map2(%arg3, %arg4, %arg5)
memref.store %10, %arg2[%11, %12] : memref
}
}
}
linalg.matmul ins(%arg0, %arg1 : memref, memref) outs(%arg2 : memref)
return
}
```
With the (old) target `linalg.matmul` still standing.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83265] s390/clang: relocation error : when there is a weak undefined symbol + -fno-PIE and -munaligned-symbols
Issue
83265
Summary
s390/clang: relocation error : when there is a weak undefined symbol + -fno-PIE and -munaligned-symbols
Labels
Assignees
Reporter
sumanthkorikkar
Problem:
===
When the symbol is weak and undefined + when the section layout is > 4GB, then it can end up with relocation error.
sample.c:6:(.text+0xc): relocation truncated to fit: R_390_PC32DBL against undefined symbol `kallsyms_markers'
Reproducer:
==
1. cat sample.c
extern const char kallsyms_names[] __attribute__((weak));
extern const unsigned int kallsyms_markers[] __attribute__((weak));
const char *data;
int main(void)
{
data = ""
}
2. clang -g -c sample.c -munaligned-symbols -fno-PIE
3. cat layout.ld
SECTIONS { . = 0x2; }
4. ld --script=layout.ld -o sample sample.o
sample.o: in function `main':
sample.c:6:(.text+0xc): relocation truncated to fit: R_390_PC32DBL against undefined symbol `kallsyms_markers'
Disassembly:
===
`Disassembly of section .text:`
` :`
`extern const char kallsyms_names[] __attribute__((weak));`
`extern const unsigned int kallsyms_markers[] __attribute__((weak));`
`const char *data;`
`int main(void)`
`{`
`0: eb bf f0 58 00 24 stmg %r11,%r15,88(%r15)`
`6: b9 04 00 bf lgr %r11,%r15`
`data = ""
`a: c4 0e 00 00 00 00 llgfrl %r0,a `
`c: R_390_PC32DBL kallsyms_markers+0x2`
`10: c4 18 00 00 00 00 lgrl %r1,10 `
`12: R_390_GOTENT kallsyms_names+0x2`
`16: b9 08 00 01 agr %r0,%r1`
`1a: c4 0b 00 00 00 00 stgrl %r0,1a `
`1c: R_390_PC32DBL data+0x2`
` 20: a7 29 00 00 lghi %r2,0`
`}`
`24: eb bf b0 58 00 04 lmg %r11,%r15,88(%r11)`
` 2a: 07 fe br %r14`
When .text layout is > 4GB and when kallsyms_markers is weak undefined, then it could
end up with relocation truncated to fit: R_390_PC32DBL against undefined symbol `kallsyms_markers'
Misc:
=
gcc doesnt have this problem with -mualigned-symbols and works fine with the same example
Thank you,
Sumanth
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83267] clang frontend command failed with exit code 139
Issue
83267
Summary
clang frontend command failed with exit code 139
Labels
clang
Assignees
Reporter
DinkydauSet
happens with this code:
```c++
#include
using namespace std;
auto expose() {
int capture = 1337;
return [c=capture](auto a) mutable {
return c + 1;
};
}
using type = decltype(std::function{expose})::result_type;
struct MyStruct{};
template<>
auto type::operator()(MyStruct a) {
return c;
}
int main() { return 0; }
```
When the captured variable in the lambda is not renamed to c, the crash doesn't happen.
The full error:
```
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-17.0.1/bin/clang++ -gdwarf-4 -g -o /app/output.s -mllvm --x86-asm-syntax=intel -S --gcc-toolchain=/opt/compiler-explorer/gcc-13.2.0 -fcolor-diagnostics -fno-crash-diagnostics -std=c++20
1. :16:35: current parser token '{'
#0 0x03349f18 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-17.0.1/bin/clang+++0x3349f18)
#1 0x03348044 llvm::sys::CleanupOnSignal(unsigned long) (/opt/compiler-explorer/clang-17.0.1/bin/clang+++0x3348044)
#2 0x0329c028 CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0
#3 0x7fe17fa42520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#4 0x06395bcd clang::LocalInstantiationScope::InstantiatedLocal(clang::Decl const*, clang::Decl*) (/opt/compiler-explorer/clang-17.0.1/bin/clang+++0x6395bcd)
#5 0x05c2bf2c clang::Sema::ActOnStartOfFunctionDef(clang::Scope*, clang::Decl*, clang::Sema::SkipBodyInfo*, clang::Sema::FnBodyKind) (/opt/compiler-explorer/clang-17.0.1/bin/clang+++0x5c2bf2c)
#6 0x05c40a21 clang::Sema::ActOnStartOfFunctionDef(clang::Scope*, clang::Declarator&, llvm::MutableArrayRef, clang::Sema::SkipBodyInfo*, clang::Sema::FnBodyKind) (/opt/compiler-explorer/clang-17.0.1/bin/clang+++0x5c40a21)
#7 0x058caaf0 clang::Parser::ParseFunctionDefinition(clang::ParsingDeclarator&, clang::Parser::ParsedTemplateInfo const&, clang::Parser::LateParsedAttrList*) (/opt/compiler-explorer/clang-17.0.1/bin/clang+++0x58caaf0)
#8 0x059c7f9f clang::Parser::ParseSingleDeclarationAfterTemplate(clang::DeclaratorContext, clang::Parser::ParsedTemplateInfo const&, clang::ParsingDeclRAIIObject&, clang::SourceLocation&, clang::ParsedAttributes&, clang::AccessSpecifier) (/opt/compiler-explorer/clang-17.0.1/bin/clang+++0x59c7f9f)
#9 0x059cfb71 clang::Parser::ParseTemplateDeclarationOrSpecialization(clang::DeclaratorContext, clang::SourceLocation&, clang::ParsedAttributes&, clang::AccessSpecifier) (/opt/compiler-explorer/clang-17.0.1/bin/clang+++0x59cfb71)
#10 0x059cfe33 clang::Parser::ParseDeclarationStartingWithTemplate(clang::DeclaratorContext, clang::SourceLocation&, clang::ParsedAttributes&, clang::AccessSpecifier) (/opt/compiler-explorer/clang-17.0.1/bin/clang+++0x59cfe33)
#11 0x058fe460 clang::Parser::ParseDeclaration(clang::DeclaratorContext, clang::SourceLocation&, clang::ParsedAttributes&, clang::ParsedAttributes&, clang::SourceLocation*) (/opt/compiler-explorer/clang-17.0.1/bin/clang+++0x58fe460)
#12 0x058cd199 clang::Parser::ParseExternalDeclaration(clang::ParsedAttributes&, clang::ParsedAttributes&, clang::ParsingDeclSpec*) (/opt/compiler-explorer/clang-17.0.1/bin/clang+++0x58cd199)
#13 0x058cef0a clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&, clang::Sema::ModuleImportState&) (/opt/compiler-explorer/clang-17.0.1/bin/clang+++0x58cef0a)
#14 0x058be95a clang::ParseAST(clang::Sema&, bool, bool) (/opt/compiler-explorer/clang-17.0.1/bin/clang+++0x58be95a)
#15 0x044f8b05 clang::CodeGenAction::ExecuteAction() (/opt/compiler-explorer/clang-17.0.1/bin/clang+++0x44f8b05)
#16 0x03dd5f21 clang::FrontendAction::Execute() (/opt/compiler-explorer/clang-17.0.1/bin/clang+++0x3dd5f21)
#17 0x03d5b9fb clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/opt/compiler-explorer/clang-17.0.1/bin/clang+++0x3d5b9fb)
#18 0x03eb5c23 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/opt/compiler-explorer/clang-17.0.1/bin/clang+++0x3eb5c23)
#19 0x00bd50c5 cc1_main(llvm::ArrayRef, char const*, void*) (/opt/compiler-explorer/clang-17.0.1/bin/clang+++0xbd50c5)
#20 0x00bce42d ExecuteCC1Tool(llvm::SmallVectorImpl&, llvm::ToolContext const&) driver.cpp:0:0
#21 0x03ba7489 void llvm::function_ref::callback_fn>, std::__cxx11::basic_string, std::allocator>*, bool*) const::'lambda'()>(long) Job.cpp:0:0
#22 0x0329c453 llvm::CrashRecoveryContext::RunSafely(llvm::function_ref) (/opt/compiler-explorer/clang-
[llvm-bugs] [Bug 83268] [IndVarSimplify] WRONG code with i128 and -replexitval=always
Issue
83268
Summary
[IndVarSimplify] WRONG code with i128 and -replexitval=always
Labels
miscompilation,
loopoptim
Assignees
Reporter
JonPsson1
This program should print -86:
```
int printf(const char *, ...);
unsigned short a = 0, b = 0;
unsigned __int128 c = 0, d = 0;
unsigned char e(unsigned char f, unsigned char g) { return f + g; }
long h() {
for (; c != 2; c = e(c, 3)) {
--d;
if (d)
continue;
return a;
}
return b;
}
int main() {
h();
printf("%d\n", (int)d);
}
```
With the option -replexitval=always, the IndVarSimplifyPass does something quite weird that I don't understand. It seems it is trying to compute the final value that is stored in the preheader, but that computation is '0', so it must be wrong.
`clang -O3 -march=z15 wrong0.i -o ./a.out<> clang -O3 -march=z15 wrong0.i -o ./a.out -mllvm -replexitval=always
`
```
IR Dump After IndVarSimplifyPass on for.body
define dso_local i64 @h() local_unnamed_addr #1 { define dso_local i64 @h() local_unnamed_addr #1 {
entry: entry:
%.pr = load i128, ptr @c, align 8, !tbaa !4 %.pr = load i128, ptr @c, align 8, !tbaa !4
%d.promoted = load i128, ptr @d, align 1, !tbaa !4 %d.promoted = load i128, ptr @d, align 1, !tbaa !4
%cmp.not5 = icmp eq i128 %.pr, 2%cmp.not5 = icmp eq i128 %.pr, 2
%extract.t9 = trunc i128 %.pr to i8 %extract.t9 = trunc i128 %.pr to i8
br i1 %cmp.not5, label %return, label %for.body.prehea br i1 %cmp.not5, label %return, label %for.body.prehea
for.body.preheader: ; predfor.body.preheader: ; pred
> %0 = add i128 %d.promoted, -1
> %1 = mul i8 %extract.t9, 85
> %2 = add i8 %1, 85
> %3 = zext i8 %2 to i128
> %umin = call i128 @llvm.umin.i128(i128 %0, i128 %3)
> %4 = sub i128 %0, %umin
br label %for.body br label %for.body
for.body: ; predfor.body: ; pred
%.off0 = phi i8 [ %add.i, %for.inc ], [ %extract.t9, % %.off0 = phi i8 [ %add.i, %for.inc ], [ %extract.t9, %
%dec46 = phi i128 [ %dec, %for.inc ], [ %d.promoted, % %dec46 = phi i128 [ %dec, %for.inc ], [ %d.promoted, %
%dec = add i128 %dec46, -1 %dec = add i128 %dec46, -1
%tobool.not = icmp eq i128 %dec, 0 %tobool.not = icmp eq i128 %dec, 0
br i1 %tobool.not, label %for.body.return_crit_edge, l br i1 %tobool.not, label %for.body.return_crit_edge, l
for.inc: ; predfor.inc: ; pred
%add.i = add i8 %.off0, 3 %add.i = add i8 %.off0, 3
%conv2 = zext i8 %add.i to i128 %conv2 = zext i8 %add.i to i128
store i128 %conv2, ptr @c, align 8, !tbaa !4store i128 %conv2, ptr @c, align 8, !tbaa !4
%cmp.not = icmp eq i8 %add.i, 2 %cmp.not = icmp eq i8 %add.i, 2
br i1 %cmp.not, label %for.cond.return_crit_edge, labe br i1 %cmp.not, label %for.cond.return_crit_edge, labe
for.cond.return_crit_edge: ; predfor.cond.return_crit_edge:; pred
%dec.lcssa10 = phi i128 [ %dec, %for.inc ] | store i128 %4, ptr @d, align 8, !tbaa !4
store i128 %dec.lcssa10, ptr @d, align 8, !tbaa !4 <
br label %return br label %return
for.body.return_crit_edge: ; predfor.body.return_crit_edge: ; pred
%dec.lcssa = phi i128 [ %dec, %for.body ]| store i128 %4, ptr @d, align 8, !tbaa !4
store i128 %dec.lcssa, ptr @d, align 8, !tbaa !4 <
br label %return br label %return
return: ; predreturn: ; pred
%retval.0.in.in = phi ptr [ @a, %for.body.return_crit_ %retval.0.in.in = phi ptr [ @a, %for.body.return_crit_
%retval.0.in = load i16, ptr %retval.0.in.in, align 2, %retval.0.in = load i16, ptr %retval.0.in.in, align 2,
%retval.0 = zext i16 %retval.0.in to i64 %retval.0 = zext i16 %retval.0.in to i64
ret i64 %retval.0 ret i64 %retval.0
} }
;
```
@nikic @xortator @uweigand
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83270] [Flang] Preprocessing lower case .f## file should report on preprocessor directives unless -cpp is given (gfortran compability)
Issue 83270 Summary [Flang] Preprocessing lower case .f## file should report on preprocessor directives unless -cpp is given (gfortran compability) Labels flang:frontend, flang, flang:semantics Assignees Reporter DominikAdamski flang-new silently skips -DMACRO flag if it preprocesses lower case *.f## file unless -cpp flag is given. Proof: Source file: ``` #ifdef TEST #define A 1 #else #define A 0 #endif program main print *, A end program ``` compilation command: ` flang-new -DTEST file.f90` Output: ``` > ./a.out 0 //Expected output 1, because of -DTEST ``` gfrotran reports that preprocessor macros are not handled: ``` gfortran -DTEST file.f90 1 | #ifdef TEST | 1 Warning: Illegal preprocessor directive ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83271] The -Wformat=2 flag should enable all -Wformat diagnostics similar to GCC
Issue 83271 Summary The -Wformat=2 flag should enable all -Wformat diagnostics similar to GCC Labels Assignees Reporter thomasnyman The behavior between `-Wformat=2` flag in Clang and GCC differ in a way which may cause users to inadvertently miss out on wanted diagnostics messages: - In GCC, the `-Wformat=2` flag [is equivalent to](https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wformat_003d2) `-Wformat -Wformat-nonliteral -Wformat-security -Wformat-y2k`. - In Clang, `-Wformat=2` [is equivalent to](https://github.com/llvm/llvm-project/blob/680c780a367bfe1c0cdf786250fd7f565ef6d23d/clang/include/clang/Basic/DiagnosticGroups.td#L987) `-Wformat-nonliteral -Wformat-security -Wformat-y2k` While `-Wformat` in Clang includes the same diagnostics as `-Wformat=2` the difference in the behavior of `-Wformat=2` between the compilers [makes it problematic to make recommendations on the use of warning flags](https://best.openssf.org/Compiler-Hardening-Guides/Compiler-Options-Hardening-Guide-for-C-and-C++#enable-additional-format-function-warnings) that would be consistent between Clang and GCC as `-Wformat` provides a superset of diagnostics in Clang, but `-Wformat=2` provides the superset of diagnostics in GCC. Consequently it would be better if the behavior of `-Wformat=2` in Clang could be changed to also include the diagnostics flags implied by `-Wformat`. Link to a test case in Compiler Explorer that demonstrates the difference in behavior with the different combinations of options: https://godbolt.org/z/nvocaaehY ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83273] [Flang] Missing diagnose when procedure pointer is subroutine but the pointer assignment target is a function
Issue 83273 Summary [Flang] Missing diagnose when procedure pointer is subroutine but the pointer assignment target is a function Labels bug, flang:frontend Assignees Reporter DanielCChen Consider the following code: ``` IMPLICIT NONE ! p is not implicitly typeable REAL, EXTERNAL :: func PROCEDURE(), POINTER :: p1 p1 => func ! illegal END PROGRAM ``` `p1` is not explicitly or implicitly typed, so it should represent a subroutine. Flang currently compiles the above code successfully. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83276] [mlir][bufferization] Incorrect bufferization with LayoutMapOption::IdentityLayoutMap
Issue
83276
Summary
[mlir][bufferization] Incorrect bufferization with LayoutMapOption::IdentityLayoutMap
Labels
mlir
Assignees
Reporter
ryan-holt-1
`OneShotBufferize` incorrectly casts away non-unit layouts on function call arguments when running with the `LayoutMapOption::IdentityLayoutMap` option.
Reproducer:
```
// RUN: mlir-opt %s --one-shot-bufferize='bufferize-function-boundaries function-boundary-type-conversion=identity-layout-map
func.func @caller(%arg0: tensor<5xf32>, %offset: index, %size: index) -> (f32) {
%extracted_slice = tensor.extract_slice %arg0[%offset] [%size] [1] : tensor<5xf32> to tensor
%result = func.call @callee(%extracted_slice) : (tensor) -> (f32)
return %result : f32
}
func.func private @callee(%arg0: tensor) -> (f32) {
%0 = arith.constant 0 : index
%extracted = tensor.extract %arg0[%0] : tensor
return %extracted : f32
}
```
results in:
```
func.func @caller(%arg0: memref<5xf32>, %arg1: index, %arg2: index) -> f32 {
%subview = memref.subview %arg0[%arg1] [%arg2] [1] : memref<5xf32> to memref>
%cast = memref.cast %subview : memref> to memref
%0 = call @callee(%cast) : (memref) -> f32
return %0 : f32
}
func.func private @callee(%arg0: memref) -> f32 {
%c0 = arith.constant 0 : index
%0 = memref.load %arg0[%c0] : memref
return %0 : f32
}
```
Notice the `memref.cast` is eliminating the layout. This will cause `callee` to load the wrong value when `%offset` is non-zero. I would have expected a new allocation and a copy at the callsite instead of the `memref.cast`. The doc for `LayoutMapOption` indicates that a copy would be the expected behavior as well.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83278] [Flang] Missing diagnose when using elemental intrinsic to declare a procedure pointer
Issue 83278 Summary [Flang] Missing diagnose when using elemental intrinsic to declare a procedure pointer Labels bug, flang:frontend Assignees Reporter DanielCChen Consider the following code: ``` procedure(abs), pointer :: pp1 end ``` The standard says: ``` C1517 (R1512) If a proc-interface describes an elemental procedure, each procedure-entity-name shall specify an external procedure. ``` Flang currently compiles the above code successfully. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83289] [X86] [ISEL] Redundant instructions selected for storing vector of floats
Issue
83289
Summary
[X86] [ISEL] Redundant instructions selected for storing vector of floats
Labels
new issue
Assignees
Reporter
nurmukhametov
Consider the following code (does `A = max(A, B)` for vectors of `float`):
```
declare <8 x float> @llvm.x86.avx.max.ps.256(<8 x float>, <8 x float>) #0
define void @foo(float* noalias nocapture %A, float* noalias nocapture readonly %B) local_unnamed_addr {
allocas:
%V1_load_bitcast_load.unpack.unpack.i = load float, float* %A, align 4
%V1_load_bitcast_load.unpack.elt17.i = getelementptr inbounds float, float* %A, i64 1
%V1_load_bitcast_load.unpack.unpack18.i = load float, float* %V1_load_bitcast_load.unpack.elt17.i, align 4
%V1_load_bitcast_load.unpack.elt19.i = getelementptr inbounds float, float* %A, i64 2
%V1_load_bitcast_load.unpack.unpack20.i = load float, float* %V1_load_bitcast_load.unpack.elt19.i, align 4
%V1_load_bitcast_load.unpack.elt21.i = getelementptr inbounds float, float* %A, i64 3
%V1_load_bitcast_load.unpack.unpack22.i = load float, float* %V1_load_bitcast_load.unpack.elt21.i, align 4
%S0.0.vec.insert.i = insertelement <8 x float> undef, float %V1_load_bitcast_load.unpack.unpack.i, i64 0
%S0.4.vec.insert.i = insertelement <8 x float> %S0.0.vec.insert.i, float %V1_load_bitcast_load.unpack.unpack18.i, i64 1
%S0.8.vec.insert.i = insertelement <8 x float> %S0.4.vec.insert.i, float %V1_load_bitcast_load.unpack.unpack20.i, i64 2
%S0.12.vec.insert.i = insertelement <8 x float> %S0.8.vec.insert.i, float %V1_load_bitcast_load.unpack.unpack22.i, i64 3
%V2_load_bitcast_load.unpack.unpack.i = load float, float* %B, align 4
%V2_load_bitcast_load.unpack.elt25.i = getelementptr inbounds float, float* %B, i64 1
%V2_load_bitcast_load.unpack.unpack26.i = load float, float* %V2_load_bitcast_load.unpack.elt25.i, align 4
%V2_load_bitcast_load.unpack.elt27.i = getelementptr inbounds float, float* %B, i64 2
%V2_load_bitcast_load.unpack.unpack28.i = load float, float* %V2_load_bitcast_load.unpack.elt27.i, align 4
%V2_load_bitcast_load.unpack.elt29.i = getelementptr inbounds float, float* %B, i64 3
%V2_load_bitcast_load.unpack.unpack30.i = load float, float* %V2_load_bitcast_load.unpack.elt29.i, align 4
%S1.0.vec.insert.i = insertelement <8 x float> undef, float %V2_load_bitcast_load.unpack.unpack.i, i64 0
%S1.4.vec.insert.i = insertelement <8 x float> %S1.0.vec.insert.i, float %V2_load_bitcast_load.unpack.unpack26.i, i64 1
%S1.8.vec.insert.i = insertelement <8 x float> %S1.4.vec.insert.i, float %V2_load_bitcast_load.unpack.unpack28.i, i64 2
%S1.12.vec.insert.i = insertelement <8 x float> %S1.8.vec.insert.i, float %V2_load_bitcast_load.unpack.unpack30.i, i64 3
%call.i.i.i = tail call <8 x float> @llvm.x86.avx.max.ps.256(<8 x float> %S0.12.vec.insert.i, <8 x float> %S1.12.vec.insert.i)
%Result.0.vec.extract.i = extractelement <8 x float> %call.i.i.i, i64 0
%Result.4.vec.extract.i = extractelement <8 x float> %call.i.i.i, i64 1
%Result.8.vec.extract.i = extractelement <8 x float> %call.i.i.i, i64 2
%Result.12.vec.extract.i = extractelement <8 x float> %call.i.i.i, i64 3
store float %Result.0.vec.extract.i, float* %A, align 4
store float %Result.4.vec.extract.i, float* %V1_load_bitcast_load.unpack.elt17.i, align 4
store float %Result.8.vec.extract.i, float* %V1_load_bitcast_load.unpack.elt19.i, align 4
store float %Result.12.vec.extract.i, float* %V1_load_bitcast_load.unpack.elt21.i, align 4
ret void
}
```
When built as follow:
```
llc -O3 -march=x86-64 -mcpu=core-avx2 -mattr=avx2 -x86-asm-syntax=intel t.ll -o -
```
contains redundant instructions `vmovd` and `vpinsrd`:
```asm
vmovups xmm0, xmmword ptr [rdi]
vmaxps xmm0, xmm0, xmmword ptr [rsi]
vmovd eax, xmm0
vpinsrd xmm0, xmm0, eax, 0
vmovdqu xmmword ptr [rdi], xmm0
ret
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83290] [flang][beginner] Clean-up function types creation in Optimizer/Builder/Runtime files
Issue 83290 Summary [flang][beginner] Clean-up function types creation in Optimizer/Builder/Runtime files Labels enhancement, flang Assignees Reporter vzakhari This comes up from @jeanPerier's comment https://github.com/llvm/llvm-project/pull/83219/files#r1506118851 We'd better use `fir::runtime::getModel` instead of direct MLIR/FIR types creation in `Numeric.cpp`, `Reduction.cpp`, `Transformational.cpp`, etc. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83292] [Flang] Incorrect diagnose when proc-iface in a procedure declaration statement is a function that returns a polymorphic procedure pointer
Issue 83292 Summary [Flang] Incorrect diagnose when proc-iface in a procedure declaration statement is a function that returns a polymorphic procedure pointer Labels bug, flang:frontend Assignees Reporter DanielCChen Consider the following test case ``` MODULE M TYPE :: DT real :: r END TYPE INTERFACE FUNCTION FunI() IMPORT CLASS(DT), POINTER :: FunI END FUNCTION END INTERFACE INTERFACE FUNCTION FunRetPtr1() IMPORT PROCEDURE(FunI), POINTER :: FunRetPtr1 END FUNCTION END INTERFACE END MODULE PROGRAM PrtAssignTarExpr USE M IMPLICIT NONE PROCEDURE(FunRetPtr1), POINTER :: Ptr1 END ``` Flang currently issues an error: ``` ./t.f:27:37: error: CLASS entity 'ptr1' must be a dummy argument, allocatable, or object pointer PROCEDURE(FunRetPtr1), POINTER :: Ptr1 ``` The code seems conforming to me and the error message doesn't quite make sense to me. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83294] [LoopUnroll][RISCV] Crash when unrolling loop containing vector instructions
Issue
83294
Summary
[LoopUnroll][RISCV] Crash when unrolling loop containing vector instructions
Labels
new issue
Assignees
Reporter
frasercrmck
When optimizing for RISC-V _without_ the vector extension enabled, the `RISCVTargetTransformInfo` returns an invalid cost and the loop unroller asserts.
This is happening on both tip (64422cf826354ee1d586c2484ec72d66db898e75) and on LLVM 18.1.0 RC4 (461274b81d8641eab64d494accddc81d7db8a09e).
``` llvm
; RUN: opt -mattr=+f,+d -S --passes=loop-unroll-full -S -disable-output
target datalayout = "e-m:e-p:64:64-i64:64-i128:128-n32:64-S128"
target triple = "riscv64-unknown-unknown-elf"
define void @foo() {
entry:
br label %for.body
for.body: ; preds = %for.body, %entry
%indvars.iv1 = phi i64 [ %indvars.iv.next, %for.body ], [ 0, %entry ]
%0 = load float, ptr null, align 4
%splat.splat.i.i.i = shufflevector <2 x float> zeroinitializer, <2 x float> zeroinitializer, <2 x i32> zeroinitializer
%cmp1.i.i.i = fcmp ogt <2 x float> zeroinitializer, zeroinitializer
%splat.splat3.i.i.i = shufflevector <2 x i32> zeroinitializer, <2 x i32> zeroinitializer, <2 x i32> zeroinitializer
%xor3.i.i.i.i.i = select <2 x i1> zeroinitializer, <2 x i32> zeroinitializer, <2 x i32> zeroinitializer
%1 = load float, ptr null, align 4
%splat.splat8.i.i.i = shufflevector <2 x float> zeroinitializer, <2 x float> zeroinitializer, <2 x i32> zeroinitializer
%sub.i.i.i = fsub <2 x float> zeroinitializer, zeroinitializer
%mul.i.i.i = shl i64 0, 0
%2 = load float, ptr null, align 4
%splat.splat.i.i.i.i = shufflevector <2 x float> zeroinitializer, <2 x float> zeroinitializer, <2 x i32> zeroinitializer
%xor3.i.i.i.v.i.i = select <2 x i1> zeroinitializer, <2 x float> zeroinitializer, <2 x float> zeroinitializer
%indvars.iv.next = add i64 %indvars.iv1, 1
%exitcond = icmp ne i64 %indvars.iv1, 8
br i1 %exitcond, label %for.body, label %exit
exit: ; preds = %for.body
ret void
}
```
Should show:
```
opt: /llvm/lib/Transforms/Scalar/LoopUnrollPass.cpp:680: std::optional analyzeLoopUnrollCost(const llvm::Loop *, unsigned int, llvm::DominatorTree &, llvm::ScalarEvolution &, const SmallPtrSetImpl &, const llvm::TargetTransformInfo &, unsigned int, unsigned int): Assertion `UnrolledCost.isValid() && RolledDynamicCost.isValid() && "All instructions must have a valid cost, whether the " "loop is rolled or unrolled."' failed.
```
This is a regression against LLVM 17, which reports (with the same input but with `--debug`):
```
Loop Unroll: F[foo] Loop %for.body
Loop Size = Invalid
Not unrolling loop which contains instructions with invalid cost.
```
I've been away from LLVM for a while so don't know if this is a failure in the RISCV cost model or an overly restrictive loop unroller.
It looks like with LLVM 17, the `CodeSize` costs were deemed to be `Invalid` by the `UnrollCostEstimator`, so the unroller exited early. Now since LLVM 18 they are no longer `Invalid` so the unroller tries to calculate profitability in `analyzeLoopUnrollCost` which can't handle `Invalid` costs and asserts.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83296] [SCEV / LoopUnroller] crash
Issue 83296 Summary [SCEV / LoopUnroller] crash Labels loopoptim Assignees Reporter JonPsson1 clang -O3 -march=z15 crash_loopunroll.i -o a.out -w -mllvm -unroll-allow-remainder=false -mllvm -unroll-count=4 #253 0x02aa209d718a llvm::ScalarEvolution::getBackedgeTakenCount [crash_loopunroll.i.tar.gz](https://github.com/llvm/llvm-project/files/14437852/crash_loopunroll.i.tar.gz) @serguei-katkov @modiking @nikic ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83310] clang++ miscompiles vectorizable comparisons by effectively eliding checks for NaN when FP exceptions are enabled
Issue
83310
Summary
clang++ miscompiles vectorizable comparisons by effectively eliding checks for NaN when FP exceptions are enabled
Labels
Assignees
Reporter
nmusolino
I have encountered a potential bug, in which `clang++-15` miscompiles C++ code that is written to _avoid_ invalid floating point operations (within the meaning in the IEEE-754 standard), such as `x < y` where either `x` or `y` is NaN:
```cpp
if (std::isnan(lhs[i]) || std::isnan(rhs[i])) {
result[i] = std::numeric_limits::min();
} else {
result[i] = lhs[i] < rhs[i]; // Would raise FE_INVALID if either operand is NaN
}
```
This miscompilation is observable when the program [enables the invalid exception](https://www.gnu.org/software/libc/manual/html_node/Control-Functions.html) using `feenableexcept(FE_INVALID);`.
Concretely, `clang++` emits instructions such as `vcmpltpd` that raise floating point exceptions when a silent NaN (SNaN) operand is encountered; these cause the program to receive `SIGFPE` when traps for `FE_INVALID` are enabled.
>From the `dis` command in `lldb-15`:
```
-> 0x5620 <+1008>: vcmpltpd %ymm4, %ymm3, %ymm3
0x5625 <+1013>: vextractf128 $0x1, %ymm3, %xmm4
0x562b <+1019>: vshufps $0x88, %xmm4, %xmm3, %xmm3 ; xmm3 = xmm3[0,2],xmm4[0,2]
0x5630 <+1024>: vandps %xmm1, %xmm3, %xmm1
0x5634 <+1028>: vextractf128 $0x1, %ymm0, %xmm3
0x563a <+1034>: vpackssdw %xmm3, %xmm0, %xmm0
0x563e <+1038>: vblendvps %xmm0, %xmm2, %xmm1, %xmm0
0x5644 <+1044>: vmovups %xmm0, 0x70(%rax)
```
The compiler ought to emit alternative instructions (such as `vcmplt_oqpd` or `vucomisd`?) that do not raise floating point exceptions on SNaN inputs.
For background, GCC had similar bug reports in [#101634](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101634) and [#100778](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100778), although the examples in those reports appear to relate to divide-by-zero exceptions.
In the example below, the bug occurs with `-O2` and `-O3`, but not `-O1`. The `-march=ivybridge` option is also required to reproduce the bug on my system.
I am not able to test with `clang++` versions 16 or 17 on my system, but the example below also triggers `SIGFPE` on the Compiler Explorer tool at godbolt.org with `clang 16.0.0` and `clang 17.0.1` for `x86_64`.
### Reproduction
```cpp
#include
#include
#include
#include
#include
#include
void Less(std::span result, std::span lhs, std::span rhs) {
for (std::size_t i = 0; i < lhs.size(); ++i) {
if (std::isnan(lhs[i]) || std::isnan(rhs[i])) {
result[i] = std::numeric_limits::min();
} else {
result[i] = lhs[i] < rhs[i];
}
}
}
int main() {
feenableexcept(FE_INVALID);
std::size_t n = 32; // Must be 32 or larger.
constexpr double nan = std::numeric_limits::quiet_NaN();
std::vector lhs(n, 0.0);
lhs.at(n - 1) = nan;
std::vector rhs(n, 0.0);
std::vector result(n);
Less(std::span(result), std::span{lhs}, std::span{rhs});
std::cout << "element " << n - 1 << ": " << result.at(n-1) << std::endl;
}
```
Compilation command:
```
clang++-15 -O3 -march=ivybridge --std=c++20 -g ./clang15_repro.cpp
```
Output of `clang++-15 --version`:
```
Ubuntu clang version 15.0.7
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 83311] [Flang] BIND(C): Passing C_LONG_DOIUBLE does not work
Issue
83311
Summary
[Flang] BIND(C): Passing C_LONG_DOIUBLE does not work
Labels
bug,
flang:ir
Assignees
Reporter
DanielCChen
C code:
```
#include
void subc(long double pi )
{
printf("in subc pi = %Lf\n", pi);
}
```
Fortran code:
```
use, intrinsic :: iso_c_binding
real(c_long_double) :: r1 = 3.1416
interface
subroutine sub(p) bind(c, name='subc')
import
real(c_long_double), intent(in), value :: p
end
end interface
call sub(r1)
end
```
Flang currently produces:
```
> a.out
in subc pi = 0.0
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 83329] Execution aborts in OpenMP runtime for wasm target when parallel region is encountered
Issue 83329 Summary Execution aborts in OpenMP runtime for wasm target when parallel region is encountered Labels new issue Assignees Reporter mawi2017 Currently, a parallel region in a wasm OpenMP application causes the following error: ``` Error: failed to run main module `example.wasm` Caused by: 0: failed to invoke command default 1: error while executing at wasm backtrace: 0: 0xafe73 - !__kmp_invoke_microtask 1: 0x283a4 - !__kmp_invoke_task_func 2: 0x22d00 - !__kmp_fork_call 3: 0x629f - !__kmpc_fork_call 4: 0xca2 - !main 5: 0xb590a - !__main_void 6: 0xbe9 - !_start note: using the `WASMTIME_BACKTRACE_DETAILS=1` environment variable may show more debugging information 2: wasm trap: indirect call type mismatch Error: error while executing at wasm backtrace: 0: 0xafe73 - !__kmp_invoke_microtask 1: 0x283a4 - !__kmp_invoke_task_func ``` It seems in [`__kmp_invoke_microtask`](https://github.com/llvm/llvm-project/blob/main/openmp/runtime/src/z_Linux_util.cpp#L2545) of the OpenMP runtime, the corresponding casts for each function call inside the `switch` are missing. For example, using `((void (*)(int*, int*, void*))(*pkfn))(>id, &tid, p_argv[0]);` instead of just `(*pkfn)(>id, &tid, p_argv[0]);`. This was also part of a previous PR [D142593](https://reviews.llvm.org/D142593). As reproducer any parallel region (even empty) will do. More comfortable might be using https://github.com/abrown/wasm-openmp-examples/ as it already includes a working Makefile for building and running. For the llvm-project subfolder just use the latest version. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
