[llvm-bugs] [Bug 136547] Crashed when use clang to compile with a ir debug location printing pass plugin
Issue
136547
Summary
Crashed when use clang to compile with a ir debug location printing pass plugin
Labels
clang
Assignees
Reporter
Wakotu
I write a pass plugin like following and use clang to compile with that plugin. And then clang crashed.
### Pass Plugin
My Pass Plugin to print Debug line and column location for each IR Instruction:
```cpp
#include "llvm/IR/DebugLoc.h"
#include "llvm/IR/Function.h"
#include "llvm/IR/Instruction.h"
#include "llvm/IR/Module.h"
#include "llvm/IR/PassManager.h"
#include "llvm/Passes/OptimizationLevel.h"
#include "llvm/Passes/PassBuilder.h"
#include "llvm/Passes/PassPlugin.h"
#include "llvm/Support/Compiler.h"
#include "llvm/Support/raw_ostream.h"
using namespace llvm;
void print_ir_loc(Instruction &Inst, int idx) {
const DebugLoc &DL = Inst.getDebugLoc();
errs() << "Before" << "\n";
unsigned line = DL.getLine();
errs() << "After" << "\n";
unsigned col = DL.getCol();
outs() << "Instruction " << idx << "\n";
outs() << "line: " << line << ", col: " << col << "\n";
outs() << "\n";
}
void print_ir_loc_for_module(Module &M) {
int idx = 0;
for (Function &F : M) {
for (auto &BB : F) {
for (auto &I : BB) {
idx += 1;
print_ir_loc(I, idx);
}
}
}
}
struct MyPass : PassInfoMixin {
PreservedAnalyses run(Module &M, ModuleAnalysisManager &MAM) {
print_ir_loc_for_module(M);
return PreservedAnalyses::all();
}
};
extern "C" LLVM_ATTRIBUTE_WEAK ::llvm::PassPluginLibraryInfo
llvmGetPassPluginInfo() {
return {LLVM_PLUGIN_API_VERSION, "MyPass", "v0.1", [](PassBuilder &PB) {
PB.registerOptimizerEarlyEPCallback(
[](ModulePassManager &MPM, OptimizationLevel) {
MPM.addPass(MyPass());
});
}};
}
```
### Terminal Output
Terminal Output as following. Note that the `Before` text was printed while `After` was not, which means clang crashed at `unsigned line = DL.getLine();` .
```text
Before
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments: /usr/lib/llvm-18/bin/clang -cc1 -triple x86_64-pc-linux-gnu -emit-obj -mrelax-all -dumpdir a- -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name hello.c -mrelocation-model pic -pic-level 2 -pic-is-pie -mframe-pointer=all -fmath-errno -ffp-contract=on -fno-rounding-math -mconstructor-aliases -funwind-tables=2 -target-cpu x86-64 -tune-cpu generic -debug-info-kind=constructor -dwarf-version=5 -debugger-tuning=gdb -fdebug-compilation-dir=/home/yqy/toys/cc/pass_plugin -fcoverage-compilation-dir=/home/yqy/toys/cc/pass_plugin -resource-dir /usr/lib/llvm-18/lib/clang/18 -internal-isystem /usr/lib/llvm-18/lib/clang/18/include -internal-isystem /usr/local/include -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/13/../../../../x86_64-linux-gnu/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -ferror-limit 19 -fgnuc-version=4.2.1 -fskip-odr-check-in-gmf -fcolor-diagnostics -fpass-plugin=MyPass.so -dwarf-debug-flags "/usr/lib/llvm-18/bin/clang -fpass-plugin=MyPass.so -g ./examples/hello.c -dumpdir a-" -faddrsig -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o /tmp/hello-7eeb7e.o -x c ./examples/hello.c
1. parser at end of file
2. Optimizer
#0 0x7f37089e73ff llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/lib/x86_64-linux-gnu/libLLVM-18.so.18.1+0xda63ff)
#1 0x7f37089e5539 llvm::sys::RunSignalHandlers() (/lib/x86_64-linux-gnu/libLLVM-18.so.18.1+0xda4539)
#2 0x7f37089e7b40 (/lib/x86_64-linux-gnu/libLLVM-18.so.18.1+0xda6b40)
#3 0x7f37077f6330 (/lib/x86_64-linux-gnu/libc.so.6+0x45330)
#4 0x7f3708ac1f7b llvm::DebugLoc::getLine() const (/lib/x86_64-linux-gnu/libLLVM-18.so.18.1+0xe80f7b)
#5 0x7f3705345f58 print_ir_loc(llvm::Instruction&, int) (./MyPass.so+0xaf58)
#6 0x7f3705346123 print_ir_loc_for_module(llvm::Module&) (./MyPass.so+0xb123)
#7 0x7f370534861c MyPass::run(llvm::Module&, llvm::AnalysisManager&) (./MyPass.so+0xd61c)
#8 0x7f3705348524 llvm::detail::PassModel>::run(llvm::Module&, llvm::AnalysisManager&) (./MyPass.so+0xd524)
#9 0x7f3708b6f341 llvm::PassManager>::run(llvm::Module&, llvm::AnalysisManager&) (/lib/x86_64-linux-gnu/libLLVM-18.so.18.1+0xf2e341)
#10 0x7f3710e76730 (/usr/lib/llvm-18/lib/libclang-cpp.so.18.1+0x1c1f730)
#11 0x7f3710e6e093 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::IntrusiveRefCntPtr, std::unique_ptr>, clang::BackendConsu
[llvm-bugs] [Bug 136652] [OpenMP] Compiler segfault with `#pragma omp` in global lambda
Issue
136652
Summary
[OpenMP] Compiler segfault with `#pragma omp` in global lambda
Labels
new issue
Assignees
Reporter
KaruroChori
https://godbolt.org/z/vnMM79oYf
This segfaults:
```cpp
#include
auto slice_work = [](size_t device, float start, float end){
#pragma omp target teams device(device)
{
}
};
int main(){
slice_work(0,0,0);
return 0;
}
```
Moving the lambda to a local function, even as static will compile just fine:
```cpp
#include
int main(){
static auto slice_work = [](size_t device, float start, float end) {
#pragma omp target teams device(device)
{
}
};
slice_work(0,0,0);
return 0;
}
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 136646] [InstCombine] The sign bit of NaN is not preserved when folding `(X <= +/-0.0) ? (0.0 - X) : X to fabs(X)`
Issue
136646
Summary
[InstCombine] The sign bit of NaN is not preserved when folding `(X <= +/-0.0) ? (0.0 - X) : X to fabs(X)`
Labels
miscompilation,
llvm:instcombine
Assignees
dtcxzyw
Reporter
dtcxzyw
Reproducer: https://alive2.llvm.org/ce/z/2JaLU9
```
define half @src(half %x) {
#0:
%gtzero = fcmp ugt half %x, 0x
%negx = fsub half 0x, %x
%fabs = select i1 %gtzero, half %x, half %negx
ret half %fabs
}
=>
define half @src(half %x) nofree willreturn memory(none) {
#0:
%fabs = fabs half %x
ret half %fabs
}
Transformation doesn't verify!
ERROR: Value mismatch
Example:
half %x = #xfd00 (SNaN)
Source:
i1 %gtzero = #x1 (1)
half %negx = #xff00 (QNaN)
half %fabs = #xfd00 (SNaN)
Target:
half %fabs = #x7d00 (SNaN)
Source value: #xfd00 (SNaN)
Target value: #x7d00 (SNaN)
Summary:
0 correct transformations
1 incorrect transformations
0 failed-to-prove transformations
0 Alive2 errors
```
Related issues:
https://github.com/AliveToolkit/alive2/pull/1155
https://github.com/llvm/llvm-project/issues/59279
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 136647] [clangd] Crashing during switching header / source file
Issue 136647 Summary [clangd] Crashing during switching header / source file Labels new issue Assignees Reporter rentruewang ``` PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. #0 0x7f97ec881979 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/lib64/libLLVM.so.20.1+0xa81979) #1 0x7f97ec87eed0 llvm::sys::RunSignalHandlers() (/lib64/libLLVM.so.20.1+0xa7eed0) #2 0x7f97ec88215b (/lib64/libLLVM.so.20.1+0xa8215b) #3 0x7f97eb641e00 __restore_rt (/lib64/libc.so.6+0x41e00) #4 0x55a414739681 (/usr/bin/clangd+0x36e681) #5 0x55a41472bfb9 (/usr/bin/clangd+0x360fb9) #6 0x55a41472bd9c (/usr/bin/clangd+0x360d9c) #7 0x55a4147211f2 (/usr/bin/clangd+0x3561f2) #8 0x55a41473d887 (/usr/bin/clangd+0x372887) #9 0x55a41471b5ed (/usr/bin/clangd+0x3505ed) #10 0x55a414719071 (/usr/bin/clangd+0x34e071) #11 0x55a414719428 (/usr/bin/clangd+0x34e428) #12 0x55a414718e58 (/usr/bin/clangd+0x34de58) #13 0x55a4147189e7 (/usr/bin/clangd+0x34d9e7) #14 0x55a414649705 (/usr/bin/clangd+0x27e705) #15 0x55a4147ff81a (/usr/bin/clangd+0x43481a) #16 0x55a4147f7550 (/usr/bin/clangd+0x42c550) #17 0x55a4147f6f3b (/usr/bin/clangd+0x42bf3b) #18 0x55a41495a4b0 (/usr/bin/clangd+0x58f4b0) #19 0x7f97eb699546 start_thread (/lib64/libc.so.6+0x99546) #20 0x7f97eb71d94c __GI___clone3 (/lib64/libc.so.6+0x11d94c) Signalled during AST worker action: InlayHints Filename: /home/me/Documents/Repos/postgres/src/include/executor/executor.h Directory: /home/me/Documents/Repos/postgres/build Command Line: /usr/bin/cc -Isrc/backend/postgres_lib.a.p -Isrc/include -I../src/include -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -O2 -g -fno-strict-aliasing -fwrapv -fexcess-precision=standard -D_GNU_SOURCE -Wmissing-prototypes -Wpointer-arith -Werror=vla -Wendif-labels -Wmissing-format-attribute -Wimplicit-fallthrough=3 -Wcast-function-type -Wshadow=compatible-local -Wformat-security -Wdeclaration-after-statement -Wmissing-variable-declarations -Wno-format-truncation -Wno-stringop-truncation -fPIC -DWITH_GZFILEOP -pthread -DBUILDING_DLL -MD -MQ src/backend/postgres_lib.a.p/executor_execAmi.c.o -MF src/backend/postgres_lib.a.p/executor_execAmi.c.o.d -c -x c-header -resource-dir=/usr/lib64/clang/20 -- /home/me/Documents/Repos/postgres/src/include/executor/executor.h Version: 1 ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 136656] `std::flat_set` dispatches non-c++17 iterators to container's `insert(const_iterator, InputIterator, InputIterator)`
Issue
136656
Summary
`std::flat_set` dispatches non-c++17 iterators to container's `insert(const_iterator, InputIterator, InputIterator)`
Labels
new issue
Assignees
Reporter
hewillk
```cpp
#include
#include
#include
#include
#include
int main() {
boost::container::vector v;
std::flat_set s(v);
std::istringstream ints("0 1 1 0");
auto r = std::ranges::subrange(std::istream_iterator(ints),
std::istream_iterator())
| std::views::transform([](int i) { return i * i; });
s.insert_range(r);
}
```
https://godbolt.org/z/6P3rnod76
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 136658] [RISCV] Miscompile when casting tvv type to pointer
Issue
136658
Summary
[RISCV] Miscompile when casting tvv type to pointer
Labels
new issue
Assignees
Reporter
zhangjunphy
commit: 5e834b9ec7fc85072ec12de780d3c793c03b7d00
godbolt: https://godbolt.org/z/cr6445nqh
This code, after compiled with `-O2 -march=rv64gv`, the `__riscv_vle32_v_f32m2` call in function `f` is gone.
```c++
#include
#include
void print(uint16_t* data, int vl) {
for (int i = 0; i < vl; ++i) {
printf("%d\n", data[i]);
}
}
void f(const float *p) {
vfloat32m2_t v = __riscv_vle32_v_f32m2(p, 1024);
print((uint16_t*)(&v), 1024);
}
```
produced ir:
```
@.str = private unnamed_addr constant [4 x i8] c"%d\0A\00", align 1
define dso_local void @print(unsigned short*, int)(ptr noundef readonly captures(none) %data, i32 noundef signext %vl) local_unnamed_addr {
entry:
%cmp3 = icmp sgt i32 %vl, 0
br i1 %cmp3, label %for.body.preheader, label %for.cond.cleanup
for.body.preheader:
%wide.trip.count = zext nneg i32 %vl to i64
br label %for.body
for.cond.cleanup:
ret void
for.body:
%indvars.iv = phi i64 [ 0, %for.body.preheader ], [ %indvars.iv.next, %for.body ]
%arrayidx = getelementptr inbounds nuw i16, ptr %data, i64 %indvars.iv
%0 = load i16, ptr %arrayidx, align 2
%conv = zext i16 %0 to i32
%call = tail call signext i32 (ptr, ...) @printf(ptr noundef nonnull dereferenceable(1) @.str, i32 noundef signext %conv)
%indvars.iv.next = add nuw nsw i64 %indvars.iv, 1
%exitcond.not = icmp eq i64 %indvars.iv.next, %wide.trip.count
br i1 %exitcond.not, label %for.cond.cleanup, label %for.body
}
declare void @llvm.lifetime.start.p0(i64 immarg, ptr captures(none)) #1
declare noundef signext i32 @printf(ptr noundef readonly captures(none), ...) local_unnamed_addr #2
declare void @llvm.lifetime.end.p0(i64 immarg, ptr captures(none)) #1
define dso_local void @f(float const*)(ptr noundef readonly captures(none) %p) local_unnamed_addr {
entry:
%v = alloca , align 4
call void @llvm.lifetime.start.p0(i64 -1, ptr nonnull %v) #3
br label %for.body.i
for.body.i:
%indvars.iv.i = phi i64 [ 0, %entry ], [ %indvars.iv.next.i, %for.body.i ]
%arrayidx.i = getelementptr inbounds nuw i16, ptr %v, i64 %indvars.iv.i
%0 = load i16, ptr %arrayidx.i, align 2
%conv.i = zext i16 %0 to i32
%call.i = tail call signext i32 (ptr, ...) @printf(ptr noundef nonnull dereferenceable(1) @.str, i32 noundef signext %conv.i)
%indvars.iv.next.i = add nuw nsw i64 %indvars.iv.i, 1
%exitcond.not.i = icmp eq i64 %indvars.iv.next.i, 1024
br i1 %exitcond.not.i, label %print(unsigned short*, int).exit, label %for.body.i
print(unsigned short*, int).exit:
call void @llvm.lifetime.end.p0(i64 -1, ptr nonnull %v) #3
ret void
}
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 136650] [InstCombine] Poison safety violation in `foldLogicOfFCmps`
Issue
136650
Summary
[InstCombine] Poison safety violation in `foldLogicOfFCmps`
Labels
miscompilation,
llvm:instcombine
Assignees
dtcxzyw
Reporter
dtcxzyw
Reproducer: https://alive2.llvm.org/ce/z/Qcvvgi
```
define i1 @src(half %x, half %y) {
#0:
%copysign.x = copysign half %x, %y
%ord = fcmp ord half %x, 0x
%cmp = fcmp uge half %copysign.x, 0x7c00
%#1 = select i1 %ord, i1 %cmp, i1 0
ret i1 %#1
}
=>
define i1 @src(half %x, half %y) nofree willreturn memory(none) {
#0:
%copysign.x = copysign half %x, %y
%#1 = fcmp oeq half %copysign.x, 0x7c00
ret i1 %#1
}
Transformation doesn't verify!
ERROR: Target is more poisonous than source
Example:
half %x = #x7c02 (SNaN)
half %y = poison
Source:
half %copysign.x = poison
i1 %ord = #x0 (0)
i1 %cmp = poison
i1 %#1 = #x0 (0)
Target:
half %copysign.x = poison
i1 %#1 = poison
Source value: #x0 (0)
Target value: poison
Summary:
0 correct transformations
1 incorrect transformations
0 failed-to-prove transformations
0 Alive2 errors
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 136659] .clang-tidy not automatically found by clang-tidy 20.1.2
Issue 136659 Summary .clang-tidy not automatically found by clang-tidy 20.1.2 Labels clang-tidy Assignees Reporter kenchung285 I have a project that originally used clang-tidy 19.1.7, and we've recently upgraded to version 20.1.2. After upgrading, I've noticed a change in behavior regarding `.clang-tidy` file discovery. In 19.1.7, `clang-tidy` was able to discover and apply our self-defined `.clang-tidy` files without explicitly passing the `-config-file` option. However, in 20.1.2, `clang-tidy` no longer discovers the `.clang-tidy` file at the project root unless we explicitly pass `-config-file`. Worse, if we do pass the `-config-file` flag (pointing to the one in the project root), `clang-tidy` seems to ignore the `.clang-tidy` file under folder B, even when checking files located in that folder. Here is the relevant directory structure: ``` project-root/ ├── README.md ├── .clang-tidy # Full rule config ├── folder A/ │ ├── some source files │ └── ... ├── folder B/ │ └── .clang-tidy # Contains "Checks: '-*'" to disable checks in this folder └── folder C/ ├── other source files └── ... ``` Expected behavior: * Without `-config-file`, `clang-tidy` should discover and respect both the project-root `.clang-tidy` and the one under `folder B`. Actual behavior: * Without `-config-file`, `.clang-tidy` is not discovered at all in 20.1.2. * With `-config-file`, `.clang-tidy` in `folder B` is ignored. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 136583] [flang] [OpenMP] Common block name symbol is not found (with the prefix "Internal")
Issue 136583 Summary [flang] [OpenMP] Common block name symbol is not found (with the prefix "Internal") Labels flang Assignees Reporter sscalpone The OpenMP spec may allow "a common block name (enclosed in slashes)." ``` % cat foo.f90 common /c/ x real :: x !$omp flush(/c/) end % flang foo.f90 % flang -fopenmp foo.f90 flang-21: warning: OpenMP support in flang is still experimental [-Wexperimental-option] error: Semantic errors in foo.f90 ./foo.f90:3:16: error: Internal: no symbol found for 'c' !$omp flush(/c/) ^ ``` Does the `Internal` signal that this is not-yet-implemented? If so, please change the message to include the phrase "not yet implemented:". Thanks! ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 136585] [SPIRV][HLSL] Crash when calling exported function and targeting SPIRV
Issue
136585
Summary
[SPIRV][HLSL] Crash when calling exported function and targeting SPIRV
Labels
backend:SPIR-V
Assignees
Reporter
farzonl
https://hlsl.godbolt.org/z/ojzoYh4bb
Version of LLVM discovered: b95ec24ff08c6ffc300bd85c8b0e53dfda4bceef
Crash only happens when targeting SPIRV.
## Code that causes crash
```hlsl
export int blah() {
return 0;
}
[numthreads(1,1,1)]
void main() {
blah();
return;
}
```
## crash stack
```gdb
#5 0x03f2438f clang::CodeGen::CodeGenFunction::EmitCall(clang::QualType, clang::CodeGen::CGCallee const&, clang::CallExpr const*, clang::CodeGen::ReturnValueSlot, llvm::Value*, llvm::CallBase**, clang::CodeGen::CGFunctionInfo const**) (/opt/compiler-explorer/clang-trunk/bin/clang+0x3f2438f)
#6 0x03f250d6 clang::CodeGen::CodeGenFunction::EmitCallExpr(clang::CallExpr const*, clang::CodeGen::ReturnValueSlot, llvm::CallBase**) (/opt/compiler-explorer/clang-trunk/bin/clang+0x3f250d6)
#7 0x03f92819 (anonymous namespace)::ScalarExprEmitter::VisitCallExpr(clang::CallExpr const*) CGExprScalar.cpp:0:0
#8 0x03f8813b clang::StmtVisitorBase::Visit(clang::Stmt*) CGExprScalar.cpp:0:0
#9 0x03f8d442 clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool) (/opt/compiler-explorer/clang-trunk/bin/clang+0x3f8d442)
#10 0x03f0771e clang::CodeGen::CodeGenFunction::EmitAnyExpr(clang::Expr const*, clang::CodeGen::AggValueSlot, bool) (/opt/compiler-explorer/clang-trunk/bin/clang+0x3f0771e)
#11 0x03f0be60 clang::CodeGen::CodeGenFunction::EmitIgnoredExpr(clang::Expr const*) (/opt/compiler-explorer/clang-trunk/bin/clang+0x3f0be60)
#12 0x04088977 clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*, llvm::ArrayRef) (/opt/compiler-explorer/clang-trunk/bin/clang+0x4088977)
#13 0x0408fe29 clang::CodeGen::CodeGenFunction::EmitCompoundStmtWithoutScope(clang::CompoundStmt const&, bool, clang::CodeGen::AggValueSlot) (/opt/compiler-explorer/clang-trunk/bin/clang+0x408fe29)
#14 0x040f0097 clang::CodeGen::CodeGenFunction::EmitFunctionBody(clang::Stmt const*) (/opt/compiler-explorer/clang-trunk/bin/clang+0x40f0097)
#15 0x04103ed1 clang::CodeGen::CodeGenFunction::GenerateCode(clang::GlobalDecl, llvm::Function*, clang::CodeGen::CGFunctionInfo const&) (/opt/compiler-explorer/clang-trunk/bin/clang+0x4103ed1)
#16 0x0415ec4b clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::GlobalDecl, llvm::GlobalValue*) (/opt/compiler-explorer/clang-trunk/bin/clang+0x415ec4b)
#17 0x0415a5e4 clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl, llvm::GlobalValue*) (/opt/compiler-explorer/clang-trunk/bin/clang+0x415a5e4)
#18 0x0415b108 clang::CodeGen::CodeGenModule::EmitGlobal(clang::GlobalDecl) (/opt/compiler-explorer/clang-trunk/bin/clang+0x415b108)
#19 0x041649ff clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) (.part.0) CodeGenModule.cpp:0:0
#20 0x0451f92e (anonymous namespace)::CodeGeneratorImpl::HandleTopLevelDecl(clang::DeclGroupRef) ModuleBuilder.cpp:0:0
#21 0x045097a9 clang::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef) (/opt/compiler-explorer/clang-trunk/bin/clang+0x45097a9)
#22 0x06141dc4 clang::ParseAST(clang::Sema&, bool, bool) (/opt/compiler-explorer/clang-trunk/bin/clang+0x6141dc4)
#23 0x0451cf4d clang::CodeGenAction::ExecuteAction() (/opt/compiler-explorer/clang-trunk/bin/clang+0x451cf4d)
#24 0x0482b58a clang::FrontendAction::Execute() (/opt/compiler-explorer/clang-trunk/bin/clang+0x482b58a)
#25 0x047a7cdb clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/opt/compiler-explorer/clang-trunk/bin/clang+0x47a7cdb)
#26 0x0491b3a3 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/opt/compiler-explorer/clang-trunk/bin/clang+0x491b3a3)
#27 0x00db1501 cc1_main(llvm::ArrayRef, char const*, void*) (/opt/compiler-explorer/clang-trunk/bin/clang+0xdb1501)
#28 0x00da9c5d ExecuteCC1Tool(llvm::SmallVectorImpl&, llvm::ToolContext const&) driver.cpp:0:0
#29 0x0458e989 void llvm::function_ref::callback_fn>, std::__cxx11::basic_string, std::allocator>*, bool*) const::'lambda'()>(long) Job.cpp:0:0
#30 0x03b31663 llvm::CrashRecoveryContext::RunSafely(llvm::function_ref) (/opt/compiler-explorer/clang-trunk/bin/clang+0x3b31663)
#31 0x0458eba9 clang::driver::CC1Command::Execute(llvm::ArrayRef>, std::__cxx11::basic_string, std::allocator>*, bool*) const (.part.0) Job.cpp:0:0
#32 0x0455215d clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, clang::driver::Command const*&, bool) const (/opt/compiler-explorer/clang-trunk/bin/clang+0x455215d)
#33 0x04553121 clang::driver::
[llvm-bugs] [Bug 136574] [X86] Unnecessary sequences of 8 GPR `mov`s back and forth
Issue
136574
Summary
[X86] Unnecessary sequences of 8 GPR `mov`s back and forth
Labels
new issue
Assignees
Reporter
dzaima
This C code (heavily reduced from real-world code implementing SIMD transpose), compiled via `-O3 -march=haswell`:
```c
#include
#include
#define load(x) _mm256_loadu_si256((void *)(x))
#define store(x, v) _mm256_storeu_si256((void *)(x), v)
void f(char *p1, char *p2, char *p3, uint64_t x, uint64_t y, uint64_t z) {
while (1) {
uint64_t i = 0;
while (1) {
if (i >= x)
break;
uint64_t j = 4 * i ? 4 * i : x;
__m256i a = load(p2 + y * 5);
__m256i l0 = load(p2);
__m256i l1 = load(p2 + j + 3 * y);
__m256i b = l0 + l1;
__m256i l2 = load(p2 + y);
__m256i l3 = load(p3 + y + j);
__m256i c = l2 + l3;
__m256i l4 = load(p3 + 6 * y);
__m256i l5 = load(p2 + j + 7 * y);
__m256i d = l4 + l5;
store(p1 + j * z + 16 * z, _mm256_permute2x128_si256(a, b, 49));
store(p1 + j * z, _mm256_permute2x128_si256(c, d, 49));
i++;
}
}
}
```
results in this segment of assembly:
```asm
...
mov rcx, rdi
mov rdi, r8
mov r8, r15
mov r15, r14
mov r14, r11
mov r11, r9
mov r9, rdx
mov rdx, r10
mov r10, qword ptr [rsp - 8]
vmovdqu ymm1, ymmword ptr [r10 + rbp]
mov r10, rdx
mov rdx, r9
mov r9, r11
mov r11, r14
mov r14, r15
mov r15, r8
mov r8, rdi
mov rdi, rcx
...
```
which could be just:
```asm
mov rcx, qword ptr [rsp - 8]
vmovdqu ymm1, ymmword ptr [rcx + rbp]
```
https://godbolt.org/z/P66GdGzaM
Similar to #81391, but for GPRs, not SIMD registers (though SIMD is still involved).
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 136559] Clang treats nested classes as non-default-constructible if they have member intializers, until the end of the outer class
Issue
136559
Summary
Clang treats nested classes as non-default-constructible if they have member intializers, until the end of the outer class
Labels
clang
Assignees
Reporter
HolyBlackCat
This is the same issue as described in this [very old stackoverflow question](https://stackoverflow.com/q/17430377/2752075).
https://gcc.godbolt.org/z/rP5YvqGfP
```cpp
#include
struct A
{
struct X
{
int x = 10;
int y = 20;
};
struct Y
{
std::variant var; // error: call to implicitly-deleted default constructor of 'A::Y'
};
};
int main()
{
A::Y y;
}
```
This compiles on GCC and MSVC. But Clang threats `std::variant` as not default-constructible (because it first checks the default-constructibility of `X` when the variant is declared, and it doesn't consider it to be default-constructible at that point because it has default member initializers and no user-declared default ctor).
GCC used to fail on this too, but it has since been fixed. So presumably there's no technical reason why Clang couldn't accept this as well?
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 136550] [APInt] Add APInt::clearBits() method
Issue 136550 Summary [APInt] Add APInt::clearBits() method Labels good first issue, llvm:support Assignees Reporter RKSimon Similar to how we have APInt::setBits(unsigned loBit, unsigned hiBit), we require a APInt::clearBits(unsigned loBit, unsigned hiBit) method to zero out bits in the specific range Noticed on #131989 - but we need something similar in a number of other cases - notably when manipulating DemandedElts masks for INSERT_SUBVECTOR ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 136568] Quadratic scaling in processing of designated initializers
Issue
136568
Summary
Quadratic scaling in processing of designated initializers
Labels
new issue
Assignees
Reporter
amonakov
```sh
printf 'x(%d)\n' $(seq 1) > x1.h
```
```c
struct S {
#define x(n) int m##n;
#include "x1.h"
#undef x
} s = {
#define x(n) .m##n = n,
#include "x1.h"
#undef x
};
```
needs more than a second to compile, and scales quadratically with the number of fields. `perf report` shows 42% in CheckDesignatedInitializer, 34% in CheckStructUnionTypes and 17.5% in FieldDecl::getCanonicalDecl.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 136588] [BOLT][RISCV]could not find corresponding %pcrel_hi
Issue 136588 Summary [BOLT][RISCV]could not find corresponding %pcrel_hi Labels BOLT Assignees Reporter dinyy When I use llvm-bolt to optimize mysql ,it arise ":0: error: could not find corresponding %pcrel_hi". ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 136608] [clang-cl] Cannot compile a nested struct with member named `std::string Name; `
Issue 136608 Summary [clang-cl] Cannot compile a nested struct with member named `std::string Name;` Labels new issue Assignees Reporter Nemirtingas Hi, I encountered an issue where clang-cl and clang couldn't compile some code, I Attached reproductible source. If I remove `std::string name;` from `Struct2_t`, it compiles. You can compile this code using my docker image: `nemirtingas/windowscross_vcpkg:msvc2022_14.40.33807_win10.0.18362.0_clang18`, this issue is about clang 19 but I first discovered it in clang 18 and the issue seems to be the same. [main.zip](https://github.com/user-attachments/files/19840025/main.zip) ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 136603] Loop unrolling confuses __builtin_dynamic_object_size() and __builtin_constant_p()
Issue
136603
Summary
Loop unrolling confuses __builtin_dynamic_object_size() and __builtin_constant_p()
Labels
new issue
Assignees
Reporter
kees
This is from https://github.com/ClangBuiltLinux/linux/issues/2076 where commit 2d1e8a03f5eeff48cd7928d003fc12f728b2c7cf seems to have exposed some recent Linux kernel code to the loop unroller (though oddly only on ARM). Attempting to extract a minimal reproducer has been a challenge, but it appears that something about loop unrolling confuses `__builtin_constant_p()`. Loop variables assigned from `__builtin_dynamic_object_size()` appear constant, whereas if it is left in a macro, they correctly stay dynamic.
It seems that a `noreturn` branch is also be required to trigger this. Anything that disables the loop unrolling fixes the problem (via `#pragma` or via changes in loop size via `NUM_ADDRS`). Bringing the external loop constraint explicitly down into the inner loop (`j < NUM_ADDRS`) also fixes it.
I'm not sure what to do next to narrow this down further.
```c
// clang -Wall -O2 -c repro.c -o repro.o
#include
#include
#include
#include
#define __compiletime_warning(msg) __attribute__((__warning__(msg)))
#define __noreturn __attribute__((__noreturn__))
extern void variable_calc_constant(size_t) __compiletime_warning("variable calculation is constant");
extern void macro_calc_constant(size_t) __compiletime_warning("macro calculation is constant");
extern void freakout(void) __noreturn;
extern int check(int);
extern int unknown;
// must be less than 10 (loop unrolling limit?)
#define NUM_ADDRS 4
struct inner {
unsigned char addr[2]; // must be greater than 1 to show warnings in unroll
};
struct middle {
struct inner bytes;
};
struct outer {
struct middle array[NUM_ADDRS];
};
void repro(void) {
struct outer *outer;
struct middle *middle;
int i, c;
outer = malloc(sizeof(*outer));
middle = outer->array;
for (i = 0, c = 0; i < unknown && c < NUM_ADDRS; i++) {
struct inner addr = { };
int j;
if (check(i))
continue;
//#pragma clang loop unroll(disable)
for (j = 0; j < c /*&& j < NUM_ADDRS*/; j++) {
const size_t v_size = __builtin_dynamic_object_size(&middle[j].bytes, 0);
#define m_size __builtin_dynamic_object_size(&middle[j].bytes, 0)
if (__builtin_constant_p(v_size))
variable_calc_constant(v_size);
if (__builtin_constant_p(m_size))
macro_calc_constant(m_size);
if (m_size < sizeof(addr))
freakout();
if (__builtin_memcmp(&middle[j].bytes, &addr, sizeof(addr)) == 0)
break;
}
if (j == c)
c++;
}
}
```
Produces (on x86_64 host, FWIW):
```
$ clang -Wall -O2 -c repro.c -o repro.o
repro.c:53:5: warning: call to 'variable_calc_constant' declared with 'warning' attribute: buggy: variable calculation is constant [-Wattribute-warning]
53 | variable_calc_constant();
| ^
repro.c:53:5: warning: call to 'variable_calc_constant' declared with 'warning' attribute: buggy: variable calculation is constant [-Wattribute-warning]
repro.c:53:5: warning: call to 'variable_calc_constant' declared with 'warning' attribute: buggy: variable calculation is constant [-Wattribute-warning]
repro.c:53:5: warning: call to 'variable_calc_constant' declared with 'warning' attribute: buggy: variable calculation is constant [-Wattribute-warning]
repro.c:53:5: warning: call to 'variable_calc_constant' declared with 'warning' attribute: buggy: variable calculation is constant [-Wattribute-warning]
5 warnings generated.
```
Without loop unrolling, this does not emit warnings. The macro-based uses of `__builtin_dynamic_object_size()` aren't resolved (which itself seems to be a bug), but the variable based ones are. Specifically, when `__builtin_dynamic_object_size()` is being determined at compile time as part of the loop unrolling, it _cannot_ reach 0 -- the loop unroller is exceeding the maximum loop counter and producing a iteration beyond the bounds of the array. This can be seen in the _fifth_ (impossible) call in the binary output:
```
xor edi, edi
call variable_calc_constant@PLT
```
https://godbolt.org/z/eT5KdTxbv
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 136607] std::generator usage with Clang causes warning/error when compiling HPX with C++23 and coroutines enabled
Issue 136607 Summary std::generator usage with Clang causes warning/error when compiling HPX with C++23 and coroutines enabled Labels clang Assignees Reporter Prachethan7 I'm encountering a compiler warning (treated as error) when compiling [HPX](https://github.com/STEllAR-GROUP/hpx) with -std=c++23 and coroutine support using Clang 17.0.6. The error is related to the usage of std::generator and seems to stem from header processing logic. ``` cmake .. \ -DHPX_DIR=/home/neo/packages/hpx/install/lib/cmake/HPX \ -DHPX_WITH_CXX_STANDARD=23 \ -DHPX_HAVE_CXX23_STD_GENERATOR=ON \ -DHPX_WITH_CXX20_COROUTINES=ON cmake --build . --target tests ``` Clang version: ``` Debian clang version 19.1.7 (3) Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/lib/llvm-19/bin ``` The error disappears when adding a missing ;, but this raises a concern: the warning may indicate a deeper issue in how std::generator is parsed or supported. Would it be possible to: Confirm whether this is an expected behavior? Clarify support status for std::generator with Clang 17? Possibly improve diagnostic feedback or preprocessor logic? [compiler_crash.log](https://github.com/user-attachments/files/19840012/compiler_crash.log) ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 136620] [DirectX] Legalize Lifetime markers
Issue 136620 Summary [DirectX] Legalize Lifetime markers Labels Assignees farzonl Reporter farzonl ## Problem We noticed many cases of DXC where we don't emit lifetime markers where clan-dxc does emit them. We were hesitant to allow these to pass on through because we weren't sure if they were correct. ## Solution We have since determined that its likely that DXC is missing lifetime markers that it should be adding and so its likely safe to make a change in `llvm/lib/Target/DirectX/DXILOpLowering.cpp` to let lifetime intrinsics pass on through. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 136561] [lldb][LoongArch] expression command cannot call the function
Issue
136561
Summary
[lldb][LoongArch] _expression_ command cannot call the function
Labels
new issue
Assignees
wangleiat
Reporter
wangleiat
test commit: be48727b95bf9075e4290cc8938ab87db8b7410c
```
user@Debian-Sid:~/llvm-project/github-main/_build_lldb$ ./bin/lldb ./a.out
(lldb) target create "./a.out"
Current executable set to '/home/user/llvm-project/github-main/_build_lldb/a.out' (loongarch64).
(lldb) b main
Breakpoint 1: where = a.out`main + 12 at test.c:6:10, address = 0x078c
(lldb) r
Process 430727 launched: '/home/user/llvm-project/github-main/_build_lldb/a.out' (loongarch64)
Process 430727 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
frame #0: 0x078c a.out`main at test.c:6:10
3}
4
5int main() {
-> 6 return 0;
7}
8
(lldb) list 1
1int add(int a, int b) {
2 return a+b;
3}
4
5int main() {
6 return 0;
7}
8
(lldb) _expression_ add(2,3)
error: _expression_ execution was interrupted: signal SIGBUS: illegal address.
The process has been returned to the state before _expression_ evaluation.
(lldb)
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 136564] [RISCV] `clang` mistakenly permits `Zilsd` extension for `rv64`
Issue
136564
Summary
[RISCV] `clang` mistakenly permits `Zilsd` extension for `rv64`
Labels
clang
Assignees
Reporter
thebigclub
The`Zilsd` and `Zclsd` [extensions](https://github.com/riscv/riscv-isa-manual/blob/main/src/zilsd.adoc) provide a way for `rv32` architectures to use doubleword loads and stores. The extensions exist for `rv32` only and not `rv64`. `clang` currently permits `Zilsd` for `rv64`:
```bash
$ echo "int main(void){}" > test.c
$ clang -march=rv64i_zilsd -c test.c
$ echo $?
0
$ clang -march=rv64i_zclsd -c test.c
clang: error: invalid arch name 'rv64i_zclsd', 'zclsd' is only supported for 'rv32'
$ echo $?
1
$ clang -v
clang version 21.0.0git (https://github.com/llvm/llvm-project.git 4aca20c8b6dcf86696db03d860e635112601a7f9)
Target: riscv32-unknown-unknown-elf
```
`clang`'s behavior for `Zilsd` should match `Zclsd` when targeting `rv64`.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 136569] [MLIR] JitRunner crashed with `PromoteIntegerOperand ` OP
Issue
136569
Summary
[MLIR] JitRunner crashed with `PromoteIntegerOperand ` OP
Labels
mlir
Assignees
Reporter
sweead
test commit: [788b50a](https://github.com/llvm/llvm-project/commit/788b50a4384985f2c221cfd8d290cabc6f59e646)
step to reproduce:
```
mlir-runner test.mlir -e main -entry-point-result=void -shared-libs=/home/workdir/llvm-project/build/lib/libmlir_runner_utils.so
```
test case:
```
module {
llvm.func @malloc(i64) -> !llvm.ptr
llvm.func @free(!llvm.ptr)
llvm.func @aligned_alloc(i64, i64) -> !llvm.ptr
llvm.func @main() -> () {
llvm.return
}
llvm.func @async_execute_fn(%arg0: !llvm.ptr, %arg1: i64, %arg2: i64, %arg3: i64, %arg4: i64, %arg5: i64, %arg6: i64, %arg7: i64, %arg8: i64, %arg9: i64, %arg10: i64, %arg11: i64, %arg12: !llvm.ptr, %arg13: !llvm.ptr, %arg14: i64, %arg15: i64, %arg16: i64, %arg17: i64, %arg18: i64, %arg19: !llvm.ptr, %arg20: !llvm.ptr, %arg21: i64, %arg22: i64, %arg23: i64, %arg24: i64, %arg25: i64, %arg26: !llvm.ptr, %arg27: !llvm.ptr, %arg28: i64, %arg29: i64, %arg30: i64, %arg31: i64, %arg32: i64) -> !llvm.ptr attributes {passthrough = ["presplitcoroutine"], sym_visibility = "private"} {
%0 = llvm.mlir.constant(0 : i32) : i32
%1 = llvm.mlir.zero : !llvm.ptr
%2 = llvm.mlir.constant(1 : i64) : i64
%3 = llvm.mlir.constant(0 : i64) : i64
%4 = llvm.mlir.addressof @__resume : !llvm.ptr
%5 = llvm.mlir.constant(false) : i1
%6 = llvm.call @mlirAsyncRuntimeCreateToken() : () -> !llvm.ptr
%7 = llvm.intr.coro.id %0, %1, %1, %1 : (i32, !llvm.ptr, !llvm.ptr, !llvm.ptr) -> !llvm.token
%8 = llvm.intr.coro.size : i64
%9 = llvm.intr.coro.align : i64
%10 = llvm.add %8, %9 : i64
%11 = llvm.sub %10, %2 : i64
%12 = llvm.sub %3, %9 : i64
%13 = llvm.and %11, %12 : i64
%14 = llvm.call @aligned_alloc(%9, %13) : (i64, i64) -> !llvm.ptr
%15 = llvm.intr.coro.begin %7, %14 : (!llvm.token, !llvm.ptr) -> !llvm.ptr
%16 = llvm.intr.coro.save %15 : (!llvm.ptr) -> !llvm.token
llvm.call @mlirAsyncRuntimeExecute(%15, %4) : (!llvm.ptr, !llvm.ptr) -> ()
%17 = llvm.intr.coro.suspend %16, %5 : i8
%18 = llvm.sext %17 : i8 to i32
llvm.switch %18 : i32, ^bb3 [
0: ^bb1,
1: ^bb2
]
^bb1: // pred: ^bb0
llvm.call @mlirAsyncRuntimeEmplaceToken(%6) : (!llvm.ptr) -> ()
llvm.br ^bb2
^bb2: // 2 preds: ^bb0, ^bb1
%19 = llvm.intr.coro.free %7, %15 : (!llvm.token, !llvm.ptr) -> !llvm.ptr
llvm.call @free(%19) : (!llvm.ptr) -> ()
llvm.br ^bb3
^bb3: // 2 preds: ^bb0, ^bb2
%20 = llvm.mlir.none : !llvm.token
%21 = llvm.intr.coro.end %15, %5, %20 : (!llvm.ptr, i1, !llvm.token) -> i1
llvm.return %6 : !llvm.ptr
}
llvm.func @mlirAsyncRuntimeAddRef(!llvm.ptr, i64) attributes {sym_visibility = "private"}
llvm.func @mlirAsyncRuntimeDropRef(!llvm.ptr, i64) attributes {sym_visibility = "private"}
llvm.func @mlirAsyncRuntimeCreateToken() -> !llvm.ptr attributes {sym_visibility = "private"}
llvm.func @mlirAsyncRuntimeCreateValue(i64) -> !llvm.ptr attributes {sym_visibility = "private"}
llvm.func @mlirAsyncRuntimeCreateGroup(i64) -> !llvm.ptr attributes {sym_visibility = "private"}
llvm.func @mlirAsyncRuntimeEmplaceToken(!llvm.ptr) attributes {sym_visibility = "private"}
llvm.func @mlirAsyncRuntimeEmplaceValue(!llvm.ptr) attributes {sym_visibility = "private"}
llvm.func @mlirAsyncRuntimeSetTokenError(!llvm.ptr) attributes {sym_visibility = "private"}
llvm.func @mlirAsyncRuntimeSetValueError(!llvm.ptr) attributes {sym_visibility = "private"}
llvm.func @mlirAsyncRuntimeIsTokenError(!llvm.ptr) -> i1 attributes {sym_visibility = "private"}
llvm.func @mlirAsyncRuntimeIsValueError(!llvm.ptr) -> i1 attributes {sym_visibility = "private"}
llvm.func @mlirAsyncRuntimeIsGroupError(!llvm.ptr) -> i1 attributes {sym_visibility = "private"}
llvm.func @mlirAsyncRuntimeAwaitToken(!llvm.ptr) attributes {sym_visibility = "private"}
llvm.func @mlirAsyncRuntimeAwaitValue(!llvm.ptr) attributes {sym_visibility = "private"}
llvm.func @mlirAsyncRuntimeAwaitAllInGroup(!llvm.ptr) attributes {sym_visibility = "private"}
llvm.func @mlirAsyncRuntimeExecute(!llvm.ptr, !llvm.ptr) attributes {sym_visibility = "private"}
llvm.func @mlirAsyncRuntimeGetValueStorage(!llvm.ptr) -> !llvm.ptr attributes {sym_visibility = "private"}
llvm.func @mlirAsyncRuntimeAddTokenToGroup(!llvm.ptr, !llvm.ptr) -> i64 attributes {sym_visibility = "private"}
llvm.func @mlirAsyncRuntimeAwaitTokenAndExecute(!llvm.ptr, !llvm.ptr, !llvm.ptr) attributes {sym_visibility = "private"}
llvm.func @mlirAsyncRuntimeAwaitValueAndExecute(!llvm.ptr, !llvm.ptr, !llvm.ptr) attributes {sym_visibility = "private"}
llvm.func @mlirAsyncRuntimeAwaitAllInGroupAndExecute(!llvm.ptr, !llvm.ptr, !llvm.ptr) attributes {sym_visibili
[llvm-bugs] [Bug 136592] UBSan: Incorrect generated `__ubsan_handle_type_mismatch_v1`?
Issue
136592
Summary
UBSan: Incorrect generated `__ubsan_handle_type_mismatch_v1`?
Labels
new issue
Assignees
Reporter
zanmato1984
In apache/arrow we encountered a weird UBSan error (https://github.com/apache/arrow/pull/46124#issuecomment-2814416656) which seems to be a false alarm. A reduced case can be found [here](https://godbolt.org/z/GsYcn155q) .
To summarize, for function:
```
uint64_t read64(const uint64_t* src, size_t n) {
uint64_t result = 0;
std::memcpy(&result, src, n);
return result;
}
```
A misaligned `src` shouldn't be considered UB because it is merely passed into `std::memcpy` as `void *` which requires no alignment. However the generated code jumps to `__ubsan_handle_type_mismatch_v1` once misaligned regardless of how it is used afterwards.
As a comparison, changing the pointer type from `uint64_t *` to `uint8_t *` gets the correct codegen - no alignment checking:
```
uint64_t read8(const uint8_t* src, size_t n) {
uint64_t result = 0;
std::memcpy(&result, src, n);
return result;
}
```
The same behavior is observed on X86 as well, and as early as 18.1.0 (17.0.1 is fine) for both Arm and X86.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 136597] [clang-format] Pointer alignment option for function return types
Issue
136597
Summary
[clang-format] Pointer alignment option for function return types
Labels
clang-format
Assignees
Reporter
oajlouni
This is a simple example to explain what I mean:
```
char* alloc_str(int size)
{
char *str = malloc(size);
return str;
}
```
I'd like to have my code formatted in a way that a pointer is right-aligned in a variable declaration and left-aligned if it is a return type.
Having read through **Clang-Format Style Options**, the only two options I've found were **DerivePointerAlignment** and **PointerAlignment** and they only seem to treat all pointers the same way.
Is there a way to achieve what I'm after? Or could this be worth considering as a new feature?
Thanks!
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 136594] Impossible to use `wasm:js-string` functions in webassembly
Issue
136594
Summary
Impossible to use `wasm:js-string` functions in webassembly
Labels
new issue
Assignees
Reporter
socketpair
Here you can see an example of WASM code how to use `concat` JS builtin:
https://developer.mozilla.org/en-US/docs/WebAssembly/Guides/_javascript__builtins#wasm_module
```wat
(func $concat (import "wasm:js-string" "concat")
(param externref externref) (result (ref extern)))
```
So, in C I defined it in the following way:
```C
__externref_t js_concat(__externref_t, __externref_t)
__attribute__((import_module("wasm:js-string"), import_name("concat")));
```
Next, I'm trying to run the code that uses definition above in the following way:
```js
const { instance } = await WebAssembly.instantiateStreaming(
fetch('trie_search.wasm'),
{
env: { },
},
{
builtins: ["js-string"],
importedStringConstants: "Something",
},
);
instance.exports.my_function();
```
Browser console says:
```
Uncaught (in promise) CompileError: WebAssembly.instantiateStreaming():
Imported builtin function "wasm:js-string" "concat" has incorrect signature
```
I guess, the problem in return value. in WAT language it should look like `(ref extern)`. How to express it in C (Clang)?
https://github.com/WebAssembly/js-string-builtins/blob/main/proposals/js-string-builtins/Overview.md#wasmjs-string-concat
https://github.com/WebAssembly/function-references/blob/master/proposals/function-references/Overview.md#binary-format
```wat
(module
(global $h (import "string_constants" "hello ") externref)
(global $w (import "string_constants" "world!") externref)
(func $concat (import "wasm:js-string" "concat")
(param externref externref) (result (ref extern)))
(func $log (import "m" "log") (param externref))
(func (export "main")
(call $log (call $concat (global.get $h) (global.get $w
)
```
Compiles perfectly well using `binryen`, but how to write an equivalent using C and clang ?
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 136596] ppc64le offload build broken 8437b7f5584765ad4f7885500647657714930fbb
Issue 136596 Summary ppc64le offload build broken 8437b7f5584765ad4f7885500647657714930fbb Labels new issue Assignees Reporter tstellar @jhuber6 This commit broke the build on ppc64le. You can reproduce by configuring with: ``` cmake -G Ninja -B build -S llvm -DCMAKE_BUILD_TYPE=Release -DLLVM_TARGETS_TO_BUILD=Native -DLLVM_ENABLE_PROJECTS=clang -DLLVM_ENABLE_RUNTIMES="offload;openmp;compiler-rt" -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_C_COMPILER=clang ``` And running: ``` ninja -C build runtimes ``` See attached build logs for details. Note we aren't seeing the same failures on configurations where llvm is built with `-DPPC_LINUX_DEFAULT_IEEELONGDOUBLE:BOOL=ON`. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 136624] Incorrect name qualification in AST / diagnostics for alias CTAD
Issue
136624
Summary
Incorrect name qualification in AST / diagnostics for alias CTAD
Labels
clang:frontend
Assignees
mizvekov
Reporter
mizvekov
Consider this example: https://compiler-explorer.com/z/bGqdsa3qc
```C++
template struct A {
U t;
};
template A(V) -> A;
namespace foo {
template using Alias = A;
}
foo::Alias t = 0;
```
Produces:
```
error: no viable conversion from 'int' to 'foo::A' (aka 'A')
```
Note that the `foo::` qualification is applied to Alias in the source code, which is in that namespace, but
on the AST (and consequently in the diagnostic) it gets applied to `A` , where it cannot be found.
The problem here is many fold:
1) We have an elaborated type including `foo::` over the deduced template specialization (DTST), which names `foo::Alias`.
2) However, when printing a DTST which has already been deduced, we choose to print it as the deduced type instead, probably for diagnostics reasons (although this is wrong for -ast-print, and we don't control this with a policy).
3) For alias CTAD, we don't build a guide which actually contains the alias template specialization `Alias`, instead the guide contains `A`.
I see a couple of solutions:
* If we fix 3, then this would print as intended: `'foo::Alias' (aka 'A')`
* We could stop doing 2, then this would print as `'foo::Alias' (aka 'A')`.
The first type does not include much information, as 2) probably intended to avoid, but it is correctly qualified, and then the 'aka' gives the missing information.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 136635] File extremely slow to compile
Issue 136635 Summary File extremely slow to compile Labels new issue Assignees Reporter jcelerier The attached file takes a very long time to build at higher optimization levels. clang-19 as provided by archlinux (x86-64). With optimizations and debug info it's been running for 20 minutes and I haven't seen it end yet so I assume it's stuck. For reference my machine can do a clean LLVM+clang build in roughly 7 minutes (420 seconds) Flags | Timings | _|___| -O0 | 30s | -O0 -g | 40s| -O1 | 72s| -O1 -g | ??? | -O2 | 109s| -O2 -march=native | 139s | -O3 | 126s | -O3 -march=native -g | ??? | [slow.zip](https://github.com/user-attachments/files/19841388/slow.zip) when tracing the performance with one of the stuck processes it seems that it is due to the removeredundantdebugvalues pass:  ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 136562] compiler printf format warning doesn't really need to happen
Issue
136562
Summary
compiler printf format warning doesn't really need to happen
Labels
new issue
Assignees
Reporter
d3x0r
Compiled as C++...
``` c++
uintptr psvNew = 0;
printf( "Socket is not a server socket %p", psvNew );
```
``` log
warning: format ‘%p’ expects argument of type ‘void*’, but argument 2 has type ‘uintptr_t {aka long unsigned int}’ [-Wformat=]
printf( "Socket is not a server socket %p", psvNew );
```
This should never actually be an issue. [u]intptr is defined as a integer type large enough to hold a pointer. It should always take the same amount of space as a pointer, and a pointer can round-trip to and from the type without issue.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 136570] Request Commit Access For mmha
Issue 136570 Summary Request Commit Access For mmha Labels infra:commit-access-request Assignees Reporter mmha Why Are you requesting commit access I started working on the ClangIR upstreaming effort recently along with @erichkeane, @dkolsen-pgi and @andykaylor. Commit access would allow me to add reviewers to my patches and merge code. (This is a duplicate of #131004 so the bots have their comments updated) ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
