[llvm-bugs] [Bug 146545] Request Commit Access For egebeysel
Issue 146545 Summary Request Commit Access For egebeysel Labels infra:commit-access-request Assignees Reporter egebeysel ### Why Are you requesting commit access I'm mainly working on MLIR-based tensor compilers and therefore core MLIR dialects and optimizations. Requesting commit access on behalf of @RooflineAI. I'd be working on them even more in the near future, and would like to be able to merge my own PRs upon approval :) ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146564] Zen3 scheduler model for the latency of VEXTRACTF128rri is probably incorrect
Issue
146564
Summary
Zen3 scheduler model for the latency of VEXTRACTF128rri is probably incorrect
Labels
new issue
Assignees
Reporter
TiborGY
See also discussion at https://discourse.llvm.org/t/are-the-latencies-of-vextractf128-correct-for-zen2-3-in-mca/86422
LLVM MCA relies on LLVM's scheduler models to predict cycle counts. This is the predicted timeline graph for a small snippet on Zen3:
```
[0,0] DER.. vmovapd (%rdi), %ymm0
[0,1] D=eeER .. vsubpd(%rsi), %ymm0, %ymm0
[0,2] D===eeeER . vmulpd%ymm0, %ymm0, %ymm0
[0,3] D==ER vextractf128 $1, %ymm0, %xmm1
[0,4] D==eE---R vmovhlps %xmm0, %xmm0, %xmm2
```
As you can see, `vextractf128` is predicted to have 4 cycles of latency. This however is inconsistent with both Agner Fogs latency tables (which list 3 cycles) and my own measurements with llvm-exegesis.
```
./llvm-exegesis -mode=latency -opcode-name=VEXTRACTF128rri -mcpu=znver3 --benchmark-repeat-count=10 -min-instructions=1000 --repetition-mode=loop
---
mode: latency
key:
instructions:
- 'VEXTRACTF128rri XMM0 YMM0 i_0x1'
config: ''
register_initial_values:
- 'YMM0=0x0'
cpu_name: znver3
llvm_triple: x86_64-unknown-linux-gnu
min_instructions: 1000
measurements:
- { key: latency, value: 3.15, per_snippet_value: 3.15, validation_counters: {} }
error: ''
info: Repeating a single explicitly serial instruction
assembled_snippet: 4883EC20C70424C7442404C7442408C744240CC7442410C7442414C7442418C744241CC5FE6F04244883C42049B80200662E0F1F8400C4E37D19C001C4E37D19C0014983C0FF75EEC3
...
```
Confusingly, AMD's official instruction latency table for Zen3 (Family_19h_Instruction_Latencies_version_1-00.xlsx, AMD Publication No. 56665 Revision 3.00 November 2020) lists `vextractf128` to have 4 cycles of latency. Perhaps I am misinterpreting my measurement results, but I cannot see how that figure could be correct. My confidence in the accuracy of the official latency table is further eroded by the fact that the two `vextractf128` variants are both listed with empty operand fields.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146576] [lldb] Update JSONTransport to use MainLoop
Issue 146576 Summary [lldb] Update JSONTransport to use MainLoop Labels lldb, lldb-dap Assignees Reporter ashgti At the moment, JSONTransport is fairly abstract to how its reading/writing. To support both pipes (e.g. stdin) and sockets, we should update https://github.com/llvm/llvm-project/blob/d79c284a2fef5f9cb6b803b3d0cb4c1f857ece03/lldb/include/lldb/Host/JSONTransport.h#L69 to perform reads using the RunLoop. With that, we should also be able to read in larger chunks and use a buffer for tracking partial messages. At the moment, our `Read` logic ends up reading 1 char at a time to try to find delimiters. This should improve the performance of reading for JSONTransport. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146566] Target assert fails downstream for tests with device target -triple x86_64-pc-windows-msvc
Issue 146566 Summary Target assert fails downstream for tests with device target -triple x86_64-pc-windows-msvc Labels new issue Assignees sarnex Reporter schittir https://github.com/llvm/llvm-project/pull/140282/files#diff-56f9373c26f0ad1f09dd4c561b7fe44dc9cfd6d363c54be44816fbc2a9f8a43e This test has been failing [this assert](url) added by https://github.com/llvm/llvm-project/pull/137882 FAIL: Clang :: CodeGenSYCL/unique_stable_name_windows_diff.cpp (11004 of 21742) TEST 'Clang :: CodeGenSYCL/unique_stable_name_windows_diff.cpp' FAILED Exit Code: 2 Command Output (stderr): -- /home/gha/actions-runner/_work/llvm-project/llvm-project/build/bin/clang -cc1 -internal-isystem /home/gha/actions-runner/_work/llvm-project/llvm-project/build/lib/clang/21/include -nostdsysteminc -triple spir64-unknown-unknown -aux-triple x86_64-pc-windows-msvc -fsycl-is-device -disable-llvm-passes -fsycl-is-device -emit-llvm /home/gha/actions-runner/_work/llvm-project/llvm-project/clang/test/CodeGenSYCL/unique_stable_name_windows_diff.cpp -o - | /home/gha/actions-runner/_work/llvm-project/llvm-project/build/bin/FileCheck /home/gha/actions-runner/_work/llvm-project/llvm-project/clang/test/CodeGenSYCL/unique_stable_name_windows_diff.cpp '-D$ADDRSPACE=addrspace(1) ' # RUN: at line 1 + /home/gha/actions-runner/_work/llvm-project/llvm-project/build/bin/clang -cc1 -internal-isystem /home/gha/actions-runner/_work/llvm-project/llvm-project/build/lib/clang/21/include -nostdsysteminc -triple spir64-unknown-unknown -aux-triple x86_64-pc-windows-msvc -fsycl-is-device -disable-llvm-passes -fsycl-is-device -emit-llvm /home/gha/actions-runner/_work/llvm-project/llvm-project/clang/test/CodeGenSYCL/unique_stable_name_windows_diff.cpp -o - + /home/gha/actions-runner/_work/llvm-project/llvm-project/build/bin/FileCheck /home/gha/actions-runner/_work/llvm-project/llvm-project/clang/test/CodeGenSYCL/unique_stable_name_windows_diff.cpp '-D$ADDRSPACE=addrspace(1) ' /home/gha/actions-runner/_work/llvm-project/llvm-project/build/bin/clang -cc1 -internal-isystem /home/gha/actions-runner/_work/llvm-project/llvm-project/build/lib/clang/21/include -nostdsysteminc -triple x86_64-pc-windows-msvc -fsycl-is-device -disable-llvm-passes -fsycl-is-device -emit-llvm /home/gha/actions-runner/_work/llvm-project/llvm-project/clang/test/CodeGenSYCL/unique_stable_name_windows_diff.cpp -o - | /home/gha/actions-runner/_work/llvm-project/llvm-project/build/bin/FileCheck /home/gha/actions-runner/_work/llvm-project/llvm-project/clang/test/CodeGenSYCL/unique_stable_name_windows_diff.cpp '-D$ADDRSPACE=' # RUN: at line 2 + /home/gha/actions-runner/_work/llvm-project/llvm-project/build/bin/clang -cc1 -internal-isystem /home/gha/actions-runner/_work/llvm-project/llvm-project/build/lib/clang/21/include -nostdsysteminc -triple x86_64-pc-windows-msvc -fsycl-is-device -disable-llvm-passes -fsycl-is-device -emit-llvm /home/gha/actions-runner/_work/llvm-project/llvm-project/clang/test/CodeGenSYCL/unique_stable_name_windows_diff.cpp -o - + /home/gha/actions-runner/_work/llvm-project/llvm-project/build/bin/FileCheck /home/gha/actions-runner/_work/llvm-project/llvm-project/clang/test/CodeGenSYCL/unique_stable_name_windows_diff.cpp '-D$ADDRSPACE=' Unknown kernel calling convention UNREACHABLE executed at /home/gha/actions-runner/_work/llvm-project/llvm-project/clang/lib/CodeGen/TargetInfo.cpp:120! 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: /home/gha/actions-runner/_work/llvm-project/llvm-project/build/bin/clang -cc1 -internal-isystem /home/gha/actions-runner/_work/llvm-project/llvm-project/build/lib/clang/21/include -nostdsysteminc -triple x86_64-pc-windows-msvc -fsycl-is-device -disable-llvm-passes -fsycl-is-device -emit-llvm /home/gha/actions-runner/_work/llvm-project/llvm-project/clang/test/CodeGenSYCL/unique_stable_name_windows_diff.cpp -o - 1. parser at end of file 2. Per-file LLVM IR generation #0 0x57d360a2cb08 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /home/gha/actions-runner/_work/llvm-project/llvm-project/llvm/lib/Support/Unix/Signals.inc:804:13 #1 0x57d360a2a5f5 llvm::sys::RunSignalHandlers() /home/gha/actions-runner/_work/llvm-project/llvm-project/llvm/lib/Support/Signals.cpp:106:18 #2 0x57d360a2d1e1 SignalHandler(int, siginfo_t*, void*) /home/gha/actions-runner/_work/llvm-project/llvm-project/llvm/lib/Support/Unix/Signals.inc:0:3 #3 0x7a0ec4f18330 (/lib/x86_64-linux-gnu/libc.so.6+0x45330) #4 0x7a0ec4f71b2c pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x9eb2c) #5 0x7a0ec4f1827e raise (/lib/x86_64-linux-gnu/libc.so.6+0x4527e) #6 0
[llvm-bugs] [Bug 146605] [CodeView] Add missing record 0x1176
Issue 146605 Summary [CodeView] Add missing record 0x1176 Labels new issue Assignees Reporter aganea Linking most recent msvcrt libraries from Microsoft generates `lld-link: ignoring unknown symbol record with kind 0x1176` when using `/verbose`. @sivadeilra Would you by chance be able to add this record? ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146581] Group signature symbol is missing when the group name is same as a section name.
Issue 146581 Summary Group signature symbol is missing when the group name is same as a section name. Labels new issue Assignees Reporter parth-07 Group signature symbol is missing when the group name is same as a section name. Reproducible example: ```bash #!/usr/bin/env bash cat >1.s <<\EOF .section foo,"ax",@progbits .globl main main: .section A,"axG",@progbits,foo EOF cat >1.arm.s <<\EOF .section foo,"ax",%progbits .globl main main: .section A,"axG",%progbits,foo EOF llvm-mc -triple arm -o 1.arm.o 1.arm.s -filetype obj llvm-mc -triple riscv64 -o 1.rv64.o 1.s -filetype obj llvm-readelf -sS 1.arm.o # .group(sh_info) is 0 and foo is missing from the symbol table llvm-readelf -sS 1.rv64.o # .group(sh_info) is 0 and foo is missing from the symbol table ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146607] [clang-tidy] Check request: performance-redundant-std-vector
Issue
146607
Summary
[clang-tidy] Check request: performance-redundant-std-vector
Labels
clang-tidy
Assignees
Reporter
denzor200
Need a check that will find cases where `std::vector` is used redundantly for **fixed-size, statically initialized data**. The check will suggest a replacement with `std::array` for better performance and clarity.
BEFORE:
```
bool foo(int val) {
std::vector v = { 1,2, 5, 10, 33 };
return std::range::find(v, val) != v.end();
}
```
AFTER:
```
bool foo(int val) {
std::array v = { 1,2, 5, 10, 33 };
return std::range::find(v, val) != v.end();
}
```
In C++17 mode the check will produce replacement with CTAD usage:
```
bool foo(int val) {
std::array v = { 1,2, 5, 10, 33 };
return std::range::find(v, val) != v.end();
}
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146560] Poison not propagate through @llvm.pow[i]
Issue
146560
Summary
Poison not propagate through @llvm.pow[i]
Labels
llvm:instcombine,
constant-folding
Assignees
Reporter
lukel97
I believe we should be able to fold `@llvm.pow[i]` with a poison operand to poison:
```llvm
define float @src(float %x) {
%powi = call float @llvm.powi(float poison, i32 %pow)
ret float %powi
}
define float @tgt(float %x) {
ret float poison
}
```
But we don't do this today: https://godbolt.org/z/EGrYPc6oW
I can't think of a reason why poison wouldn't propagate, I presume it would act similarly to e.g. `@llvm.sqrt` which we do fold poison through.
Alive doesn't seem to support the pow[i] libcall just yet https://alive2.llvm.org/ce/z/CXcVgc
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146579] [[clang::unsafe_buffer_usage]] Source range in unsafe pointer arithmetic warning doesn't show entire unsafe operation
Issue
146579
Summary
[[clang::unsafe_buffer_usage]] Source range in unsafe pointer arithmetic warning doesn't show entire unsafe operation
Labels
clang
Assignees
Reporter
tsepez
Given a file range0.cc:
```
int lookup(int *ptr, unsigned idx) {
return ptr[idx];
}
int* predecrement(int* ptr) {
return --ptr; // not actually useful, only for example
}
```
```
range0.cc:3:10:{3:10-3:13}: warning: unsafe buffer access [-Wunsafe-buffer-usage]
3 |return ptr[idx];
| ^~~
range0.cc:3:10: note: pass -fsafe-buffer-usage-suggestions to receive code hardening suggestions
range0.cc:7:12:{7:12-7:15}: warning: unsafe pointer arithmetic [-Wunsafe-buffer-usage]
7 |return --ptr; // not actually useful, only for example
| ^~~
```
The returned range indicates only the unsafe operand rather than the range of the unsafe operation.
We seek to automate applying the _Pragma("clang unsafe_buffer_usage begin") / _Pragma("clang unsafe_buffer_usage end") form of suppression around the ranges as exactly indicated by the compiler,
and using some macro trickery, i.e.
```
#define UNSAFE_BUFFERS(...) \
_Pragma("clang unsafe_buffer_usage begin") \
__VA_ARGS__ \
_Pragma("clang unsafe_buffer_usage end")
int lookup(int *ptr, unsigned idx) {
return UNSAFE_BUFFERS(ptr)[idx];
}
int* predecrement2(int* ptr) {
return --UNSAFE_BUFFERS(ptr); // not actually useful, only for example
}
```
The ptr[idx] looks unusual but does suppress the error. The --ptr case, however gives
```
range1.cc:12:27: warning: unsafe pointer arithmetic [-Wunsafe-buffer-usage]
12 | return --UNSAFE_BUFFERS(ptr); // not actually useful, only for example
| ^~~
```
The returned range should cover the entire unsafe operation, not the unsafe argument allowing us to write
```
int lookup(int *ptr, unsigned idx) {
return UNSAFE_BUFFERS(ptr[idx]);
}
int* predecrement(int* ptr) {
return UNSAFE_BUFFERS(--ptr); // not actually useful, only for example
}
```
which compiles cleanly
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146573] [openmp] Assertion failure at z_Linux_util.cpp(2108): file != NULL.
Issue 146573 Summary [openmp] Assertion failure at z_Linux_util.cpp(2108): file != NULL. Labels new issue Assignees Reporter berolinux I'm seeing some crashes of code using OpenMP build with clang 20.1.7 inside containers on a Linux box: `Assertion failure at z_Linux_util.cpp(2108): file != NULL` Looking at the code in question, this error is generated here: https://github.com/llvm/llvm-project/blob/main/openmp/runtime/src/z_Linux_util.cpp#L2121-L2125 if `/proc//maps` can't be opened. I'm not sure yet how exactly this is triggered (given the container in question does mount /proc inside it); I suspect it may happen when the conatiner is set up (decompressing the filesystem image for the container is parallelized -> openmp code is called -- but /proc is only mounted inside the container after the filesystem image is ready). ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146559] [lldb-dap] Hover on objc declarations vs expressions is different
Issue 146559 Summary [lldb-dap] Hover on objc declarations vs expressions is different Labels lldb-dap Assignees Reporter ashgti I'm looking into updating lldb-dap's _expression_ request and digging into this I found some inconsistencies with how we're evaluating terms in the hover request. Specifically, if you have some obj-c code like: ``` MyType *foo = [[MyType alloc] init]; [foo doWork]; ``` If you hover over the declaration of `foo` VSCode is actually sending a hover request for `*foo`. If you hover over `foo` when its about to invoke a method, it will send a request for `foo`. When we call `frame.GetValueForVariablePath` with the first form, its dereferencing the variable. Which is a totally valid _expression_, but not what I think the user meant when they hover over the variable. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146568] [clang-format] Mixed pointer and reference alignment suggestion
Issue 146568 Summary [clang-format] Mixed pointer and reference alignment suggestion Labels clang-format Assignees Reporter untodesu By searching I found at minimum one issue (#136597) asking for a solution on this. It would really be cool to have an option for a mixed pointer and reference alignment for various cases (mainly return types, template arguments and anything else): ```c++ // Return type is aligned-left // Argument is aligned-right const char* my_function(const std::string& my_argument); // Template argument is aligned-left extern std::vector list_of_strings; // Variable is aligned-right extern const char *my_cool_string; ``` We work on a large-scale project with this specific code style and mixed pointer/reference alignment is the only thing that practically stops us from auto-formatting the entire source tree :trollface: Thanks in advance! ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146555] BOLT does not work with Stale Profiles even while using YAML profile format
Issue 146555 Summary BOLT does not work with Stale Profiles even while using YAML profile format Labels Assignees Reporter lsreenivas Please refer to the thread: [https://discourse.llvm.org/t/how-to-solve-the-problem-of-stale-profile-data-when-bolt-is-used-with-pgo/78007/12](url) I tried the following things but still we are not seeing the optimization gains even after we switched to YAML profiles. Please read the details below. We started to convert our *.fdata profiles to YAML profiles via: llvm-bolt mylib.so -data mylib.fdata -w mylib.yaml When we use the YAML profile_N to optimize library N ( here N = release number, for example ) then we can see good performance gains. But we want to use YAML for helping us with stale profiling, which is my hard requirement. When I used the same YAML profile N to inject and optimize the next release library_(N+1), then shockingly we are seeing no gain at all and a poor result. We are at LLVM 19.1.3 and for the optimization we are exactly using the following command: > llvm-bolt --data="" --dyno-stats --eliminate-unreachable --icf --icp-eliminate-loads --infer-stale-profile --inline-all --match-profile-with-function-hash --reorder-blocks=ext-tsp --reorder-functions=cdsort --split-all-cold --split-eh --split-functions --update-debug-sections --use-gnu-stack /original/mylib.so -o /optimized/mylib.so -v=1 As you can see, we are already using: --infer-stale-profile and --match-profile-with-function-hash, thinking that these two options will really help us in getting stale profile matching benefit. However, we still see the same issue even with the YAML profiles, which we observed in fdata profiles. i.e., when we inject profile_N of yaml into release_N+1, it does not work and shows no gains and in fact poor results. Could you please tell if we are missing something here ? thank you ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146612] [clang-tidy] Check request: bugprone-avoid-inline-constexpr-in-Implementations
Issue 146612 Summary [clang-tidy] Check request: bugprone-avoid-inline-constexpr-in-Implementations Labels clang-tidy Assignees Reporter denzor200 C++17 suggests us the possibility to use `inline` on `constexpr` variables, but when identical `inline constexpr` variables are defined in different translation units with different values, this violates the One Definition Rule (ODR) which manifests unpredictably (e.g., different values in different TUs). Need a check to get rid from `inline` keyword on `constexpr` variables in source files. BEFORE: ``` // foo.cpp inline constexpr int MAX_SIZE = 1024; ``` AFTER: ``` // foo.cpp constexpr int MAX_SIZE = 1024; ``` **Scope** - Applies only to sources (.cpp, .cxx, etc.), ignoring .h files. **Why `bugprone-`?** - Runtime behaviour potentially affected due to unexpected constant's value selected in link time. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146614] Regression in Clang 17+ when inheriting operators from recursive base classes
Issue
146614
Summary
Regression in Clang 17+ when inheriting operators from recursive base classes
Labels
clang
Assignees
Reporter
eerkela
Clang 17.0.1+ segfaults when compiling this simple definition of an overload set:
```
#include
#include
template
struct overloads {
std::decay_t func;
overloads(F&& f) : func(std::move(f)) {}
template
decltype(auto) operator()(A&&... args)
requires (requires{{func(std::forward(args)...)};})
{
return (func(std::forward(args)...));
}
};
template
struct overloads : overloads {
std::decay_t func;
overloads(F1&& f1, F2&& f2, Fs&&... fs) :
overloads(std::move(f2), std::move(fs)...),
func(std::move(f1))
{}
using overloads::operator(); // <- problem at this line
template
decltype(auto) operator()(A&&... args)
requires (requires{{func(std::forward(args)...)};})
{
return (func(std::forward(args)...));
}
};
template
overloads(Fs...) -> overloads;
int main() {
overloads func {
[](int x) { return 0; },
[](const char* y) { return 1; }
};
std::cout << func(1) << "\n";
std::cout << func("abc") << "\n";
}
```
Previous versions of Clang (tested back to 10.0.0 via compiler explorer) and all versions of GCC 10.1+ compile and run just fine, but Clang 17.0.1 and beyond produces the following error:
```
Stack dump:
0. Program arguments: /opt/compiler-explorer/clang-17.0.1/bin/clang-17 -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -dumpdir /app/output.s- -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name example.cpp -mrelocation-model pic -pic-level 2 -pic-is-pie -mframe-pointer=all -fmath-errno -ffp-contract=on -fno-rounding-math -fno-verbose-asm -mconstructor-aliases -funwind-tables=2 -target-cpu x86-64 -tune-cpu generic -debug-info-kind=constructor -dwarf-version=4 -debugger-tuning=gdb -fcoverage-compilation-dir=/app -resource-dir /opt/compiler-explorer/clang-17.0.1/lib/clang/17 -internal-isystem /opt/compiler-explorer/gcc-13.2.0/lib/gcc/x86_64-linux-gnu/13.2.0/../../../../include/c++/13.2.0 -internal-isystem /opt/compiler-explorer/gcc-13.2.0/lib/gcc/x86_64-linux-gnu/13.2.0/../../../../include/c++/13.2.0/x86_64-linux-gnu -internal-isystem /opt/compiler-explorer/gcc-13.2.0/lib/gcc/x86_64-linux-gnu/13.2.0/../../../../include/c++/13.2.0/backward -internal-isystem /opt/compiler-explorer/clang-17.0.1/lib/clang/17/include -internal-isystem /usr/local/include -internal-isystem /opt/compiler-explorer/gcc-13.2.0/lib/gcc/x86_64-linux-gnu/13.2.0/../../../../x86_64-linux-gnu/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -std=c++20 -fdeprecated-macro -fdebug-compilation-dir=/app -ferror-limit 19 -fgnuc-version=4.2.1 -fno-implicit-modules -fcxx-exceptions -fexceptions -fcolor-diagnostics -faddrsig -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o /tmp/example-363665.o -x c++
1. :48:6: current parser token ';'
2. :44:12: parsing function body 'main'
3. :44:12: in compound statement ('{}')
4. :6:8: instantiating class definition 'overloads<(lambda at :46:9), (lambda at :47:9)>'
#0 0x03349f18 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-17.0.1/bin/clang-17+0x3349f18)
#1 0x03347adc SignalHandler(int) Signals.cpp:0:0
#2 0x767963442520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#3 0x0643acd0 clang::Sema::CheckParameterPacksForExpansion(clang::SourceLocation, clang::SourceRange, llvm::ArrayRef, clang::SourceLocation>>, clang::MultiLevelTemplateArgumentList const&, bool&, bool&, std::optional&) (/opt/compiler-explorer/clang-17.0.1/bin/clang-17+0x643acd0)
#4 0x063aaf58 clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformExprs(clang::Expr* const*, unsigned int, bool, llvm::SmallVectorImpl&, bool*) SemaTemplateInstantiate.cpp:0:0
#5 0x063b2afc clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformCallExpr(clang::CallExpr*) SemaTemplateInstantiate.cpp:0:0
#6 0x063a9f86 clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformExpr(clang::Expr*) SemaTemplateInstantiate.cpp:0:0
#7 0x063ce908 clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformRequiresExpr(clang::RequiresExpr*) SemaTemplateInstantiate.cpp:0:0
#8 0x063a975e clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformExpr(clang::Expr*) SemaTemplateInstantiate.cpp:0:0
#9 0x063b4d65 clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformParenExpr(clang::ParenExpr*) SemaTemplateInstantiate.cpp:0:0
#10 0x
[llvm-bugs] [Bug 146528] Weird behavior of padding of `-target-abi experimental-mv`
Issue
146528
Summary
Weird behavior of padding of `-target-abi experimental-mv`
Labels
new issue
Assignees
Reporter
yhx-12243
When compiling WebAssembly using `-target-abi experimental-mv`, the struct with padding will result in a very weird padding result: Use a lot of `i32` to waste with. For example:
`1.cpp`:
```cpp
struct Unit {};
struct A {
int x;
Unit c;
};
A foo() {
return {};
}
```
Compiling command: `clang++ 1.cpp -S -O3 --target=wasm32-unknown-unknown -Xclang -target-abi -Xclang experimental-mv`
Result `1.s`:
```wat
.file "1.cpp"
.functype _Z3foov () -> (i32, i32, i32, i32, i32)
.section .text._Z3foov,"",@
.hidden _Z3foov # -- Begin function _Z3foov
.globl _Z3foov
.type _Z3foov,@function
_Z3foov: # @_Z3foov
.functype _Z3foov () -> (i32, i32, i32, i32, i32)
.local i32
# %bb.0:
i32.const 0
local.get 0
local.get 0
local.get 0
local.get 0
# fallthrough-return
end_function
# -- End function
```
However, if I change `Unit` into `char`, the behavior is as we expected.
I think it is a bug of experimental-mv ABI.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146537] [AVR] Linking produces wrong startup code for xmega3 devices
Issue 146537 Summary [AVR] Linking produces wrong startup code for xmega3 devices Labels new issue Assignees Reporter tomtor script: ``` L=/home/tom/.arduino15/packages/arduino/tools/avr-gcc/7.3.0-atmel3.6.1-arduino7/lib/gcc/avr/7.3.0 LXM3=$L/avrxmega3 LTINY=$L/avr25 clang -L$LXM3 -Os -target avr-none -mmcu=attiny402 bad_copy_data.c -o bad.out clang -L$LTINY -Os -target avr-none -mmcu=attiny84 bad_copy_data.c -o good.out ``` `good.out` for the `attiny84` is OK, but `bad.out` for the `attiny402` has the following code fragment: ``` 0040 <__do_copy_data>: 40: 1f e3 ldi r17, 0x3F ; 63 42: a0 e0 ldi r26, 0x00 ; 0 44: bf e3 ldi r27, 0x3F ; 63 46: e9 ec ldi r30, 0xC9 ; 201 48: f0 e0 ldi r31, 0x00 ; 0 4a: 02 c0 rjmp.+4 ; 0x50 <.Lname11> 4c: 05 90 lpm r0, Z+ 4e: 0d 92 st X+, r0 50: a0 30 cpi r26, 0x00 ; 0 52: b1 07 cpc r27, r17 54: d9 f7 brne.-10; 0x4c <.Lname10+0x2> ``` This loop from the CRT tries to copy 0 bytes (because RO data is mapped in the RAM space at 0x8000) and this test: ` 50: a0 30 cpi r26, 0x00 ; 0` fails because `X` has been already incremented in the previous line, so it will copy 0x1 bytes overwriting the complete IO region and all RAM. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146541] [BOLT][AArch64] unable to run BOLT on libffi
Issue 146541 Summary [BOLT][AArch64] unable to run BOLT on libffi Labels BOLT Assignees Reporter geofft We originally ran into this building CPython for python-build-standalone, but here's a minimal reproducer: ``` ubuntu@ubuntu:~/libffi-3.5.1$ ./configure CFLAGS=-Wl,-emit-relocs ubuntu@ubuntu:~/libffi-3.5.1$ make -j8 ubuntu@ubuntu:~/libffi-3.5.1$ llvm-bolt-21 aarch64-unknown-linux-gnu/.libs/libffi.so.8.2.0 -o=foo BOLT-INFO: shared object or position-independent executable detected BOLT-INFO: Target architecture: aarch64 BOLT-INFO: BOLT version: BOLT-INFO: first alloc address is 0x0 BOLT-INFO: creating new program header table at address 0x20, offset 0x20 BOLT-INFO: enabling relocation mode BOLT-WARNING: function ffi_go_closure_SYSV/1 has an object detected in a padding region at address 0x18048 BOLT-WARNING: function __clear_cache/1 has an object detected in a padding region at address 0x18068 BOLT-WARNING: 1 collisions detected while hashing binary objects. Use -v=1 to see the list. BOLT-INFO: number of removed linker-inserted veneers: 0 BOLT-INFO: 0 out of 134 functions in the binary (0.0%) have non-empty execution profile BOLT-INFO: removed 17 empty blocks BOLT-ERROR: cannot relax ADR in non-simple function trampoline_code_table/1 ``` This is with https://github.com/libffi/libffi/releases/download/v3.5.1/libffi-3.5.1.tar.gz, Ubuntu Plucky, and the the current version from apt.llvm.org (bolt-21=1:21~++20250630095742+59a7185dd9d6-1~exp1~20250630215911.150). I think this is because [trampoline_code_table is defined as hand-written assembly](https://github.com/libffi/libffi/blob/v3.5.1/src/aarch64/sysv.S#L580) that does an `adr` and has no `nop`s for BOLT to work with. A naive attempt at throwing some extra `nop`s into that function gave a worse failure, which I guess makes sense because it's loading some PC-relative addresses and I surely got those addresses wrong. But also it would be cool to be able to run BOLT without requiring changes in third-party code. FWIW I think I would be happy leaving this un-optimized, if that's an option, but the `adr` relaxation pass looks unconditional and it seems to error out instead of skipping optimizing this one function. I don't totally understand whether this pass really needs to be mandatory. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146542] [BUG][RISCV][BOLT] Incorrect GOT Relocation Handling in some case
Issue 146542 Summary [BUG][RISCV][BOLT] Incorrect GOT Relocation Handling in some case Labels BOLT Assignees Reporter dinyy I use the newest version clang and gcc(main branch ) to complie mysql-8.0.33. And bolt failed to deal with mysql. When I run this command: > llvm-bolt mysqld -o mysqld.test It occuers that： > Segmentation fault After use gdb to debug , I found that R_RISCV_GOT_HI20 Relocation Handling failed . Bolt think when occur GOT relocation infomation , always find 2 instruction to get imm, and transform the symbole to __BOLT_got_zero + offset , the code is in `bolt\lib\Core\BinaryFunction.cpp` and `bolt\lib\Core\Relocation.cpp.` To deal with this case: > 2242d12: 01620797auipc a5,0x1620 2242d12: R_RISCV_GOT_HI20 _ITM_deregisterTMCloneTable 2242d12: R_RISCV_RELAX *ABS* 2242d16: 7de7b783ld a5,2014(a5) # 38634f0 <_ITM_deregisterTMCloneTable@Base> but the mysqld binary which is compiled by newest clang and gcc , will occur this case: > 02244c08 <.Lpcrel_hi153>: 2244c08: 01621617auipc a2,0x1621 2244c08: R_RISCV_GOT_HI20 connection_events_loop_aborted_flag 2244c0c: 66a1**lui a3,0x8** 02244c0e <.Lpcrel_hi154>: 2244c0e: 01621717auipc a4,0x1621 2244c0e: R_RISCV_GOT_HI20 log_output_options 02244c12 <.Lpcrel_hi155>: 2244c12: 01621797auipc a5,0x1621 2244c12: R_RISCV_GOT_HI20 query_logger 2244c16: f2a50b93addis7,a0,-214 # 3c09b28 <.L_MergedGlobals.1012> 2244c16: R_RISCV_PCREL_LO12_I .Lpcrel_hi151 2244c16: R_RISCV_RELAX *ABS* 2244c1a: d2458d93addis11,a1,-732 # fb9928 <.LJTI30_0> 2244c1a: R_RISCV_PCREL_LO12_I .Lpcrel_hi152 2244c1a: R_RISCV_RELAX *ABS* I try to fix it by find auipc+ld pattern when the relocation is about GOT in `bolt\lib\Core\BinaryFunction.cpp` ，but failed. Now I need some help to fix this bug. Could someone help me? And I want to use `bolt/utils/bughunter.sh` on RISCV , but failed. It couldn't work because `createRelocation` and `encodeValueRISCV` not implemented. Are there any way to trace the bug？ ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146629] [mlir][support] Operation::getRawDictionaryAttrs return value that does not meet expectations
Issue
146629
Summary
[mlir][support] Operation::getRawDictionaryAttrs return value that does not meet expectations
Labels
bug
Assignees
Reporter
lipracer
When I wanted to obtain a list of attributes from `Operation` that were declared in the same order as the tbgen file, I found this method defined in `Operation.h:509 getRawDictionaryAttrs `, but this method returns an empty list. Here is a simple test:
```
constexpr char ir[] = R"(
func.func @test_unary_f32(%arg0 : tensor<4xf32>) -> () {
%2 = tosa.clamp %arg0 { min_val = 0.0 : f32, max_val = 10.0 : f32 } : (tensor<4xf32>) -> tensor<*xf32>
return
}
)";
TEST(OperationAttribueTest, getRawDictionaryAttrs) {
MLIRContext context;
context.getOrLoadDialect();
context.getOrLoadDialect();
auto module =
mlir::parseSourceString(ir, mlir::ParserConfig{&context});
auto clampOp =
&module->getBodyRegion().front().front().getRegion(0).front().front();
clampOp->dump();
llvm::errs() << clampOp->getRawDictionaryAttrs() << "\n";
}
```
and test output:
```
%0 = tosa.clamp %arg0 { min_val = 0.0 : f32, max_val = 10.0 : f32 } : (tensor<4xf32>) -> tensor<*xf32>
{}
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146631] Internal compiler error while cross-compiling LLVM 20.1.5 with GCC 8.1.0
Issue
146631
Summary
Internal compiler error while cross-compiling LLVM 20.1.5 with GCC 8.1.0
Labels
new issue
Assignees
Reporter
Sangeetha-E
While cross-compiling LLVM 20.1.5 using GCC 8.1.0, I am encountering the following issues:
Initial Error:
```
llvm-20.1.5.src/lib/Support/APFloat.cpp:130:61: error: 'const llvm::fltSemantics{15, -14, 11, 16, IEEE754, IEEE, true, true}' is not a constant _expression_
static constexpr fltSemantics semIEEEhalf = {15, -14, 11, 16};
```
Reference Fix Applied:
I followed the suggestion in this GitHub issue:
https://github.com/llvm/llvm-project/issues/81013#issue-2123529849
Subsequent Error After Applying Fix:
```
llvm-20.1.5.src/lib/Analysis/CtxProfAnalysis.cpp:233:5: internal compiler error: in tsubst_decomp_names, at cp/pt.c:16535
for (auto &[_, SubCtxSet] : Ctx.callsites())
```
Note:
- These issues occur when using GCC 8.1.0.
- When I compile LLVM 20.1.5 with GCC 13, the build completes successfully.
- This suggests that newer versions of LLVM (including 20.1.5) may require GCC >= 13 for successful compilation.
Request:
Please confirm:
- Whether LLVM 20.1.5 officially requires GCC 13 or later.
- Are there any known workarounds to build LLVM 20.1.5 with GCC 8.x?
Thank you.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146621] [DebugInfo][LICM] Debug value loss caused by hoisting the cmp instructions
Issue 146621 Summary [DebugInfo][LICM] Debug value loss caused by hoisting the cmp instructions Labels loopoptim, debuginfo, llvm:transforms Assignees Reporter Apochens In the function `hoistMinMax()` in LICM, after replacing the comparisons in loop with the hoisted compared result, the optimization erases the replaced comparison (i.e., `Cond1` and `Cond2` in the following code, which are the two operands of the logical operation instruction `I`) without salvaging the debug values. https://github.com/llvm/llvm-project/blob/2599a9aeb543f01cb20e3fdc2713aa8c8cb20fbf/llvm/lib/Transforms/Scalar/LICM.cpp#L2491-L2494 **Here is an example:** https://godbolt.org/z/M38xhTY3a ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146496] [feat] clang-tidy to output auditable information (per-file enabled/disabled checks)
Issue 146496 Summary [feat] clang-tidy to output auditable information (per-file enabled/disabled checks) Labels clang-tidy Assignees Reporter elupus When auditing a software release, it would be good to be able to see a log file from clang-tidy with actual enabled checks (per-file) as well as possible suppressed check inlined in source. It is possible to run clang-tidy with --list-checks or --dump-config as a separate invocation. But having this type of output possible aughmented with "in-file" suppressions would be very usefull. Also listing disabled checks would be useful. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146508] Clanf SISEGV in addAssociatedClassesAndNamespaces since clang 9.0
Issue 146508 Summary Clanf SISEGV in addAssociatedClassesAndNamespaces since clang 9.0 Labels clang Assignees Reporter mariete1223 I have not been able to reduce it more. The original version without reducing gave the error addAssociatedClassesAndNamespaces((anonymous namespace)::AssociatedLookup&, clang::QualType) SemaLookup.cpp:0:0, repeatedly until stack exhaustion, the reduced one does not seem to give any feedback, so both versions will be posted. ## Stack dump: ``` #0 0x5c1e0215318f llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/usr/local/bin/clang-21+0x3c4a18f) #1 0x5c1e02150bd4 SignalHandler(int, siginfo_t*, void*) Signals.cpp:0:0 #2 0x723f94a83420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420) #3 0x5c1e04ab0330 addAssociatedClassesAndNamespaces((anonymous namespace)::AssociatedLookup&, clang::QualType) SemaLookup.cpp:0:0 #4 0x5c1e04ab2eea addAssociatedClassesAndNamespaces((anonymous namespace)::AssociatedLookup&, clang::TemplateArgument const&) SemaLookup.cpp:0:0 #5 0x5c1e04ab2f38 addAssociatedClassesAndNamespaces((anonymous namespace)::AssociatedLookup&, clang::TemplateArgument const&) SemaLookup.cpp:0:0 #6 0x5c1e04ab08bf addAssociatedClassesAndNamespaces((anonymous namespace)::AssociatedLookup&, clang::QualType) SemaLookup.cpp:0:0 #7 0x5c1e04ab2eea addAssociatedClassesAndNamespaces((anonymous namespace)::AssociatedLookup&, clang::TemplateArgument const&) SemaLookup.cpp:0:0 #8 0x5c1e04ab2f38 addAssociatedClassesAndNamespaces((anonymous namespace)::AssociatedLookup&, clang::TemplateArgument const&) SemaLookup.cpp:0:0 #9 0x5c1e04ab08bf addAssociatedClassesAndNamespaces((anonymous namespace)::AssociatedLookup&, clang::QualType) SemaLookup.cpp:0:0 #10 0x5c1e04ab2eea addAssociatedClassesAndNamespaces((anonymous namespace)::AssociatedLookup&, clang::TemplateArgument const&) SemaLookup.cpp:0:0 #11 0x5c1e04ab2f38 addAssociatedClassesAndNamespaces((anonymous namespace)::AssociatedLookup&, clang::TemplateArgument const&) SemaLookup.cpp:0:0 #12 0x5c1e04ab08bf addAssociatedClassesAndNamespaces((anonymous namespace)::AssociatedLookup&, clang::QualType) SemaLookup.cpp:0:0 #13 0x5c1e04ab2eea addAssociatedClassesAndNamespaces((anonymous namespace)::AssociatedLookup&, clang::TemplateArgument const&) SemaLookup.cpp:0:0 #14 0x5c1e04ab2f38 addAssociatedClassesAndNamespaces((anonymous namespace)::AssociatedLookup&, clang::TemplateArgument const&) SemaLookup.cpp:0:0 #15 0x5c1e04ab08bf addAssociatedClassesAndNamespaces((anonymous namespace)::AssociatedLookup&, clang::QualType) SemaLookup.cpp:0:0 #16 0x5c1e04ab2eea addAssociatedClassesAndNamespaces((anonymous namespace)::AssociatedLookup&, clang::TemplateArgument const&) SemaLookup.cpp:0:0 #17 0x5c1e04ab2f38 addAssociatedClassesAndNamespaces((anonymous namespace)::AssociatedLookup&, clang::TemplateArgument const&) SemaLookup.cpp:0:0 #18 0x5c1e04ab08bf addAssociatedClassesAndNamespaces((anonymous namespace)::AssociatedLookup&, clang::QualType) SemaLookup.cpp:0:0 #19 0x5c1e04ab2eea addAssociatedClassesAndNamespaces((anonymous namespace)::AssociatedLookup&, clang::TemplateArgument const&) SemaLookup.cpp:0:0 #20 0x5c1e04ab2f38 addAssociatedClassesAndNamespaces((anonymous namespace)::AssociatedLookup&, clang::TemplateArgument const&) SemaLookup.cpp:0:0 #21 0x5c1e04ab08bf addAssociatedClassesAndNamespaces((anonymous namespace)::AssociatedLookup&, clang::QualType) SemaLookup.cpp:0:0 #22 0x5c1e04ab2eea addAssociatedClassesAndNamespaces((anonymous namespace)::AssociatedLookup&, clang::TemplateArgument const&) SemaLookup.cpp:0:0 #23 0x5c1e04ab2f38 addAssociatedClassesAndNamespaces((anonymous namespace)::AssociatedLookup&, clang::TemplateArgument const&) SemaLookup.cpp:0:0 #24 0x5c1e04ab08bf addAssociatedClassesAndNamespaces((anonymous namespace)::AssociatedLookup&, clang::QualType) SemaLookup.cpp:0:0 #25 0x5c1e04ab2eea addAssociatedClassesAndNamespaces((anonymous namespace)::AssociatedLookup&, clang::TemplateArgument const&) SemaLookup.cpp:0:0 #26 0x5c1e04ab2f38 addAssociatedClassesAndNamespaces((anonymous namespace)::AssociatedLookup&, clang::TemplateArgument const&) SemaLookup.cpp:0:0 #27 0x5c1e04ab08bf addAssociatedClassesAndNamespaces((anonymous namespace)::AssociatedLookup&, clang::QualType) SemaLookup.cpp:0:0 #28 0x5c1e04ab2eea addAssociatedClassesAndNamespaces((anonymous namespace)::AssociatedLookup&, clang::TemplateArgument const&) SemaLookup.cpp:0:0 #29 0x5c1e04ab2f38 addAssociatedClassesAndNamespaces((anonymous namespace)::AssociatedLookup&, clang::TemplateArgument const&) SemaLookup.cpp:0:0 #30 0x5c1e04ab08bf addAssociatedClassesAndNamespaces((anonymous namespace)::Assoc
[llvm-bugs] [Bug 146512] [clang] ICE with large constexpr array of std::variant triggers LLVM ERROR: out of memory
Issue 146512 Summary [clang] ICE with large constexpr array of std::variant triggers LLVM ERROR: out of memory Labels clang Assignees Reporter mariete1223 When defining a very large array of std::variant elements as a constexpr local variable, Clang triggers an internal failure: ## Stack dump ``` Stack dump: 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 -x c++ 1. parser at end of file 2. :2:12: parsing function body 'main' #0 0x03f78848 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x3f78848) #1 0x03f764d4 llvm::sys::CleanupOnSignal(unsigned long) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x3f764d4) #2 0x03ebb048 CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0 #3 0x79f5a0c42520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520) #4 0x79f5a0c969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc) #5 0x79f5a0c42476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476) #6 0x79f5a0c287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3) #7 0x03ec685b (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x3ec685b) #8 0x03ec6875 (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x3ec6875) #9 0x79f5a10ae9a3 operator new(unsigned long) (/lib/x86_64-linux-gnu/libstdc++.so.6+0xae9a3) #10 0x0748b1dc clang::APValue::MakeArray(unsigned int, unsigned int) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x748b1dc) #11 0x078a4205 (anonymous namespace)::ArrayExprEvaluator::VisitCXXConstructExpr(clang::CXXConstructExpr const*, (anonymous namespace)::LValue const&, clang::APValue*, clang::QualType) ExprConstant.cpp:0:0 #12 0x078a69fd clang::StmtVisitorBase::Visit(clang::Stmt const*) ExprConstant.cpp:0:0 #13 0x078a869d EvaluateArray(clang::Expr const*, (anonymous namespace)::LValue const&, clang::APValue&, (anonymous namespace)::EvalInfo&) ExprConstant.cpp:0:0 #14 0x0786a280 EvaluateInPlace(clang::APValue&, (anonymous namespace)::EvalInfo&, (anonymous namespace)::LValue const&, clang::Expr const*, bool) (.part.0) ExprConstant.cpp:0:0 #15 0x078ad3c1 clang::Expr::EvaluateAsInitializer(clang::APValue&, clang::ASTContext const&, clang::VarDecl const*, llvm::SmallVectorImpl>&, bool) const (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x78ad3c1) #16 0x076cad42 clang::VarDecl::evaluateValueImpl(llvm::SmallVectorImpl>&, bool) const (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x76cad42) #17 0x076caeba clang::VarDecl::evaluateValue() const (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x76caeba) #18 0x069d1249 clang::Sema::DiagnoseUnusedDecl(clang::NamedDecl const*, llvm::function_ref) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x69d1249) #19 0x069d2d0d clang::Sema::ActOnPopScope(clang::SourceLocation, clang::Scope*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x69d2d0d) #20 0x06625815 clang::Parser::ExitScope() (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6625815) #21 0x0673b351 clang::Parser::ParseFunctionStatementBody(clang::Decl*, clang::Parser::ParseScope&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x673b351) #22 0x06633bd3 clang::Parser::ParseFunctionDefinition(clang::ParsingDeclarator&, clang::Parser::ParsedTemplateInfo const&, clang::Parser::LateParsedAttrList*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6633bd3) #23 0x0666987d clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, clang::DeclaratorContext, clang::ParsedAttributes&, clang::Parser::ParsedTemplateInfo&, clang::SourceLocation*, clang::Parser::ForRangeInit*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x666987d) #24 0x066276be clang::Parser::ParseDeclOrFunctionDefInternal(clang::ParsedAttributes&, clang::ParsedAttributes&, clang::ParsingDeclSpec&, clang::AccessSpecifier) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x66276be) #25 0x06627e69 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::ParsedAttributes&, clang::ParsedAttributes&, clang::ParsingDeclSpec*, clang::AccessSpecifier) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6627e69) #26 0x0662f7aa clang::Parser::ParseExternalDeclaration(clang::ParsedAttributes&, clang::ParsedAttributes&, clang::ParsingDeclSpec*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x662f7aa) #27 0x0663077d c
[llvm-bugs] [Bug 146518] [RISCV] Crash on pass RISCVInsertVSETVLI
Issue 146518 Summary [RISCV] Crash on pass RISCVInsertVSETVLI Labels new issue Assignees Reporter sc-clulzze `Assertion `I->containsInterval(Start, End) && "Segment is not entirely in range!"' failed.` Godbolt example - https://godbolt.org/z/GxTb5Grdd Looking at backtace, problem is inside RISCVInsertVSETVLI pass, issue reproduced on ToT ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146519] [clang-tidy] Remove redundant comparison operators
Issue 146519 Summary [clang-tidy] Remove redundant comparison operators Labels clang-tidy Assignees Reporter SunBlack Since C++20 rewriting rules exists, so that it is e.g. not anymore necessary to define `operator!=` when `operator==` already exists. I hope that the compilers will optimize accordingly, so that the rewrite rule is always as fast as the manual rule (as an example: If there used to be `a!=b` and `a==b` and you remove the former rule, that the compiler does not make `!(a==b)` out of it, i.e. 2 assemler instructions instead of one). SonarLint already have a [check](https://rules.sonarsource.com/cpp/RSPEC-6186/) for this, so that you could spot what could also be adjusted. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146520] gnu::cleanup can call gnu::error function
Issue
146520
Summary
gnu::cleanup can call gnu::error function
Labels
Assignees
Reporter
xB
clang compiles this with no error:
```c
[[gnu::error("error please")]]
void cleaner_function(char*);
void asdf(void){
[[gnu::cleanup(cleaner_function)]]
char x;
}
```
clang is x86_64 20.1.7 downloaded from https://mirrors.edge.kernel.org/pub/tools/llvm/
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146523] [lldb] Add pretty printers for flat_* containers
Issue 146523 Summary [lldb] Add pretty printers for flat_* containers Labels lldb Assignees Reporter philnik777 lldb has pretty printers for the associative and unordered containers, but currently not for the flat_* container adaptors. It would be nice if they could also be formatted properly. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146482] [clang-tidy] clang-analyzer-* checks should be disabled by default
Issue 146482 Summary [clang-tidy] clang-analyzer-* checks should be disabled by default Labels clang-tidy Assignees Reporter carlosgalvezp Currently, `clang-analyzer-*` checks are enabled by default. They are not special compared to other checks, so I see no reason why they should have special treatment. They are also heavier than most regular checks so there's a hidden performance penalty by default. Also, it leads to clang-tidy running silently when no checks are requested. It's better to fail early and tell people that they must explicitly request checks of their choice for clang-tidy to work. Otherwise people may think they have enabled checks, but they haven't. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146483] [Integer division]Optimization missed in looped division
Issue
146483
Summary
[Integer division]Optimization missed in looped division
Labels
new issue
Assignees
Reporter
bionukg
I learned that, for any `uint32_t i`, `i/3` is equivalent to `(uint64_t(i)*0xAAAB)>>33`. This is how modern compilers typically optimize integer division by constants.
To verify this equivalence, I've written the following code:
```cpp
#include
#include
#include
//[[gnu::noinline]]
uint32_t div3_v0(uint32_t a) { return a / 3; }
//[[gnu::noinline]]
uint32_t div3_v1(uint32_t a) { return (static_cast(a) * 0xAAAB) >> 33; }
uint64_t test0()
{
uint64_t res0 = 0;
for (uint64_t i = 0; i <= 0x'; ++i)
{
res0 += div3_v0(i);
}
return res0;
}
uint64_t test1()
{
uint64_t res1 = 0;
for (uint64_t i = 0; i <= 0x'; ++i)
{
res1 += div3_v1(i);
}
return res1;
}
int main()
{
// Iterate through all possible uint32_t values
for (uint64_t i = 0; i <= 0x'; ++i)
{
// Calculate result using regular division
uint32_t division_result = div3_v0(i);
// Calculate result using multiplication and right shift
uint32_t multiplication_shift_result = div3_v1(i);
// Verify if both results are equal
if (division_result != multiplication_shift_result)
{
std::cout << "i = " << i << std::endl;
std::cout << "i/3 = " << division_result << std::endl;
std::cout << "(uint64_t(i)*0xAAAB)>>33 = " << multiplication_shift_result << std::endl;
return 1;
}
}
std::cout << "for all i in uint32_t, i / 3 == (uint64_t(i)*0xAAAB)>>33" << std::endl;
// Test time cost
auto tp0 = std::chrono::high_resolution_clock::now();
uint64_t res0 = test0();
auto tp1 = std::chrono::high_resolution_clock::now();
auto tp2 = std::chrono::high_resolution_clock::now();
uint64_t res1 = test1();
auto tp3 = std::chrono::high_resolution_clock::now();
std::cout << "res0 = " << res0 << std::endl;
std::cout << "res1 = " << res1 << std::endl;
std::cout << "duration0 = " << std::chrono::duration_cast(tp1 - tp0).count() << " ms" << std::endl;
std::cout << "duration1 = " << std::chrono::duration_cast(tp3 - tp2).count() << " ms" << std::endl;
return 0;
}
```
When compiled with `-O3` on my system, the output is:
```
for all i in uint32_t, i / 3 == (uint64_t(i)*0xAAAB)>>33
res0 = 3074457343470774955
res1 = 3074457343470774955
duration0 = 1514 ms
duration1 = 1095 ms
```
The performance discrepancy between `duration0` and `duration1` is unexpected, as both functions should theoretically be optimized to the same machine code.
Upon examining the generated assembly code, I noticed that in `test1`, the multiplication `static_cast(i) * 0xAAAB` has undergone strength reduction optimization and been converted into a sequence of addition operations. However, in `test0`, while the division was optimized into a multiplication, the subsequent multiplication was not further optimized into addition operations. This appears to be a missed optimization opportunity.
Additionally, even though `div3_v0` and `div3_v1` produce identical assembly code, they are treated as distinct functions with separate memory addresses. This is another missed optimization, as the compiler should recognize their semantic equivalence and merge them.
Compilation command used: `clang++ -march=x86-64 -O3 -g -mno-sse -mno-avx -mno-avx512f`
This issue can be reproduced with the following compilers:
1. `x86-64 clang 20.1.0` on `godbolt.org`
2. On my WSL environment:
```
Ubuntu clang version 19.1.7 (++20250114103320+cd708029e0b2-1~exp1~20250114103432.75)
Target: x86_64-pc-linux-gnu
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146477] [CMake] Missing documentation for LLVM_ENABLE_LIBEDIT
Issue 146477 Summary [CMake] Missing documentation for LLVM_ENABLE_LIBEDIT Labels documentation, good first issue, cmake Assignees Reporter yashssh There is no mention of LLVM_ENABLE_LIBEDIT flag on https://llvm.org/docs/CMake.html Need documentation around the use of the flag and supported values. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146484] Efficient memcpy when src or dest can be nullptr
Issue 146484 Summary Efficient memcpy when src or dest can be nullptr Labels new issue Assignees Reporter QrczakMK How to obtain efficient `memcpy()` when src or dest can be `nullptr` (when the size is 0)? `memcpy(_, nullptr, 0)` and `memcpy(nullptr, _, 0)` have UB according to C and C++ standards, except that https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3322.pdf has been accepted for the next C standard; I could find nothing for C++. GCC makes use of that UB, e.g. by skipping explicit `nullptr` checks after `memcpy()`. Clang does not. Sanitizers are consistent with that. In GCC, `__builtin_memcpy()` behaves like `memcpy()` in this respect, i.e. does not allow `nullptr`. This suggests that portable code (at least including GCC) one should not blindly issue `memcpy()` nor `__builtin_memcpy()` if null pointers are possible. According to https://github.com/llvm/llvm-project/issues/49459, `llvm.memcpy` is safe to call with some null pointers and zero size, but I could not find a documentation that `__builtin_memcpy()` has this property too. The issue concludes with 'I think we can safely close this, with the answer being "yes, you can pass null pointer arguments"', but I feel uneasy relying on that comment without a more official documentation. Clang nor GCC do not optimize portable `if (len != 0) memcpy(dest, src, len)` to a plain call to `memcpy()`, even though Clang could if it indeed assumes that actual `memcpy()` in the runtime library is valid with some null pointers and zero size. Explicit zero checks slow down my implementation of joining a bunch of string_views by 14%. What should I do, so that this is efficient at least on Clang? In practice using `__builtin_memcpy()` or even `memcpy()` inside `#ifdef __clang__` should work, but I would like to have a more official guarantee that this must work. And perhaps this requires some version check if the behavior changed in Clang in the past. The same applies to `memset()`. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146506] Clang ICEs in SemaTemplateDeduction.cpp since version 4.0
Issue
146506
Summary
Clang ICEs in SemaTemplateDeduction.cpp since version 4.0
Labels
clang
Assignees
Reporter
mariete1223
## Assertion
```
clang++: /root/llvm-project/llvm/tools/clang/lib/Sema/SemaTemplateDeduction.cpp:868: unsigned int {anonymous}::PackDeductionScope::addPacks(clang::TemplateArgument): Assertion `!Packs.empty() && "Pack expansion without unexpanded packs?"' failed.
```
## Stack dump
```
Stack dump:
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 -x c++
1. :10:5: current parser token '{'
2. :4:1: parsing struct/union/class body 'remove_separators<>'
#0 0x03f78848 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x3f78848)
#1 0x03f764d4 llvm::sys::CleanupOnSignal(unsigned long) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x3f764d4)
#2 0x03ebb048 CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0
#3 0x710809a42520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#4 0x710809a969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
#5 0x710809a42476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
#6 0x710809a287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
#7 0x710809a2871b (/lib/x86_64-linux-gnu/libc.so.6+0x2871b)
#8 0x710809a39e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96)
#9 0x0709d351 (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x709d351)
#10 0x0709ddb9 DeduceTemplateSpecArguments(clang::Sema&, clang::TemplateParameterList*, clang::QualType, clang::QualType, clang::sema::TemplateDeductionInfo&, bool, llvm::SmallVectorImpl&, bool*) SemaTemplateDeduction.cpp:0:0
#11 0x07097ddb DeduceTemplateArgumentsByTypeMatch(clang::Sema&, clang::TemplateParameterList*, clang::QualType, clang::QualType, clang::sema::TemplateDeductionInfo&, llvm::SmallVectorImpl&, unsigned int, PartialOrderingKind, bool, bool*) SemaTemplateDeduction.cpp:0:0
#12 0x070a0d05 clang::ClassTemplatePartialSpecializationDecl* getMoreSpecialized(clang::Sema&, clang::QualType, clang::QualType, clang::ClassTemplatePartialSpecializationDecl*, clang::ClassTemplateDecl*, clang::sema::TemplateDeductionInfo&) SemaTemplateDeduction.cpp:0:0
#13 0x070a1551 clang::Sema::isMoreSpecializedThanPrimary(clang::ClassTemplatePartialSpecializationDecl*, clang::sema::TemplateDeductionInfo&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x70a1551)
#14 0x06fe265d void checkTemplatePartialSpecialization(clang::Sema&, clang::ClassTemplatePartialSpecializationDecl*) SemaTemplate.cpp:0:0
#15 0x070129d1 clang::Sema::ActOnClassTemplateSpecialization(clang::Scope*, unsigned int, clang::TagUseKind, clang::SourceLocation, clang::SourceLocation, clang::CXXScopeSpec&, clang::TemplateIdAnnotation&, clang::ParsedAttributesView const&, llvm::MutableArrayRef, clang::SkipBodyInfo*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x70129d1)
#16 0x06696aab clang::Parser::ParseClassSpecifier(clang::tok::TokenKind, clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo&, clang::AccessSpecifier, bool, clang::Parser::DeclSpecContext, clang::ParsedAttributes&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6696aab)
#17 0x0666b4e0 clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&, clang::Parser::ParsedTemplateInfo&, clang::AccessSpecifier, clang::Parser::DeclSpecContext, clang::Parser::LateParsedAttrList*, clang::ImplicitTypenameContext) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x666b4e0)
#18 0x06690ba1 clang::Parser::ParseCXXClassMemberDeclaration(clang::AccessSpecifier, clang::ParsedAttributes&, clang::Parser::ParsedTemplateInfo&, clang::ParsingDeclRAIIObject*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6690ba1)
#19 0x067470a5 clang::Parser::ParseDeclarationAfterTemplate(clang::DeclaratorContext, clang::Parser::ParsedTemplateInfo&, clang::ParsingDeclRAIIObject&, clang::SourceLocation&, clang::ParsedAttributes&, clang::AccessSpecifier) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x67470a5)
#20 0x0675492f clang::Parser::ParseTemplateDeclarationOrSpecialization(clang::DeclaratorContext, clang::SourceLocation&, clang::ParsedAttributes&, clang::AccessSpecifier) (.part.0) ParseTemplate.cpp:0:0
#21 0x06690fed clang::Parser::ParseCXXClassMemberDeclaration(clang::AccessSpecifier, clang::ParsedAttributes&, clang::Parser::ParsedTemplateInfo&, clang::ParsingDeclRAIIObject*) (/opt/compi
[llvm-bugs] [Bug 146536] Clang breaks debuggers when using c++ modules
Issue 146536 Summary Clang breaks debuggers when using c++ modules Labels clang Assignees Reporter Yuria-Shikibe Toolchain: LLVM 20.1.7 + MSVC STL; (Both clang and clang-cl are tested) Build system: xmake; OS: Windows11; ## The formatted view is broken: （Tried both vsdbg and clion embedded LLDB 9.0) Using `#include `, formatted:   Using `import std`. broken:   Build System Log ``` [ 2%]: generating.module.deps src\main.cpp checking for D:\lib\LLVM\bin\clang-scan-deps.exe ... ok [ 2%]: generating.module.deps C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.44.35207\modules\std.ixx [ 2%]: generating.module.deps C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.44.35207\modules\std.compat.ixx D:\lib\LLVM\bin\clang-scan-deps.exe --format=p1689 -- D:\lib\LLVM\bin\clang.exe -x c++ -Qunused-arguments -m64 --target=x86_64-windows-msvc -fms-runtime-lib=dll_dbg -g -Wall -O0 -std=c++23 -fexceptions -fcxx-exceptions -finput-charset=UTF-8 -fexec-charset=UTF-8 -c src\main.cpp -o build\.objs\mo_yanxi\windows\x64\debug\src\main.cpp.obj D:\lib\LLVM\bin\clang-scan-deps.exe --format=p1689 -- D:\lib\LLVM\bin\clang.exe -x c++ -Qunused-arguments -m64 --target=x86_64-windows-msvc -fms-runtime-lib=dll_dbg -g -Wall -O0 -std=c++23 -fexceptions -fcxx-exceptions -finput-charset=UTF-8 -fexec-charset=UTF-8 -c "C:\\Program Files\\Microsoft Visual Studio\\2022\\Community\\VC\\Tools\\MSVC\\14.44.35207\\modules\\std.ixx" -o build\.objs\mo_yanxi\windows\x64\debug\a609f1d98a904a32bb8edcee0d1c8530\std.ixx.obj D:\lib\LLVM\bin\clang-scan-deps.exe --format=p1689 -- D:\lib\LLVM\bin\clang.exe -x c++ -Qunused-arguments -m64 --target=x86_64-windows-msvc -fms-runtime-lib=dll_dbg -g -Wall -O0 -std=c++23 -fexceptions -fcxx-exceptions -finput-charset=UTF-8 -fexec-charset=UTF-8 -c "C:\\Program Files\\Microsoft Visual Studio\\2022\\Community\\VC\\Tools\\MSVC\\14.44.35207\\modules\\std.compat.ixx" -o build\.objs\mo_yanxi\windows\x64\debug\a609f1d98a904a32bb8edcee0d1c8530\std.compat.ixx.obj checking for flags (clang_module_file) ... ok checking for flags (clang_module_output) ... ok [ 17%]: compiling.module.bmi.debug std D:\lib\LLVM\bin\clang.exe -c -Qunused-arguments -m64 --target=x86_64-windows-msvc -fms-runtime-lib=dll_dbg -g -Wall -O0 -std=c++23 -fexceptions -fcxx-exceptions -finput-charset=UTF-8 -fexec-charset=UTF-8 -x c++-module --precompile -Wno-include-angled-in-module-purview -Wno-reserved-module-identifier -Wno-deprecated-declarations -fmodule-output=build\.gens\mo_yanxi\windows\x64\debug\rules\bmi\cache\interfaces\5451787d\std.pcm -o build\.gens\mo_yanxi\windows\x64\debug\rules\bmi\cache\interfaces\5451787d\std.pcm "C:\\Program Files\\Microsoft Visual Studio\\2022\\Community\\VC\\Tools\\MSVC\\14.44.35207\\modules\\std.ixx" checking for flags (-fdiagnostics-color=always) ... ok checking for flags (-fansi-escape-codes) ... ok [ 25%]: compiling.debug C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.44.35207\modules\std.ixx D:\lib\LLVM\bin\clang.exe -c -Qunused-arguments -m64 --target=x86_64-windows-msvc -fms-runtime-lib=dll_dbg -g -Wall -O0 -std=c++23 -fexceptions -fcxx-exceptions -finput-charset=UTF-8 -fexec-charset=UTF-8 -x c++ -Wno-include-angled-in-module-purview -Wno-reserved-module-identifier -Wno-deprecated-declarations -o build\.objs\mo_yanxi\windows\x64\debug\a609f1d98a904a32bb8edcee0d1c8530\std.ixx.obj "C:\\Program Files\\Microsoft Visual Studio\\2022\\Community\\VC\\Tools\\MSVC\\14.44.35207\\modules\\std.ixx" [ 43%]: compiling.debug src\main.cpp D:\lib\LLVM\bin\clang.exe -c -Qunused-arguments -m64 --target=x86_64-windows-msvc -fms-runtime-lib=dll_dbg -g -Wall -O0 -std=c++23 -fexceptions -fcxx-exceptions -finput-charset=UTF-8 -fexec-charset=UTF-8 -fmodule-file=std=build\.gens\mo_yanxi\windows\x64\debug\rules\bmi\cache\interfaces\5451787d\std.pcm -o build\.objs\mo_yanxi\windows\x64\debug\src\main.cpp.obj src\main.cpp checking for flags (-MMD -MF) ... ok checking for D:\lib\LLVM\bin\clang++.exe ... ok checking for flags (clang_ms_runtime_lib) ... ok [ 60%]: linking.debug mo_yanxi.exe D:\lib\LLVM\bin\clang++.exe -o build\windows\x64\debug\mo_yanxi.exe build\.objs\mo_yanxi\windows\x64\debug\src\main.cpp.obj build\.objs\mo_yanxi\windows\x64\debug\a609f1d98a904a32bb8edcee0d1c8530\std.ixx.obj -m64 --target=x86_64-windows-msvc -nostdlib -g checking for clang ... D:\lib\LLVM\bin\clang.exe checkin
