[llvm-bugs] [Bug 136516] [AArch64] `clz` on u8/u16 unnecessarily zero-extended to u32
Issue
136516
Summary
[AArch64] `clz` on u8/u16 unnecessarily zero-extended to u32
Labels
new issue
Assignees
Reporter
Kmeakin
The result of the `clz` instruction on an 8-bit or 16-bit value is unecessarily zero-extended to 32-bits via `and`
# C++ example
https://godbolt.org/z/rc9P4a54a
```c++
#include
using u8 = uint8_t;
using u16 = uint16_t;
using u32 = uint32_t;
using u64 = uint64_t;
using u128 = __uint128_t;
auto src8(u8 x) { return __builtin_clzg(x); }
auto src16(u16 x) { return __builtin_clzg(x); }
```
# Clang assembly
```asm
src8(unsigned char):
and w8, w0, #0xff
clz w8, w8
sub w8, w8, #24
and w0, w8, #0xff
ret
src16(unsigned short):
and w8, w0, #0x
clz w8, w8
sub w8, w8, #16
and w0, w8, #0x
ret
```
# GCC assembly
```asm
src8(unsigned char):
and w0, w0, 255
clz w0, w0
sub w0, w0, #24
ret
src16(unsigned short):
and w0, w0, 65535
clz w0, w0
sub w0, w0, #16
ret
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 136504] [Clang] Crash on CTAD for alias template involving lambda
Issue
136504
Summary
[Clang] Crash on CTAD for alias template involving lambda
Labels
Assignees
Reporter
MagentaTreehouse
```c++
template
struct A {
A(T, F f = {}) { f({}); }
};
template
using AA = A;
AA a{0};
```
See https://compiler-explorer.com/z/bffrq8j91.
Unreachable:
```console
non-canonical or dependent type in IR-generation
UNREACHABLE executed at /root/llvm-project/llvm/tools/clang/lib/CodeGen/CodeGenFunction.cpp:263!
```
Stack dump
```console
0. Program arguments: /opt/compiler-explorer/clang-assertions-trunk/bin/clang++ -gdwarf-4 -g -o /app/output.s -mllvm --x86-asm-syntax=intel -fno-verbose-asm -S --gcc-toolchain=/opt/compiler-explorer/gcc-snapshot -fcolor-diagnostics -fno-crash-diagnostics -std=c++20
1. parser at end of file
2. Per-file LLVM IR generation
3. :3:5: Generating code for declaration 'A:7:26)>::A'
4. :3:20: LLVM IR generation of compound statement ('{}')
#0 0x03ef1728 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x3ef1728)
#1 0x03eef3b4 llvm::sys::CleanupOnSignal(unsigned long) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x3eef3b4)
#2 0x03e33ef8 CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0
#3 0x7b77a7a42520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#4 0x7b77a7a969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
#5 0x7b77a7a42476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
#6 0x7b77a7a287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
#7 0x03e3f47a (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x3e3f47a)
#8 0x04433f12 clang::CodeGen::CodeGenFunction::getEvaluationKind(clang::QualType) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x4433f12)
#9 0x0471c62f clang::CodeGen::isAggregateTypeForABI(clang::QualType) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x471c62f)
#10 0x04702d14 (anonymous namespace)::X86_64ABIInfo::getIndirectResult(clang::QualType, unsigned int) const X86.cpp:0:0
#11 0x0470b338 (anonymous namespace)::X86_64ABIInfo::classifyArgumentType(clang::QualType, unsigned int, unsigned int&, unsigned int&, bool, bool) const X86.cpp:0:0
#12 0x0470bda4 (anonymous namespace)::X86_64ABIInfo::computeInfo(clang::CodeGen::CGFunctionInfo&) const X86.cpp:0:0
#13 0x0478c031 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/bin/clang+++0x478c031)
#14 0x0478e643 arrangeLLVMFunctionInfo(clang::CodeGen::CodeGenTypes&, bool, llvm::SmallVectorImpl>&, clang::CanQual) CGCall.cpp:0:0
#15 0x0479187c clang::CodeGen::CodeGenTypes::arrangeCXXMethodType(clang::CXXRecordDecl const*, clang::FunctionProtoType const*, clang::CXXMethodDecl const*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x479187c)
#16 0x04791a7b clang::CodeGen::CodeGenTypes::arrangeCXXMethodDeclaration(clang::CXXMethodDecl const*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x4791a7b)
#17 0x0427b279 clang::CodeGen::CodeGenFunction::EmitCXXMemberOrOperatorMemberCallExpr(clang::CallExpr const*, clang::CXXMethodDecl const*, clang::CodeGen::ReturnValueSlot, bool, clang::NestedNameSpecifier*, bool, clang::Expr const*, llvm::CallBase**) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x427b279)
#18 0x0427c383 clang::CodeGen::CodeGenFunction::EmitCXXOperatorMemberCallExpr(clang::CXXOperatorCallExpr const*, clang::CXXMethodDecl const*, clang::CodeGen::ReturnValueSlot, llvm::CallBase**) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x427c383)
#19 0x04256fc6 clang::CodeGen::CodeGenFunction::EmitCallExpr(clang::CallExpr const*, clang::CodeGen::ReturnValueSlot, llvm::CallBase**) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x4256fc6)
#20 0x042c8c34 (anonymous namespace)::ScalarExprEmitter::VisitCallExpr(clang::CallExpr const*) CGExprScalar.cpp:0:0
#21 0x042bbea0 clang::StmtVisitorBase::Visit(clang::Stmt*) CGExprScalar.cpp:0:0
#22 0x042c1c2c clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x42c1c2c)
#23 0x0422dfde clang::CodeGen::CodeGenFunction::EmitAnyExpr(clang::Expr const*, clang::CodeGen::AggValueSlot, bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x422dfde)
#24 0x04254f5d clang::CodeGen::CodeGenFunction::EmitIgnoredExpr(clang::Expr const*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x4254f5d)
#25 0x043
[llvm-bugs] [Bug 136536] Missed Optimization: Store of Known Zero Not Folded in Conditional Path
Issue
136536
Summary
Missed Optimization: Store of Known Zero Not Folded in Conditional Path
Labels
new issue
Assignees
Reporter
GINN-Imp
The following reduced IR is derived from https://eigen.tuxfamily.org/dox/Ref_8h_source.html.
More specifically, it comes from function ` EIGEN_DEVICE_FUNC bool construct(_expression_& expr)` (line 111).
Godbolt: https://godbolt.org/z/436xvYdsv
Missed optimization: `store i8 %2, ptr @v, align 1` --> `store i8 0, ptr @v, align 1`
alive2 proof: https://alive2.llvm.org/ce/z/kjuHWQ
```llvm
@_ZN5EigenL14no_more_assertE = internal global i8 0, align 1
@v = external global i8
define void @src(i1 %0) {
%2 = zext i1 %0 to i8
br i1 %0, label %common.ret, label %3
3:; preds = %1
%.b2 = load i1, ptr @_ZN5EigenL14no_more_assertE, align 1
br i1 %.b2, label %common.ret, label %4
4:; preds = %3
store i1 true, ptr @_ZN5EigenL14no_more_assertE, align 1
store i8 %2, ptr @v, align 1
br label %common.ret
common.ret: ; preds = %1, %3, %4
ret void
}
```
opt-trunk -O3 generates:
```llvm
define void @src(i1 %0) local_unnamed_addr #0 {
%2 = zext i1 %0 to i8
br i1 %0, label %common.ret, label %3
3:; preds = %1
%.b2 = load i1, ptr @_ZN5EigenL14no_more_assertE, align 1
br i1 %.b2, label %common.ret, label %4
4: ; preds = %3
store i1 true, ptr @_ZN5EigenL14no_more_assertE, align 1
store i8 %2, ptr @v, align 1
br label %common.ret
common.ret: ; preds = %4, %3, %1
ret void
}
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 136535] Flang on Windows AArch64: LLVM ERROR: INIT_TRAMPOLINE operation is only supported on Linux.
Issue 136535 Summary Flang on Windows AArch64: LLVM ERROR: INIT_TRAMPOLINE operation is only supported on Linux. Labels flang Assignees Reporter hmartinez82 While building the json-fortran project targeting `aarch64-w64-windows-gnu`: ``` [1/8] C:\msys64\clangarm64\bin\flang.exe -IC:\Dev\Github\MINGW-packages\mingw-w64-json-fortran\src\json-fortran-9.0.2\src -IC:\Dev\Github\MINGW-packages\mingw-w64-json-fortran\src\build-CLANGARM64\include -O3 -module-dir. -ffixed-line-length-72 -c CMakeFiles\jsonfortran.dir\src\json_value_module.F90-pp.f90 -o CMakeFiles\jsonfortran.dir\src\json_value_module.F90.obj FAILED: CMakeFiles/jsonfortran.dir/src/json_value_module.F90.obj json_value_module.mod C:\msys64\clangarm64\bin\flang.exe -IC:\Dev\Github\MINGW-packages\mingw-w64-json-fortran\src\json-fortran-9.0.2\src -IC:\Dev\Github\MINGW-packages\mingw-w64-json-fortran\src\build-CLANGARM64\include -O3 -module-dir. -ffixed-line-length-72 -c CMakeFiles\jsonfortran.dir\src\json_value_module.F90-pp.f90 -o CMakeFiles\jsonfortran.dir\src\json_value_module.F90.obj LLVM ERROR: INIT_TRAMPOLINE operation is only supported on Linux. PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. Stack dump: 0. Program arguments: C:/msys64/clangarm64/bin/flang -fc1 -triple aarch64-w64-windows-gnu -emit-obj -I C:\\Dev\\Github\\MINGW-packages\\mingw-w64-json-fortran\\src\\json-fortran-9.0.2\\src -I C:\\Dev\\Github\\MINGW-packages\\mingw-w64-json-fortran\\src\\build-CLANGARM64\\include -ffixed-line-length=72 -mrelocation-model pic -pic-level 2 -target-cpu generic -target-feature +v8a -target-feature +fp-armv8 -target-feature +neon -fversion-loops-for-stride -module-dir . -resource-dir C:/msys64/clangarm64/lib/clang/20 -mframe-pointer=none -O3 -o CMakeFiles\\jsonfortran.dir\\src\\json_value_module.F90.obj -x f95-cpp-input CMakeFiles\\jsonfortran.dir\\src\\json_value_module.F90-pp.f90 1. Running pass 'Function Pass Manager' on module 'FIRModule'. 2. Running pass 'AArch64 Instruction Selection' on function '@_QMjson_value_modulePjson_check_all_for_duplicate_keys' Exception Code: 0xC01D #0 0x7ffda6cf9928 HandleAbort (C:\msys64\clangarm64\bin\libLLVM-20.dll+0xc59928) #1 0x7ffe7647ae50 (C:\Windows\System32\ucrtbase.dll+0x7ae50) #2 0x8e39fffe7647ba5c flang: error: flang frontend command failed due to signal (use -v to see invocation) flang version 20.1.3 Target: aarch64-w64-windows-gnu Thread model: posix InstalledDir: C:/msys64/clangarm64/bin flang: note: diagnostic msg: PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: flang: note: diagnostic msg: C:/msys64/tmp/json_value_module-0fd919 flang: note: diagnostic msg: C:/msys64/tmp/json_value_module-0fd919.sh flang: note: diagnostic msg: ninja: build stopped: subcommand failed. ``` Attached are the two files, and also `json_value_module.F90` preprocessed ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 136532] [DebugInfo][LoopDistribute] Removing instructions without salvaging the debug variable Info
Issue 136532 Summary [DebugInfo][LoopDistribute] Removing instructions without salvaging the debug variable Info Labels question, debuginfo, llvm:transforms Assignees Reporter Apochens I found a case in LoopDistribute, where debug value informaiton is not salvaged when removing unused instructions in the distributed loops. Here is an example: https://godbolt.org/z/soc3YxGMe. According to the documentation _How to Update Debug Info_, the debug value info should be salvaged. However, in LoopDistribute, although some of the debug value addresses inside a distributed loop become `poison`, the correct addresses of them can be obtained in other distributed loop. In addition, salvaging the debug value info will leads to some long `DIExpression`s in the given example. So, it seems that the current debug info maintenance in LoopDistribute works well. I'm not sure whether the conclusion is right. So, this issue is currently a question. cc @OCHyams ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 136540] [clang] compilation (instruction selection) failure when targeting AArch64 architecture
Issue
136540
Summary
[clang] compilation (instruction selection) failure when targeting AArch64 architecture
Labels
clang
Assignees
Reporter
JustinKim98
I tried to compile following code in newest clang built from source in current main branch, but there seems to be a bug in AArch64 nstruction selection.
This happens only when I put -O3 option for optimization in debug build.
Here's the compilation command
```bash
clang error.ll -c -O3 --target=aarch64-linux-gnu -o error
```
```llvmir
; error.ll
target triple = "aarch64-unknown-linux-gnu"
define i32 @error(ptr %0, i64 %1) {
br label %3
3:; preds = %6, %2
%.sroa.0.0 = phi <5 x i64> [ zeroinitializer, %2 ], [ %.sroa.0.24.vec.insert, %6 ]
%4 = phi i64 [ 0, %2 ], [ %15, %6 ]
%5 = icmp slt i64 %4, 5
br i1 %5, label %6, label %16
6: ; preds = %3
%7 = getelementptr i8, ptr %0, i64 %4
%8 = load half, ptr %7, align 2
%9 = insertelement <1 x half> zeroinitializer, half %8, i64 0
%10 = fcmp ule <1 x half> %9, zeroinitializer
%11 = insertelement <1 x i64> zeroinitializer, i64 %4, i64 0
%12 = shufflevector <5 x i64> %.sroa.0.0, <5 x i64> zeroinitializer, <1 x i32>
%13 = select <1 x i1> %10, <1 x i64> %12, <1 x i64> %11
%14 = shufflevector <1 x i64> %13, <1 x i64> zeroinitializer, <5 x i32>
%.sroa.0.24.vec.insert = shufflevector <5 x i64> zeroinitializer, <5 x i64> %14, <5 x i32>
%15 = add i64 %4, 1
br label %3
16: ; preds = %16, %3
%17 = extractelement <5 x i64> %.sroa.0.0, i64 %1
store i64 %17, ptr %0, align 4
br label %16
}
```
Here's the output
```
clang++: warning: argument unused during compilation: '-c' [-Wunused-command-line-argument]
clang++: /root/llvm-project/llvm/lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp:6598: llvm::SDValue llvm::DAGTypeLegalizer::WidenVecRes_SETCC(llvm::SDNode*): Assertion `InOp1.getValueType() == WidenInVT && InOp2.getValueType() == WidenInVT && "Input not widened to expected type!"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments: /opt/compiler-explorer/clang-assertions-trunk/bin/clang++ -g -o /app/output.s -fno-verbose-asm -S -x ir -fcolor-diagnostics -fno-crash-diagnostics -O3 --target=aarch64-linux-gnu -c
1. Code generation
2. Running pass 'Function Pass Manager' on module ''.
3. Running pass 'AArch64 Instruction Selection' on function '@error'
#0 0x03ef1728 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x3ef1728)
#1 0x03eef3b4 llvm::sys::CleanupOnSignal(unsigned long) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x3eef3b4)
#2 0x03e33ef8 CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0
#3 0x7381dee42520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#4 0x7381dee969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
#5 0x7381dee42476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
#6 0x7381dee287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
#7 0x7381dee2871b (/lib/x86_64-linux-gnu/libc.so.6+0x2871b)
#8 0x7381dee39e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96)
#9 0x053428bf llvm::DAGTypeLegalizer::WidenVecRes_SETCC(llvm::SDNode*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x53428bf)
#10 0x0534dffa llvm::DAGTypeLegalizer::WidenVectorResult(llvm::SDNode*, unsigned int) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x534dffa)
#11 0x052f6e4b llvm::DAGTypeLegalizer::run() (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x52f6e4b)
#12 0x052f7c39 llvm::SelectionDAG::LegalizeTypes() (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x52f7c39)
#13 0x0526a843 llvm::SelectionDAGISel::CodeGenAndEmitDAG() (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x526a843)
#14 0x0526e0c5 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x526e0c5)
#15 0x0526f385 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x526f385)
#16 0x0525ff2f llvm::SelectionDAGISelLegacy::runOnMachineFunction(llvm::MachineFunction&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x525ff2f)
#17 0x0321baea llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (.part.0) MachineFunctionPass.cpp:0:0
#18 0x0383d41f llvm::FPPassManager::runOnFunction(llvm::Function&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x383d41f)
#19 0x0383d7d1 llvm::F
[llvm-bugs] [Bug 136541] [clang-format] Regression: AlignConsecutiveDeclarations introduces invalid spacing in using declarations with overloaded operators
Issue
136541
Summary
[clang-format] Regression: AlignConsecutiveDeclarations introduces invalid spacing in using declarations with overloaded operators
Labels
clang-format
Assignees
Reporter
kust1011
### Description
In Clang-format versions 20.1.1 and 20.1.2, enabling `AlignConsecutiveDeclarations` causes incorrect formatting of `using` declarations involving overloaded operators. Specifically, an extra space is inserted between the scope resolution operator `::` and the overloaded operator name, resulting in invalid C++ syntax.
Minimal Example
**Input:**
```cpp
#include
void test1() {
using std::operator==;
std::vector v;
}
void test2() {
using std::operator==;
std::vector v;
}
```
**Formatted Output with Clang-format 20.1.1 / 20.1.2:**
```cpp
#include
void test1() {
using std:: operator==;
std::vector v;
}
void test2() {
using std::operator==;
std::vector v;
}
```
In `test1()`, Clang-format inserts extra whitespace between `::` and `operator==`, producing a non-standard formatting that may be misleading or undesirable in production code. This behavior is triggered when the `using` declaration is followed by another declaration that enables alignment logic (e.g., `std::vector v;`) under the `AlignConsecutiveDeclarations` setting. While the resulting code is still syntactically valid, the formatting contradicts conventional C++ style and may degrade readability or tooling reliability.
Style Configuration
```yaml
BasedOnStyle: LLVM
SpaceBeforeParens: Never
SpacesInAngles: Never
AlignConsecutiveDeclarations: true
```
Analysis
This issue appears to stem from the alignment logic introduced by `AlignConsecutiveDeclarations`. When multiple declarations are present, Clang-format attempts to align them, treating `operator==` in the `using` declaration as a field to align. This leads to the insertion of spaces within the `using` declaration, breaking the syntax.
Notably, this behavior is a regression from Clang-format 19.1.7, which correctly preserved or corrected the formatting regardless of context.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 136538] How do I get the future index of a symbol in the AsmPrinter stage?
Issue 136538 Summary How do I get the future index of a symbol in the AsmPrinter stage? Labels new issue Assignees Reporter StevenYangCC How do I get the future index of a symbol in the AsmPrinter stage? ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 136518] placement new
Issue
136518
Summary
placement new
Labels
new issue
Assignees
Reporter
ordinary-github-user
https://godbolt.org/z/qo1nKq4qb
`-std=c++26 -O3 -Wall -mavx512bw -mbmi -fno-exceptions`
```c++
#include
#include
#include
template
struct StaticVector
{
union { T m_data[N]; };
std::uint8_t m_size;
constexpr StaticVector(auto&&...args)noexcept :m_size{ sizeof...(args) }
{
std::construct_at(&m_data);
}
constexpr void push_back(const T x)noexcept
{
new(m_data+m_size)T{x};
}
};
static_assert([]
{
StaticVector vec{1};
vec.push_back(1);
return true;
}());
```
```
free(): invalid next size (fast)
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-trunk/bin/clang++ -gdwarf-4 -g -o /app/output.s -mllvm --x86-asm-syntax=intel -fno-verbose-asm -S --gcc-toolchain=/opt/compiler-explorer/gcc-snapshot -fcolor-diagnostics -fno-crash-diagnostics -std=c++26 -O3 -Wall -mavx512bw -mbmi -fno-exceptions
1. parser at end of file
#0 0x03be2778 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x3be2778)
#1 0x03be08bc llvm::sys::CleanupOnSignal(unsigned long) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x3be08bc)
#2 0x03b311c8 CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0
#3 0x796790242520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#4 0x7967902969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
#5 0x796790242476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
#6 0x7967902287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
#7 0x796790289676 (/lib/x86_64-linux-gnu/libc.so.6+0x89676)
#8 0x7967902a0cfc (/lib/x86_64-linux-gnu/libc.so.6+0xa0cfc)
#9 0x7967902a2a9d (/lib/x86_64-linux-gnu/libc.so.6+0xa2a9d)
#10 0x7967902a5453 __libc_free (/lib/x86_64-linux-gnu/libc.so.6+0xa5453)
#11 0x06d90ecb clang::Sema::PerformPendingInstantiations(bool, bool) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x6d90ecb)
#12 0x062ee589 clang::Sema::ActOnEndOfTranslationUnitFragment(clang::Sema::TUFragmentKind) (.part.0) Sema.cpp:0:0
#13 0x062eed1d clang::Sema::ActOnEndOfTranslationUnit() (/opt/compiler-explorer/clang-trunk/bin/clang+++0x62eed1d)
#14 0x06153cb3 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&, clang::Sema::ModuleImportState&) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x6153cb3)
#15 0x0614207a clang::ParseAST(clang::Sema&, bool, bool) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x614207a)
#16 0x0451cebd clang::CodeGenAction::ExecuteAction() (/opt/compiler-explorer/clang-trunk/bin/clang+++0x451cebd)
#17 0x0482b4fa clang::FrontendAction::Execute() (/opt/compiler-explorer/clang-trunk/bin/clang+++0x482b4fa)
#18 0x047a7c4b clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x47a7c4b)
#19 0x0491b313 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x491b313)
#20 0x00db1451 cc1_main(llvm::ArrayRef, char const*, void*) (/opt/compiler-explorer/clang-trunk/bin/clang+++0xdb1451)
#21 0x00da9bad ExecuteCC1Tool(llvm::SmallVectorImpl&, llvm::ToolContext const&) driver.cpp:0:0
#22 0x0458e8f9 void llvm::function_ref::callback_fn>, std::__cxx11::basic_string, std::allocator>*, bool*) const::'lambda'()>(long) Job.cpp:0:0
#23 0x03b315e3 llvm::CrashRecoveryContext::RunSafely(llvm::function_ref) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x3b315e3)
#24 0x0458eb19 clang::driver::CC1Command::Execute(llvm::ArrayRef>, std::__cxx11::basic_string, std::allocator>*, bool*) const (.part.0) Job.cpp:0:0
#25 0x045520cd clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, clang::driver::Command const*&, bool) const (/opt/compiler-explorer/clang-trunk/bin/clang+++0x45520cd)
#26 0x04553091 clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&, llvm::SmallVectorImpl>&, bool) const (/opt/compiler-explorer/clang-trunk/bin/clang+++0x4553091)
#27 0x0455d3dc clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&, llvm::SmallVectorImpl>&) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x455d3dc)
#28 0x00dae181 clang_main(int, char**, llvm::ToolContext const&) (/opt/compiler-explorer/clang-trunk/bin/clang+++0xdae181)
#29 0x00c2fec4 main (/opt/compiler-explorer/clang-trunk/bin/clang+++0xc2fec4)
#30 0x796790229d90 (/lib/x86_64-linux-gnu/libc.so.6+0x29d90)
#31 0x796790229e40 __libc_start_main (/lib/x86_64-l
[llvm-bugs] [Bug 136519] [X86] Use `vpinsrq` in building 2-element vector of 64-bit int loads
Issue
136519
Summary
[X86] Use `vpinsrq` in building 2-element vector of 64-bit int loads
Labels
new issue
Assignees
Reporter
dzaima
For building a two 64-bit element vector, clang currently does separate loads and packs them together, e.g. this code:
```c
typedef uint64_t u64x2 __attribute__((vector_size(16)));
u64x2 generic_int(uint64_t* a, uint64_t* b) {
return (u64x2){*a, *b};
}
__m128i intrinsics(uint64_t* a, uint64_t* b) {
__m128i lo = _mm_loadu_si64(a);
return _mm_insert_epi64(lo, *b, 1);
}
__m128i intrinsics_int_domain(uint64_t* a, uint64_t* b) {
__m128i lo = _mm_loadu_si64(a);
__m128i t = _mm_insert_epi64(lo, *b, 1);
return _mm_add_epi64(t, t);
}
```
via `-O3 -march=haswell` compiles to:
```asm
generic_int:
vmovsd xmm0, qword ptr [rsi]
vmovsd xmm1, qword ptr [rdi]
vmovlhpsxmm0, xmm1, xmm0
ret
intrinsics:
vmovsd xmm0, qword ptr [rsi]
vmovsd xmm1, qword ptr [rdi]
vmovlhpsxmm0, xmm1, xmm0
ret
intrinsics_int_domain:
vmovq xmm0, qword ptr [rsi]
vmovq xmm1, qword ptr [rdi]
vpunpcklqdq xmm0, xmm1, xmm0
vpaddq xmm0, xmm0, xmm0
ret
```
even though the load of `b` could be done together with the packing via `vpinsrq` for integer domain, and `vmovhps` for unspecified domain if preferring float is desired, i.e.:
```asm
vmovq xmm0, qword ptr [rdi]
vpinsrq xmm0, xmm0, qword ptr [rsi], 1
```
Additionally, per uops.info data, post-icelake, `vpinsrq` has higher throughput than `vmovhps`, and via some local microbenchmarking on Haswell I don't see any domain crossing penalties for either in any direction, so for it could make sense to always use `vpinsrq` and never `vmovhps` (or at least on the applicable targets).
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 136522] [Flang] Incorrect execution result of using polymorphic variable in select type construct
Issue 136522 Summary [Flang] Incorrect execution result of using polymorphic variable in select type construct Labels flang Assignees Reporter ohno-fj ``` Version of flang : 21.0.0(ebba554a3211b0b98d3ae33ba70f9d6ceaab6ad4)/AArch64 ``` In the attached program, `variable (p)` is the return value of `function (ufun)`. It is `a polymorphic variable` that can be of either `derived type (obj3)` or `integer type (obj)`, but it looks like the wrong behavior in `select type construct`. `type is (integer) ` in `select type construct` is not executed. The above program is sngg457k_22.f90. The result is correct if the return value of `function (ufun)` is specified directly: - Before modification ``` p=ufun(n) select type(b=>p) ``` - After modification ``` select type(b=>ufun(n)) ``` The above program is sngg457k_23.f90. The following are the test program, Flang, Gfortran and ifx compilation/execution result. sngg457k_22.f90: ```fortran program main type ty integer :: ii end type ty type ,extends(ty) :: ty1 integer :: jj end type ty1 type(ty1),target:: obj3 integer,target:: obj class(*),allocatable::p do n=0,1 print*,"n=",n p=ufun(n) select type(b=>p) type is (ty1) write(6,*) "b%ii = ", b%ii, " b%jj = ", b%jj type is (integer) write(6,*) "obj = ", obj end select end do print*,"pass" contains function ufun(n) class(*),pointer :: ufun obj3%ii=1 obj3%jj=10 obj=100 select case(n) case(0) ufun=>obj3 case(1) ufun=>obj end select end function ufun end program main ``` ``` $ flang sngg457k_22.f90; ./a.out n= 0 b%ii = 1 b%jj = 10 n= 1 b%ii = 100 b%jj = 0 pass $ ``` ``` $ gfortran sngg457k_22.f90; ./a.out n= 0 b%ii =1 b%jj = 10 n= 1 obj = 100 pass $ ``` ``` $ ifx sngg457k_22.f90; ./a.out n= 0 b%ii =1 b%jj = 10 n= 1 obj = 100 pass $ ``` sngg457k_23.f90: ```fortran program main type ty integer :: ii end type ty type ,extends(ty) :: ty1 integer :: jj end type ty1 type(ty1),target:: obj3 integer,target:: obj class(*),allocatable::p do n=0,1 print*,"n=",n ! p=ufun(n) ! select type(b=>p) select type(b=>ufun(n)) type is (ty1) write(6,*) "b%ii = ", b%ii, " b%jj = ", b%jj type is (integer) write(6,*) "obj = ", obj end select end do print*,"pass" contains function ufun(n) class(*),pointer :: ufun obj3%ii=1 obj3%jj=10 obj=100 select case(n) case(0) ufun=>obj3 case(1) ufun=>obj end select end function ufun end program main ``` ``` $ flang sngg457k_23.f90; ./a.out n= 0 b%ii = 1 b%jj = 10 n= 1 obj = 100 pass $ ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 136521] [Flang] No error checking when derived type is not interoperable because derived type has no BIND attribute
Issue 136521 Summary [Flang] No error checking when derived type is not interoperable because derived type has no BIND attribute Labels flang:frontend Assignees Reporter ohno-fj ``` Version of flang : 21.0.0(ebba554a3211b0b98d3ae33ba70f9d6ceaab6ad4)/AArch64 ``` The attached program is not correct. In this program, 'derived type (ss)' is not interoperable because 'derived type (ty1)' has no BIND attribute. 'Fortran standard 2023: 18.3.4 Interoperability of derived types and C structure types/C1806'. However, flang does not detect any errors and the compilation succeeds. Gfortran and ifx detect errors and both result in compilation errors. The following are the test program, Flang, Gfortran and ifx compilation/execution result. snfm1102_err003_3.f90: ```fortran program main type:: ty1 integer :: iii end type ty1 type,bind(c):: a integer :: i type(ty1) ::ss end type a end program main ``` ``` $ flang snfm1102_err003_3.f90 $ ``` ``` $ gfortran snfm1102_err003_3.f90 snfm1102_err003_3.f90:2:12: 2 | type:: ty1 |1 Error: Derived type ‘ty1’ declared at (1) must have the BIND attribute to be C interoperable $ ``` ``` $ ifx snfm1102_err003_3.f90 snfm1102_err003_3.f90(7): error #8752: This derived type component of an interoperable type is not itself interoperable (does not have the BIND(C) attribute). [SS] type(ty1) ::ss -^ compilation aborted for snfm1102_err003_3.f90 (code 1) $ ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 136523] [Flang] Incorrect execution result of assigning the value of an expression when the length of the variable is greater than the length of the expression
Issue 136523 Summary [Flang] Incorrect execution result of assigning the value of an _expression_ when the length of the variable is greater than the length of the _expression_ Labels flang Assignees Reporter ohno-fj ``` Version of flang : 21.0.0(ebba554a3211b0b98d3ae33ba70f9d6ceaab6ad4)/AArch64 ``` According to `Fortran standard 2023 : 10.2.1.3 Interpretation of intrinsic assignments`: In the attached program, if the length of `variable (asc)` is greater than the length of `_expression_ (["BD","CC"])`, the value of the _expression_ is written to fill the blanks on the right to be the same length as the variable. However, `unlimited polymorphic array (asc)` is not appended with a blank. And `ordinary arrays (ch1)` is appended with a blank. The following are the test program, Flang, Gfortran and ifx compilation/execution result. FT_SelectType_24.f90: ```fortran program main type ty class(*),allocatable :: cptr(:) end type ty type(ty) :: obj1 character(len=3)::kk ="AAA" character(len=3), allocatable :: ch1(:) allocate(ch1(3)) allocate(obj1%cptr(2),source=kk) select type(asc=>obj1%cptr) type is(character(len=*)) ch1 = ["BD","CC"] write(6,*) "len(ch1(1)) = ", len(ch1(1)), " ch1(1) = ", ch1(1) write(6,*) "len(ch1(2)) = ", len(ch1(2)), " ch1(2) = ", ch1(2) asc = ["BD","CC"] write(6,*) "len(asc(1)) = ", len(asc(1)), " asc(1) = ", asc(1) write(6,*) "len(asc(2)) = ", len(asc(2)), " asc(2) = ", asc(2) class default write(6,*) "error2" end select print*,"PASS" end program main ``` ``` $ flang FT_SelectType_24.f90; ./a.out len(ch1(1)) = 3 ch1(1) = BD len(ch1(2)) = 3 ch1(2) = CC len(asc(1)) = 3 asc(1) = BDC len(asc(2)) = 3 asc(2) = C ^@ PASS $ ``` ``` $ gfortran FT_SelectType_24.f90; ./a.out len(ch1(1)) =3 ch1(1) = BD len(ch1(2)) = 3 ch1(2) = CC len(asc(1)) =3 asc(1) = BD len(asc(2)) = 3 asc(2) = CC PASS $ ``` ``` $ ifx FT_SelectType_24.f90; ./a.out len(ch1(1)) =3 ch1(1) = BD len(ch1(2)) = 3 ch1(2) = CC len(asc(1)) =3 asc(1) = BD len(asc(2)) = 3 asc(2) = CC PASS $ ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 136529] Ubuntu 25.04 apt repo?
Issue 136529 Summary Ubuntu 25.04 apt repo? Labels new issue Assignees Reporter oscarbg Still missing.. (https://apt.llvm.org/) ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 136497] [clang-format]:Feature Request Add option to disable space before braces
Issue
136497
Summary
[clang-format]:Feature Request Add option to disable space before braces
Labels
clang-format
Assignees
Reporter
JM-FRANK
**Description**
Clang-Format currently enforces a space before opening braces `{` for code blocks (functions, control statements, etc.`)`, generating:
```c
void function() { ... }
if (condition) { ... }
```
Request: Introduce a new configuration option (e.g., SpaceBeforeBrace) to allow disabling this space, achieving:
```c
void function(){ ... }
if (condition){ ... }
```
Why This Matters
Code Style Compliance: Many projects (especially in embedded systems or legacy codebases) mandate brace styles without preceding spaces.
Consistency: Users should have full control over whitespace rules to match team/company guidelines.
Existing Limitations: Current options like BreakBeforeBraces control line breaks but not spaces.
Proposed Solution
Add a configuration option such as:
```yaml
SpaceBeforeBrace: None | Always (default)
```
Examples:
```
SpaceBeforeBrace: None → void f(){ ... }
SpaceBeforeBrace: Always (default) → void f() { ... }
```
Existing options cannot achieve this:
BreakBeforeBraces: Controls line breaks, not spaces.
SpaceBeforeCpp11BracedList: Affects initialization lists only.
SpacesInParensOptions: Irrelevant to brace positioning.
Example Configuration & Output
Desired .clang-format:
```yaml
BasedOnStyle: LLVM
SpaceBeforeBrace: None
BreakBeforeBraces: Attach
```
Formatted Code:
```c
void example(){ // No space before {
if (x > 0){ // No space here either
doSomething();
}
}
```
This feature would significantly enhance Clang-Format’s flexibility. Thank you for considering this request!
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 136506] [WebAssembly] `DEBUG_VALUE`s not collected for non-first defs
Issue
136506
Summary
[WebAssembly] `DEBUG_VALUE`s not collected for non-first defs
Labels
new issue
Assignees
Reporter
SingleAccretion
In writing a test for an unrelated issue, I came across this code:
https://github.com/llvm/llvm-project/blob/842e5915778a820c63cf38b75bec932a6ea8c18b/llvm/lib/Target/WebAssembly/WebAssemblyDebugValueManager.cpp#L29-L44
This means that any non-first defs of multivalue instructions will get their `DEBUG_VALUE`s dropped. The reproduction is something like below:
```llvm
target triple = "wasm32-unknown-unknown"
declare {i32, i32} @extern_func_multivalue(i32, i32)
define i32 @single_non_dbg_use_multivalue(i32 %0, i32 %1) !dbg !15 {
%full_value = call {i32, i32} @extern_func_multivalue(i32 1, i32 2), !dbg !27
%full_value_one = extractvalue {i32, i32} %full_value, 0, !dbg !27
%full_value_two = extractvalue {i32, i32} %full_value, 1, !dbg !27
call void @llvm.dbg.value(metadata i32 %full_value_two, metadata !16, metadata !DIExpression()), !dbg !28
%partial_value = call {i32, i32} @extern_func_multivalue(i32 %full_value_one, i32 %full_value_two), !dbg !28
%partial_value_one = extractvalue {i32, i32} %partial_value, 0, !dbg !28
%partial_value_two = extractvalue {i32, i32} %partial_value, 1, !dbg !28
call void @llvm.dbg.value(metadata i32 %partial_value_two, metadata !17, metadata !DIExpression()), !dbg !28
ret i32 %partial_value_one, !dbg !29
}
!15 = distinct !DISubprogram(name: "single_non_dbg_use_multivalue", scope: !1, file: !1, type: !7, flags: DIFlagPrototyped, spFlags: DISPFlagDefinition, unit: !0)
!16 = !DILocalVariable(name: "value_used", scope: !15, type: !9)
!17 = !DILocalVariable(name: "value_unused", scope: !15, type: !9)
!27 = !DILocation(line: 27, scope: !15)
!28 = !DILocation(line: 28, scope: !15)
!29 = !DILocation(line: 29, scope: !15)
!llvm.dbg.cu = !{!0}
!llvm.module.flags = !{!2, !3}
!0 = distinct !DICompileUnit(language: DW_LANG_C_plus_plus_14, file: !1, producer: "LLC", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, splitDebugInlining: false, nameTableKind: None)
!1 = !DIFile(filename: "test.ll", directory: "")
!2 = !{i32 7, !"Dwarf Version", i32 4}
!3 = !{i32 2, !"Debug Info Version", i32 3}
!7 = !DISubroutineType(types: !8)
!8 = !{!9, !9, !9}
!9 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)
```
```bash
> llc test.ll -mattr=+multivalue -target-abi=experimental-mv -O0 -o - --filetype=obj | llvm-dwarfdump -
```
```dwarf
0x000b: DW_TAG_compile_unit
DW_AT_producer("LLC")
DW_AT_language (DW_LANG_C_plus_plus_14)
DW_AT_name("test.ll")
DW_AT_stmt_list (0x)
DW_AT_low_pc (0x0002)
DW_AT_high_pc (0x002c)
0x0022: DW_TAG_subprogram
DW_AT_low_pc(0x0002)
DW_AT_high_pc (0x002c)
DW_AT_frame_base (DW_OP_WASM_location 0x3 0x0, DW_OP_stack_value)
DW_AT_name ("single_non_dbg_use_multivalue")
DW_AT_type (0x003b "int")
DW_AT_external (true)
0x003b: DW_TAG_base_type
DW_AT_name ("int")
DW_AT_encoding (DW_ATE_signed)
DW_AT_byte_size (0x04)
```
We should expect to see the variable record for at least `value_used` (`value_unused` looks to be getting dropped earlier).
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 136509] Firefox 137 miscompiles with LLVM 20 on x86_64 + musl + LTO/PGO
Issue 136509 Summary Firefox 137 miscompiles with LLVM 20 on x86_64 + musl + LTO/PGO Labels new issue Assignees Reporter q66 Building Firefox 137 with LTO+PGO configuration equivalent to the upstream builds yields a browser that frequently crashes with the following backtrace: ``` * thread #1, name = 'firefox', stop reason = signal SIGSEGV: address not mapped to object (fault address=0x3b8) frame #0: 0x7fffead0a363 libxul.so`mozilla::dom::BrowsingContext::Top() [inlined] RefPtr::operator bool(this=) const at RefPtr.h:338:45 (lldb) bt * thread #1, name = 'firefox', stop reason = signal SIGSEGV: address not mapped to object (fault address=0x3b8) * frame #0: 0x7fffead0a363 libxul.so`mozilla::dom::BrowsingContext::Top() [inlined] RefPtr::operator bool(this=) const at RefPtr.h:338:45 frame #1: 0x7fffead0a363 libxul.so`mozilla::dom::BrowsingContext::Top(this=0x) at BrowsingContext.cpp:222:10 frame #2: 0x7fffebde79da libxul.so`mozilla::dom::BrowserSessionStore::UpdateSessionStore(mozilla::dom::CanonicalBrowsingContext*, mozilla::Maybe const&, mozilla::Maybe const&, unsigned int) [inlined] mozilla::dom::CanonicalBrowsingContext::Top(this=0x) at CanonicalBrowsingContext.h:114:66 frame #3: 0x7fffebde79d2 libxul.so`mozilla::dom::BrowserSessionStore::UpdateSessionStore(mozilla::dom::CanonicalBrowsingContext*, mozilla::Maybe const&, mozilla::Maybe const&, unsigned int) [inlined] ShouldUpdateSessionStore(aBrowsingContext=, aEpoch=) at BrowserSessionStore.cpp:71:25 frame #4: 0x7fffebde79d2 libxul.so`mozilla::dom::BrowserSessionStore::UpdateSessionStore(this=0x7fffa9894f40, aBrowsingContext=, aFormData=, aScrollPosition=, aEpoch=) at BrowserSessionStore.cpp:245:8 frame #5: 0x7fffebde8391 libxul.so`mozilla::dom::PSessionStoreParent::OnMessageReceived(IPC::Message const&) [inlined] mozilla::dom::SessionStoreParent::RecvIncrementalSessionStoreUpdate(this=0x7fffae954800, aBrowsingContext=0x7fffb778, aFormData=, aScrollPosition=, aEpoch=) at SessionStoreParent.cpp:209:20 frame #6: 0x7fffebde8380 libxul.so`mozilla::dom::PSessionStoreParent::OnMessageReceived(this=0x7fffae954800, msg__=) at PSessionStoreParent.cpp:344:86 frame #7: 0x7fffebeaa1d3 libxul.so`mozilla::dom::PContentParent::OnMessageReceived(this=, msg__=0x7fffe30a3880) at PContentParent.cpp:6738:32 frame #8: 0x7fffea63fdf6 libxul.so`mozilla::ipc::MessageChannel::DispatchMessage(mozilla::ipc::ActorLifecycleProxy*, mozilla::UniquePtr>) [inlined] mozilla::ipc::MessageChannel::DispatchAsyncMessage(this=0x7fff8ce45a80, aProxy=0x7fffca072a80, aMsg=0x7fffe30a3880) at MessageChannel.cpp:1789:25 frame #9: 0x7fffea63fd8d libxul.so`mozilla::ipc::MessageChannel::DispatchMessage(this=0x7fff8ce45a80, aProxy=0x7fffca072a80, aMsg=UniquePtr > @ 0x7fffcdc8) at MessageChannel.cpp:1716:9 frame #10: 0x7fffea63f71b libxul.so`mozilla::ipc::MessageChannel::MessageTask::Run() [inlined] mozilla::ipc::MessageChannel::RunMessage(this=0x7fff8ce45a80, aProxy=0x7fffca072a80, aTask=0x7fffe304f860) at MessageChannel.cpp:1507:3 frame #11: 0x7fffea63f640 libxul.so`mozilla::ipc::MessageChannel::MessageTask::Run(this=0x7fffe304f860) at MessageChannel.cpp:1607:14 frame #12: 0x7fffea63e269 libxul.so`mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock const&) [inlined] mozilla::RunnableTask::Run(this=0x7fffe3146b20) at TaskController.cpp:703:16 frame #13: 0x7fffea63e246 libxul.so`mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock const&) [inlined] mozilla::TaskController::RunTask(aTask=0x7fffe3146b20) at TaskController.cpp:228:71 frame #14: 0x7fffea63e246 libxul.so`mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal(this=0x738db900, aProofOfLock=) at TaskController.cpp:1250:20 frame #15: 0x7fffea5b6566 libxul.so`NS_ProcessNextEvent(nsIThread*, bool) [inlined] mozilla::TaskController::ExecuteNextTaskOnlyMainThreadInternal(this=0x738db900, aProofOfLock=0x7fffd130) at TaskController.cpp:1073:15 frame #16: 0x7fffea5b655b libxul.so`NS_ProcessNextEvent(nsIThread*, bool) [inlined] mozilla::TaskController::ProcessPendingMTTask(this=0x738db900, aMayWait=false) at TaskController.cpp:639:36 frame #17: 0x7fffea5b654f libxul.so`NS_ProcessNextEvent(nsIThread*, bool) [inlined] mozilla::TaskController::TaskController()::$_0::operator()(this=) const at TaskController.cpp:333:37 frame #18: 0x7fffea5b6540 libxul.so`NS_ProcessNextEvent(nsIThread*, bool) [inlined] mozilla::detail::RunnableFunction::Run(this=) at nsThreadUt
[llvm-bugs] [Bug 136495] [lldb-dap] X64 assembly shows wrong lines
Issue 136495 Summary [lldb-dap] X64 assembly shows wrong lines Labels new issue Assignees Reporter eronnen When stepping through x64 it shows the wrong lines in the assembly (in the following example the 2nd step stays in the same line, and the 5th step jumps over an instructiuon) https://github.com/user-attachments/assets/a6fe8d66-3f57-473b-8a0f-a2de37f8158b ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 136498] [LSR] Regression in array access with constant stride
Issue 136498 Summary [LSR] Regression in array access with constant stride Labels new issue Assignees Reporter abdimoallim It appears LSR does not recognize that shift operations could be promoted to operate directly on 64-bit values instead of adding extra 32-bit truncation and sign-extension for ops on loop induction variables. E.g. direct 64-bit shifting compared to `lea r9d, [8*rcx]` then `movsxd r9, r9d` for `i*8` and `i<<3` respectively. ```llvm %35 = trunc nuw nsw i64 %indvars.iv to i32 %shl = shl i32 %35, 3 %idxprom = sext i32 %shl to i64 %arrayidx = getelementptr inbounds i32, ptr %src, i64 %idxprom ``` [Godbolt test](https://godbolt.org/z/xe6d9Ks69) (timeout on Alive2). ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 136480] llvm-project/libcxx/src/exception.cpp:17:12: fatal error: 'cxxabi.h' file not found
Issue 136480 Summary llvm-project/libcxx/src/exception.cpp:17:12: fatal error: 'cxxabi.h' file not found Labels libc++ Assignees Reporter KipHamiltons Same issue as #82197. Full error ```log FAILED: libcxx/src/CMakeFiles/cxx_shared.dir/exception.cpp.o /Users/kip/llvm-project/build/bin/clang++ --target=arm64-apple-darwin23.5.0 -DLIBCXX_BUILDING_LIBCXXABI -DLIBC_NAMESPACE=__llvm_libc_common_utils -D_DEBUG -D_GLIBCXX_ASSERTIONS -D_LIBCPP_BUILDING_LIBRARY -D_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER -D_LIBCPP_REMOVE_TRANSITIVE_INCLUDES -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/Users/kip/llvm-project/libcxx/src -I/Users/kip/llvm-project/build/include/c++/v1 -I/Users/kip/llvm-project/cmake/Modules/../../libc -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wmisleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color -g -std=c++23 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX15.2.sdk -mmacosx-version-min=14.5 -fPIC -faligned-allocation -nostdinc++ -fvisibility-inlines-hidden -fvisibility=hidden -fsized-deallocation -Wall -Wextra -Wnewline-eof -Wshadow -Wwrite-strings -Wno-unused-parameter -Wno-long-long -Werror=return-type -Wextra-semi -Wundef -Wunused-template -Wformat-nonliteral -Wzero-length-array -Wdeprecated-redundant-constexpr-static-def -Wno-nullability-completeness -Wno-user-defined-literals -Wno-covered-switch-default -Wno-suggest-override -Wno-error -MD -MT libcxx/src/CMakeFiles/cxx_shared.dir/exception.cpp.o -MF libcxx/src/CMakeFiles/cxx_shared.dir/exception.cpp.o.d -o libcxx/src/CMakeFiles/cxx_shared.dir/exception.cpp.o -c /Users/kip/llvm-project/libcxx/src/exception.cpp /Users/kip/llvm-project/libcxx/src/exception.cpp:17:12: fatal error: 'cxxabi.h' file not found 17 | # include |^~ 1 error generated. ``` Commands: ```sh $ mkdir build && cd build $ cmake -DCMAKE_INSTALL_PREFIX=$(pwd)/install-prefix -DCMAKE_C_COMPILER=/opt/homebrew/Cellar/llvm/20.1.2/bin/clang -DCMAKE_CXX_COMPILER=/opt/homebrew/Cellar/llvm/20.1.2/bin/clang++ -DCMAKE_BUILD_TYPE=Debug -DLLVM_ENABLE_PROJECTS="clang;lldb" -DLLVM_TARGETS_TO_BUILD=AArch64 -DLLVM_USE_LINKER=lld -DCMAKE_CXX_STANDARD=20 -DLLVM_BUILD_TESTS=ON -DLLVM_ENABLE_RUNTIMES=libcxx -GNinja ../llvm $ ninja ``` Configuration: - Mac M1 - MacOS Sonoma 14.5 - Darwin Kernel Version 23.5.0 - Git commit e8245d53247f155d234e1de647aac2678c49ac28 ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 136479] operator delete isn't annotated with `captures(none)`
Issue 136479 Summary operator delete isn't annotated with `captures(none)` Labels new issue Assignees Reporter philnik777 I'm not 100% certain that it would be correct to annotate `operator delete` with `captures(none)`, but `operator new` is already being annotated with `noalias`, even though that's technically not guaranteed to be correct. Should Clang add `captures(none)` with `-fassume-sane-operator-new`? ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 136481] Windows clang-cl.exe 19.1.1 crash
Issue 136481 Summary Windows clang-cl.exe 19.1.1 crash Labels new issue Assignees Reporter MiguelBarro ## Environment - [Github workflow](https://raw.githubusercontent.com/MiguelBarro/CppCoroutines/refs/heads/main/.github/workflows/ci.yml) - Github hosted windows-latest runner (matches windows-2025 on this report date) - using `CMake` with visual studio generator using `ClangCl` toolset. ## Reproduction steps The crash was generated in [this repo](https://github.com/MiguelBarro/CppCoroutines.git) *github actions*. The repo workflow uses windows, ubuntu and Macos github hosted runners. It runs `CMake` to build C++ sources. The issue is in the `windows-clang` job. Note that `clang` works perfectly on Ubuntu (see `ubuntu-clang` and `macos-clang` jobs). The issue appears when the C++ sources were modified to use `unique_ptr`. ## Crash report It is available [here](https://github.com/MiguelBarro/CppCoroutines/actions/runs/14553506438/job/40827454188#logs). basically: ``` 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: "C:\\Program Files\\Microsoft Visual Studio\\2022\\Enterprise\\VC\\Tools\\Llvm\\x64\\bin\\clang-cl.exe" @C:\\Users\\runneradmin\\AppData\\Local\\Temp\\MSBuildTemp\\tmp53ddccde22e94fa5985920d130732494.rsp 1. parser at end of file 2. Optimizer first.vcxproj -> D:\a\CppCoroutines\CppCoroutines\examples\build\Gor\RelWithDebInfo\first.exe Building Custom Rule D:/a/CppCoroutines/CppCoroutines/examples/basics/CMakeLists.txt 3. Running pass "require,function(invalidate),require,cgscc(devirt<4>(inline,function-attrs,argpromotion,openmp-opt-cgscc,function(sroa,early-cse,speculative-execution,jump-threading,correlated-propagation,simplifycfg,instcombine,aggressive-instcombine,libcalls-shrinkwrap,tailcallelim,simplifycfg,reassociate,constraint-elimination,loop-mssa(loop-instsimplify,loop-simplifycfg,licm,loop-rotate,licm,simple-loop-unswitch),simplifycfg,instcombine,loop(loop-idiom,indvars,simple-loop-unswitch,loop-deletion,loop-unroll-full),sroa,vector-combine,mldst-motion,gvn<>,sccp,bdce,instcombine,jump-threading,correlated-propagation,adce,memcpyopt,dse,move-auto-init,loop-mssa(licm),coro-elide,simplifycfg,instcombine),function-attrs,function(require),coro-split)),function(invalidate),cgscc(devirt<4>())" on module "D:\a\CppCoroutines\CppCoroutines\examples\Gor\client.cpp" 4. Running pass "cgscc(devirt<4>(inline,function-attrs,argpromotion,openmp-opt-cgscc,function(sroa,early-cse,speculative-execution,jump-threading,correlated-propagation,simplifycfg,instcombine,aggressive-instcombine,libcalls-shrinkwrap,tailcallelim,simplifycfg,reassociate,constraint-elimination,loop-mssa(loop-instsimplify,loop-simplifycfg,licm,loop-rotate,licm,simple-loop-unswitch),simplifycfg,instcombine,loop(loop-idiom,indvars,simple-loop-unswitch,loop-deletion,loop-unroll-full),sroa,vector-combine,mldst-motion,gvn<>,sccp,bdce,instcombine,jump-threading,correlated-propagation,adce,memcpyopt,dse,move-auto-init,loop-mssa(licm),coro-elide,simplifycfg,instcombine),function-attrs,function(require),coro-split))" on module "D:\a\CppCoroutines\CppCoroutines\examples\Gor\client.cpp" 5. Running pass "jump-threading" on function "?session@@YA?AV?$future@U?$pair@_K_K@std@@@std@@AEAVio_service@asio@@AEAV?$basic_resolver_iterator@Vtcp@ip@asio@@@ip@4@_KAEAU?$atomic@_N@2@@Z.resume" Exception Code: 0xC005 #0 0x7ff790d194ce (C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\Llvm\x64\bin\clang-cl.exe+0xec94ce) #1 0x7ff7911330ea (C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\Llvm\x64\bin\clang-cl.exe+0x12e30ea) #2 0x7ff79164d3c4 (C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\Llvm\x64\bin\clang-cl.exe+0x17fd3c4) #3 0x7ff791645076 (C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\Llvm\x64\bin\clang-cl.exe+0x17f5076) #4 0x7ff79173db96 (C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\Llvm\x64\bin\clang-cl.exe+0x18edb96) #5 0x7ff7917390af (C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\Llvm\x64\bin\clang-cl.exe+0x18e90af) #6 0x7ff7917355f0 (C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\Llvm\x64\bin\clang-cl.exe+0x18e55f0) #7 0x7ff791177c24 (C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\Llvm\x64\bin\clang-cl.exe+0x1327c24) #8 0x7ff791177a71 (C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\Llvm\x64\bin\clang-cl.exe+0x1327a71) #9 0x7ff7914b9643 (C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\Llvm\x64\bin\clang-cl.exe+0x1669643) #10 0x7ff7914b92c1 (
[llvm-bugs] [Bug 136491] Runtime unavailability of unified shared memory not disclosed by libomptarget
Issue 136491 Summary Runtime unavailability of unified shared memory not disclosed by libomptarget Labels new issue Assignees Reporter KaruroChori > I found the issue at least in my case. Debian official kernel images are built without CONFIG_DEVICE_PRIVATE. > Which is needed for this feature to work. > https://forums.developer.nvidia.com/t/how-to-enable-hmm-on-debian/316561 > > Time to rebuild the kernel. > > **Addendum**: I can confirm that with the freshly baked kernel it works. _Originally posted by @KaruroChori in [#127334](https://github.com/llvm/llvm-project/issues/127334#issuecomment-2817171884)_ Debian's kernel images, and possibly others, don't ship with support for USM out of the box. At runtime, applications which have been built with `#pragma omp requires unified_shared_memory` are going to fail without providing any meaningful error message which describes the issue. It would be nice if libomptarget could perform a check at runtime and provide a more meaningful error message for this type of failure. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 136487] [CIR] Upstream VectorType support
Issue
136487
Summary
[CIR] Upstream VectorType support
Labels
ClangIR
Assignees
AmrDeveloper
Reporter
AmrDeveloper
### Overview
Upstream, the basic support for vector types. The initial change should add support for declaring and initialising global variables that are a vector of existing scalar types. Follow-up patches can add support for local variables accessing elements and perform vector op.
### Suggested minimal test case
```
typedef int vi4 __attribute__((vector_size(16)));
vi4 a = { 1, 2, 3, 4 };
vi4 b = { x, 5, 6, x + 1 };
```
### Existing incubator tests
clang/test/CIR/CodeGen/vectype.c
clang/test/CIR/CodeGen/vectype-ext.c
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 136492] [lldb-dap] Debugging with no source code available
Issue 136492 Summary [lldb-dap] Debugging with no source code available Labels new issue Assignees Reporter eronnen When stepping into a module where the source code is not available, vscode shows an error instead of showing the assembly: https://github.com/user-attachments/assets/6f7617a0-9bb7-43e1-9a79-5ae1bdfcc69a ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 136493] lto and optimised out symbols
Issue 136493 Summary lto and optimised out symbols Labels new issue Assignees Reporter ilobilo I'm compiling and linking my project with full lto. During runtime, the executable reads and parses its own symbol table and uses those entries for loading shared objects. Unfortunately, lto optimises out some of those symbols, so those objects can not be relocated and loaded. I can mark each unresolved symbol with ``[[gnu::used]]``, but I don't have access to many of them, as they are from external projects. I'm wondering, is there a way to force the linker to not remove/optimise out symbols from the target executable? ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
