[llvm-bugs] [Bug 120197] Cannot compare std::string's in if constexpr
Issue
120197
Summary
Cannot compare std::string's in if constexpr
Labels
new issue
Assignees
Reporter
Fedr
This program
```c++
#include
struct A {
static constexpr std::string name() { return "a"; }
};
template
bool f( T && ) {
if constexpr ( T::name() == "a" )
return true;
else
return false;
}
int main() {
return f( A{} );
}
```
is accepted by GCC and MSVC, but Clang complains:
```
error: constexpr if condition is not a constant _expression_
9 | if constexpr ( T::name() == "a" )
| ^~~~
```
Online demo: https://gcc.godbolt.org/z/o3nMx3zWj
Original discussion: https://stackoverflow.com/q/79283228/7325599
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120200] [clang] [coroutine] Possible over optimization of co_return
Issue
120200
Summary
[clang] [coroutine] Possible over optimization of co_return
Labels
clang
Assignees
Reporter
NewSigma
Hi, clang community
I want to discuss an unusual usage of coroutine and CRTP. The following code gives the expected result using MSVC, but a unpredictable result using GCC and clang. Intert a printf into final_suspend helps clang give the expected result.
A similar discussion is on [GCC Bugzilla](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118074).
https://godbolt.org/z/5rGjKPhW1
clang version: 16.0.0 ~ trunk
Build option: -std=c++20 -O2
```
#include
#include
#include
template
struct CRCoro { // Curiously Recurring Coroutine
struct RValueWrapper {
T* p;
operator T&&() const noexcept { return std::move(*p); }
};
using promise_type = T;
T& getDerived() noexcept { return *static_cast(this); }
auto get_return_object() noexcept { return RValueWrapper(&getDerived()); }
std::suspend_never initial_suspend() noexcept { return {}; }
std::suspend_never final_suspend() noexcept {
//printf("final_suspend\n");
return {};
}
void return_value(T&& x) noexcept { getDerived() = std::move(x); }
void unhandled_exception() {}
};
struct A : public CRCoro {
int a;
};
A func() {
A aa{};
aa.a = 5;
co_return std::move(aa);
}
int main() {
printf("%d\n", func().a);
return 0;
}
```
Expected result(MSVC): 5
Possible result of clang: -387938488
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120201] SPEC CPU2017 521.wrf_r and 621wrf_s build error (flang 19.1.5 and 20.0 Segmentation fault)
Issue 120201 Summary SPEC CPU2017 521.wrf_r and 621wrf_s build error (flang 19.1.5 and 20.0 Segmentation fault) Labels flang Assignees Reporter edisonchan Encountered a segmentation fault error when trying to compile SPEC CPU2017 521.wrf_r adn 621.wrf_s for aarch64-android-linux-gnu target using flang-new. ``` default=base:# flags for all base OPTIMIZE= -Ofast -march=armv8-a -static EXTRA_FLAGS= -Wno-implicit-int -Wno-deprecated-ofast -Wno-deprecated-non-prototype # for flang-new 19.1+ EXTRA_CFLAGS = -Wno-implicit-int -Wno-deprecated-ofast -Wno-deprecated-non-prototype # for flang-new 19.1+ intrate,intspeed=base: # flags for integer base EXTRA_CFLAGS = -fno-strict-aliasing -fno-unsafe-math-optimizations -fno-finite-math-only -fgnu89-inline -fcommon fprate,fpspeed=base: EXTRA_CFLAGS += -fno-strict-aliasing EXTRA_CXXFLAGS = -fno-finite-math-only EXTRA_FFLAGS = #-fallow-argument-mismatch .. 521.wrf_r,621.wrf_s: #lang='F,C' CPORTABILITY = -DSPEC_CASE_FLAG FPORTABILITY = -fconvert=swap .. ``` Device: vivo iQOO 13 OS: termux proot Ubuntu 24.04.1 LTS aarch64 LLVM: llvm 19.1.5 and LLVM 20.0 ``` /home/edison/llvm/bin/flang-new -c -o module_alloc_space_3.fppized.o -I. -I./netcdf/include -I./inc -Ofast -march=armv8-a -static -fconvert=swap module_alloc_space_3.fppized.f90 PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. Stack dump: 0. Program arguments: /home/edison/llvm/bin/flang-new -fc1 -triple aarch64-android-linux-gnu -emit-obj -I . -I ./netcdf/include -I ./inc -mrelocation-model pic -pic-level 2 -pic-is-pie -ffast-math -target-cpu generic -target-feature +outline-atomics -target-feature +v> flang-new: error: unable to execute command: Segmentation fault flang-new: error: flang frontend command failed due to signal (use -v to see invocation) flang-new version 19.1.5 (https://github.com/llvm/llvm-project.git ab4b5a2db582958af1ee308a790cfdb42bd24720) Target: aarch64-android-linux-gnu Thread model: posix InstalledDir: /home/edison/llvm/bin flang-new: note: diagnostic msg: PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: flang-new: note: diagnostic msg: /tmp/module_alloc_space_3-dac996 flang-new: note: diagnostic msg: /tmp/module_alloc_space_3-dac996.sh flang-new: note: diagnostic msg: specmake: *** [/home/edison/cpu2017/benchspec/Makefile.defaults:386: module_alloc_space_3.fppized.o] Error 254 specmake: *** Waiting for unfinished jobs /home/edison/llvm/bin/flang-new -c -o module_alloc_space_2.fppized.o -I. -I./netcdf/include -I./inc -Ofast -march=armv8-a -static -fconvert=swap module_alloc_space_2.fppized.f90 ``` [diagnostic_msg.zip](https://github.com/user-attachments/files/18162694/diagnostic_msg.zip) ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120215] `libc++.modules.json` resource does not exist
Issue
120215
Summary
`libc++.modules.json` resource does not exist
Labels
libc++
Assignees
Reporter
h-2
I am trying this C++ Modules PoC:
CMakeLists.txt:
```CMake
cmake_minimum_required(VERSION 3.30)
set(CMAKE_CXX_STANDARD 23)
set(CMAKE_CXX_STANDARD_REQUIRED YES)
set(CMAKE_EXPERIMENTAL_CXX_IMPORT_STD "0e5b6991-d74f-4b3d-a41c-cf096e0b2508")
set(CMAKE_CXX_MODULE_STD ON)
project(example LANGUAGES CXX)
add_executable(main main.cpp)
```
main.cpp:
```cpp
import std;
int main()
{
std::print("foobar\n");
}
```
I have the following relevant packages installed:
```
ii clang-19 1:19.1.5~++20241203083347+ab4b5a2db582-1~exp1~20241203083401.69 amd64 C, C++ and Objective-C compiler
ii cmake 3.30.2-0kitware1ubuntu24.04.1 amd64cross-platform, open-source make system
ii cmake-data 3.30.2-0kitware1ubuntu24.04.1 all CMake data files (modules, templates and documentation
ii libc++-19-dev:amd64 1:19.1.5~++20241203083347+ab4b5a2db582-1~exp1~20241203083401.69 amd64 LLVM C++ Standard library (development files)
ii libc++1-19:amd64 1:19.1.5~++20241203083347+ab4b5a2db582-1~exp1~20241203083401.69 amd64 LLVM C++ Standard library
ii libc++abi-19-dev:amd64 1:19.1.5~++20241203083347+ab4b5a2db582-1~exp1~20241203083401.69 amd64LLVM low level support for a standard C++ library (development files)
ii libc++abi1-19:amd64
```
I build the project with:
`cmake ../ -DCMAKE_CXX_COMPILER=clang++-19 -DCMAKE_CXX_FLAGS="-stdlib=libc++" -DCMAKE_BUILD_TYPE=Debug -G Ninja`
It outputs:
```-- The CXX compiler identification is Clang 19.1.5
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/clang++-19 - skipped
-- Detecting CXX compile features
CMake Warning (dev) at /usr/share/cmake-3.30/Modules/Compiler/CMakeCommonCompilerMacros.cmake:248 (cmake_language):
CMake's support for `import std;` in C++23 and newer is experimental. It
is meant only for experimentation and feedback to CMake developers.
Call Stack (most recent call first):
/usr/share/cmake-3.30/Modules/CMakeDetermineCompilerSupport.cmake:113 (cmake_create_cxx_import_std)
/usr/share/cmake-3.30/Modules/CMakeTestCXXCompiler.cmake:83 (CMAKE_DETERMINE_COMPILER_SUPPORT)
CMakeLists.txt:10 (project)
This warning is for project developers. Use -Wno-dev to suppress it.
-- Detecting CXX compile features - done
-- Configuring done (0.4s)
CMake Error in CMakeLists.txt:
The "CXX_MODULE_STD" property on the target "main" requires that the
"__CMAKE::CXX23" target exist, but it was not provided by the toolchain.
Reason:
`libc++.modules.json` resource does not exist
-- Generating done (0.0s)
CMake Generate step failed. Build files cannot be regenerated correctly.
```
The requested file **is** installed by the official apt-package; it is located at: `/usr/lib/llvm-19/lib/libc++.modules.json`
But clang doesn't seem to be able to find it there.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120203] [X86] AVX1 targets failure to recognise VPTEST YMM pattern
Issue
120203
Summary
[X86] AVX1 targets failure to recognise VPTEST YMM pattern
Labels
backend:X86
Assignees
Reporter
RKSimon
```ll
define i1 @both_equal_v32qi(<32 x i8> %a, <32 x i8> %b, <32 x i8> %v) {
entry:
%0 = icmp ne <32 x i8> %v, %a
%1 = icmp ne <32 x i8> %v, %b
%2 = or <32 x i1> %0, %1
%3 = bitcast <32 x i1> %2 to i32
%cmp5 = icmp eq i32 %3, 0
ret i1 %cmp5
}
define i1 @both_equal_v16qi(<16 x i8> %a, <16 x i8> %b, <16 x i8> %v) {
entry:
%0 = icmp ne <16 x i8> %v, %a
%1 = icmp ne <16 x i8> %v, %b
%2 = or <16 x i1> %0, %1
%3 = bitcast <16 x i1> %2 to i16
%cmp5 = icmp eq i16 %3, 0
ret i1 %cmp5
}
```
llc -mcpu=znver2
```asm
both_equal_v32qi: # @both_equal_v32qi
vpxor %ymm0, %ymm2, %ymm0
vpxor %ymm1, %ymm2, %ymm1
vpor%ymm1, %ymm0, %ymm0
vptest %ymm0, %ymm0
sete%al
vzeroupper
retq
both_equal_v16qi: # @both_equal_v16qi
vpxor %xmm0, %xmm2, %xmm0
vpxor %xmm1, %xmm2, %xmm1
vpor%xmm1, %xmm0, %xmm0
vptest %xmm0, %xmm0
sete %al
retq
```
llc -mcpu=btver2
```asm
both_equal_v32qi: # @both_equal_v32qi
vpcmpeqb%xmm0, %xmm2, %xmm3
vextractf128$1, %ymm2, %xmm4
vpcmpeqb %xmm1, %xmm2, %xmm2
vextractf128$1, %ymm0, %xmm0
vextractf128$1, %ymm1, %xmm1
vpcmpeqb%xmm0, %xmm4, %xmm0
vpcmpeqb%xmm1, %xmm4, %xmm1
vpand %xmm2, %xmm3, %xmm2
vpand %xmm1, %xmm0, %xmm0
vpand %xmm0, %xmm2, %xmm0
vpmovmskb %xmm0, %eax
xorl$65535, %eax# imm = 0x
sete%al
retq
both_equal_v16qi: # @both_equal_v16qi
vpxor %xmm0, %xmm2, %xmm0
vpxor %xmm1, %xmm2, %xmm1
vpor%xmm1, %xmm0, %xmm0
vptest %xmm0, %xmm0
sete %al
retq
```
The AVX2 codegen is legal on AVX1 (just replace vpxor/vpor with vxorps/vorps).
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120227] Incorrect memref size produced during privatization post-affine-fusion
Issue
120227
Summary
Incorrect memref size produced during privatization post-affine-fusion
Labels
new issue
Assignees
Reporter
bane0101
Hi,
This issue can almost be considered a clone of https://github.com/llvm/llvm-project/issues/115989, except that the example used here has affine scalar loads and stores, instead of their affine vector counterparts. I see that incorrect memref sizes are generated after fusing the loops below :
```
// fusion_test.mlir
module {
func.func @main(%arg0: memref<2x4xf32>, %arg1: memref<1x2x4xf32>) {
%alloc = memref.alloc() : memref<1x2x4xf32>
affine.for %i = 0 to 1 {
%0 = affine.load %arg0[0, 0] : memref<2x4xf32>
%1 = affine.load %arg0[0, 1] : memref<2x4xf32>
%2 = affine.load %arg0[0, 2] : memref<2x4xf32>
%3 = affine.load %arg0[0, 3] : memref<2x4xf32>
%4 = affine.load %arg0[1, 0] : memref<2x4xf32>
%5 = affine.load %arg0[1, 1] : memref<2x4xf32>
%6 = affine.load %arg0[1, 2] : memref<2x4xf32>
%7 = affine.load %arg0[1, 3] : memref<2x4xf32>
affine.store %0, %alloc[0, 0, 0] : memref<1x2x4xf32>
affine.store %1, %alloc[0, 0, 1] : memref<1x2x4xf32>
affine.store %2, %alloc[0, 0, 2] : memref<1x2x4xf32>
affine.store %3, %alloc[0, 0, 3] : memref<1x2x4xf32>
affine.store %4, %alloc[0, 1, 0] : memref<1x2x4xf32>
affine.store %5, %alloc[0, 1, 1] : memref<1x2x4xf32>
affine.store %6, %alloc[0, 1, 2] : memref<1x2x4xf32>
affine.store %7, %alloc[0, 1, 3] : memref<1x2x4xf32>
}
affine.for %i = 0 to 2 {
affine.for %j = 0 to 4 {
%8 = affine.load %alloc[0, %i, %j] : memref<1x2x4xf32>
%9 = arith.negf %8 : f32
affine.store %9, %arg1[0, %i, %j] : memref<1x2x4xf32>
}
}
return
}
}
```
`$> mlir-opt --affine-loop-fusion fusion_test.mlir`
results in the following output:
```
module {
func.func @main(%arg0: memref<2x4xf32>, %arg1: memref<1x2x4xf32>) {
%alloc = memref.alloc() : memref<1x1x1xf32>
affine.for %arg2 = 0 to 2 {
affine.for %arg3 = 0 to 4 {
%0 = affine.load %arg0[0, 0] : memref<2x4xf32>
%1 = affine.load %arg0[0, 1] : memref<2x4xf32>
%2 = affine.load %arg0[0, 2] : memref<2x4xf32>
%3 = affine.load %arg0[0, 3] : memref<2x4xf32>
%4 = affine.load %arg0[1, 0] : memref<2x4xf32>
%5 = affine.load %arg0[1, 1] : memref<2x4xf32>
%6 = affine.load %arg0[1, 2] : memref<2x4xf32>
%7 = affine.load %arg0[1, 3] : memref<2x4xf32>
affine.store %0, %alloc[0, 0, 0] : memref<1x1x1xf32>
affine.store %1, %alloc[0, 0, 1] : memref<1x1x1xf32>
affine.store %2, %alloc[0, 0, 2] : memref<1x1x1xf32>
affine.store %3, %alloc[0, 0, 3] : memref<1x1x1xf32>
affine.store %4, %alloc[0, 1, 0] : memref<1x1x1xf32>
affine.store %5, %alloc[0, 1, 1] : memref<1x1x1xf32>
affine.store %6, %alloc[0, 1, 2] : memref<1x1x1xf32>
affine.store %7, %alloc[0, 1, 3] : memref<1x1x1xf32>
%8 = affine.load %alloc[0, %arg2, %arg3] : memref<1x1x1xf32>
%9 = arith.negf %8 : f32
affine.store %9, %arg1[0, %arg2, %arg3] : memref<1x2x4xf32>
}
}
return
}
}
```
Here, the type of `%alloc` changed from `memref<1x2x4xf32>` to `memref<1x1x1xf32>` which is incorrect. The memref privatization code needs fixing.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120228] unrelated `TypedefDecl` included in AST dump for empty function
Issue
120228
Summary
unrelated `TypedefDecl` included in AST dump for empty function
Labels
question,
clang:frontend
Assignees
Reporter
firewave
```cpp
void f()
{
}
```
`clang -Xclang -ast-dump -E - < a.cpp`
```
TranslationUnitDecl 0x60efd80ef9f8 <>
|-TypedefDecl 0x60efd80f0228 <> implicit __int128_t '__int128'
| `-BuiltinType 0x60efd80effc0 '__int128'
|-TypedefDecl 0x60efd80f0298 <> implicit __uint128_t 'unsigned __int128'
| `-BuiltinType 0x60efd80effe0 'unsigned __int128'
|-TypedefDecl 0x60efd80f05a0 <> implicit __NSConstantString 'struct __NSConstantString_tag'
| `-RecordType 0x60efd80f0370 'struct __NSConstantString_tag'
| `-Record 0x60efd80f02f0 '__NSConstantString_tag'
|-TypedefDecl 0x60efd80f0648 <> implicit __builtin_ms_va_list 'char *'
| `-PointerType 0x60efd80f0600 'char *'
| `-BuiltinType 0x60efd80efaa0 'char'
|-TypedefDecl 0x60efd80f0940 <> implicit __builtin_va_list 'struct __va_list_tag[1]'
| `-ConstantArrayType 0x60efd80f08e0 'struct __va_list_tag[1]' 1
| `-RecordType 0x60efd80f0720 'struct __va_list_tag'
| `-Record 0x60efd80f06a0 '__va_list_tag'
`-FunctionDecl 0x60efd8151470 <:1:1, line:3:1> line:1:6 f 'void ()'
`-CompoundStmt 0x60efd8151560
```
Where are these `TypedefDecl` coming from? They seem totally unrelated and unnecessary to the code that is being pocessed.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120208] Request Commit Access For tgymnich
Issue 120208 Summary Request Commit Access For tgymnich Labels infra:commit-access-request Assignees Reporter tgymnich ### Why Are you requesting commit access ? Both for private and professional contributions to LLVM. Right now I am working towards adding floating point info to LLT. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120214] -Wtautological-compare should flag tautological pointer bounds checks
Issue
120214
Summary
-Wtautological-compare should flag tautological pointer bounds checks
Labels
clang:diagnostics
Assignees
Reporter
nikic
`-Wtautological-compare` should report pointer "bounds checks" patterns that are always true/false because unsigned pointer arithmetic cannot overflow.
```
bool test1(const char *ptr, size_t index) {
return ptr + index < ptr; // always false
}
bool test2(const char *ptr, size_t index) {
return ptr + index >= ptr; // always true
}
```
These two are fine though:
```
bool test3(const char *ptr, ssize_t index) {
return ptr + index < ptr; // unknown
}
bool test4(const char *ptr, ssize_t index) {
return ptr + index >= ptr; // unknown
}
```
Idea from https://github.com/llvm/llvm-project/pull/118472#issuecomment-2548141458.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120237] Program terminated with signal: SIGKILL Compiler returned: 137
Issue
120237
Summary
Program terminated with signal: SIGKILL Compiler returned: 137
Labels
new issue
Assignees
Reporter
TatyanaDoubts
To reproduce run the following test with -passes=loop-vectorize on opt:
```
; ModuleID = './reduced.ll'
source_filename = "./reduced.ll"
target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128-ni:1-p2:32:8:8:32-ni:2"
target triple = "x86_64-unknown-linux-gnu"
define void @wombat() #0 gc "statepoint-example" {
bb:
call void @llvm.assume(i1 false)
call void @llvm.assume(i1 false)
br label %bb6
bb1: ; preds = %bb2, %bb6
br label %bb2
bb2: ; preds = %bb2, %bb1
%phi = phi i32 [ %add4, %bb2 ], [ 0, %bb1 ]
%phi3 = phi i32 [ 0, %bb2 ], [ 0, %bb1 ]
%add = add i32 0, 0
%add4 = add i32 %phi, 1
%icmp = icmp ugt i32 %phi, 0
br i1 %icmp, label %bb1, label %bb2
bb5: ; preds = %bb5
br i1 false, label %bb6, label %bb5
bb6: ; preds = %bb5, %bb
%phi7 = phi i32 [ 0, %bb5 ], [ 0, %bb ]
br label %bb1
}
; Function Attrs: nocallback nofree nosync nounwind willreturn memory(inaccessiblemem: write)
declare void @llvm.assume(i1 noundef) #1
attributes #0 = { "target-features"="+prfchw,-cldemote,+avx,+aes,+sahf,+pclmul,-xop,+crc32,-amx-fp8,+xsaves,-avx512fp16,-usermsr,-sm4,-egpr,+sse4.1,-avx512ifma,+xsave,+sse4.2,-tsxldtrk,-sm3,-ptwrite,-widekl,-movrs,+invpcid,+64bit,+xsavec,-avx10.1-512,-avx512vpopcntdq,+cmov,-avx512vp2intersect,+avx512cd,+movbe,-avxvnniint8,-ccmp,-amx-int8,-kl,-avx10.1-256,+evex512,-avxvnni,+rtm,+adx,+avx2,-hreset,-movdiri,-serialize,-sha512,-vpclmulqdq,+avx512vl,-uintr,-cf,+clflushopt,-raoint,-cmpccxadd,+bmi,-amx-tile,+sse,-avx10.2-256,-gfni,-avxvnniint16,-amx-fp16,-zu,-ndd,+xsaveopt,+rdrnd,+avx512f,-amx-bf16,-avx512bf16,-avx512vnni,-push2pop2,+cx8,+avx512bw,+sse3,+pku,-nf,-amx-tf32,-amx-avx512,+fsgsbase,-clzero,-mwaitx,-lwp,+lzcnt,-sha,-movdir64b,-ppx,-wbnoinvd,-enqcmd,-amx-transpose,-avx10.2-512,-avxneconvert,-tbm,-pconfig,-amx-complex,+ssse3,+cx16,+bmi2,+fma,+popcnt,-avxifma,+f16c,-avx512bitalg,-rdpru,+clwb,+mmx,+sse2,+rdseed,-avx512vbmi2,-prefetchi,-amx-movrs,-rdpid,-fma4,-avx512vbmi,-shstk,-vaes,-waitpkg,-sgx,+fxsr,+avx512dq,-sse4a,-avx512f" }
attributes #1 = { nocallback nofree nosync nounwind willreturn memory(inaccessiblemem: write) "target-features"="+prfchw,-cldemote,+avx,+aes,+sahf,+pclmul,-xop,+crc32,-amx-fp8,+xsaves,-avx512fp16,-usermsr,-sm4,-egpr,+sse4.1,-avx512ifma,+xsave,+sse4.2,-tsxldtrk,-sm3,-ptwrite,-widekl,-movrs,+invpcid,+64bit,+xsavec,-avx10.1-512,-avx512vpopcntdq,+cmov,-avx512vp2intersect,+avx512cd,+movbe,-avxvnniint8,-ccmp,-amx-int8,-kl,-avx10.1-256,+evex512,-avxvnni,+rtm,+adx,+avx2,-hreset,-movdiri,-serialize,-sha512,-vpclmulqdq,+avx512vl,-uintr,-cf,+clflushopt,-raoint,-cmpccxadd,+bmi,-amx-tile,+sse,-avx10.2-256,-gfni,-avxvnniint16,-amx-fp16,-zu,-ndd,+xsaveopt,+rdrnd,+avx512f,-amx-bf16,-avx512bf16,-avx512vnni,-push2pop2,+cx8,+avx512bw,+sse3,+pku,-nf,-amx-tf32,-amx-avx512,+fsgsbase,-clzero,-mwaitx,-lwp,+lzcnt,-sha,-movdir64b,-ppx,-wbnoinvd,-enqcmd,-amx-transpose,-avx10.2-512,-avxneconvert,-tbm,-pconfig,-amx-complex,+ssse3,+cx16,+bmi2,+fma,+popcnt,-avxifma,+f16c,-avx512bitalg,-rdpru,+clwb,+mmx,+sse2,+rdseed,-avx512vbmi2,-prefetchi,-amx-movrs,-rdpid,-fma4,-avx512vbmi,-shstk,-vaes,-waitpkg,-sgx,+fxsr,+avx512dq,-sse4a,-avx512f" }
```
Reproducer: https://godbolt.org/z/x7WrWvoxa
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120209] LLVM_ENABLE_RUNTIMES: Failed to parse {json_file}: {e}
Issue
120209
Summary
LLVM_ENABLE_RUNTIMES: Failed to parse {json_file}: {e}
Labels
new issue
Assignees
jhuber6
Reporter
Meinersbur
In certain situations when build the runtimes, the following soft error appears:
```
[ 56%/2.891s :: 4->31->45 (of 79)] Generating /home/meinersbur/build/llvm-project-flangrt/release_bootstrap/compile_commands.json
Failed to parse {json_file}: {e}
Failed to parse {json_file}: {e}
```
This happens during merging the stage1 `compile_commands.json` with the runtimes's `compile_commands.json` introduced in #116303. For instance, when one of the `compile_commands.json` is deleted.
I strongly suggest to not mess with the CMake-generated `compile_commands.json`.
First, the rule depends on its own output, potentially creating a dependency loop that will always re-run the command. Ninja seems to have a protection mechanism for the, but Make does not. When the command is run repeatedly, it will append `compile_commands.json` each time making the file grow and grow.
Second, `compile_commands.json` is created during the CMake configure phase, but the append rule runs at the build phase, and only when running the `all` target. That is, one gets inconcistent views of the file.
Third, the file may not exist for various reasons, for instance after `make clean`. It is only implemented for the Makefile and Ninja generator and will be missing for other generators. There might be [more cases](https://github.com/llvm/llvm-project/pull/110217#issuecomment-2536772017) that I could not reproduce.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120211] `__builtin_bit_cast` to `bool` diverges from GCC's behavior
Issue 120211 Summary `__builtin_bit_cast` to `bool` diverges from GCC's behavior Labels clang:frontend, constexpr Assignees Reporter tbaederr This is the specific case: ```c++ constexpr bool A = __builtin_bit_cast(bool, 'A'); static_assert(A); ``` GCC happily compiles this while clang prints an error: ``` array.cpp:128:16: error: constexpr variable 'a' must be initialized by a constant _expression_ 128 | constexpr bool a = __builtin_bit_cast(bool, 'A'); |^ ~ array.cpp:128:20: note: value 65 cannot be represented in type 'bool' 128 | constexpr bool a = __builtin_bit_cast(bool, 'A'); |^ ``` This specific diagnostic is tested exactly _once_, in `SemaCXX/constexpr-builtin-bit-cast.cpp`. It's an edge case which clang checks for all integral types though: https://github.com/llvm/llvm-project/blob/0693b9e9ccdec5f09a3080b1bec73f5004a8dfa3/clang/lib/AST/ExprConstant.cpp#L7495-L7507 I think the relevant part from https://eel.is/c++draft/bit.cast is > For the result and each object created within it, if there is no value of the object's type corresponding to the value representation produced, the behavior is undefined[.](https://eel.is/c++draft/bit.cast#2.sentence-5) If there are multiple such values, which value is produced is unspecified[.](https://eel.is/c++draft/bit.cast#2.sentence-6) Does the first sentence apply here or the second? CC @zygoloid ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120229] [C++20][Modules] Unrecognised import directives with -E option
Issue
120229
Summary
[C++20][Modules] Unrecognised import directives with -E option
Labels
new issue
Assignees
iains,
urnathan,
dmpolukhin,
ChuanqiXu9
Reporter
dmpolukhin
[D121591](https://reviews.llvm.org/D121591) added insertion of `-fdirectives-only` for header units compiled for preprocessor output. This option prevents macro expansion in the output, see [D121099](https://reviews.llvm.org/D121099). But it has very unfortunate side effect that `import` may not be recognized because Lexer recognize them only at top level and if there is nothing before. The reproducer is following:
```
// RUN: rm -fR %t
// RUN: split-file %s %t
// RUN: cd %t
// RUN: %clang_cc1 -verify -std=c++20 -Wno-experimental-header-units -emit-header-unit -xc++-user-header bz0.h -o bz0.pcm -fmodule-name=bz0.h
// Test direct build.
// RUN: %clang_cc1 -verify -std=c++20 -Wno-experimental-header-units -fmodule-map-file=modules.map -emit-header-unit -xc++-user-header -fmodule-file=bz0.h=bz0.pcm bz.h
// Test build for preprocessed output.
// RUN: %clang_cc1 -verify -std=c++20 -Wno-experimental-header-units -fmodule-map-file=modules.map -emit-header-unit -xc++-user-header -fmodule-file=bz0.h=bz0.pcm bz.h -E -fdirectives-only -o pp_output
// RUN: %clang_cc1 -verify -std=c++20 -Wno-experimental-header-units -fmodule-map-file=modules.map -emit-header-unit -xc++-user-header -fmodule-file=bz0.h=bz0.pcm pp_output
//--- modules.map
module "bz0.h" {
header "bz0.h"
export *
}
//--- h1.h
#pragma once
#define PUSH_WARNING _Pragma("GCC diagnostic push")
#define POP_WARNING _Pragma("GCC diagnostic pop")
PUSH_WARNING
POP_WARNING
//--- h2.h
#pragma once
#define FOO
struct A {};
//--- bz0.h
#include "h2.h"
// expected-no-diagnostics
//--- bz.h
// expected-no-diagnostics
#include "h1.h"
import "bz0.h";
#ifndef FOO
#error "FOO macro is not defined"
#endif
#include "h2.h"
```
After https://github.com/llvm/llvm-project/pull/111662 clang recognizes `import` after pragmas but because macro expansion is disabled it cannot be recognized in this case. One of the way to fix this issue is to allow macro expansion but preserve macro definitions in the output because they should be exported to preserve semantic.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120234] [clang-cl] Auto link `clang_rt` library when half-precision floating point types are used
Issue
120234
Summary
[clang-cl] Auto link `clang_rt` library when half-precision floating point types are used
Labels
new issue
Assignees
Reporter
zufuliu
Tested LLVM 19.1.5, following code with pragma comment out failed to link. it seems frontend doesn't emit link hint for `clang_rt` library.
```c++
//#pragma comment(lib, "clang_rt.builtins-x86_64.lib")
__bf16 add16(__bf16 x, __bf16 y) {
return x + y;
}
int main(int argc, char *argv[]) {
int x = argv[0][0] - '0';
return (int)add16((__bf16)argc, (__bf16)(x));
}
```
```console
D:\notepad4>clang-cl /c test.cpp
D:\notepad4>lld-link test.obj
lld-link: error: undefined symbol: __truncsfbf2
>>> referenced by test.obj:(struct __clang::__bf16 __cdecl add16(struct __clang::__bf16, struct __clang::__bf16))
>>> referenced by test.obj:(struct __clang::__bf16 __cdecl add16(struct __clang::__bf16, struct __clang::__bf16))
>>> referenced by test.obj:(struct __clang::__bf16 __cdecl add16(struct __clang::__bf16, struct __clang::__bf16))
>>> referenced 2 more times
D:\notepad4>link test.obj
Microsoft (R) Incremental Linker Version 14.42.34435.0
Copyright (C) Microsoft Corporation. All rights reserved.
test.obj : error LNK2019: unresolved external symbol __truncsfbf2 referenced in function "struct __clang::__bf16 __cdecl add16(struct __clang::__bf16,struct __clang::__bf16)" (?add16@@YAU__bf16@__clang@@U12@0@Z)
test.exe : fatal error LNK1120: 1 unresolved externals
D:\notepad4>
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120206] -Wreturn-stack-address false positive
Issue
120206
Summary
-Wreturn-stack-address false positive
Labels
clang:memory-safety
Assignees
hokein
Reporter
hokein
https://gcc.godbolt.org/z/T3PW87TTW
```
struct [[gsl::Pointer]] view {};
struct S {
view s;
};
struct [[gsl::Owner]] Q {
const S& get() const [[clang::lifetimebound]];
};
view g(view b, int c) {
return c > 1 ? Q().get().s : b; // bogus diagnostic on `Q()`.
}
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120284] Request Commit Access For sarnex
Issue 120284 Summary Request Commit Access For sarnex Labels infra:commit-access-request Assignees Reporter sarnex ### Why Are you requesting commit access ? I work for Intel on GPU offloading and am currently working on SPIR-V-based OpenMP offload as well as on SYCL in general. I am also a developer for Gentoo Linux in my private time, but all of my changes have been as part of my work with Intel so far. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120299] Remove `urllib2`
Issue 120299 Summary Remove `urllib2` Labels new issue Assignees Reporter mtelka There are few places where `urllib2` is still mentioned. Namely: - https://github.com/llvm/llvm-project/blob/e8ce6c4e69745b1b2cd6f7479c48fbae44622cb3/lld/utils/benchmark.py#L22 - https://github.com/llvm/llvm-project/blob/e8ce6c4e69745b1b2cd6f7479c48fbae44622cb3/clang/tools/scan-view/bin/scan-view#L16 - https://github.com/llvm/llvm-project/blob/e8ce6c4e69745b1b2cd6f7479c48fbae44622cb3/llvm/utils/unicode-case-fold.py#L28 - https://github.com/llvm/llvm-project/blob/e8ce6c4e69745b1b2cd6f7479c48fbae44622cb3/clang/docs/tools/dump_ast_matchers.py#L13 Since `urllib2` is [python2-only thing](https://docs.python.org/2/library/urllib2.html) and since Python 2 is no longer supported by LLVM then I believe all traces of `urllib2` could be safely removed. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120335] [flang][debug] Missing function/subroutine attribute {DW_AT_elemental, DW_AT_pure, DW_AT_recursive}
Issue
120335
Summary
[flang][debug] Missing function/subroutine attribute {DW_AT_elemental, DW_AT_pure, DW_AT_recursive}
Labels
flang
Assignees
Reporter
jieljiel
Flang currently does not generate DWARF attribute DW_AT_elemental, DW_AT_pure and DW_AT_recursive for function/subroutine.
Need to emit metadata for `DISubprogram` field `spFlags:`, values are: DISPFlagElemental, DISPFlagPure, and DISPFlagRecursive. These procedure attributes info should be retrievable from the func operation.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120362] apple llvm 19.1.6 missing libclang_rt.asan_ios_dynamic.dylib
Issue 120362 Summary apple llvm 19.1.6 missing libclang_rt.asan_ios_dynamic.dylib Labels new issue Assignees Reporter calvin2021y I try download `https://github.com/llvm/llvm-project/releases/download/llvmorg-19.1.6/LLVM-19.1.6-macOS-ARM64.tar.xz`, compare to llvm18 there is no `libclang_rt.asan_ios_dynamic.dylib` I try build myself on x86_64, not work with error: ```sh file Parser.cpp.o differs between phase 2 and phase 3 sed: RE error: illegal byte sequence sed: RE error: illegal byte sequence file TableGenBackendSkeleton.cpp.o differs between phase 2 and phase 3 sed: RE error: illegal byte sequence sed: RE error: illegal byte sequence file DetailedRecordsBackend.cpp.o differs between phase 2 and phase 3 sed: RE error: illegal byte sequence sed: RE error: illegal byte sequence file TGLexer.cpp.o differs between phase 2 and phase 3 sed: RE error: illegal byte sequence sed: RE error: illegal byte sequence file TableGenBackend.cpp.o differs between phase 2 and phase 3 sed: RE error: illegal byte sequence sed: RE error: illegal byte sequence file TGParser.cpp.o differs between phase 2 and phase 3 sed: RE error: illegal byte sequence sed: RE error: illegal byte sequence file StringMatcher.cpp.o differs between phase 2 and phase 3 sed: RE error: illegal byte sequence sed: RE error: illegal byte sequence file SetTheory.cpp.o differs between phase 2 and phase 3 sed: RE error: illegal byte sequence sed: RE error: illegal byte sequence file JSONBackend.cpp.o differs between phase 2 and phase 3 sed: RE error: illegal byte sequence sed: RE error: illegal byte sequence file Error.cpp.o differs between phase 2 and phase 3 # Packaging the release as clang+llvm-19.1.6-x86_64-apple-darwin22.tar.xz ``` try build with: ```sh llvm/utils/release/test-release.sh \ -release 19.1.6 \ -final \ -triple x86_64-apple-darwin22 \ -j 12 \ -use-ninja \ -configure-flags "-DLLVM_USE_STATIC_ZSTD=ON" \ -lldb \ -no-test-suite ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120361] [InstCombine] `samesign` should be dropped when folding logical and of icmps
Issue
120361
Summary
[InstCombine] `samesign` should be dropped when folding logical and of icmps
Labels
miscompilation,
llvm:instcombine
Assignees
dtcxzyw
Reporter
dtcxzyw
Reproducer: https://alive2.llvm.org/ce/z/YSW_NC
```
define i1 @src(i8 %0, i8 %1) {
start:
%2 = icmp samesign eq i8 %0, -1
%3 = icmp ne i8 %0, 0
%4 = icmp ugt i8 %0, %0
%result = select i1 %3, i1 %2, i1 %4
ret i1 %result
}
define i1 @tgt(i8 %0, i8 %1) {
start:
%2 = icmp samesign eq i8 %0, -1
ret i1 %2
}
```
```
define i1 @src(i8 %#0, i8 %#1) {
start:
%#2 = icmp samesign eq i8 %#0, 255
%#3 = icmp ne i8 %#0, 0
%#4 = icmp ugt i8 %#0, %#0
%result = select i1 %#3, i1 %#2, i1 %#4
ret i1 %result
}
=>
define i1 @tgt(i8 %#0, i8 %#1) {
start:
%#2 = icmp samesign eq i8 %#0, 255
ret i1 %#2
}
Transformation doesn't verify!
ERROR: Target is more poisonous than source
Example:
i8 %#0 = #x00 (0)
i8 %#1 = poison
Source:
i1 %#2 = poison
i1 %#3 = #x0 (0)
i1 %#4 = #x0 (0)
i1 %result = #x0 (0)
Target:
i1 %#2 = poison
Source value: #x0 (0)
Target value: poison
```
Reported by https://github.com/dtcxzyw/llvm-mutation-based-fuzz-service/issues/14 while reviewing https://github.com/llvm/llvm-project/pull/120177.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120339] Redundant Copying of Large Struct Parameter to Stack When Passed to Another Function
Issue
120339
Summary
Redundant Copying of Large Struct Parameter to Stack When Passed to Another Function
Labels
new issue
Assignees
Reporter
jonathan-gruber-jg
When passing a large struct as an argument to a function, and the calling function already has the large struct as a parameter, Clang redundantly copies the struct parameter to the stack.
A minimal test case is in the attached file test.c.txt (GitHub would not allow me to upload it with the .c extension, sadly), reproduced below for your convenience:
```
struct S {
void *x, *y, *z, *w;
};
extern int extern_func(struct S);
int tail_call(struct S x) {
return extern_func(x);
}
int non_tail_call(struct S x) {
return ~extern_func(x);
}
```
I only tested the target architectures x86_64, aarch64, and riscv64, but I would not be surprised if other target architectures exhibit the same inefficiency.
Host system: Arch Linux, x86_64.
Clang version: official Arch Linux package of clang, version 18.1.8-4.
Command line to reproduce results: clang -c test.c --target= -O
x86_64 assembly (Intel syntax), with -Oz, -Os, -O2, or -O3
```
tail_call:
push rbp
mov rbp,rsp
pop rbp
jmp extern_func
non_tail_call:
push rbp
mov rbp,rsp
subrsp,0x20
movaps xmm0,XMMWORD PTR [rbp+0x10]
movaps xmm1,XMMWORD PTR [rbp+0x20]
movups XMMWORD PTR [rsp+0x10],xmm1
movups XMMWORD PTR [rsp],xmm0
call extern_func
noteax
addrsp,0x20
poprbp
ret
```
aarch64 assembly, with -Oz, -Os, -O2, or -O3
```
tail_call:
sub sp, sp, #0x30
stp x29, x30, [sp, #32]
add x29, sp, #0x20
ldp q0, q1, [x0]
mov x0, sp
stp q0, q1, [sp]
bl extern_func
ldp x29, x30, [sp, #32]
add sp, sp, #0x30
ret
non_tail_call:
sub sp, sp, #0x30
stp x29, x30, [sp, #32]
add x29, sp, #0x20
ldp q0, q1, [x0]
mov x0, sp
stp q0, q1, [sp]
bl extern_func
mvn w0, w0
ldp x29, x30, [sp, #32]
add sp, sp, #0x30
ret
```
riscv64 assembly, with -Oz, -Os, -O2, or -O3
```
tail_call:
addi sp,sp,-48
sd ra,40(sp)
lda1,24(a0)
lda2,16(a0)
lda3,8(a0)
lda0,0(a0)
sda1,32(sp)
sda2,24(sp)
sd a3,16(sp)
sda0,8(sp)
addi a0,sp,8
auipc ra,0x0
jalr ra # extern_func
ldra,40(sp)
addi sp,sp,48
ret
non_tail_call:
addi sp,sp,-48
sdra,40(sp)
ld a1,24(a0)
lda2,16(a0)
lda3,8(a0)
lda0,0(a0)
sda1,32(sp)
sda2,24(sp)
sda3,16(sp)
sd a0,8(sp)
addi a0,sp,8
auipc ra,0x0
jalr ra # extern_func
not a0,a0
ldra,40(sp)
addi sp,sp,48
ret
```
Only the tail call for x86_64 is optimized semi-correctly, save for the pointless register and stack manipulation prior to the unconditional branch to extern_func.
Please let me know if I should include anything else in this bug report.
[test.c.txt](https://github.com/user-attachments/files/18172937/test.c.txt)
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120355] Insufficient Optimization of Variadic Functions for Some Targets
Issue
120355
Summary
Insufficient Optimization of Variadic Functions for Some Targets
Labels
new issue
Assignees
Reporter
jonathan-gruber-jg
Clang insufficiently optimizes variadic functions for some target architectures. I only tested the target architectures aarch64 and riscv64, so I'm unsure about other target architectures.
Below is a minimal test case:
```
#include
void yes_ap(int dummy, ...) {
va_list ap;
va_start(ap, dummy);
va_end(ap);
}
void no_ap(int dummy, ...) {
/* Nothing. */
}
```
Host system: Arch Linux, x86_64.
Clang version: official Arch Linux package of clang, version 18.1.8-4.
Command line to reproduce results: clang -c test.c --target=\ -O\
aarch64 assembly with -O2, -O3, -Os, or -Oz is along the lines of this:
```
yes_ap:
sub sp, sp, #0xc0
stp x1, x2, [sp, #136]
stp x3, x4, [sp, #152]
stp x5, x6, [sp, #168]
str x7, [sp, #184]
stp q0, q1, [sp]
stp q2, q3, [sp, #32]
stp q4, q5, [sp, #64]
stp q6, q7, [sp, #96]
add sp, sp, #0xc0
ret
no_ap:
sub sp, sp, #0xc0
stp x1, x2, [sp, #136]
stp x3, x4, [sp, #152]
stp x5, x6, [sp, #168]
str x7, [sp, #184]
stp q0, q1, [sp]
stp q2, q3, [sp, #32]
stp q4, q5, [sp, #64]
stp q6, q7, [sp, #96]
add sp, sp, #0xc0
ret
```
riscv64 assembly with -O2, -O3, -Os, or -Oz is along the lines of this:
```
yes_ap:
addi sp,sp,-64
sd a7,56(sp)
sd a6,48(sp)
sd a5,40(sp)
sd a4,32(sp)
sd a3,24(sp)
sd a2,16(sp)
sd a1,8(sp)
addi sp,sp,64
ret
no_ap:
addi sp,sp,-64
sd a7,56(sp)
sd a6,48(sp)
sd a5,40(sp)
sd a4,32(sp)
sd a3,24(sp)
sd a2,16(sp)
sd a1,8(sp)
addi sp,sp,64
ret
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120347] `Generic_GCC` can't find GCC 13's `omp.h`
Issue 120347 Summary `Generic_GCC` can't find GCC 13's `omp.h` Labels new issue Assignees Reporter adamnovak I'm using Binder with LLVM 14.0.5. It seems like it builds and uses a bunch of Clang, and the bits of Clang it uses are having a lot of trouble finding my `omp.h`. Here's my log: ``` BINDER COMMAND: binder/./build/llvm-14.0.5/llvm-14.0.5.Linux-5.15.49-linuxkit-aarch64-with-glibc2.39.release/bin/binder --root-module bdsg --prefix /mnt/libbdsg-bindings-fix/libbdsg/bdsg/cmake_bindings/ --bind bdsg --config config.cfg all_cmake_includes.hpp -- -std=c++14 -I/mnt/libbdsg-bindings-fix/libbdsg/bdsg/include -I/mnt/libbdsg-bindings-fix/libbdsg/bdsg/deps/DYNAMIC/include -I/mnt/libbdsg-bindings-fix/libbdsg/bdsg/deps/pybind11/include -I/mnt/libbdsg-bindings-fix/libbdsg/bdsg/deps/hopscotch-map/include -I/mnt/libbdsg-bindings-fix/libbdsg/bdsg/deps/sdsl-lite/include -I/mnt/libbdsg-bindings-fix/libbdsg/bdsg/deps/mio/include -I/mnt/libbdsg-bindings-fix/libbdsg/bdsg/deps/libhandlegraph/src/include -I/mnt/libbdsg-bindings-fix/libbdsg/bdsg/deps/sparsepp -I/mnt/libbdsg-bindings-fix/libbdsg/bdsg/deps/BBHash -DNDEBUG -v clang version 14.0.5 (https://github.com/RosettaCommons/binder.git d5ef611f80cc91848db1fbd09d26b97013aa4db5) Target: aarch64-unknown-linux-gnu Thread model: posix InstalledDir: Found candidate GCC installation: /../lib/gcc/aarch64-linux-gnu/13 Selected GCC installation: /../lib/gcc/aarch64-linux-gnu/13 Candidate multilib: .;@m64 Selected multilib: .;@m64 clang version 14.0.5 (https://github.com/RosettaCommons/binder.git d5ef611f80cc91848db1fbd09d26b97013aa4db5) Target: aarch64-unknown-linux-gnu Thread model: posix InstalledDir: /mnt/libbdsg-bindings-fix/libbdsg/binder/build/llvm-14.0.5/llvm-14.0.5.Linux-5.15.49-linuxkit-aarch64-with-glibc2.39.release/bin Found candidate GCC installation: /usr/lib/gcc/aarch64-linux-gnu/13 Selected GCC installation: /usr/lib/gcc/aarch64-linux-gnu/13 Candidate multilib: .;@m64 Selected multilib: .;@m64 clang Invocation: "/mnt/libbdsg-bindings-fix/libbdsg/binder/build/llvm-14.0.5/llvm-14.0.5.Linux-5.15.49-linuxkit-aarch64-with-glibc2.39.release/bin/clang-tool" "-cc1" "-triple" "aarch64-unknown-linux-gnu" "-fsyntax-only" "-disable-free" "-clear-ast-before-backend" "-disable-llvm-verifier" "-discard-value-names" "-main-file-name" "all_cmake_includes.hpp" "-mrelocation-model" "static" "-mframe-pointer=non-leaf" "-fmath-errno" "-ffp-contract=on" "-fno-rounding-math" "-mconstructor-aliases" "-funwind-tables=2" "-target-cpu" "generic" "-target-feature" "+neon" "-target-feature" "+v8a" "-target-abi" "aapcs" "-fallow-half-arguments-and-returns" "-debugger-tuning=gdb" "-v" "-fcoverage-compilation-dir=/mnt/libbdsg-bindings-fix/libbdsg" "-resource-dir" "/mnt/libbdsg-bindings-fix/libbdsg/binder/build/llvm-14.0.5/llvm-14.0.5.Linux-5.15.49-linuxkit-aarch64-with-glibc2.39.release/lib/clang/14.0.5" "-I" "/mnt/libbdsg-bindings-fix/libbdsg/bdsg/include" "-I" "/mnt/libbdsg-bindings-fix/libbdsg/bdsg/deps/DYNAMIC/include" "-I" "/mnt/libbdsg-bindings-fix/libbdsg/bdsg/deps/pybind11/include" "-I" "/mnt/libbdsg-bindings-fix/libbdsg/bdsg/deps/hopscotch-map/include" "-I" "/mnt/libbdsg-bindings-fix/libbdsg/bdsg/deps/sdsl-lite/include" "-I" "/mnt/libbdsg-bindings-fix/libbdsg/bdsg/deps/mio/include" "-I" "/mnt/libbdsg-bindings-fix/libbdsg/bdsg/deps/libhandlegraph/src/include" "-I" "/mnt/libbdsg-bindings-fix/libbdsg/bdsg/deps/sparsepp" "-I" "/mnt/libbdsg-bindings-fix/libbdsg/bdsg/deps/BBHash" "-D" "NDEBUG" "-internal-isystem" "/usr/lib/gcc/aarch64-linux-gnu/13/../../../../include/c++/13" "-internal-isystem" "/usr/lib/gcc/aarch64-linux-gnu/13/../../../../include/aarch64-linux-gnu/c++/13" "-internal-isystem" "/usr/lib/gcc/aarch64-linux-gnu/13/../../../../include/c++/13/backward" "-internal-isystem" "/mnt/libbdsg-bindings-fix/libbdsg/binder/build/llvm-14.0.5/llvm-14.0.5.Linux-5.15.49-linuxkit-aarch64-with-glibc2.39.release/lib/clang/14.0.5/include" "-internal-isystem" "/usr/local/include" "-internal-isystem" "/usr/lib/gcc/aarch64-linux-gnu/13/../../../../aarch64-linux-gnu/include" "-internal-externc-isystem" "/usr/include/aarch64-linux-gnu" "-internal-externc-isystem" "/include" "-internal-externc-isystem" "/usr/include" "-std=c++14" "-fdeprecated-macro" "-fdebug-compilation-dir=/mnt/libbdsg-bindings-fix/libbdsg" "-ferror-limit" "19" "-fno-signed-char" "-fgnuc-version=4.2.1" "-fcxx-exceptions" "-fexceptions" "-fcolor-diagnostics" "-target-feature" "+outline-atomics" "-faddrsig" "-D__GCC_HAVE_DWARF2_CFI_ASM=1" "-x" "c++-header" "/mnt/libbdsg-bindings-fix/libbdsg/all_cmake_includes.hpp" clang -cc1 version 14.0.5 based upon LLVM 14.0.5 default target aarch64-unknown-linux-gnu ignoring nonexistent directory "/usr/lib/gcc/aarch64-linux-gnu/13/../../../../aarch64-linux-gnu/include" ignoring nonexist
[llvm-bugs] [Bug 120350] [clang][enum_overflow]Clang incorrectly thinks that enumerators of enum does not fit in the largest integer type
Issue
120350
Summary
[clang][enum_overflow]Clang incorrectly thinks that enumerators of enum does not fit in the largest integer type
Labels
clang
Assignees
Reporter
zhaojiangkun-1
Test case:
```
enum E {
e1 = 0x,
e2, e3
} e = e3;
#define SA(I,X) int a##I[(X)? 1 : -1]
SA(1, sizeof(E) == sizeof(__int128));
```
Backtrace:
```
warning: incremented enumerator value 18446744073709551616 is not representable in the largest integer type [-Wenum-too-large]
e2, e3
^
./ext1/int128-3.C:11:1: error: 'a1' declared as an array with a negative size
SA(1, sizeof(E) == sizeof(__int128));
^~~~
./ext1/int128-3.C:9:26: note: expanded from macro 'SA'
#define SA(I,X) int a##I[(X)? 1 : -1]
^~~
1 warning and 1 error generated.
```
It can be compiled in gcc, but an error is reported in clang.
https://godbolt.org/z/4Pdxs5sEs
This problem has been fixed before, but is it not compatible with this yet?
https://github.com/llvm/llvm-project/issues/24667
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120357] Old alignof Macro for C89 Broken as C23 Extension
Issue
120357
Summary
Old alignof Macro for C89 Broken as C23 Extension
Labels
new issue
Assignees
Reporter
Sha0
Please consider the following **offsetof.c** file:
```
~ $ cat offsetof.c
/*
* Compiler:
~ $ gcc -v
clang version 19.1.4
Target: aarch64-unknown-linux-android24
Thread model: posix
InstalledDir: /data/data/com.termux/files/usr/bin
* Error:
~ $ gcc -ansi -pedantic -Wall -Wextra -Werror -o offsetof offsetof.c 2>&1
offsetof.c:27:21: error: defining a type within 'offsetof' is a C23 extension [-Werror,-Wc23-extensions]
27 | return offsetof(struct { char c; }, c);
| ^~
/data/data/com.termux/files/usr/lib/clang/19/include/__stddef_offsetof.h:16:43: note: expanded from macro 'offsetof'
16 | #define offsetof(t, d) __builtin_offsetof(t, d)
| ^
1 error generated.
* Why?
*/
#include
int main(void)
{
return offsetof(struct { char c; }, c);
}
```
A relevant portion of C89 for **stddef.h** is:
```
[...] and
offsetof( type, member-designator)
which expands to an integral constant _expression_ that has type size_t,
the value of which is the offset in bytes, to the structure member
(designated by member-designator ), from the beginning of its
structure (designated by type ). The member-designator shall be such
that given
static type t;
then the _expression_ &(t. member-designator ) evaluates to an address
constant. (If the specified member is a bit-field, the behavior is
undefined.)
[...]
```
The **clang** error-message reports a "C23 extension." It is now December, 2024. At least 12 years ago, this "code-snippet" was produced:
- https://ideone.com/wL6wm
- (linked to from the https://www.iso-9899.info/wiki/Code_snippets page)
It uses an **alignof** macro shared by Mr. Chris M. Thomasson in **Usenet** (probably the **comp.lang.c** section) from before that time, which is something like:
```
#define alignof(type) (offsetof(struct {char c; type t;}, t))
```
I suspect that similar macros have been in use for much, much longer, but I could be mistaken.
If we are invoking clang in a C89 mode and we interpret the quotation above as authoritative, then I perceive that the type used within the offsetof macro in the code-file (shared far above) meets the "static type t;" condition and I do not perceive a C23 extension being relevant to such old usage.
Is this an opportunity for improvement?
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120353] Inefficient Stack Usage in Creating and Passing Large Struct Argument
Issue
120353
Summary
Inefficient Stack Usage in Creating and Passing Large Struct Argument
Labels
new issue
Assignees
Reporter
jonathan-gruber-jg
When creating a large struct and passing it as an argument, Clang stores the struct on the stack twice. By a "large" struct, I mean one that is too large to be passed as an argument in the argument registers and must instead be passed on the stack.
A minimal test case is in the attached file test.c.txt (GitHub would not allow me to upload it with the .c extension, sadly), reproduced below for your convenience:
```
struct S {
void *x, *y, *z, *w;
};
extern int extern_func(struct S);
int tail_call(void *x, void *y, void *z, void *w) {
struct S a = { x, y, z, w };
return extern_func(a);
}
int non_tail_call(void *x, void *y, void *z, void *w) {
struct S a = { x, y, z, w };
return ~extern_func(a);
}
```
I tested the target architecture x86_64 but am unsure if any other target architectures have this inefficiency.
Host system: Arch Linux, x86_64.
Clang version: official Arch Linux package of clang, version 18.1.8-4.
Command line to reproduce results: clang -c test.c --target=\ -O\
x86_64 assembly (Intel syntax), with -Oz, -Os, -O2, or -O3
```
tail_call:
push rbp
movrbp,rsp
subrsp,0x40
movQWORD PTR [rbp-0x20],rdi
movQWORD PTR [rbp-0x18],rsi
movQWORD PTR [rbp-0x10],rdx
movQWORD PTR [rbp-0x8],rcx
movups xmm0,XMMWORD PTR [rbp-0x20]
movups xmm1,XMMWORD PTR [rbp-0x10]
movups XMMWORD PTR [rsp+0x10],xmm1
movups XMMWORD PTR [rsp],xmm0
call extern_func
addrsp,0x40
poprbp
ret
non_tail_call:
push rbp
movrbp,rsp
subrsp,0x40
movQWORD PTR [rbp-0x20],rdi
movQWORD PTR [rbp-0x18],rsi
movQWORD PTR [rbp-0x10],rdx
movQWORD PTR [rbp-0x8],rcx
movups xmm0,XMMWORD PTR [rbp-0x20]
movups xmm1,XMMWORD PTR [rbp-0x10]
movups XMMWORD PTR [rsp+0x10],xmm1
movups XMMWORD PTR [rsp],xmm0
call extern_func
noteax
addrsp,0x40
poprbp
ret
```
[test.c.txt](https://github.com/user-attachments/files/18174500/test.c.txt)
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120269] Pragma message treated as a warning (Windows, clang-cl 18.1.8)
Issue
120269
Summary
Pragma message treated as a warning (Windows, clang-cl 18.1.8)
Labels
Assignees
Reporter
askebv
`first.cpp`:
```
#pragma message("Hi compiler!")
int main(void) { }
```
`build.bat`:
```
@echo off
REM Minimal test:
set LinkerFlags=-opt:ref -incremental:no
clang-cl "first.cpp" -o test.exe /link %LinkerFlags%
REM My actual settings where I need it to not be a warning:
REM set ClangCompilerFlags=-g -arch:AVX2 -fdiagnostics-absolute-paths -Wno-writable-strings -Wno-unused-variable -Wno-unused-parameter -Wno-unused-command-line-argument -Wno-unused-function
REM clang-cl -W4 -WX "first.cpp" -o test.exe /link %LinkerFlags%
```
**Output:**
```
first.cpp(1,9): warning: Hi compiler [-W#pragma-messages]
1 | #pragma message("Hi compiler!")
| ^
1 warning generated.
```
**Expected Output:**
```Hi compiler!```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120285] [clang-tidy] readability-simplify-boolean-expr requires redundant NOLINT to shush
Issue
120285
Summary
[clang-tidy] readability-simplify-boolean-expr requires redundant NOLINT to shush
Labels
enhancement,
clang-tidy
Assignees
Reporter
LegalizeAdulthood
Consider the following code:
```
inline bool check( OptixResult res )
{
if( res != OPTIX_SUCCESS ) // NOLINT(readability-simplify-boolean-expr)
{
return true; // NOLINT(readability-simplify-boolean-expr)
}
return false;
}
```
The `NOLINT` on the `if` statement should also apply to the interior `return` statement, but currently clang-tidy requires both annotations to be quiet.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120307] [flang][debug] Incorrect module variable scope when applying "use, only"
Issue 120307 Summary [flang][debug] Incorrect module variable scope when applying "use, only" Labels flang Assignees Reporter jieljiel Code example, ``` module mod1 integer :: a = 1 integer :: b = 2 end module subroutine sub1() use mod1, only : a end subroutine ``` When using debugger to inspect variable from inside sub1, only `a` should be visible, but currently flang is giving the whole module imported to sub1. ``` !2 = !DIModule(scope: !4, name: "mod1", file: !3, line: 1) !11 = distinct !DISubprogram(name: "sub1", linkageName: "sub1_", scope: !3, file: !3, line: 6, type: !12, scopeLine: 6, spFlags: DISPFlagDefinition | DISPFlagOptimized, unit: !4, retainedNodes: !14) !15 = !DIImportedEntity(tag: DW_TAG_imported_module, scope: !11, entity: !2, file: !3, line: 1) ``` The solution should be straight forward, (1) change the `tag:` field of `DIImportedEntity` from `DW_TAG_imported_module` to `DW_TAG_imported_declaration`; (2) change the `entity:` field of `DIImportedEntity` from referencing the module to refencing the variable; ``` !1 = distinct !DIGlobalVariable(name: "a", linkageName: "_QMmod1Ea", scope: !2, file: !3, line: 2, type: !8, isLocal: false, isDefinition: true) !2 = !DIModule(scope: !4, name: "mod1", file: !3, line: 1) !11 = distinct !DISubprogram(name: "sub1", linkageName: "sub1_", scope: !3, file: !3, line: 6, type: !12, scopeLine: 6, spFlags: DISPFlagDefinition | DISPFlagOptimized, unit: !4, retainedNodes: !14) !15 = !DIImportedEntity(tag: DW_TAG_imported_declaration, scope: !11, entity: !1, file: !3, line: 1) ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120256] Failing assertion in AMDGPUAttributor with ptrtoint casts and AS 3
Issue
120256
Summary
Failing assertion in AMDGPUAttributor with ptrtoint casts and AS 3
Labels
backend:AMDGPU,
crash-on-valid
Assignees
Reporter
ritter-x2a
I observe a failing assertion in the AMDGPUAttributor in code with ptrtoint casts and address space 3. It occurs on trunk since commit 41ed16c3b3362e51b7063eaef6461ab704c1ec7a by @jwanggit86.
Reproducer:
```
target datalayout = "e-p:64:64-p1:64:64-p2:32:32-p3:32:32-p4:64:64-p5:32:32-p6:32:32-p7:160:256:256:32-p8:128:128-p9:192:256:256:32-i64:64-v16:16-v24:32-v32:32-v48:64-v96:128-v192:256-v256:256-v512:512-v1024:1024-v2048:2048-n32:64-S32-A5-G1-ni:7:8:9"
target triple = "amdgcn-amd-amdhsa"
@buf_shared = internal addrspace(3) global [2080 x i8] undef, align 16
define protected amdgpu_kernel void @foo(ptr addrspace(1) nocapture noundef writeonly initializes((0, 1)) %res.coerce) local_unnamed_addr {
entry:
%conv.i = and i32 trunc (i64 sub (i64 16, i64 ptrtoint (ptr addrspacecast (ptr addrspace(3) @buf_shared to ptr) to i64)) to i32), 15
%add.ptr = getelementptr inbounds nuw i8, ptr addrspace(3) @buf_shared, i32 %conv.i
%0 = load i8, ptr addrspace(3) %add.ptr, align 1
store i8 %0, ptr addrspace(1) %res.coerce, align 1
ret void
}
```
`opt -mcpu=gfx1030 --amdgpu-attributor frame.ll` with the above as `frame.ll` yields:
```
opt: /home/faritter/projects/ritter-x2a-fork/llvm-project/llvm/include/llvm/Support/Casting.h:578: decltype(auto) llvm::cast(From*) [with To = llvm::PointerType; From = llvm::Type]: Assertion `isa(Val) && "cast() argument of incompatible type!"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0. Program arguments: ../../build/bin/opt -mcpu=gfx1030 --amdgpu-attributor frame.ll
1. Running pass 'AMDGPU Attributor' on module 'frame.ll'.
#0 0x5d350dd6d050 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (../../build/bin/opt+0x531f050)
#1 0x5d350dd6a46f llvm::sys::RunSignalHandlers() (../../build/bin/opt+0x531c46f)
#2 0x5d350dd6a5c5 SignalHandler(int) Signals.cpp:0:0
#3 0x78045a842520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#4 0x78045a8969fc __pthread_kill_implementation ./nptl/pthread_kill.c:44:76
#5 0x78045a8969fc __pthread_kill_internal ./nptl/pthread_kill.c:78:10
#6 0x78045a8969fc pthread_kill ./nptl/pthread_kill.c:89:10
#7 0x78045a842476 gsignal ./signal/../sysdeps/posix/raise.c:27:6
#8 0x78045a8287f3 abort ./stdlib/abort.c:81:7
#9 0x78045a82871b _nl_load_domain ./intl/loadmsgcat.c:1177:9
#10 0x78045a839e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96)
#11 0x5d3509d95b2b (anonymous namespace)::AAAMDAttributesFunction::needFlatScratchInit(llvm::Attributor&) AMDGPUAttributor.cpp:0:0
#12 0x5d3509da0aeb (anonymous namespace)::AAAMDAttributesFunction::updateImpl(llvm::Attributor&) AMDGPUAttributor.cpp:0:0
#13 0x5d350c2c03ea llvm::AbstractAttribute::update(llvm::Attributor&) (../../build/bin/opt+0x38723ea)
#14 0x5d350c2d319d llvm::Attributor::updateAA(llvm::AbstractAttribute&) (../../build/bin/opt+0x388519d)
#15 0x5d3509d9fb96 (anonymous namespace)::AAAMDAttributes const* llvm::Attributor::getOrCreateAAFor<(anonymous namespace)::AAAMDAttributes>(llvm::IRPosition, llvm::AbstractAttribute const*, llvm::DepClassTy, bool, bool) (.constprop.0) AMDGPUAttributor.cpp:0:0
#16 0x5d3509da213b (anonymous namespace)::runImpl(llvm::Module&, llvm::AnalysisGetter&, llvm::TargetMachine&, llvm::AMDGPUAttributorOptions) (.constprop.0) AMDGPUAttributor.cpp:0:0
#17 0x5d3509da2a3e (anonymous namespace)::AMDGPUAttributorLegacy::runOnModule(llvm::Module&) AMDGPUAttributor.cpp:0:0
#18 0x5d350db050a9 llvm::legacy::PassManagerImpl::run(llvm::Module&) (../../build/bin/opt+0x50b70a9)
#19 0x5d35095b6d12 optMain (../../build/bin/opt+0xb68d12)
#20 0x78045a829d90 __libc_start_call_main ./csu/../sysdeps/nptl/libc_start_call_main.h:58:16
#21 0x78045a829e40 call_init ./csu/../csu/libc-start.c:128:20
#22 0x78045a829e40 __libc_start_main ./csu/../csu/libc-start.c:379:5
#23 0x5d35095ac855 _start (../../build/bin/opt+0xb5e855)
Aborted (core dumped)
```
Used cmake options (probably not minimal):
```
-DCMAKE_BUILD_TYPE:STRING=Release
-DCMAKE_CXX_COMPILER_LAUNCHER:STRING=ccache
"-DLLVM_ENABLE_PROJECTS:STRING=clang;lld;clang-tools-extra"
"-DLLVM_ENABLE_RUNTIMES:STRING=compiler-rt;openmp"
-DLLVM_ENABLE_ASSERTIONS:BOOL=TRUE
-DLLVM_FORCE_ENABLE_STATS:BOOL=TRUE
-DLLVM_USE_SPLIT_DWARF:BOOL=TRUE
-DLLVM_ENABLE_DUMP:BOOL=TRUE
```
I reduced the above IR from this HIP code:
```
// clang -xhip --offload-arch=gfx1030 -isystem /opt/rocm/include --driver-mode=g++ -O3 ./frame.hip
#include "hip/hip_runtime.h"
#define ALIGNMENT_ZERO_BITS 4
#define NUM_MOVE_THREADS 64
[llvm-bugs] [Bug 120310] [LLDB] Crash when using `frame variable` command and there is instance of a class with shared_ptr inside of it
Issue
120310
Summary
[LLDB] Crash when using `frame variable` command and there is instance of a class with shared_ptr inside of it
Labels
new issue
Assignees
Reporter
TheRealCringengineer
LLDB is crashing when im trying to execute `frame variable` command and there is instance of a class that contains shared_ptr inside of it
Platform: Windows 11 23H2
Compiler that used to build executable: MSVC v19.41
What version of lldb were tested:
lldb v19.0 (installed from visual studio installer)
lldb v20.0 (builded from sources on 17 of december 2024)
Minimal code to reproduce bug
```cpp
#include
class Test
{
public:
Test(std::shared_ptr v)
: value(v)
{}
std::shared_ptr GetValue() { return value; }
private:
std::shared_ptr value;
};
int main()
{
std::unique_ptr test = std::make_unique(25);
std::cout << "Test " << *test << std::endl;
Test t(std::make_shared(42));
std::cout << "Test2 " << *t.GetValue() << std::endl;
}
```
Actions to reproduce this bug
1) Build executable
2) Attach lldb to it with `lldb app.exe`
3) Set breakpoint on main
4) run program to hit the breakpoint
5) execute command `frame variable`
6) expect crash
Stacktrace generated by lldb v20.0 builded from sources
```
Exception Code: 0xC005
#0 0x7ff953a9d065 lldb::SBUnixSignals::SetShouldSuppress(int, bool) (W:\llvm-project\Release\bin\liblldb.dll+0x29d065)
#1 0x7ff953d8ad4e lldb::SBUnixSignals::SetShouldSuppress(int, bool) (W:\llvm-project\Release\bin\liblldb.dll+0x58ad4e)
#2 0x7ff953c87964 lldb::SBUnixSignals::SetShouldSuppress(int, bool) (W:\llvm-project\Release\bin\liblldb.dll+0x487964)
#3 0x7ff953ab3e4b lldb::SBUnixSignals::SetShouldSuppress(int, bool) (W:\llvm-project\Release\bin\liblldb.dll+0x2b3e4b)
#4 0x7ff953ab44ec lldb::SBUnixSignals::SetShouldSuppress(int, bool) (W:\llvm-project\Release\bin\liblldb.dll+0x2b44ec)
#5 0x7ff953ab583a lldb::SBUnixSignals::SetShouldSuppress(int, bool) (W:\llvm-project\Release\bin\liblldb.dll+0x2b583a)
#6 0x7ff953ab3b09 lldb::SBUnixSignals::SetShouldSuppress(int, bool) (W:\llvm-project\Release\bin\liblldb.dll+0x2b3b09)
#7 0x7ff953ab3fba lldb::SBUnixSignals::SetShouldSuppress(int, bool) (W:\llvm-project\Release\bin\liblldb.dll+0x2b3fba)
#8 0x7ff953ab44ec lldb::SBUnixSignals::SetShouldSuppress(int, bool) (W:\llvm-project\Release\bin\liblldb.dll+0x2b44ec)
#9 0x7ff953ab583a lldb::SBUnixSignals::SetShouldSuppress(int, bool) (W:\llvm-project\Release\bin\liblldb.dll+0x2b583a)
#10 0x7ff953c77308 lldb::SBUnixSignals::SetShouldSuppress(int, bool) (W:\llvm-project\Release\bin\liblldb.dll+0x477308)
#11 0x7ff955cb80cb lldb::SBUnixSignals::SetShouldSuppress(int, bool) (W:\llvm-project\Release\bin\liblldb.dll+0x24b80cb)
#12 0x7ff953ae0aee lldb::SBUnixSignals::SetShouldSuppress(int, bool) (W:\llvm-project\Release\bin\liblldb.dll+0x2e0aee)
#13 0x7ff953aed662 lldb::SBUnixSignals::SetShouldSuppress(int, bool) (W:\llvm-project\Release\bin\liblldb.dll+0x2ed662)
#14 0x7ff953aef829 lldb::SBUnixSignals::SetShouldSuppress(int, bool) (W:\llvm-project\Release\bin\liblldb.dll+0x2ef829)
#15 0x7ff953a90f60 lldb::SBUnixSignals::SetShouldSuppress(int, bool) (W:\llvm-project\Release\bin\liblldb.dll+0x290f60)
#16 0x7ff953a488b9 lldb::SBUnixSignals::SetShouldSuppress(int, bool) (W:\llvm-project\Release\bin\liblldb.dll+0x2488b9)
#17 0x7ff953afa519 lldb::SBUnixSignals::SetShouldSuppress(int, bool) (W:\llvm-project\Release\bin\liblldb.dll+0x2fa519)
#18 0x7ff953930a74 lldb::SBDebugger::RunCommandInterpreter(bool, bool) (W:\llvm-project\Release\bin\liblldb.dll+0x130a74)
#19 0x7ff6003d5083 (W:\llvm-project\Release\bin\lldb.exe+0x5083)
#20 0x7ff6003d921f (W:\llvm-project\Release\bin\lldb.exe+0x921f)
#21 0x7ff6003fd4ec (W:\llvm-project\Release\bin\lldb.exe+0x2d4ec)
#22 0x7ffa6c42259d (C:\WINDOWS\System32\KERNEL32.DLL+0x1259d)
#23 0x7ffa6d34af38 (C:\WINDOWS\SYSTEM32\ntdll.dll+0x5af38)
```
Stacktrace generated by lldb v19.0.0 (from visual studio installer)
```
Exception Code: 0xC005
#0 0x7ff9a4b2547c lldb::SBUnixSignals::SetShouldSuppress(int, bool) (W:\binary\liblldb.dll+0x50547c)
#1 0x7ff9a486b95a lldb::SBUnixSignals::SetShouldSuppress(int, bool) (W:\binary\liblldb.dll+0x24b95a)
#2 0x7ff9a4881a0b lldb::SBUnixSignals::SetShouldSuppress(int, bool) (W:\binary\liblldb.dll+0x261a0b)
#3 0x7ff9a48820a7 lldb::SBUnixSignals::SetShouldSuppress(int, bool) (W:\binary\liblldb.dll+0x2620a7)
#4 0x7ff9a4883362 lldb::SBUnixSignals::SetShouldSuppress(int, bool) (W:\binary\liblldb.dll+0x263362)
#5 0x7ff9a488179e lldb::SBUnixSignals::SetShouldSuppress(int, bool) (W:\binary\liblldb.dll+0x26179e)
#6 0x7ff9a4881b85 lldb::SBUnixSignals::SetShouldSuppress(int, bool) (W:\binary\liblld
[llvm-bugs] [Bug 120313] LLVM ERROR: ThinLTO cannot create input file: Opaque pointers are only supported in -opaque-pointers mode
Issue 120313 Summary LLVM ERROR: ThinLTO cannot create input file: Opaque pointers are only supported in -opaque-pointers mode Labels new issue Assignees Reporter tjgreen42 From a build job for my project today (https://github.com/timescale/pgvectorscale/actions/runs/12381741123/job/34562157462 in case anyone wants to poke around): ``` LLVM ERROR: ThinLTO cannot create input file: Opaque pointers are only supported in -opaque-pointers mode (Producer: 'LLVM18.1.3' Reader: 'LLVM 14.0.6') PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. Stack dump: 0. Program arguments: /usr/lib/llvm-14/bin/llvm-lto -thinlto -thinlto-action="" -o vector.index.bc vector/src/bitutils.bc vector/src/bitvec.bc vector/src/halfutils.bc vector/src/halfvec.bc vector/src/hnsw.bc vector/src/hnswbuild.bc vector/src/hnswinsert.bc vector/src/hnswscan.bc vector/src/hnswutils.bc vector/src/hnswvacuum.bc vector/src/ivfbuild.bc vector/src/ivfflat.bc vector/src/ivfinsert.bc vector/src/ivfkmeans.bc vector/src/ivfscan.bc vector/src/ivfutils.bc vector/src/ivfvacuum.bc vector/src/sparsevec.bc vector/src/vector.bc #0 0x7f4ab82aa98a llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0xeaa98a) #1 0x7f4ab82a87df llvm::sys::RunSignalHandlers() (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0xea87df) #2 0x7f4ab82aaec0 (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0xeaaec0) #3 0x7f4ab6c45320 (/lib/x86_64-linux-gnu/libc.so.6+0x45320) #4 0x7f4ab6c9eb1c __pthread_kill_implementation ./nptl/./nptl/pthread_kill.c:44:76 #5 0x7f4ab6c9eb1c __pthread_kill_internal ./nptl/./nptl/pthread_kill.c:78:10 #6 0x7f4ab6c9eb1c pthread_kill ./nptl/./nptl/pthread_kill.c:89:10 #7 0x7f4ab6c4526e raise ./signal/../sysdeps/posix/raise.c:27:6 #8 0x7f4ab6c288ff abort ./stdlib/./stdlib/abort.c:81:7 #9 0x7f4ab81de9a5 (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0xdde9a5) #10 0x7f4ab984bacd llvm::ThinLTOCodeGenerator::addModule(llvm::StringRef, llvm::StringRef) (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0x244bacd) #11 0x00416394 (/usr/lib/llvm-14/bin/llvm-lto+0x416394) #12 0x0040fe92 (/usr/lib/llvm-14/bin/llvm-lto+0x40fe92) #13 0x7f4ab6c2a1ca __libc_start_call_main ./csu/../sysdeps/nptl/libc_start_call_main.h:74:3 #14 0x7f4ab6c2a28b call_init ./csu/../csu/libc-start.c:128:20 #15 0x7f4ab6c2a28b __libc_start_main ./csu/../csu/libc-start.c:347:5 #16 0x0040ac25 (/usr/lib/llvm-14/bin/llvm-lto+0x40ac25) Aborted (core dumped) ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120317] [flang][debug] Missing renamed module variable
Issue 120317 Summary [flang][debug] Missing renamed module variable Labels flang Assignees Reporter jieljiel Example code, ``` module mod1 integer :: a = 1, b = 2 end module subroutine sub1() use mod1, foo => a print *, foo, b end subroutine subroutine sub2() use mod1, only : bar => b print *, bar end subroutine ``` With flang, no DW_TAG_variable is generated for `foo` and `bar`. Proposed solution is to insert metadata nodes of `DIImportedEntity` with `tag:` field to be `DW_TAG_imported_declaration` and `name:` field to be tha variable's name, e.g. ``` !23 = !DIImportedEntity(tag: DW_TAG_imported_declaration, entity: !13, scope: !22, file: !3, line: 5, name: "foo") !30 = !DIImportedEntity(tag: DW_TAG_imported_declaration, entity: !16, scope: !29, file: !3, line: 10, name: "bar") ``` By looking into the DWARF from gfortran, with or without `only`, the scope could be different though, either belong to the subprogram or the imported module. ``` <1><2f>: Abbrev Number: 4 (DW_TAG_module) <30> DW_AT_name: (indirect string, offset: 0x10): mod1 ... <1><6f>: Abbrev Number: 6 (DW_TAG_subprogram) <70> DW_AT_external: 1 <70> DW_AT_name: (indirect string, offset: 0xef): sub1 ... <2><91>: Abbrev Number: 7 (DW_TAG_imported_module) ... <95> DW_AT_import : <0x2f> [Abbrev Number: 4 (DW_TAG_module)] <3><99>: Abbrev Number: 2 (DW_TAG_imported_declaration) ... <9c> DW_AT_name : foo DW_AT_import : <0x3b> [Abbrev Number: 1 (DW_TAG_variable)] ... <1>: Abbrev Number: 8 (DW_TAG_subprogram) DW_AT_external: 1 DW_AT_name: (indirect string, offset: 0xf4): sub2 ... <2>: Abbrev Number: 2 (DW_TAG_imported_declaration) ... DW_AT_name: bar DW_AT_import : <0x51> [Abbrev Number: 1 (DW_TAG_variable)] ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120254] "Instruction does not dominate" error with multi-dimensional reductions
Issue
120254
Summary
"Instruction does not dominate" error with multi-dimensional reductions
Labels
regression,
flang:openmp
Assignees
ergawy
Reporter
eugeneepshteyn
Recently, reductions with multi-dimensional arrays started to fail with flang. Reproducer:
```
subroutine parallel_reduction(a, x, N, M)
use omp_lib
implicit none
integer, intent(in) :: N, M
real, intent(in) :: a(N, M)
real, intent(out) :: x(M)
integer :: i, j
x = 0.0
!$OMP PARALLEL DO REDUCTION(+:x)
do j = 1, M
do i = 1, N
x(j) = x(j) + a(i, j)
end do
end do
!$OMP END PARALLEL DO
end subroutine parallel_reduction
```
How to reproduce:
```
$ flang -c -fopenmp reduction-sub.f90
flang-20: warning: OpenMP support in flang is still experimental [-Wexperimental-option]
Instruction does not dominate all uses!
%73 = alloca { ptr, i64, i32, i8, i8, i8, i8, [1 x [3 x i64]] }, i64 1, align 8
call void @llvm.memcpy.p0.p0.i32(ptr %34, ptr %73, i32 48, i1 false)
error: failed to create the LLVM module
```
Information about the flang compiler that can reproduce the issue (any recent will probably work):
```
$ flang --version
flang version 20.0.0git (https://github.com/llvm/llvm-project.git bdf727065b581c45b68a81090272f497f1ce5485)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/eepshteyn/src/flang-upstream/build/bin
Build config: +unoptimized, +assertions
```
"git bisect" pointed to the following commit that caused the regression:
```
commit 7f72d71de7c3b7d36d9f463b1459a6d2f6c989e6 (HEAD)
Author: Kareem Ergawy
Date: Thu Dec 5 05:23:49 2024 +0100
[OpenMP][OMPIRBuilder] Refactor reduction initialization logic into one util (#118447)
This refactors the logic needed to emit init logic for reductions by
moving some duplicated code into a shared util. The logic for doing is
quite involved and is needed for any construct that has reductions.
Moreover, when a construct has both private and reduction clauses, both
sets of clauses need to cooperate with each other when emitting the
logic needed for allocation and initialization. Therefore, this PR
clearly sets the boundaries for the logic needed to initialize
reductions.
```
github commit: https://github.com/llvm/llvm-project/commit/7f72d71de7c3b7d36d9f463b1459a6d2f6c989e6
github PR: https://github.com/llvm/llvm-project/pull/118447
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120289] Request Commit Access For @V-FEXrt
Issue 120289 Summary Request Commit Access For @V-FEXrt Labels infra:commit-access-request Assignees Reporter V-FEXrt ### Why are you requesting commit access? I'm a new core member of the HLSL team primarily working on the backend generation of DXIL and SPIRV from HLSL intrinsics with certainly a bunch more contributions across the repo yet to come. Here are some PRS I've landed/am working on thus far: - https://github.com/llvm/llvm-project/pull/115902 - https://github.com/llvm/llvm-project/pull/116858 - https://github.com/llvm/llvm-project/pull/117077 - https://github.com/llvm/llvm-project/pull/117245 ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120277] [C++][Modules] Assertion failure undeduced type in IR-generation
Issue
120277
Summary
[C++][Modules] Assertion failure undeduced type in IR-generation
Labels
new issue
Assignees
Reporter
davidstone
Given the following valid translation units:
```c++
export module a;
export template
struct a {
static auto f() {
}
};
```
```c++
export module b;
import a;
void b() {
a<0> t;
}
```
```c++
export module c;
import a;
void c() {
a<0>::f();
}
```
```c++
export module d;
import a;
import b;
import c;
struct d {
static void g() {
a<0>::f();
a<1>::f();
}
};
```
clang crashes with
```console
/opt/compiler-explorer/clang-assertions-trunk/bin/clang++ --gcc-toolchain=/opt/compiler-explorer/gcc-snapshot -fcolor-diagnostics -fno-crash-diagnostics -std=c++20 -MD -MT CMakeFiles/foo.dir/d.cpp.o -MF CMakeFiles/foo.dir/d.cpp.o.d @CMakeFiles/foo.dir/d.cpp.o.modmap -o CMakeFiles/foo.dir/d.cpp.o -c /app/d.cpp
undeduced type in IR-generation
UNREACHABLE executed at /root/llvm-project/clang/lib/CodeGen/CodeGenFunction.cpp:266!
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments: /opt/compiler-explorer/clang-assertions-trunk-20241217/bin/clang-20 -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -disable-free -clear-ast-before-backend -main-file-name d.cpp -mrelocation-model pic -pic-level 2 -pic-is-pie -mframe-pointer=all -fmath-errno -ffp-contract=on -fno-rounding-math -mconstructor-aliases -funwind-tables=2 -target-cpu x86-64 -tune-cpu generic -debugger-tuning=gdb -fdebug-compilation-dir=/app/build -fcoverage-compilation-dir=/app/build -resource-dir /opt/compiler-explorer/clang-assertions-trunk-20241217/lib/clang/20 -std=c++20 -fdeprecated-macro -ferror-limit 19 -fgnuc-version=4.2.1 -fno-implicit-modules -fmodule-file=a=CMakeFiles/foo.dir/a.pcm -fmodule-file=b=CMakeFiles/foo.dir/b.pcm -fmodule-file=c=CMakeFiles/foo.dir/c.pcm -fskip-odr-check-in-gmf -fcxx-exceptions -fexceptions -fcolor-diagnostics -faddrsig -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o CMakeFiles/foo.dir/d.cpp.o -x pcm CMakeFiles/foo.dir/d.pcm
1. parser at end of file
2. /app/d.cpp:8:14: LLVM IR generation of declaration 'd::g'
3. /app/d.cpp:8:14: Generating code for declaration 'd::g'
#0 0x03c58b18 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-assertions-trunk-20241217/bin/clang-20+0x3c58b18)
#1 0x03c5651c SignalHandler(int) Signals.cpp:0:0
#2 0x7c2ac3c42520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#3 0x7c2ac3c969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
#4 0x7c2ac3c42476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
#5 0x7c2ac3c287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
#6 0x03baf6ea (/opt/compiler-explorer/clang-assertions-trunk-20241217/bin/clang-20+0x3baf6ea)
#7 0x0403386a clang::CodeGen::CodeGenFunction::getEvaluationKind(clang::QualType) (/opt/compiler-explorer/clang-assertions-trunk-20241217/bin/clang-20+0x403386a)
#8 0x041b6ccf clang::CodeGen::isAggregateTypeForABI(clang::QualType) (/opt/compiler-explorer/clang-assertions-trunk-20241217/bin/clang-20+0x41b6ccf)
#9 0x0419cd36 (anonymous namespace)::X86_64ABIInfo::getIndirectReturnResult(clang::QualType) const X86.cpp:0:0
#10 0x041a698b (anonymous namespace)::X86_64ABIInfo::computeInfo(clang::CodeGen::CGFunctionInfo&) const X86.cpp:0:0
#11 0x043b42d1 clang::CodeGen::CodeGenTypes::arrangeLLVMFunctionInfo(clang::CanQual, clang::CodeGen::FnInfoOpts, llvm::ArrayRef>, clang::FunctionType::ExtInfo, llvm::ArrayRef, clang::CodeGen::RequiredArgs) (/opt/compiler-explorer/clang-assertions-trunk-20241217/bin/clang-20+0x43b42d1)
#12 0x043b6739 arrangeLLVMFunctionInfo(clang::CodeGen::CodeGenTypes&, bool, llvm::SmallVectorImpl>&, clang::CanQual) CGCall.cpp:0:0
#13 0x043b6b3f clang::CodeGen::CodeGenTypes::arrangeFreeFunctionType(clang::CanQual) (/opt/compiler-explorer/clang-assertions-trunk-20241217/bin/clang-20+0x43b6b3f)
#14 0x041008f0 clang::CodeGen::CodeGenTypes::ConvertFunctionTypeInternal(clang::QualType) (/opt/compiler-explorer/clang-assertions-trunk-20241217/bin/clang-20+0x41008f0)
#15 0x041010e7 clang::CodeGen::CodeGenTypes::ConvertType(clang::QualType) (/opt/compiler-explorer/clang-assertions-trunk-20241217/bin/clang-20+0x41010e7)
#16 0x040af678 clang::CodeGen::CodeGenModule::GetAddrOfFunction(clang::GlobalDecl, llvm::Type*, bool, bool, clang::CodeGen::ForDefinition_t) (/opt/compiler-explorer/clang-assertions-trunk-20241217/bin/clang-20+0x40af678)
#17 0x0443aa3e clang::CodeGen::CodeGenModule::getRawFunctionPointer(clang::GlobalDecl, llvm::Type*) (/
[llvm-bugs] [Bug 120278] Sanitizer common_interface_defs not actually common to all sanitizers
Issue
120278
Summary
Sanitizer common_interface_defs not actually common to all sanitizers
Labels
new issue
Assignees
Reporter
tavianator
`` includes ``, so I assumed that those functions would be available under MSan as well as ASan. But it seems not to be the case:
```console
$ cat foo.c
#include
#include
int main(void) {
char *buf = malloc(1024);
__sanitizer_annotate_contiguous_container(buf, buf + 1024, buf + 512, buf + 1024);
return 0;
}
$ clang -fsanitize=memory foo.c
/usr/bin/ld: /tmp/foo-072909.o: in function `main':
foo.c:(.text+0x171): undefined reference to `__sanitizer_annotate_contiguous_container'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
$ clang --version
clang version 18.1.8
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 120371] clang frontend fail
Issue 120371 Summary clang frontend fail Labels clang Assignees Reporter JeremieHuteau PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script. Stack dump: 0. Program arguments: /usr/bin/clang++ -I/home/arche/ntfs/CS/chess/engine/src/engine -I/home/arche/ntfs/CS/chess/engine/external -I/home/arche/ntfs/CS/chess/engine/src/games/core -I/home/arche/ntfs/CS/chess/engine/src/games -I/home/arche/ntfs/CS/chess/engine/src/games/chess -I/home/arche/ntfs/CS/chess/engine/src -I/home/arche/ntfs/CS/chess/engine/src/common -g -Og -Wall -Wextra -Wconversion -Wpedantic -std=gnu++20 -MD -MT src/engine/CMakeFiles/engine_objects.dir/selfplay_data.cpp.o -MF CMakeFiles/engine_objects.dir/selfplay_data.cpp.o.d -o CMakeFiles/engine_objects.dir/selfplay_data.cpp.o -c /home/arche/ntfs/CS/chess/engine/src/engine/selfplay_data.cpp 1. /home/arche/ntfs/CS/chess/engine/src/engine/graph.hpp:75:47: current parser token ';' 2. /home/arche/ntfs/CS/chess/engine/src/engine/graph.hpp:10:1: parsing namespace 'my_engine' 3. /home/arche/ntfs/CS/chess/engine/src/engine/graph.hpp:13:1: parsing struct/union/class body 'my_engine::Graph' Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it): 0 libLLVM.so.18.1 0x7f13c27c4d90 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 64 1 libLLVM.so.18.1 0x7f13c27c226d llvm::sys::CleanupOnSignal(unsigned long) + 141 2 libLLVM.so.18.1 0x7f13c26a88e9 3 libc.so.60x7f13c1a4c1d0 4 libclang-cpp.so.18.1 0x7f13cadf482c clang::QualType::isNonConstantStorage(clang::ASTContext const&, bool, bool) + 252 5 libclang-cpp.so.18.1 0x7f13cb1a82a3 clang::Sema::CheckCompleteVariableDeclaration(clang::VarDecl*) + 1091 6 libclang-cpp.so.18.1 0x7f13cb1aa390 clang::Sema::AddInitializerToDecl(clang::Decl*, clang::Expr*, bool) + 3088 7 libclang-cpp.so.18.1 0x7f13ca7c7546 clang::Parser::ParseCXXClassMemberDeclaration(clang::AccessSpecifier, clang::ParsedAttributes&, clang::Parser::ParsedTemplateInfo const&, clang::ParsingDeclRAIIObject*) + 8182 8 libclang-cpp.so.18.1 0x7f13ca7c8428 clang::Parser::ParseCXXClassMemberDeclarationWithPragmas(clang::AccessSpecifier&, clang::ParsedAttributes&, clang::TypeSpecifierType, clang::Decl*) + 1528 9 libclang-cpp.so.18.1 0x7f13ca7c8933 clang::Parser::ParseCXXMemberSpecification(clang::SourceLocation, clang::SourceLocation, clang::ParsedAttributes&, unsigned int, clang::Decl*) + 1043 10 libclang-cpp.so.18.1 0x7f13ca7ca9bb clang::Parser::ParseClassSpecifier(clang::tok::TokenKind, clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, bool, clang::Parser::DeclSpecContext, clang::ParsedAttributes&) + 5371 11 libclang-cpp.so.18.1 0x7f13ca7cc11a clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&, clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, clang::Parser::DeclSpecContext, clang::Parser::LateParsedAttrList*, clang::ImplicitTypenameContext) + 3226 12 libclang-cpp.so.18.1 0x7f13ca867b01 clang::Parser::ParseSingleDeclarationAfterTemplate(clang::DeclaratorContext, clang::Parser::ParsedTemplateInfo const&, clang::ParsingDeclRAIIObject&, clang::SourceLocation&, clang::ParsedAttributes&, clang::AccessSpecifier) + 945 13 libclang-cpp.so.18.1 0x7f13ca868bea clang::Parser::ParseTemplateDeclarationOrSpecialization(clang::DeclaratorContext, clang::SourceLocation&, clang::ParsedAttributes&, clang::AccessSpecifier) + 1242 14 libclang-cpp.so.18.1 0x7f13ca869156 clang::Parser::ParseDeclarationStartingWithTemplate(clang::DeclaratorContext, clang::SourceLocation&, clang::ParsedAttributes&, clang::AccessSpecifier) + 182 15 libclang-cpp.so.18.1 0x7f13ca7dcfdb clang::Parser::ParseDeclaration(clang::DeclaratorContext, clang::SourceLocation&, clang::ParsedAttributes&, clang::ParsedAttributes&, clang::SourceLocation*) + 667 16 libclang-cpp.so.18.1 0x7f13ca86954b clang::Parser::ParseExternalDeclaration(clang::ParsedAttributes&, clang::ParsedAttributes&, clang::ParsingDeclSpec*) + 763 17 libclang-cpp.so.18.1 0x7f13ca7bb47f clang::Parser::ParseInnerNamespace(llvm::SmallVector const&, unsigned int, clang::SourceLocation&, clang::ParsedAttributes&, clang::BalancedDelimiterTracker&) + 527 18 libclang-cpp.so.18.1 0x7f13ca7bc5f9 clang::Parser::ParseNamespace(clang::DeclaratorContext, clang::SourceLocation&, clang::SourceLocation) + 4185 19 libclang-cpp.so.18.1 0x7f13ca7dd18c clang::Parser::ParseDeclaration(clang::DeclaratorContext, clang::SourceLocation&, clang::ParsedAttributes&, clang::ParsedAttributes&, clang::SourceLocation*) + 1100 20 libclang-cpp.
