[llvm-bugs] [Bug 123487] [BOLT] Crash: "Cannot encode high byte register in REX-prefixed instruction" during basic block reordering of libvulkan_radeon.so
Issue
123487
Summary
[BOLT] Crash: "Cannot encode high byte register in REX-prefixed instruction" during basic block reordering of libvulkan_radeon.so
Labels
BOLT
Assignees
Reporter
ms178
**Description:**
Bolt crashes during optimization of the `libvulkan_radeon.so` library (part of the Mesa Radeon Vulkan driver) when using the `--lite=false` flag. The crash occurs during the basic block reordering phase (`ExtTSPReorderAlgorithm`) and is caused by an error in the x86 code emitter: "Cannot encode high byte register in REX-prefixed instruction".
**Environment:**
* **Operating System:** CachyOS
* **LLVM/BOLT Version:** Recent snapshot of LLVM-git (3def49cb64ec1298290724081bd37dbdeb2ea5f8)
* **Host Compiler:** GCC 14.2.1
* **Target Architecture:** x86-64
* **Binary:** `libvulkan_radeon.so` (from Mesa Radeon Vulkan driver)
* **BOLT command:** `llvm-bolt "$file" --data "${srcdir}/bolt_profile/vkcube.perf.data" --dyno-stats --lite=false --cu-processing-batch-size=64 --eliminate-unreachable --frame-opt=all --icf=all --jump-tables=aggressive --min-branch-clusters --stoke --sctc-mode=always --plt=all --hot-data --hot-text --frame-opt-rm-stores --peepholes=all --infer-stale-profile=1 --x86-strip-redundant-address-size --indirect-call-promotion=all --reg-reassign --use-aggr-reg-reassign --reorder-blocks=ext-tsp --reorder-functions=cdsort --split-all-cold --split-eh --split-functions --split-strategy=cdsplit --skip-funcs=.text/1 -o "_build64/bolt/$(basename "$file")"` (part of a larger build script)
**Steps to Reproduce:**
1. Build Mesa with the Radeon Vulkan driver enabled.
2. Collect profiling data using `perf` while running a Vulkan application (e.g., `vkcube`).
3. Attempt to optimize `libvulkan_radeon.so` using llvm-bolt with the command line arguments specified above, particularly including `--lite=false`.
**Expected Behavior:**
llvm-bolt should successfully optimize `libvulkan_radeon.so` without crashing. This does work in lite mode.
**Actual Behavior:**
llvm-bolt crashes with the following error message:
```
LLVM ERROR: Cannot encode high byte register in REX-prefixed instruction
```
**Stack Trace:**
```
LLVM ERROR: Cannot encode high byte register in REX-prefixed instruction
#0 0x640fccb7a9c5 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) Signals.cpp:0:0
#1 0x640fccb7adbc SignalHandler(int) Signals.cpp:0:0
#2 0x766b28647530 (/usr/lib/libc.so.6+0x47530)
#3 0x766b286b6ccd pthread_kill (/usr/lib/libc.so.6+0xb6ccd)
#4 0x766b28647472 raise (/usr/lib/libc.so.6+0x47472)
#5 0x766b286244a3 abort (/usr/lib/libc.so.6+0x244a3)
#6 0x640fccb56622 llvm::report_fatal_error(llvm::Twine const&, bool) (/home/marcus/llvm20/bin/llvm-bolt+0x3756622)
#7 0x640fcb64ae45 (/home/marcus/llvm20/bin/llvm-bolt+0x224ae45)
#8 0x640fcbb100d8 (anonymous namespace)::X86MCCodeEmitter::emitPrefixImpl(unsigned int&, llvm::MCInst const&, llvm::MCSubtargetInfo const&, llvm::SmallVectorImpl&) const X86MCCodeEmitter.cpp:0:0
#9 0x640fcbb0c323 (anonymous namespace)::X86MCCodeEmitter::encodeInstruction(llvm::MCInst const&, llvm::SmallVectorImpl&, llvm::SmallVectorImpl&, llvm::MCSubtargetInfo const&) const (.4c1216ec09f139b7b42615b3f5e2d4e3) X86MCCodeEmitter.cpp:0:0
#10 0x640fcd0ef6ed llvm::bolt::BinaryBasicBlock::estimateSize(llvm::MCCodeEmitter const*) const (/home/marcus/llvm20/bin/llvm-bolt+0x3cef6ed)
#11 0x640fcd0695e6 llvm::bolt::ExtTSPReorderAlgorithm::reorderBasicBlocks(llvm::bolt::BinaryFunction&, llvm::SmallVector&) const (/home/marcus/llvm20/bin/llvm-bolt+0x3c695e6)
#12 0x640fccfe07fe std::_Function_handler::_M_invoke(std::_Any_data const&, llvm::bolt::BinaryFunction&) BinaryPasses.cpp:0:0
#13 0x640fcd1905ca std::_Function_handler, std::function, std::__cxx11::basic_string, std::allocator>, bool, unsigned int)::$_0 (std::_Rb_tree_iterator>, std::_Rb_tree_iterator>)>>::_M_invoke(std::_Any_data const&) ParallelUtilities.cpp:0:0
#14 0x640fccca6578 std::_Function_handler (), std::__future_base::_Task_setter, std::__future_base::_Result_base::_Deleter>, std::thread::_Invoker>>, void>>::_M_invoke(std::_Any_data const&) DWARFRewriter.cpp:0:0
#15 0x640fccc03da1 std::__future_base::_State_baseV2::_M_do_set(std::function ()>*, bool*) JITLinkLinker.cpp:0:0
#16 0x766b286ba3f7 (/usr/lib/libc.so.6+0xba3f7)
#17 0x766b286ba479 __pthread_once (/usr/lib/libc.so.6+0xba479)
#18 0x640fcbedba60 void std::call_once ()>*, bool*), std::__future_base::_State_baseV2*, std::function ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function ()>*&&, bool*&&) JITLinkLinker.cpp:0:0
#19 0x640fcbedb9b1 std::__future_base::_State_baseV2::_M_set_result(
[llvm-bugs] [Bug 123492] clang-tidy android-cloexec-fopen docs should say if `e` is safe across platforms
Issue 123492 Summary clang-tidy android-cloexec-fopen docs should say if `e` is safe across platforms Labels clang-tidy Assignees Reporter seanm The docs for `android-cloexec-fopen` here: https://clang.llvm.org/extra/clang-tidy/checks/android/cloexec-fopen.html say only "fopen() should include `e` in their mode string; so `re` would be valid. This is equivalent to having set FD_CLOEXEC on that descriptor." By having "android" in the check's name, one assumes this works on Android. The macOS 10.13 through 15.3 man pages say `e` is supported. Not sure about Windows, linux, the BSDs, or others. But most important of all: is it known that adding `e` would be harmless/ignored on all OSes? If it's not knowm, it's risky to just add an `e` in cross-platform code, because maybe the `e` would break some implementations of fopen. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123481] `test_uptime::test_uptime_with_file_containing_valid_boot_time_utmpx_record stdout` fails on linux arm64
Issue
123481
Summary
`test_uptime::test_uptime_with_file_containing_valid_boot_time_utmpx_record stdout` fails on linux arm64
Labels
new issue
Assignees
Reporter
sylvestre
See:
https://github.com/uutils/coreutils/pull/7153
```
test_uptime::test_uptime_with_file_containing_valid_boot_time_utmpx_record stdout
run: /home/runner/work/coreutils/coreutils/target/aarch64-unknown-linux-gnu/debug/coreutils uptime testx
thread 'test_uptime::test_uptime_with_file_containing_valid_boot_time_utmpx_record' panicked at tests/by-util/test_uptime.rs:116:10:
Command was expected to succeed. code: 101
stdout = 09:22:30
stderr = thread 'main' panicked at src/uucore/src/lib/features/utmpx.rs:190:31:
attempt to multiply with overflow
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
stack backtrace:
0: rust_begin_unwind
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/std/src/panicking.rs:652:5
1: core::panicking::panic_fmt
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/core/src/panicking.rs:72:14
2: tests::common::util::CmdResult::success
at ./tests/common/util.rs:417:9
3: tests::common::util::UCommand::succeeds
at ./tests/common/util.rs:1782:9
4: tests::test_uptime::test_uptime_with_file_containing_valid_boot_time_utmpx_record
at ./tests/by-util/test_uptime.rs:114:5
5: tests::test_uptime::test_uptime_with_file_containing_valid_boot_time_utmpx_record::{{closure}}
at ./tests/by-util/test_uptime.rs:103:67
6: core::ops::function::FnOnce::call_once
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/core/src/ops/function.rs:250:5
7: core::ops::function::FnOnce::call_once
at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/core/src/ops/function.rs:250:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123498] clang-trunk fails to compile valid code
Issue
123498
Summary
clang-trunk fails to compile valid code
Labels
new issue
Assignees
Reporter
beached
It looks like a recent change has broken the following code and it is instantiating the else branch of an if constexpr
https://gcc3.godbolt.org/z/YvKjrEKsG
```cpp
#include
#include
#include
template
struct remove_array_ref;
template
struct remove_array_ref {
using type = T[N];
};
template
using remove_array_ref_t = typename remove_array_ref::type;
template ,
typename U = std::enable_if_t>,
remove_array_ref_t>>
constexpr bool array_cmp(T && lhs, T &&rhs, Compare const &cmp = Compare{}) {
for (size_t n = 0; n < std::extent_v; ++n) {
if constexpr (std::rank_v == 1) {
if (not cmp(lhs[n], rhs[n])) {
return false;
}
} else {
if (not array_cmp(lhs[n], rhs[n], cmp)) {
return false;
}
}
}
return true;
}
int main() {
{
constexpr int ints1[]{1, 2, 3, 4};
constexpr int ints2[]{1, 2, 3, 4};
static_assert(array_cmp(ints1, ints2));
}
{
constexpr int ints3[2][4]{{1, 2, 3, 4}, {1, 2, 3, 4}};
constexpr int ints4[2][4]{{1, 2, 3, 4}, {1, 2, 3, 4}};
static_assert(array_cmp(ints3, ints4));
}
}
```
```
:25:21: error: no matching function for call to 'array_cmp'
25 | if (not array_cmp(lhs[n], rhs[n], cmp)) {
| ^
:37:23: note: in instantiation of function template specialization 'array_cmp, const int[4]>' requested here
37 | static_assert(array_cmp(ints1, ints2));
| ^
:18:16: note: candidate template ignored: substitution failure [with T = const int &, Compare = std::equal_to]: implicit instantiation of undefined template 'remove_array_ref'
13 | using remove_array_ref_t = typename remove_array_ref::type;
| ~
14 |
15 | template ,
16 | typename U = std::enable_if_t>,
17 | remove_array_ref_t>>
18 | constexpr bool array_cmp(T && lhs, T &&rhs, Compare const &cmp = Compare{}) {
| ^
:37:23: error: static assertion _expression_ is not an integral constant _expression_
37 | static_assert(array_cmp(ints1, ints2));
| ^~~
:42:23: error: static assertion _expression_ is not an integral constant _expression_
42 | static_assert(array_cmp(ints3, ints4));
| ^~~
3 errors generated.
Compiler returned: 1
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123485] cppcoreguidelines-interfaces-global-init false positive for global references initialized from other globals
Issue
123485
Summary
cppcoreguidelines-interfaces-global-init false positive for global references initialized from other globals
Labels
clang-tidy,
false-positive
Assignees
Reporter
LegalizeAdulthood
Suppose you have the following code:
```
double g_params[MAX_PARAMS]{};
static const double &LAMBDA{g_params[0]};
```
`cppcoreguidelines-interfaces-global-init` is reported for the declaration of `LAMBDA`, but this is erroneous.
To reproduce:
1. `git clone https://github.com/LegalizeAdulthood/iterated-dynamics.git`
2. `git checkout 3f219d4dfce69d8bcab73412d0b261f378a6a239`
3. `cmake --preset default`
4. run clang-tidy on `lorenz.cpp`
5. false positive reported for lines 1295-1300
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123479] [CI] LLDB test failures related to zlib
Issue 123479 Summary [CI] LLDB test failures related to zlib Labels new issue Assignees boomanaiden154 Reporter boomanaiden154 When running lldb tests in the new premerge system on Github Actions, we're seeing some test failures due to a missing/misconfigured zlib: ``` 2025-01-18T03:38:02.9058314Z FAIL: lldb-shell :: SymbolFile/DWARF/x86/debug-names-compressed.cpp (1587 of 2651) 2025-01-18T03:38:02.9059816Z TEST 'lldb-shell :: SymbolFile/DWARF/x86/debug-names-compressed.cpp' FAILED 2025-01-18T03:38:02.9061028Z Exit Code: 1 2025-01-18T03:38:02.9061285Z 2025-01-18T03:38:02.9061478Z Command Output (stderr): 2025-01-18T03:38:02.9061975Z -- 2025-01-18T03:38:02.9065413Z RUN: at line 6: /__w/llvm-project/llvm-project/build/bin/clang --target=specify-a-target-or-use-a-_host-substitution -c -o /__w/llvm-project/llvm-project/build/tools/lldb/test/Shell/SymbolFile/DWARF/x86/Output/debug-names-compressed.cpp.tmp.o --target=x86_64-pc-linux -gdwarf-5 -gpubnames /__w/llvm-project/llvm-project/lldb/test/Shell/SymbolFile/DWARF/x86/debug-names-compressed.cpp 2025-01-18T03:38:02.9072765Z + /__w/llvm-project/llvm-project/build/bin/clang --target=specify-a-target-or-use-a-_host-substitution -c -o /__w/llvm-project/llvm-project/build/tools/lldb/test/Shell/SymbolFile/DWARF/x86/Output/debug-names-compressed.cpp.tmp.o --target=x86_64-pc-linux -gdwarf-5 -gpubnames /__w/llvm-project/llvm-project/lldb/test/Shell/SymbolFile/DWARF/x86/debug-names-compressed.cpp 2025-01-18T03:38:02.9079018Z RUN: at line 7: /opt/llvm/bin/ld.lld /__w/llvm-project/llvm-project/build/tools/lldb/test/Shell/SymbolFile/DWARF/x86/Output/debug-names-compressed.cpp.tmp.o -o /__w/llvm-project/llvm-project/build/tools/lldb/test/Shell/SymbolFile/DWARF/x86/Output/debug-names-compressed.cpp.tmp --compress-debug-sections=zlib 2025-01-18T03:38:02.9084673Z + /opt/llvm/bin/ld.lld /__w/llvm-project/llvm-project/build/tools/lldb/test/Shell/SymbolFile/DWARF/x86/Output/debug-names-compressed.cpp.tmp.o -o /__w/llvm-project/llvm-project/build/tools/lldb/test/Shell/SymbolFile/DWARF/x86/Output/debug-names-compressed.cpp.tmp --compress-debug-sections=zlib 2025-01-18T03:38:02.9088241Z ld.lld: error: --compress-debug-sections: LLVM was not built with LLVM_ENABLE_ZLIB or did not find zlib at build time 2025-01-18T03:38:02.9089218Z 2025-01-18T03:38:02.9089389Z -- 2025-01-18T03:38:02.9089590Z 2025-01-18T03:38:02.9089752Z ``` Doesn't look like it should be too complicated to fix, just wanted to create a bug so I don't lose track of the issue and forget to fix it until I see the failure again. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123456] missed optimization to simple vptest when using libstdc++ std::experimental::simd to detect all-zero pattern on x86-64 avx
Issue
123456
Summary
missed optimization to simple vptest when using libstdc++ std::experimental::simd to detect all-zero pattern on x86-64 avx
Labels
new issue
Assignees
Reporter
ImpleLee
The following code uses libstdc++ experimental simd, and wants to detect several all-zero patterns that can be easily done with the vptest instructions. All the code is available at https://godbolt.org/z/Kx68E1T6v .
```c++
#include
#include
namespace stdx = std::experimental;
template
using simd_of = stdx::simd>;
using data_t = simd_of;
bool simple_ptest(data_t x) {
return all_of(x == 0);
}
bool ptest_and(data_t a, data_t b) {
return all_of((a & b) == 0);
}
bool ptest_andn(data_t a, data_t b) {
return all_of((a & ~b) == 0);
}
```
Equivalent assembly (hand-written):
```asm
simple_ptest:
vptest %xmm0, %xmm0
sete%al
ret
ptest_and:
vptest %xmm0, %xmm1
sete%al
ret
ptest_andn:
vptest %xmm0, %xmm1
setc%al
ret
```
But clang++ generates the following code at `-O3 -march=x86-64-v3`.
```asm
simple_ptest(std::experimental::parallelism_v2::simd>):
vpxor xmm1, xmm1, xmm1
vpcmpeqdxmm0, xmm0, xmm1
vpcmpeqdxmm1, xmm1, xmm1
vptest xmm0, xmm1
setb al
ret
ptest_and(std::experimental::parallelism_v2::simd>, std::experimental::parallelism_v2::simd>):
vpand xmm0, xmm1, xmm0
vpxor xmm1, xmm1, xmm1
vpcmpeqd xmm0, xmm0, xmm1
vpcmpeqdxmm1, xmm1, xmm1
vptest xmm0, xmm1
setbal
ret
ptest_andn(std::experimental::parallelism_v2::simd>, std::experimental::parallelism_v2::simd>):
vpandn xmm0, xmm1, xmm0
vpxor xmm1, xmm1, xmm1
vpcmpeqd xmm0, xmm0, xmm1
vpcmpeqdxmm1, xmm1, xmm1
vptest xmm0, xmm1
setbal
ret
```
reference: [the same issue at gcc bugzilla](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118416) (identified as a duplicate to another missed optimization).
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123467] Clang++ 18.1.3 crashes on C++20 project
Issue 123467 Summary Clang++ 18.1.3 crashes on C++20 project Labels clang Assignees Reporter mmerkel Here is the Stack dump, and I attach the preprocessed source and associated run script in the .tar.gz file. Please let me know if you need more info: Stack dump: 0. Program arguments: clang++ -DCGAL_USE_GMPXX=1 -DFMT_SHARED -I/home/mmpi/Code/2D-VertexModel/src -I/home/mmpi/Code/2D-VertexModel/lib -I/usr/local/include/eigen3 -I/home/mmpi/Code/2D-VertexModel/cmake-build-release -Wall -Wextra -Wno-deprecated-enum-enum-conversion -Wno-deprecated-copy -O3 -std=gnu++20 -fdiagnostics-color=always -frounding-math -MD -MT test/CMakeFiles/all_tests.dir/minimization_times.cpp.o -MF test/CMakeFiles/all_tests.dir/minimization_times.cpp.o.d -o test/CMakeFiles/all_tests.dir/minimization_times.cpp.o -c /home/mmpi/Code/2D-VertexModel/test/minimization_times.cpp 1. parser at end of file 2. Per-file LLVM IR generation 3. /home/mmpi/Code/2D-VertexModel/src/physics/Foam.h:293:12: Generating code for declaration 'VertexModel2D::Physics::Foam::Els, VertexModel2D::Geometry::CombinedDofs, VertexModel2D::Geometry::Bc::SimplePeriodic_Dofs, VertexModel2D::Geometry::VertexBased2D_Dofs>, VertexModel2D::T1Criterion::LengthBased<>::Els>::DirectedEdge::DirectedEdge' Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it): 0 libLLVM.so.18.1 0x705b665a63bf llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 63 1 libLLVM.so.18.1 0x705b665a44f9 llvm::sys::RunSignalHandlers() + 89 2 libLLVM.so.18.1 0x705b664f0227 3 libc.so.6 0x705b65045320 4 libLLVM.so.18.1 0x705b666d0952 llvm::Instruction::eraseFromParent() + 18 5 libclang-cpp.so.18.1 0x705b6ee1fdde 6 libclang-cpp.so.18.1 0x705b6ee1becd 7 libclang-cpp.so.18.1 0x705b6ee15858 clang::CodeGen::CodeGenFunction::EmitAggExpr(clang::Expr const*, clang::CodeGen::AggValueSlot) + 744 8 libclang-cpp.so.18.1 0x705b6ed64791 clang::CodeGen::CodeGenFunction::EmitInitializerForField(clang::FieldDecl*, clang::CodeGen::LValue, clang::Expr*) + 433 9 libclang-cpp.so.18.1 0x705b6ed6f17f 10 libclang-cpp.so.18.1 0x705b6ed65ea6 clang::CodeGen::CodeGenFunction::EmitCtorPrologue(clang::CXXConstructorDecl const*, clang::CXXCtorType, clang::CodeGen::FunctionArgList&) + 2070 11 libclang-cpp.so.18.1 0x705b6ed65265 clang::CodeGen::CodeGenFunction::EmitConstructorBody(clang::CodeGen::FunctionArgList&) + 853 12 libclang-cpp.so.18.1 0x705b6efaeeb5 clang::CodeGen::CodeGenFunction::GenerateCode(clang::GlobalDecl, llvm::Function*, clang::CodeGen::CGFunctionInfo const&) + 1077 13 libclang-cpp.so.18.1 0x705b6ed42670 clang::CodeGen::CodeGenModule::codegenCXXStructor(clang::GlobalDecl) + 240 14 libclang-cpp.so.18.1 0x705b6f04e440 15 libclang-cpp.so.18.1 0x705b6efc9fe6 clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl, llvm::GlobalValue*) + 294 16 libclang-cpp.so.18.1 0x705b6efbce53 clang::CodeGen::CodeGenModule::EmitDeferred() + 291 17 libclang-cpp.so.18.1 0x705b6efbce6f clang::CodeGen::CodeGenModule::EmitDeferred() + 319 18 libclang-cpp.so.18.1 0x705b6efbce6f clang::CodeGen::CodeGenModule::EmitDeferred() + 319 19 libclang-cpp.so.18.1 0x705b6efbce6f clang::CodeGen::CodeGenModule::EmitDeferred() + 319 20 libclang-cpp.so.18.1 0x705b6efbce6f clang::CodeGen::CodeGenModule::EmitDeferred() + 319 21 libclang-cpp.so.18.1 0x705b6efbce6f clang::CodeGen::CodeGenModule::EmitDeferred() + 319 22 libclang-cpp.so.18.1 0x705b6efbce6f clang::CodeGen::CodeGenModule::EmitDeferred() + 319 23 libclang-cpp.so.18.1 0x705b6efbce6f clang::CodeGen::CodeGenModule::EmitDeferred() + 319 24 libclang-cpp.so.18.1 0x705b6efbce6f clang::CodeGen::CodeGenModule::EmitDeferred() + 319 25 libclang-cpp.so.18.1 0x705b6efbce6f clang::CodeGen::CodeGenModule::EmitDeferred() + 319 26 libclang-cpp.so.18.1 0x705b6efbce6f clang::CodeGen::CodeGenModule::EmitDeferred() + 319 27 libclang-cpp.so.18.1 0x705b6efbce6f clang::CodeGen::CodeGenModule::EmitDeferred() + 319 28 libclang-cpp.so.18.1 0x705b6efbce6f clang::CodeGen::CodeGenModule::EmitDeferred() + 319 29 libclang-cpp.so.18.1 0x705b6efba9ed clang::CodeGen::CodeGenModule::Release() + 109 30 libclang-cpp.so.18.1 0x705b6f069d0c 31 libclang-cpp.so.18.1 0x705b6ef9f4e7 clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 167 32 libclang-cpp.so.18.1 0x705b6db973d6 clang::ParseAST(clang::Sema&, bool, bool) + 598 33 libclang-cpp.so.18.1 0x705b6fa0662c clang::FrontendAction::Execute() + 92 34 libclang-cpp.so.18.1 0x705b6f9830b4 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 708 35 libclang-cpp.so.18.1 0x705b6fa8263d clang
[llvm-bugs] [Bug 123457] clang-cl - Conflicting types for atomic_signal_fence
Issue
123457
Summary
clang-cl - Conflicting types for atomic_signal_fence
Labels
new issue
Assignees
Reporter
Neumann-A
LLVM: 19.1.6
MSVC: 17.12.3
```
D:\installed\x64-windows\compiler-llvm\bin\clang-cl.exe -TP -DNOMINMAX -DQJp2Plugin_EXPORTS -DQT_CORE_LIB -DQT_DEPRECATED_WARNINGS -DQT_EXPLICIT_QFILE_CONSTRUCTION_FROM_PATH -DQT_GUI_LIB -DQT_NO_AS_CONST=1 -DQT_NO_DEBUG -DQT_NO_EXCEPTIONS -DQT_NO_FOREACH -DQT_NO_FOREACH=1 -DQT_NO_JAVA_STYLE_ITERATORS -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_NO_QASCONST -DQT_NO_QEXCHANGE -DQT_NO_QSNPRINTF -DQT_PLUGIN -DQT_USE_QSTRINGBUILDER -DUNICODE -DWIN32 -DWIN64 -D_CRT_SECURE_NO_WARNINGS -D_ENABLE_EXTENDED_ALIGNED_STORAGE -D_UNICODE -D_WIN64 -ID:\b\qtimageformats\x64-windows-static-rel\src\plugins\imageformats\jp2\QJp2Plugin_autogen\include -ID:\b\qtimageformats\src\here-src-6-3afc88f6f5.clean\src\plugins\imageformats\jp2 -ID:\b\qtimageformats\x64-windows-static-rel\src\plugins\imageformats\jp2 -ID:\b\qtimageformats\x64-windows-static-rel\include -imsvcD:\installed\x64-windows\VS\VC\Tools\MSVC\14.42.34433\include -imsvcD:\installed\x64-windows\VS\VC\Tools\MSVC\14.42.34433\ATLMFC\include -imsvcD:\installed\x64-windows\VS\VC\Auxiliary\VS\include -imsvc"D:\installed\x64-windows\WinSDK\Windows Kits\10\include\10.0.26100.0\ucrt" -imsvc"D:\installed\x64-windows\WinSDK\Windows Kits\10\include\10.0.26100.0\um" -imsvc"D:\installed\x64-windows\WinSDK\Windows Kits\10\include\10.0.26100.0\shared" -imsvc"D:\installed\x64-windows\WinSDK\Windows Kits\10\include\10.0.26100.0\winrt" -imsvc"D:\installed\x64-windows\WinSDK\Windows Kits\10\include\10.0.26100.0\cppwinrt" -imsvc"D:\installed\x64-windows\WinSDK\Windows Kits\NETFXSDK\4.8.1\include\um" -imsvcD:\installed\x64-windows-static\include -imsvcD:\installed\x64-windows-static\include\Qt6\QtCore -imsvcD:\installed\x64-windows-static\include\Qt6 -imsvcD:\installed\x64-windows-static\share\Qt6\mkspecs\win32-clang-msvc -imsvcD:\installed\x64-windows-static\include\Qt6\QtGui /nologo /DWIN32 /D_WINDOWS -Wno-implicit-function-declaration /utf-8 -msse4.2 -m64 /GR /EHsc /MD /O2 /Oi /Gy /DNDEBUG /Z7 -std:c++17 -MD /W3 /EHs-c- /wd4530 /wd4577 -Wno-ignored-attributes -ftrivial-auto-var-init=pattern /showIncludes /Fosrc\plugins\imageformats\jp2\CMakeFiles\QJp2Plugin.dir\qjp2handler.cpp.obj /Fdsrc\plugins\imageformats\jp2\CMakeFiles\QJp2Plugin.dir\ -c -- D:\b\qtimageformats\src\here-src-6-3afc88f6f5.clean\src\plugins\imageformats\jp2\qjp2handler.cpp
In file included from D:\b\qtimageformats\src\here-src-6-3afc88f6f5.clean\src\plugins\imageformats\jp2\qjp2handler.cpp:12:
In file included from D:\installed\x64-windows-static\include\jasper/jasper.h:78:
In file included from D:\installed\x64-windows-static\include\jasper/jas_init.h:73:
In file included from D:\installed\x64-windows-static\include\jasper/jas_malloc.h:81:
In file included from D:\installed\x64-windows-static\include\jasper/jas_thread.h:89:
D:\installed\x64-windows\compiler-llvm\lib\clang\19\include\stdatomic.h(82,6): error: conflicting types for 'atomic_thread_fence'
82 | void atomic_thread_fence(memory_order);
| ^
D:\installed\x64-windows\VS\VC\Tools\MSVC\14.42.34433\include\atomic(308,36): note: previous definition is here
308 | _EXPORT_STD extern "C" inline void atomic_thread_fence(const memory_order _Order) noexcept {
| ^
In file included from D:\b\qtimageformats\src\here-src-6-3afc88f6f5.clean\src\plugins\imageformats\jp2\qjp2handler.cpp:12:
In file included from D:\installed\x64-windows-static\include\jasper/jasper.h:78:
In file included from D:\installed\x64-windows-static\include\jasper/jas_init.h:73:
In file included from D:\installed\x64-windows-static\include\jasper/jas_malloc.h:81:
In file included from D:\installed\x64-windows-static\include\jasper/jas_thread.h:89:
D:\installed\x64-windows\compiler-llvm\lib\clang\19\include\stdatomic.h(83,6): error: conflicting types for 'atomic_signal_fence'
83 | void atomic_signal_fence(memory_order);
| ^
D:\installed\x64-windows\VS\VC\Tools\MSVC\14.42.34433\include\atomic(312,36): note: previous definition is here
312 | _EXPORT_STD extern "C" inline void atomic_signal_fence(const memory_order _Order) noexcept {
| ^
2 errors generated.
```
Adding a `#ifndef _MSC_VER` around the two `atomic_` functions makes the code compile but I don't know if that is the correct fix.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123459] False negatives clang-analyzer-core.StackAddressEscape when storing pointers/references in container
Issue
123459
Summary
False negatives clang-analyzer-core.StackAddressEscape when storing pointers/references in container
Labels
new issue
Assignees
Reporter
chrchr-github
~~~c++
#include
#include
struct S { std::string* s; };
std::vector f() {
std::vector v;
{
std::string a{ "abc" };
v.push_back({ &a });
}
return v;
}
struct T { std::string& s; };
std::vector g() {
std::vector v;
{
std::string b{ "def" };
v.push_back({ b });
}
return v;
}
int main() {
return f()[0].s->size() + g()[0].s.size();
}
~~~
https://godbolt.org/z/sMb8Ebv9j
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123462] Functions merging doesn't respect TBAA metadata on store instructions
Issue
123462
Summary
Functions merging doesn't respect TBAA metadata on store instructions
Labels
new issue
Assignees
Reporter
Panzerschrek
See https://github.com/llvm/llvm-project/blob/58326f1d5b5b379590af92dd129b2f3b3e96af46/llvm/lib/Transforms/Utils/FunctionComparator.cpp#L698
Metadata for `store` instructions (including TBAA) isn't compared in function comparator. This may lead to merging functions with different TBAA metadata. This means breaking further optimizations based on TBAA, including removing loads and stores wrongly assumed to be redundant and optimized-out.
Example generated by my language compiler:
```llvm
%"1A" = type { i64 }
%"1B" = type { i64 }
; Function Attrs: nounwind
define private void @_Z6BStoreR1By(ptr noalias nonnull dereferenceable(8) %_arg_b, i64 %_arg_x) unnamed_addr #0 {
allocations:
%x = alloca i64, align 8
%0 = getelementptr inbounds %"1B", ptr %_arg_b, i32 0, i32 0
br label %func_code
func_code: ; preds = %allocations
store i64 %_arg_x, ptr %x, align 8, !tbaa !7
%1 = load i64, ptr %x, align 8, !tbaa !7
store i64 %1, ptr %0, align 8, !tbaa !7
ret void
}
; Function Attrs: nounwind
define private void @_Z6AStoreR1Ax(ptr noalias nonnull dereferenceable(8) %_arg_a, i64 %_arg_x) unnamed_addr #0 {
allocations:
%x = alloca i64, align 8
%0 = getelementptr inbounds %"1A", ptr %_arg_a, i32 0, i32 0
br label %func_code
func_code: ; preds = %allocations
store i64 %_arg_x, ptr %x, align 8, !tbaa !0
%1 = load i64, ptr %x, align 8, !tbaa !0
store i64 %1, ptr %0, align 8, !tbaa !0
ret void
}
; Function Attrs: nounwind
define hidden ptr @GetAStore() unnamed_addr #0 {
allocations:
br label %func_code
func_code:; preds = %allocations
ret ptr @_Z6AStoreR1Ax
}
; Function Attrs: nounwind
define hidden ptr @GetBStore() unnamed_addr #0 {
allocations:
br label %func_code
func_code:; preds = %allocations
ret ptr @_Z6BStoreR1By
}
attributes #0 = { nounwind }
!0 = !{!1, !1, i64 0}
!1 = !{!"i64", !2, i64 0}
!2 = !{!"byte64", !3, i64 0}
!3 = !{!"byte32", !4, i64 0}
!4 = !{!"byte16", !5, i64 0}
!5 = !{!"byte8", !6, i64 0}
!6 = !{!"__U_tbaa_root"}
!7 = !{!8, !8, i64 0}
!8 = !{!"u64", !2, i64 0}
```
Functions `BStore` and `AStore` have almost identical code - they store a value in memory, but using different TBAA tags - for `i64` and `u64` language types (which are in my language distinct from each other).
After running optimization passes (including functions merge pass) I get following code:
```llvm
; Function Attrs: mustprogress nofree norecurse nosync nounwind willreturn memory(argmem: write)
define private void @_Z6AStoreR1Ax(ptr noalias nocapture nonnull writeonly dereferenceable(8) %_arg_a, i64 %_arg_x) unnamed_addr #0 {
allocations:
store i64 %_arg_x, ptr %_arg_a, align 8, !tbaa !0
ret void
}
; Function Attrs: mustprogress nofree norecurse nosync nounwind willreturn memory(none)
define hidden nonnull ptr @GetAStore() unnamed_addr #1 {
allocations:
ret ptr @_Z6AStoreR1Ax
}
; Function Attrs: mustprogress nofree norecurse nosync nounwind willreturn memory(none)
define hidden nonnull ptr @GetBStore() unnamed_addr #1 {
allocations:
ret ptr @_Z6AStoreR1Ax
}
attributes #0 = { mustprogress nofree norecurse nosync nounwind willreturn memory(argmem: write) }
attributes #1 = { mustprogress nofree norecurse nosync nounwind willreturn memory(none) }
!0 = !{!1, !1, i64 0}
!1 = !{!"i64", !2, i64 0}
!2 = !{!"byte64", !3, i64 0}
!3 = !{!"byte32", !4, i64 0}
!4 = !{!"byte16", !5, i64 0}
!5 = !{!"byte8", !6, i64 0}
!6 = !{!"__U_tbaa_root"}
```
Two functions were merged, but this is incorrect behavior. In such example it's not a big deal, but in cases where such functions may be inlined later this may cause a bug leading to miscompilation and crashes in result binary code.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123471] [Clang] Clang crashes when attempting to call a member function via CRTP in a default argument expression
Issue
123471
Summary
[Clang] Clang crashes when attempting to call a member function via CRTP in a default argument _expression_
Labels
clang
Assignees
Reporter
venkatrao1
I'm using this [clang19 docker image](https://hub.docker.com/layers/silkeh/clang/19/images/sha256-12b393a8a03b2b2296a28e01651c0be35d5fc7c612df71a93ed2be4a61f46598) to reproduce, here's a [godbolt reproduction](https://godbolt.org/z/jcorvY5K6) as well.
Reproduction file:
```cpp
template
struct CRTPBase {
auto& self() { return static_cast(*this); }
};
template
struct Foo : CRTPBase> {
int x() const { return 5; }
// illegal to call a non-static member fn "self" here, I think
int callXByDefault(int val = self().x()) { return val; }
private:
using CRTPBase>::self;
};
int main() {
return Foo{}.callXByDefault();
}
```
Note: removing the template parameter T from Foo produces an error instead of crashing, which I think should be the correct behavior with the template parameter as well.
[stderr.txt](https://github.com/user-attachments/files/18465707/stderr.txt)
[repro-b39b7a.cpp.txt](https://github.com/user-attachments/files/18465709/repro-b39b7a.cpp.txt)
[repro-b39b7a.sh.txt](https://github.com/user-attachments/files/18465708/repro-b39b7a.sh.txt)
I get the following in stderr:
```
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: clang++ -c -std=c++20 -emit-llvm -Xclang -disable-llvm-passes repro.cpp
1. parser at end of file
2. repro.cpp:17:5: LLVM IR generation of declaration 'main'
3. repro.cpp:17:5: Generating code for declaration 'main'
#0 0x7f72f89ca3c6 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/usr/lib/llvm-19/bin/../lib/libLLVM.so.19.1+0xeb73c6)
#1 0x7f72f89c8070 llvm::sys::RunSignalHandlers() (/usr/lib/llvm-19/bin/../lib/libLLVM.so.19.1+0xeb5070)
#2 0x7f72f8910210 (/usr/lib/llvm-19/bin/../lib/libLLVM.so.19.1+0xdfd210)
#3 0x7f72f764f050 (/lib/x86_64-linux-gnu/libc.so.6+0x3c050)
#4 0x7f730169fb5f clang::CodeGen::CodeGenFunction::GetAddressOfBaseClass(clang::CodeGen::Address, clang::CXXRecordDecl const*, clang::CXXBaseSpecifier const* const*, clang::CXXBaseSpecifier const* const*, bool, clang::SourceLocation) (/usr/lib/llvm-19/bin/../lib/libclang-cpp.so.19.1+0x1fa4b5f)
#5 0x7f73017403b4 (/usr/lib/llvm-19/bin/../lib/libclang-cpp.so.19.1+0x20453b4)
#6 0x7f730173ef7d clang::CodeGen::CodeGenFunction::EmitPointerWithAlignment(clang::Expr const*, clang::CodeGen::LValueBaseInfo*, clang::CodeGen::TBAAAccessInfo*, clang::CodeGen::KnownNonNull_t) (/usr/lib/llvm-19/bin/../lib/libclang-cpp.so.19.1+0x2043f7d)
#7 0x7f730176a5d9 clang::CodeGen::CodeGenFunction::EmitCXXMemberOrOperatorMemberCallExpr(clang::CallExpr const*, clang::CXXMethodDecl const*, clang::CodeGen::ReturnValueSlot, bool, clang::NestedNameSpecifier*, bool, clang::Expr const*) (/usr/lib/llvm-19/bin/../lib/libclang-cpp.so.19.1+0x206f5d9)
#8 0x7f7301769819 clang::CodeGen::CodeGenFunction::EmitCXXMemberCallExpr(clang::CXXMemberCallExpr const*, clang::CodeGen::ReturnValueSlot) (/usr/lib/llvm-19/bin/../lib/libclang-cpp.so.19.1+0x206e819)
#9 0x7f7301757031 clang::CodeGen::CodeGenFunction::EmitCallExpr(clang::CallExpr const*, clang::CodeGen::ReturnValueSlot) (/usr/lib/llvm-19/bin/../lib/libclang-cpp.so.19.1+0x205c031)
#10 0x7f7301743999 clang::CodeGen::CodeGenFunction::EmitCallExprLValue(clang::CallExpr const*) (/usr/lib/llvm-19/bin/../lib/libclang-cpp.so.19.1+0x2048999)
#11 0x7f7301742aa5 clang::CodeGen::CodeGenFunction::EmitLValueHelper(clang::Expr const*, clang::CodeGen::KnownNonNull_t) (/usr/lib/llvm-19/bin/../lib/libclang-cpp.so.19.1+0x2047aa5)
#12 0x7f730174b88c clang::CodeGen::CodeGenFunction::EmitCastLValue(clang::CastExpr const*) (/usr/lib/llvm-19/bin/../lib/libclang-cpp.so.19.1+0x205088c)
#13 0x7f7301742a95 clang::CodeGen::CodeGenFunction::EmitLValueHelper(clang::Expr const*, clang::CodeGen::KnownNonNull_t) (/usr/lib/llvm-19/bin/../lib/libclang-cpp.so.19.1+0x2047a95)
#14 0x7f730173768d clang::CodeGen::CodeGenFunction::EmitLValue(clang::Expr const*, clang::CodeGen::KnownNonNull_t) (/usr/lib/llvm-19/bin/../lib/libclang-cpp.so.19.1+0x203c68d)
#15 0x7f730176a7a4 clang::CodeGen::CodeGenFunction::EmitCXXMemberOrOperatorMemberCallExpr(clang::CallExpr const*, clang::CXXMethodDecl const*, clang::CodeGen::ReturnValueSlot, bool, clang::NestedNameSpecifier*, bool, clang::Expr const*) (/usr/lib/llvm-19/bin/../lib/libclang-cpp.so.19.1+0x206f7a4)
#16 0x7f7301769819 clang::CodeGen::CodeGenFunction::EmitCXXMemberCallExpr(clang::CXXMemberCallExpr const*, clang::CodeGen::ReturnValueSlot) (/usr/lib/llvm-19/bin/../lib/libclang-cpp.so.19.1+0x206e8
[llvm-bugs] [Bug 123472] [clang++] Constraints aren't substituted in an unevaluated context
Issue 123472 Summary [clang++] Constraints aren't substituted in an unevaluated context Labels clang Assignees Reporter katzdm https://godbolt.org/z/EG4Kf4xvd The _expression_ of a _simple-requirement_ is an unevaluated operand ([[expr.prim.req.simple]](https://eel.is/c++draft/expr.prim.req#simple-1.sentence-2)), but Clang doesn't currently seem to be pushing a corresponding `ExpressionEvaluationContext` to treat them as such. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
