[llvm-bugs] [Bug 123756] [llvm-mca][FeatureReques] In timeline graph, note source of delay for each instruction
Issue 123756 Summary [llvm-mca][FeatureReques] In timeline graph, note source of delay for each instruction Labels new issue Assignees Reporter ibogosavljevic Currently, the timeline graph looks like this: ``` Timeline view: 012345 Index 0123456789 [0,0] DeeER... vmulps %xmm0, %xmm1, %xmm2 [0,1] D==eeeER .. vhaddps %xmm2, %xmm2, %xmm3 [0,2] .DeeeER. vhaddps %xmm3, %xmm3, %xmm4 [1,0] .DeeE-R. vmulps %xmm0, %xmm1, %xmm2 [1,1] . D=eeeE---R . vhaddps %xmm2, %xmm2, %xmm3 [1,2] . DeeeER . vhaddps %xmm3, %xmm3, %xmm4 [2,0] . DeeE-R . vmulps %xmm0, %xmm1, %xmm2 [2,1] . DeeeER . vhaddps %xmm2, %xmm2, %xmm3 [2,2] . D==eeeER vhaddps %xmm3, %xmm3, %xmm4 ``` The value `=` means an instruction is dispatched but it cannot execute. There are two reasons why an instruction cannot execute: * It is waiting for data from some previous instruction (dependency) * It is waiting for available HW resource (resource pressure) Instead of using `=` for both reasons, consider using one character (e.g. `=`) for dependency stall, and another character (e.g. `_`) for resource pressure stall. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123760] Handling tied operands in RISCVVLOptimizer
Issue
123760
Summary
Handling tied operands in RISCVVLOptimizer
Labels
backend:RISC-V
Assignees
Reporter
lukel97
TL;DR: we can't express tail undefined with ternary pseudos
I've been exploring using RISCVVLOptimizer to reduce VL toggles with EVL tail folding. In some of the benchmarks we fail to reduce the AVL of a ternary instruction, causing a vl toggle e.g.:
```asm
vsetvli a4, zero, e32, m2, ta, ma
vsext.vf2 v14, v10
vsetvli zero, a1, e32, m2, ta, ma
vmadd.vvv14, v12, v8
```
Although we're able to reduce the AVL of the vmadd.vv itself, we can't reduce the AVL of the vsext.vf2 because its user, vmadd.vv, is a tied operand:
```
Trying to reduce VL for early-clobber %43:vrm2 = PseudoVSEXT_VF2_M2 $noreg(tied-
def 0), killed %42:vr, -1, 5, 3
Checking user: %49:vrm2 = nsw PseudoVMADD_VV_M2 %43:vrm2(tied-def 0), killed %
47:vrm2, %48:vrm2, %40:gprnox0, 5, 1
Abort because user used as tied operand
```
We don't allow users that are passthrus because the tail elements past `vl` will depend on them.
```c++
std::optional RISCVVLOptimizer::checkUsers(MachineInstr &MI) {
for (auto &UserOp : MRI->use_operands(MI.getOperand(0).getReg())) {
...
// Tied operands might pass through.
if (UserOp.isTied()) {
LLVM_DEBUG(dbgs() << "Abort because user used as tied operand\n");
return std::nullopt;
}
```
At first glance we might think that we can relax this restriction if the user's policy is ta/ma. However I don't think this is correct because tail agnostic/mask agnostic != tail undefined/mask undefined, so we still need to preserve the passthru to get "previous or -1" for each element.
I think the problem comes down to how for binary pseudos we represent tail undefined/mask undefined by using NoRegister for the passthru.
For ternary pseudos the third operand is simultaneously also the passthru, so it's not possible to represent a tail undefined/mask undefined pseudo with a non-undefined third operand.
This means that we lose the information that the inactive elements are undefined during instruction selection. One possible solution could be to add new _INACTIVE_UNDEF pseudos with a TSFlag that marks this fact, and use these for regular SDNode patterns. Then RISCVVLOptimizer (and RISCVInsertVSETVLI) could pick up the TSFlag and allow it as a user.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123761] expm1(x) is not folded at the compilation time when x is constant
Issue
123761
Summary
expm1(x) is not folded at the compilation time when x is constant
Labels
new issue
Assignees
Reporter
k-arrows
Consider the following C++ example. The function exp(x) is folded, but expm1(x) is not. I still don't have a good idea of how to list these kinds of issues exhaustively.
https://godbolt.org/z/ravEhEEqh
```cpp
#include
double f1() {
return std::exp(0.)-1.;
}
double f2() {
return std::expm1(0.);
}
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123763] SIGSEGV on getTypdefName on invalid type
Issue 123763 Summary SIGSEGV on getTypdefName on invalid type Labels new issue Assignees Reporter zokrezyl Hi, am getting the following SIGSEGV when using python clang.cindex, (libclang.so.19.1.7) with python 3.13.1. Am parsing a huge codebase, could not identify exactly the type/typedef context, but likely the exception(al) situation could be handled better in libclang. only context I can provide is ``` TypeKind.INVALID ``` while the type object is obviously "invalid", it is returned by one of the other methods on cursor or type. Other methods on this invalid type object do not cause sisgegv, so would expect this one also to return null/none or so. Thanks and Regards, Z ```* thread #1, name = 'python3', stop reason = signal SIGSEGV: address not mapped to object (fault address: 0x0) frame #0: 0x743dd043 libclang.so.19.1.7`clang_getTypedefName + 35 libclang.so.19.1.7`clang_getTypedefName: -> 0x743dd043 <+35>: movq (%rax), %rdi 0x743dd046 <+38>: callq 0x7481a360 ; clang::TypedefType const* clang::Type::getAs() const 0x743dd04b <+43>: testq %rax, %rax 0x743dd04e <+46>: je 0x743dd0b0 ; <+144> (lldb) bt * thread #1, name = 'python3', stop reason = signal SIGSEGV: address not mapped to object (fault address: 0x0) * frame #0: 0x743dd043 libclang.so.19.1.7`clang_getTypedefName + 35 frame #1: 0x77357056 libffi.so.8`ffi_call_unix64 + 86 frame #2: 0x77355af9 libffi.so.8`ffi_call_int + 489 frame #3: 0x77356363 libffi.so.8`ffi_call + 291 frame #4: 0x7736f473 _ctypes.cpython-313-x86_64-linux-gnu.so`_ctypes_callproc.cold + 751 frame #5: 0x773759e0 _ctypes.cpython-313-x86_64-linux-gnu.so`PyCFuncPtr_call + 336 ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123766] [Flang] Static initialization failure for CHARACTER type when `constant-expr` is impl-do
Issue 123766 Summary [Flang] Static initialization failure for CHARACTER type when `constant-expr` is impl-do Labels flang:frontend Assignees Reporter DanielCChen Consider the following code ``` PROGRAM InitExpCharOP IMPLICIT NONE INTEGER :: I CHARACTER(10), PARAMETER :: A(10)= '0123456789' CHARACTER(LEN=10, KIND=1) :: C1(10)= [(REPEAT(A(I)(1:I),1) // REPEAT(A(I)(I+1:10), 1) , I=1,10)] END ``` Flang currently issues an error as: ``` ./a3.f:7:41: error: Initialization _expression_ for 'c1' ([(repeat(a(int(int(i,kind=4),kind=8))(1_8:int(int(i,kind=4),kind=8)),1_8)//repeat(a(int(int(i,kind=4),kind=8))(int(int(i,kind=4)+1_4,kind=8):10_8),1_8),INTEGER(8)::i=1_8,10_8,1_8)]) cannot be computed as a constant value CHARACTER(LEN=10, KIND=1) :: C1(10)= [(REPEAT(A(I)(1:I),1) // REPEAT(A(I)(I+1:10), 1) , I=1,10)] ^^^ ``` The code seems conforming to me. All ifort, gfortran and XLF compiled it successfully. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123726] clang 20: Sporadic crashes of clang-tidy check modernize-use-constraints
Issue
123726
Summary
clang 20: Sporadic crashes of clang-tidy check modernize-use-constraints
Labels
clang,
clang-tidy
Assignees
Reporter
pkl97
clang-tidy check modernize-use-constraints crashes sporadically (approximately in 5% of the runs) when given this program to analyze:
```c++
#include
int main(int argc, char** argv)
{
return EXIT_FAILURE;
}
```
boost/filesystem/path.hpp was taken from the current version Boost 1.87.0.
Script to run clang-tidy in a loop:
```Shell
for i in {0001..1000}
do
echo "Iteration $i"
clang-tidy --extra-arg=-I/usr/local/clang20el9/include/c++/v1 --checks=-*,modernize-use-constraints --header-filter=^/home/user/devel/PROJECTS/.* -p /home/user/devel /home/user/devel/PROJECTS/FileWriter/UnityBuild.cpp
done
```
A dump of the crash:
[ClangTidyCrash.txt](https://github.com/user-attachments/files/18488796/ClangTidyCrash.txt)
The last commit included in my clang 20 build from branch master is 106c483a102e1328f11e2b1d9398f4ad2826b59f from 2025-01-19.
The crash does not occur in clang-tidy 19 with the same Boost header file.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123727] [X86][AVX512] Generate `valignq` instead of `vpermi2pd`
Issue
123727
Summary
[X86][AVX512] Generate `valignq` instead of `vpermi2pd`
Labels
question,
backend:X86
Assignees
abhishek-kaushik22
Reporter
abhishek-kaushik22
Consider this ir:
```llvm
define <8 x double> @bar(i64 %x, ptr %arr, <8 x double> %val1, <8 x double> %val2) {
entry:
%gep1 = getelementptr double, ptr %arr, i64 %x
%gepload1 = load <8 x double>, ptr %gep1, align 16
%z = add i64 %x, 8
%gep3 = getelementptr double, ptr %arr, i64 %z
%gepload3 = load <8 x double>, ptr %gep3, align 16
%shuffle1 = shufflevector <8 x double> %gepload1, <8 x double> %gepload3, <8 x i32>
store <8 x double> %shuffle1, ptr %gep1, align 16
ret <8 x double> %gepload3
}
```
Currently, we generate
```asm
.LCPI0_1:
.byte 1 # 0x1
.byte 2 # 0x2
.byte 3 # 0x3
.byte 4 # 0x4
.byte 5 # 0x5
.byte 6 # 0x6
.byte 7 # 0x7
.byte 8 # 0x8
bar: # @bar
vmovupd zmm1, zmmword ptr [rsi + 8*rdi]
vmovupd zmm0, zmmword ptr [rsi + 8*rdi + 64]
vpmovsxbq zmm2, qword ptr [rip + .LCPI0_1] # zmm2 = [1,2,3,4,5,6,7,8]
vpermi2pd zmm2, zmm1, zmm0
vmovupd zmmword ptr [rsi + 8*rdi], zmm2
ret
```
but can't we generate a `valignq` instead of the full permute?
```asm
bar:# @bar
vmovupd zmm1, zmmword ptr [rsi + 8*rdi]
vmovupd zmm0, zmmword ptr [rsi + 8*rdi + 64]
valignq zmm2, zmm1, zmm0, 1
vmovupd zmmword ptr [rsi + 8*rdi], zmm2
ret
```
This saves us from saving the pattern `.LCPI0_1` in the binary.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123828] clang++ segfault when using import std in module
Issue 123828 Summary clang++ segfault when using import std in module Labels clang Assignees Reporter jpc0 While building a module that has `import std` I get a segfault in clang++ 20 building with a very new cmake. I am using the flags `-stdlib=libc++ -Xclang -fno-validate-pch` and the linker flags `-stdlib=libc++ -lc++abi`. I have also tested with onl the `-stdlib=libc++` flag and `-stdlib=libc++ -lc++abi` linker flags and get the same error. The CMake output before the stackdump is: ``` /usr/bin/clang++-20 -stdlib=libc++ -g -std=gnu++23 -MD -MT CMakeFiles/test.dir/test.cpp.o -MF CMakeFiles/test.dir/test.cpp.o.d @CMakeFiles/test.dir/test.cpp.o.modmap -o CMakeFiles/test.dir/test.cpp.o -c /home/jpc0/devel/git/debug/clang20/test.cpp PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script. ``` I am running on Ubuntu 24.04.1 LTS under WSL if that makes any difference. I do not currenly have a different configuration of OS to test under. I have a git repo [here](https://github.com/jpc0/clang20importstdsegfault) that has a basic reproduction as well as the relevant preprocessed source and associated run script. In the repo run: ```sh cmake -S . --preset debug cmake --build build ``` and the crash will happen. All variables passed to cmake is in the CMakePresets debug preset. ``` Ubuntu clang version 20.0.0 (++20250120081916+d35d7f4b13c0-1~exp1~20250120202047.676) Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/lib/llvm-20/bin ``` ``` cmake version 3.31.4-g98de8ec ``` I got clang from the ubuntu repo added video the llvm install script: `deb http://apt.llvm.org/noble/ llvm-toolchain-noble main` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123832] crash: crash while compiling JoltPhysic in release
Issue 123832 Summary crash: crash while compiling JoltPhysic in release Labels new issue Assignees Reporter firesgc 16>PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script. 16>Stack dump: 16>0. Program arguments: "C:\\Program Files\\Microsoft Visual Studio\\2022\\Preview\\VC\\Tools\\Llvm\\x64\\bin\\clang-cl.exe" @ [QuadTree.zip](https://github.com/user-attachments/files/18497076/QuadTree.zip) [QuadTree.zip](https://github.com/user-attachments/files/18497081/QuadTree.zip) 16>1. parser at end of file 16>2. Code generation 16>3. Running pass 'Function Pass Manager' on module '..\..\Jaose\3rdParty\JoltPhysics\Jolt\Physics\Collision\BroadPhase\QuadTree.cpp'. 16>4. Running pass 'X86 DAG->DAG Instruction Selection' on function '@"??$ConstructObject@AEA_N@?$FixedSizeFreeList@VNode@QuadTree@JPH@@@JPH@@QEAAIAEA_N@Z"' 16>Exception Code: 0xC005 16> #0 0x7ff73dfec31b (C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe+0x277c31b) 16> #1 0x7ff73e658b1a (C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe+0x2de8b1a) 16> #2 0x7ff73d9410dd (C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe+0x20d10dd) 16> #3 0x7ff73da840c6 (C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe+0x22140c6) 16> #4 0x7ff73bc2b6b9 (C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe+0x3bb6b9) 16> #5 0x7ff73d91472e (C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe+0x20a472e) 16> #6 0x7ff73d935533 (C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe+0x20c5533) 16> #7 0x7ff73bbb6111 (C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe+0x346111) 16> #8 0x7ff73bbb5bdd (C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe+0x345bdd) 16> #9 0x7ff73bbafa69 (C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe+0x33fa69) 16>#10 0x7ff73d930365 (C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe+0x20c0365) 16>#11 0x7ff73dcef1a8 (C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe+0x247f1a8) 16>#12 0x7ff73be217e1 (C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe+0x5b17e1) 16>#13 0x7ff73be21282 (C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe+0x5b1282) 16>#14 0x7ff73be1dfb4 (C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe+0x5adfb4) 16>#15 0x7ff73be1bb30 (C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe+0x5abb30) 16>#16 0x7ff73be1a4fe (C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe+0x5aa4fe) 16>#17 0x7ff73cc2e4cd (C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe+0x13be4cd) 16>#18 0x7ff73bfabc05 (C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe+0x73bc05) 16>#19 0x7ff73bfaba08 (C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe+0x73ba08) 16>#20 0x7ff73bc5f6e8 (C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe+0x3ef6e8) 16>#21 0x7ff73bc5f09e (C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe+0x3ef09e) 16>#22 0x7ff73bc5ebb7 (C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe+0x3eebb7) 16>#23 0x7ff73bc58a47 (C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe+0x3e8a47) 16>#24 0x7ff73bc560c3 (C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe+0x3e60c3) 16>#25 0x7ff73dd74b70 (C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe+0x2504b70) 16>#26 0x7ffa1145e8d7 (C:\WINDOWS\System32\KERNEL32.DLL+0x2e8d7) 16>#27 0x7ffa1245fbcc (C:\WINDOWS\SYSTEM32\ntdll.dll+0xdfbcc) 16>clang-cl : error : clang frontend command failed due to signal (use -v to see invocation) 16>clang version 18.1.8 16>Target: amd64-pc-windows-msvc 16>Thread model: posix 16>InstalledDir: C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/
[llvm-bugs] [Bug 123842] Add a property to launch.json to specify the location of the lldb-dap to use
Issue 123842 Summary Add a property to launch.json to specify the location of the lldb-dap to use Labels lldb-dap Assignees JDevlieghere Reporter tedwoodward Some users, especially embedded developers, switch between toolchains frequently. Currently, the lldb-dap extension allows this by changing a setting in the extension, but this is cumbersome if a user switches frequently on a per-project basis. Add a property to configurations for lldb-dap in launch.json to specify the location of the lldb-dap executable to use, overriding the setting in the extension for that configuration. If the property does not exist, use the setting in the extension. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123845] Linter invocation failed with return code -1073741819 when run on richedittest project
Issue 123845 Summary Linter invocation failed with return code -1073741819 when run on richedittest project Labels new issue Assignees Reporter sclchua My PR was failing on the autolinting step > Error: Linter invocation failed with return code -1073741819. > stdout: > stderr: Clang-formating 4 files > PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. > Stack dump: > 0. Program arguments: D:\\a\\_work\\_temp\\nuget\\microsoft.office.clang-format.20250110.1.0\\bin/clang-format.exe -i --files=C:\\Users\\CLOUDT~1\\AppData\\Local\\Temp\\.tmpZlVljt > Exception Code: 0xC005 > #0 0x7ff69c6cc9eb (D:\a\_work\_temp\nuget\microsoft.office.clang-format.20250110.1.0\bin\clang-format.exe+0x21c9eb) > #1 0x7ff69c6ad639 (D:\a\_work\_temp\nuget\microsoft.office.clang-format.20250110.1.0\bin\clang-format.exe+0x1fd639) > #2 0x7ff69c684a32 (D:\a\_work\_temp\nuget\microsoft.office.clang-format.20250110.1.0\bin\clang-format.exe+0x1d4a32) > #3 0x7ff69c68675e (D:\a\_work\_temp\nuget\microsoft.office.clang-format.20250110.1.0\bin\clang-format.exe+0x1d675e) > #4 0x7ff69c4be38c (D:\a\_work\_temp\nuget\microsoft.office.clang-format.20250110.1.0\bin\clang-format.exe+0xe38c) > #5 0x7ff69c4c1009 (D:\a\_work\_temp\nuget\microsoft.office.clang-format.20250110.1.0\bin\clang-format.exe+0x11009) > #6 0x7ff69ca2cc44 (D:\a\_work\_temp\nuget\microsoft.office.clang-format.20250110.1.0\bin\clang-format.exe+0x57cc44) > #7 0x7ffdde0c4cb0 (C:\Windows\System32\KERNEL32.DLL+0x14cb0) > #8 0x7ffddf4dedcb (C:\Windows\SYSTEM32\ntdll.dll+0x7edcb) > > ##[warning]LIB_ResourceFile does not exist > ##[warning]Resource file haven't been set, can't find loc string for key: LIB_ProcessExitCode > ##[error]LIB_ProcessExitCode D:\a\_work\_tasks\autolinter-download_d4bbeddb-4d0c-4367-beb6-b89b91e11da9\0.1.51\cli\windows_x64\autolinter.exe 1 > Finishing: 🚀 autolinter orchestrate > I tried to run the autolinter for the files locally and noticed only one file produced the same error: richedittest\restest.6\Genesis\gencommon\src\dvrbase.cpp I even saw the error on a different enlistment with no changes made. PR: https://dev.azure.com/Office/Office/_git/Office/pullrequest/3711482 Job: https://dev.azure.com/Office/Office/_build/results?buildId=34025729&view=logs&j=9a3eca11-4b99-5b5d-b11d-5d42b2c5b33e&t=7b18c78e-79f3-569c-2c08-866309d05551&l=140 ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123847] [HLSL] Add checks to the SPIRVInstructionSelector's `selectExtInst` functions for SPIR-V extended instruction set availability
Issue
123847
Summary
[HLSL] Add checks to the SPIRVInstructionSelector's `selectExtInst` functions for SPIR-V extended instruction set availability
Labels
new issue
Assignees
Reporter
Icohedron
Certain SPIR-V instructions are supported only with the [OpenCL extended instruction set](https://registry.khronos.org/SPIR-V/specs/unified1/OpenCL.ExtendedInstructionSet.100.html) but not the [GLSL extended instruction set](https://registry.khronos.org/SPIR-V/specs/unified1/GLSL.std.450.html), and vice-versa.
For example, the `reflect` instruction is supported in GLSL, but not OpenCL. Without adding a check that the extended instruction set is usable by the current SPIR-V target, the compiler will simply crash when attempting to select `G_INTRINSIC intrinsic(@llvm.spv.reflect)` in an OpenCL SPIR-V target.
#122992 implements the check as follows in `llvm/lib/Target/SPIRV/SPIRVInstructionSelector.cpp`:
```c++
bool SPIRVInstructionSelector::selectExtInst(Register ResVReg,
const SPIRVType *ResType,
MachineInstr &I,
GL::GLSLExtInst GLInst) const {
if (!STI.canUseExtInstSet(
SPIRV::InstructionSet::InstructionSet::GLSL_std_450)) {
std::string DiagMsg;
raw_string_ostream OS(DiagMsg);
I.print(OS, true, false, false, false);
DiagMsg += " is only supported with the GLSL extended instruction set.\n";
report_fatal_error(DiagMsg.c_str(), false);
}
return selectExtInst(ResVReg, ResType, I,
{{SPIRV::InstructionSet::GLSL_std_450, GLInst}});
}
```
There should be similar checks made for the other overloaded versions of the `selectExtInst` to keep things consistent.
```c++
bool selectExtInst(Register ResVReg, const SPIRVType *ResType,
MachineInstr &I, CL::OpenCLExtInst CLInst) const;
bool selectExtInst(Register ResVReg, const SPIRVType *ResType,
MachineInstr &I, CL::OpenCLExtInst CLInst,
GL::GLSLExtInst GLInst) const;
bool selectExtInst(Register ResVReg, const SPIRVType *ResType,
MachineInstr &I, const ExtInstList &ExtInsts) const;
```
A non-exhaustive list of OpenCL-only instructions:
- `vstoren`
- `vloadn`
- `shuffle`
(Note: AFAIK, these OpenCL-only instructions do not have corresponding HLSL intrinsics. I am not sure if there are any OpenCL-only instructions that have a direct [HLSL intrinsic](https://learn.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-intrinsic-functions) equivalent.)
A non-exhaustive list of GLSL-only instructions:
- `Reflect`
- `Refract`
- `FaceForward`
A full list of exclusive instructions may be constructed by comparing the [OpenCL extended instruction set](https://registry.khronos.org/SPIR-V/specs/unified1/OpenCL.ExtendedInstructionSet.100.html) and [GLSL extended instruction set](https://registry.khronos.org/SPIR-V/specs/unified1/GLSL.std.450.html) specifications.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123851] [libc][assert] provide `static_assert` macro pre-`__STDC_VERSION__ == 202311L`
Issue 123851 Summary [libc][assert] provide `static_assert` macro pre-`__STDC_VERSION__ == 202311L` Labels good first issue, libc Assignees Reporter nickdesaulniers prior to C23, `static_assert` was a macro provided by assert.h. I just hit this trying to build compiler-rt builtins against llvm-libc; we don't provide a definition of `static_assert` and compiler-rt uses the compiler default language standard (currently -std=c17). We should add something along the lines of: ```c #if __STDC_VERSION__ < 202311L #define static_assert(x, y) _Static_assert((x), y) #endif ``` in libc/include/llvm-libc-macros/assert-macros.h. cc @frobtech ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123854] [Clang] Crash when mangling lambda with requires clause
Issue
123854
Summary
[Clang] Crash when mangling lambda with requires clause
Labels
clang
Assignees
Reporter
MagentaTreehouse
The following C++20 code causes a crash since Clang 18:
```c++
template
constexpr auto f() {
return [] () requires requires (T x) { x; } {};
}
int main() {
f()();
}
```
See https://compiler-explorer.com/z/z475c49eW.
Assertion:
```console
clang++: /root/llvm-project/clang/lib/AST/ItaniumMangle.cpp:5919:
void {anonymous}::CXXNameMangler::mangleFunctionParam(const clang::ParmVarDecl*):
Assertion `parmDepth < FunctionTypeDepth.getDepth()' failed.
```
Stack dump
```console
0. Program arguments: /opt/compiler-explorer/clang-assertions-trunk/bin/clang++ -gdwarf-4 -g -o /app/output.s -mllvm --x86-asm-syntax=intel -fno-verbose-asm -S --gcc-toolchain=/opt/compiler-explorer/gcc-snapshot -fcolor-diagnostics -fno-crash-diagnostics -std=c++20
1. parser at end of file
2. :6:5: LLVM IR generation of declaration 'main'
3. :6:5: Generating code for declaration 'main'
4. :3:12: Mangling declaration 'f()::(anonymous class)::operator()'
#0 0x03cb5ea8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x3cb5ea8)
#1 0x03cb3bb4 llvm::sys::CleanupOnSignal(unsigned long) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x3cb3bb4)
#2 0x03c00088 CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0
#3 0x757fbf442520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#4 0x757fbf4969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
#5 0x757fbf442476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
#6 0x757fbf4287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
#7 0x757fbf42871b (/lib/x86_64-linux-gnu/libc.so.6+0x2871b)
#8 0x757fbf439e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96)
#9 0x07a9ca8d (anonymous namespace)::CXXNameMangler::mangleFunctionParam(clang::ParmVarDecl const*) ItaniumMangle.cpp:0:0
#10 0x07a9fd15 (anonymous namespace)::CXXNameMangler::mangleExpression(clang::Expr const*, unsigned int, bool)::'lambda0'(clang::NamedDecl const*)::operator()(clang::NamedDecl const*) const (.isra.0) ItaniumMangle.cpp:0:0
#11 0x07a9869f (anonymous namespace)::CXXNameMangler::mangleExpression(clang::Expr const*, unsigned int, bool) ItaniumMangle.cpp:0:0
#12 0x07aa8eba (anonymous namespace)::CXXNameMangler::mangleRequirement(clang::SourceLocation, clang::concepts::Requirement const*) ItaniumMangle.cpp:0:0
#13 0x07a99405 (anonymous namespace)::CXXNameMangler::mangleExpression(clang::Expr const*, unsigned int, bool) ItaniumMangle.cpp:0:0
#14 0x07a9cfdb (anonymous namespace)::CXXNameMangler::mangleBareFunctionType(clang::FunctionProtoType const*, bool, clang::FunctionDecl const*) ItaniumMangle.cpp:0:0
#15 0x07a9e4e0 (anonymous namespace)::CXXNameMangler::mangleFunctionEncoding(clang::GlobalDecl) ItaniumMangle.cpp:0:0
#16 0x07a9f5c7 (anonymous namespace)::CXXNameMangler::mangle(clang::GlobalDecl) ItaniumMangle.cpp:0:0
#17 0x07aa1e04 (anonymous namespace)::ItaniumMangleContextImpl::mangleCXXName(clang::GlobalDecl, llvm::raw_ostream&) ItaniumMangle.cpp:0:0
#18 0x07ac663b clang::MangleContext::mangleName(clang::GlobalDecl, llvm::raw_ostream&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x7ac663b)
#19 0x041f1c24 getMangledNameImpl(clang::CodeGen::CodeGenModule&, clang::GlobalDecl, clang::NamedDecl const*, bool) CodeGenModule.cpp:0:0
#20 0x042045dd clang::CodeGen::CodeGenModule::getMangledName(clang::GlobalDecl) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x42045dd)
#21 0x0423e701 clang::CodeGen::CodeGenModule::GetAddrOfFunction(clang::GlobalDecl, llvm::Type*, bool, bool, clang::CodeGen::ForDefinition_t) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x423e701)
#22 0x0403b703 clang::CodeGen::CodeGenFunction::EmitCXXMemberOrOperatorMemberCallExpr(clang::CallExpr const*, clang::CXXMethodDecl const*, clang::CodeGen::ReturnValueSlot, bool, clang::NestedNameSpecifier*, bool, clang::Expr const*, llvm::CallBase**) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x403b703)
#23 0x0403bd13 clang::CodeGen::CodeGenFunction::EmitCXXOperatorMemberCallExpr(clang::CXXOperatorCallExpr const*, clang::CXXMethodDecl const*, clang::CodeGen::ReturnValueSlot, llvm::CallBase**) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x403bd13)
#24 0x04019246 clang::CodeGen::CodeGenFunction::EmitCallExpr(clang::CallExpr const*, clang::CodeGen::ReturnValueSlot, llvm::CallBase**) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x4019246)
#25 0x04087814 (anonymous namespace)::ScalarExprEmit
[llvm-bugs] [Bug 123770] Parser at end of file, segmentation fault
Issue 123770 Summary Parser at end of file, segmentation fault Labels new issue Assignees Reporter sigurd4 Compiler crash. Full logs are added in attachment. I've only added the first crash below. # Crash logs ``` [main] Building folder: /home/sigurd/Code/c++/programmering2/2-4_høyde_på_tree/build/debug main [build] Starting build [proc] Executing command: /usr/bin/cmake --build /home/sigurd/Code/c++/programmering2/2-4_høyde_på_tree/build/debug --config Debug --target main -- [build] [1/2 0% :: 0.003] Re-checking globbed directories... [build] [1/24 4% :: 0.540] Scanning '/home/sigurd/Code/c++/programmering2/2-4_høyde_på_tree/build/debug/_deps/std-src/std.cppm' for CXX dependencies [build] [2/24 8% :: 0.561] Generating CXX dyndep file _deps/std-build/CMakeFiles/std.dir/CXX.dd [build] [4/24 12% :: 0.588] Generating CXX dyndep file CMakeFiles/main.dir/CXX.dd [build] [13/24 16% :: 1.688] Building CXX object CMakeFiles/main.dir/src/units/si/si_area.cppm.o [build] FAILED: CMakeFiles/main.dir/src/units/si/si_area.cppm.o CMakeFiles/main.dir/units-si_area.pcm [build] /usr/bin/clang++ -stdlib=libc++ -g -std=gnu++23 -isystem/usr/include/c++/v1 "-isystem/usr/include/c++/v1/*" -Wall -Wextra -pedantic -Wpedantic -Wsign-conversion -Wconversion -Werror=switch -fdiagnostics-color=always -Wdouble-promotion -Wnull-dereference -Winfinite-recursion -Wmisleading-indentation -g -Werror=return-local-addr -Wno-c++23-extensions -Xclang -emit-module-interface -fmodules -stdlib=libc++ -fbuiltin-module-map -fimplicit-module-maps -fprebuilt-module-path=/home/sigurd/Code/c++/programmering2/2-4_høyde_på_tree/build/debug/modules -fretain-comments-from-system-headers -Wstrict-overflow -MD -MT CMakeFiles/main.dir/src/units/si/si_area.cppm.o -MF CMakeFiles/main.dir/src/units/si/si_area.cppm.o.d @CMakeFiles/main.dir/src/units/si/si_area.cppm.o.modmap -o CMakeFiles/main.dir/src/units/si/si_area.cppm.o -c '/home/sigurd/Code/c++/programmering2/2-4_høyde_på_tree/src/units/si/si_area.cppm' [build] PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script. [build] Stack dump: [build] 0. Program arguments: /usr/bin/clang-20 -cc1 -triple x86_64-pc-linux-gnu -emit-obj -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name si_area.cppm -mrelocation-model pic -pic-level 2 -pic-is-pie -mframe-pointer=all -fmath-errno -ffp-contract=on -fno-rounding-math -mconstructor-aliases -funwind-tables=2 -target-cpu x86-64 -tune-cpu generic -debug-info-kind=constructor -dwarf-version=5 -debugger-tuning=gdb -fdebug-compilation-dir=/home/sigurd/Code/c++/programmering2/2-4_h\303\270yde_p\303\245_tree/build/debug -fcoverage-compilation-dir=/home/sigurd/Code/c++/programmering2/2-4_h\303\270yde_p\303\245_tree/build/debug -resource-dir /usr/lib/clang/20 -Wall -Wextra -Wpedantic -Wsign-conversion -Wconversion -Werror=switch -Wdouble-promotion -Wnull-dereference -Winfinite-recursion -Wmisleading-indentation -Werror=return-local-addr -Wno-c++23-extensions -Wstrict-overflow -pedantic -std=gnu++23 -fdeprecated-macro -ferror-limit 19 -fgnuc-version=4.2.1 -fmodules -fimplicit-module-maps -fmodules-cache-path=/home/sigurd/.cache/clang/ModuleCache -fmodule-map-file=/usr/lib/clang/20/include/module.modulemap -fprebuilt-module-path=/home/sigurd/Code/c++/programmering2/2-4_h\303\270yde_p\303\245_tree/build/debug/modules -fmodules-validate-system-headers -fskip-odr-check-in-gmf -fcxx-exceptions -fexceptions -fcolor-diagnostics -fretain-comments-from-system-headers -emit-module-interface -faddrsig -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o CMakeFiles/main.dir/src/units/si/si_area.cppm.o -x pcm CMakeFiles/main.dir/units-si_area.pcm [build] 1. parser at end of file [build] #0 0x772922d78ea3 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/usr/bin/../lib/libLLVM.so.20.0+0x2778ea3) [build] #1 0x772922d76a1f llvm::sys::RunSignalHandlers() (/usr/bin/../lib/libLLVM.so.20.0+0x2776a1f) [build] #2 0x772922d796b6 (/usr/bin/../lib/libLLVM.so.20.0+0x27796b6) [build] #3 0x77292044c1d0 (/usr/bin/../lib/libc.so.6+0x3d1d0) [build] #4 0x772928f50bf9 clang::ASTWriter::WriteSubmodules(clang::Module*, clang::ASTContext*) (/usr/bin/../lib/libclang-cpp.so.20.0+0x3150bf9) [build] #5 0x772928f67d63 clang::ASTWriter::WriteASTCore(clang::Sema*, llvm::StringRef, clang::Module*) (/usr/bin/../lib/libclang-cpp.so.20.0+0x3167d63) [build] #6 0x772928f6640e clang::ASTWriter::WriteAST(llvm::PointerUnion, llvm::StringRef, clang::Module*, llvm::StringRef, bool) (/usr/bin/../lib/libclang-cpp.so.20.0+0x316640e) [build] #7 0x772928fbd7cf clang::PCHGenerator::HandleTranslationUnit(clang::ASTContext&) (/usr/bin/../lib/lib
[llvm-bugs] [Bug 123815] [c++][Modules] Member variable of non-exported type has inaccessible hidden friend with defaulted comparison
Issue
123815
Summary
[c++][Modules] Member variable of non-exported type has inaccessible hidden friend with defaulted comparison
Labels
new issue
Assignees
Reporter
davidstone
The following valid translation units
```c++
export module a;
namespace n {
}
```
```c++
export module b;
import a;
namespace n {
struct monostate {
friend bool operator==(monostate, monostate) = default;
};
export struct wrapper {
friend bool operator==(wrapper const &, wrapper const &) = default;
monostate m_value;
};
} // namespace n
```
```c++
import b;
static_assert(n::wrapper() == n::wrapper());
```
are rejected by clang with
```console
In file included from /app/c.cpp:1:
b.cpp:12:67: error: invalid operands to binary _expression_ ('const monostate' and 'const monostate')
12 | friend bool operator==(wrapper const &, wrapper const &) = default;
| ^
c.cpp:3:28: note: in defaulted equality comparison operator for 'wrapper' first required here
3 | static_assert(n::wrapper() == n::wrapper());
|^
c.cpp:3:28: error: static assertion _expression_ is not an integral constant _expression_
3 | static_assert(n::wrapper() == n::wrapper());
| ~^~~
2 errors generated.
```
See it live: https://godbolt.org/z/19dG3G7Pb
Introduced by c5e4afe6733c58e24023ede04275bbed3bde8240 @ChuanqiXu9
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123817] fails to link `error: undefined reference to 'llvm::checkRegister`
Issue 123817 Summary fails to link `error: undefined reference to 'llvm::checkRegister` Labels build-problem Assignees Reporter sylvestre On linux amd64: ``` FAILED: bin/llvm-ar : && /usr/bin/g++ -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -Wno-unused-command-line-argument -Wdate-time -D_FORTIFY_SOURCE=3 -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time -fno-lifetime-dse -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-nonnull -Wno-class-memaccess -Wno-redundant-move -Wno-pessimizing-move -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wsuggest-override -Wno-comment -Wno-misleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color -ffunction-sections -fdata-sections -fdebug-prefix-map=/build/source/build-llvm=../ -fdebug-prefix-map=/build/source/= -no-canonical-prefixes -ffile-prefix-map=/build/source/build-llvm=../ -ffile-prefix-map=/build/source/= -no-canonical-prefixes -O3 -DNDEBUG -Wl,-z,relro -Wl,--build-id -fuse-ld=gold-Wl,--gc-sections tools/llvm-ar/CMakeFiles/llvm-ar.dir/llvm-ar.cpp.o tools/llvm-ar/CMakeFiles/llvm-ar.dir/llvm-ar-driver.cpp.o -o bin/llvm-ar -Wl,-rpath,"\$ORIGIN/../lib:" lib/libLLVMM68kAsmParser.a lib/libLLVMXtensaAsmParser.a lib/libLLVMX86AsmParser.a lib/libLLVMM68kDesc.a lib/libLLVMXtensaDesc.a lib/libLLVMX86Desc.a lib/libLLVMM68kInfo.a lib/libLLVMXtensaInfo.a lib/libLLVMX86Info.a lib/libLLVMBinaryFormat.a lib/libLLVMCore.a lib/libLLVMDlltoolDriver.a lib/libLLVMLibDriver.a lib/libLLVMObject.a lib/libLLVMSupport.a lib/libLLVMTargetParser.a lib/libLLVMM68kCodeGen.a lib/libLLVMM68kDesc.a lib/libLLVMM68kInfo.a lib/libLLVMAsmPrinter.a lib/libLLVMGlobalISel.a lib/libLLVMSelectionDAG.a lib/libLLVMCodeGen.a lib/libLLVMCGData.a lib/libLLVMBitWriter.a lib/libLLVMObjCARCOpts.a lib/libLLVMScalarOpts.a lib/libLLVMAggressiveInstCombine.a lib/libLLVMInstCombine.a lib/libLLVMTransformUtils.a lib/libLLVMTarget.a lib/libLLVMAnalysis.a lib/libLLVMProfileData.a lib/libLLVMSymbolize.a lib/libLLVMDebugInfoDWARF.a lib/libLLVMDebugInfoPDB.a lib/libLLVMDebugInfoCodeView.a lib/libLLVMDebugInfoMSF.a lib/libLLVMDebugInfoBTF.a lib/libLLVMCodeGenTypes.a lib/libLLVMMCDisassembler.a lib/libLLVMObject.a lib/libLLVMMCParser.a lib/libLLVMMC.a lib/libLLVMIRReader.a lib/libLLVMAsmParser.a lib/libLLVMTextAPI.a lib/libLLVMOption.a lib/libLLVMBitReader.a lib/libLLVMCore.a lib/libLLVMBinaryFormat.a lib/libLLVMRemarks.a lib/libLLVMTargetParser.a lib/libLLVMBitstreamReader.a lib/libLLVMSupport.a lib/libLLVMDemangle.a -lrt -ldl -lm /usr/lib/x86_64-linux-gnu/libz.so /usr/lib/x86_64-linux-gnu/libzstd.so && : lib/libLLVMXtensaAsmParser.a(XtensaAsmParser.cpp.o):XtensaAsmParser.cpp:function XtensaAsmParser::parseRegister(llvm::SmallVectorImpl > >&, bool, bool):(.text._ZN15XtensaAsmParser13parseRegisterERN4llvm15SmallVectorImplISt10unique_ptrINS0_18MCParsedAsmOperandESt14default_deleteIS3_bb+0x353): error: undefined reference to 'llvm::checkRegister(llvm::MCRegister, llvm::FeatureBitset const&)' lib/libLLVMXtensaAsmParser.a(XtensaAsmParser.cpp.o):XtensaAsmParser.cpp:function XtensaAsmParser::ParseInstructionWithSR(llvm::ParseInstructionInfo&, llvm::StringRef, llvm::SMLoc, llvm::SmallVectorImpl > >&):(.text._ZN15XtensaAsmParser22ParseInstructionWithSRERN4llvm20ParseInstructionInfoENS0_9StringRefENS0_5SMLocERNS0_15SmallVectorImplISt10unique_ptrINS0_18MCParsedAsmOperandESt14default_deleteIS7_+0x230): error: undefined reference to 'llvm::checkRegister(llvm::MCRegister, llvm::FeatureBitset const&)' collect2: error: ld returned 1 exit status ``` Regression range: 0f9e91346698..cdd321462aec ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123800] Bug in LDS lowering, F.hasAddressTaken() under-estimates escape analysis
Issue 123800 Summary Bug in LDS lowering, F.hasAddressTaken() under-estimates escape analysis Labels new issue Assignees ergawy, JonChesterfield Reporter JonChesterfield Reported by @ergawy as O0 reaching a trap. Reproducer is somewhat lengthy (mostly openmp runtime code, from O0). AMDGPUMemoryUtils::getTransitiveUsesOfLDS builds a set of LDS variables that are used by (non-kernel) functions that have their address taken. Kernels that call an unknown function then allocate all those variables. The bug here goes: ``` 1. kernel __omp_offloading_fc00_5e49a7c_main_l13 2. stashes a pointer to function __omp_offloading_fc00_5e49a7c_main_l13_omp_outlined_wrapper (and later calls it, indirectly) 3. __omp_offloading_fc00_5e49a7c_main_l13_omp_outlined_wrapper directly calls function __kmpc_get_shared_variables 4. __kmpc_get_shared_variables uses LDS global ZL32SharedMemVariableSharingSpacePtr ``` Since the function accessing the LDS variable doesn't have it's address taken, the variable doesn't get added to the set of problematic variables. However that function is called by some other function whose address is taken, so it needed to be. Instead of hasAddressTaken, this needs to be a (basic) escape analysis test. Transitive instead of only checking the immediate user. Crawling CallGraph marking functions would work but hopefully there's a cleaner fix. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123801] [HLSL] Implement default constant buffer `$Globals`
Issue 123801 Summary [HLSL] Implement default constant buffer `$Globals` Labels HLSL Assignees Reporter hekota All non-resource variable declarations in the global scope are implicitly added to `$Global` constant buffer. In Sema we need to recognize these declarations and assign them `hlsl_constant` address space. At the end of Sema we will probably need to generate an implicit `HLSLBufferDecl` for the `$Globals` constant buffer and create its layout struct. Then we need to add support for this implicit buffer in codegen, making sure the code is generated in a similar way as other `cbuffer`s. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123821] [libc][docs]re-enable pthread docs
Issue 123821 Summary [libc][docs]re-enable pthread docs Labels documentation, libc Assignees Reporter nickdesaulniers Forked from https://github.com/llvm/llvm-zorg/issues/359#issuecomment-2600285688. It seems that https://github.com/llvm/llvm-project/commit/539b15b41a6a01017c0a555e89b7d2b62ba194d2 introduced an issue where `docs-libc-html` is failing to rebuild. I wasn't able to reproduce locally when setting `-DLLVM_ENABLE_RUNTIMES="libc"`, but I think the bot sets multiple runtimes. Perhaps that is what tickles the issue. For now, I plan to just partially revert 539b15b41a6a01017c0a555e89b7d2b62ba194d2, and when we have more time we can dig into why this is an issue and how to work around it. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123786] [BUILD] Not able to select mold in Windows
Issue 123786 Summary [BUILD] Not able to select mold in Windows Labels new issue Assignees Reporter QBos07 I try to configure to LLM to build with mold as the linker. I use clang from LLVM 19 windows release. My cmake invocation is `cmake -S . -B build -DLLVM_USE_LINKER=mold -DLLVM_PARALLEL_LINK_JOBS=1` I also tryed `CMAKE_LINKER=mold` and setting `-fuse-ld=mold` still: ```ninja build bin/llvm-min-tblgen.exe: CXX_EXECUTABLE_LINKER__llvm-min-tblgen_Debug utils/TableGen/Basic/CMakeFiles/obj.LLVMTableGenBasic.dir/ARMTargetDefEmitter.cpp.obj utils/TableGen/Basic/CMakeFiles/obj.LLVMTableGenBasic.dir/Attributes.cpp.obj utils/TableGen/Basic/CMakeFiles/obj.LLVMTableGenBasic.dir/CodeGenIntrinsics.cpp.obj utils/TableGen/Basic/CMakeFiles/obj.LLVMTableGenBasic.dir/DirectiveEmitter.cpp.obj utils/TableGen/Basic/CMakeFiles/obj.LLVMTableGenBasic.dir/IntrinsicEmitter.cpp.obj utils/TableGen/Basic/CMakeFiles/obj.LLVMTableGenBasic.dir/RISCVTargetDefEmitter.cpp.obj utils/TableGen/Basic/CMakeFiles/obj.LLVMTableGenBasic.dir/SDNodeProperties.cpp.obj utils/TableGen/Basic/CMakeFiles/obj.LLVMTableGenBasic.dir/TableGen.cpp.obj utils/TableGen/Basic/CMakeFiles/obj.LLVMTableGenBasic.dir/VTEmitter.cpp.obj utils/TableGen/CMakeFiles/llvm-min-tblgen.dir/llvm-min-tblgen.cpp.obj | lib/LLVMSupport.lib lib/LLVMTableGen.lib lib/LLVMDemangle.lib || lib/LLVMDemangle.lib lib/LLVMSupport.lib lib/LLVMTableGen.lib utils/TableGen/Basic/obj.LLVMTableGenBasic FLAGS = -Werror=date-time -Werror=unguarded-availability-new -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wmisleading-indentation -Wctad-maybe-unsupported -O0 -D_DEBUG -D_DLL -D_MT -Xclang --dependent-lib=msvcrtd -g -Xclang -gcodeview LINK_FLAGS = -fuse-ld=mold -Xlinker /subsystem:console -fuse-ld=lld-link LINK_LIBRARIES = lib/LLVMSupport.lib lib/LLVMTableGen.lib -lpsapi.lib -lshell32.lib -lole32.lib -luuid.lib -ladvapi32.lib -lws2_32.lib -lntdll.lib lib/LLVMDemangle.lib -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 -loldnames OBJECT_DIR = utils\TableGen\CMakeFiles\llvm-min-tblgen.dir POST_BUILD = cd . PRE_LINK = cd . TARGET_COMPILE_PDB = utils\TableGen\CMakeFiles\llvm-min-tblgen.dir\ TARGET_FILE = bin\llvm-min-tblgen.exe TARGET_IMPLIB = lib\llvm-min-tblgen.lib TARGET_PDB = bin\llvm-min-tblgen.pdb ``` notice the `-Xlinker /subsystem:console -fuse-ld=lld-link` at the end ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123778] I don't think this test is quite right. But since we don't have any historical practice with negative leap seconds, my reasoning is based on an assumption: the IANA db contain
Issue 123778 Summary I don't think this test is quite right. But since we don't have any historical practice with negative leap seconds, my reasoning is based on an assumption: the IANA db contains the earliest time after a leap second is fully inserted. I'm basing this on the fact that positive leap seconds are inserted at 11:59:60 PM on 30 June/31 December, but the db contains 12:00:00 AM on 1 July/1 January. Labels new issue Assignees Reporter ldionne I don't think this test is quite right. But since we don't have any historical practice with negative leap seconds, my reasoning is based on an assumption: the IANA db contains the earliest time after a leap second is fully inserted. I'm basing this on the fact that positive leap seconds are inserted at 11:59:60 PM on 30 June/31 December, but the db contains 12:00:00 AM on 1 July/1 January. For a positive leap second, the `utc_time` when insertion begins is this `sys_time` plus the accumulated offset, because the insertion begins at the time that would otherwise be 12:00:00 AM on the following day. The test is correct for those cases. But negative leap seconds are different. Insertion happens at the time that would otherwise be 11:59:59 PM, i.e., one second earlier, so I think you have to subtract `1s` to get the correct transition time for negative leap seconds. _Originally posted by @MattStephanson in https://github.com/llvm/llvm-project/pull/90393#discussion_r1585147783_ ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123808] Windows aarch64 MC assert failure: `:0: error: Incorrect size for foo prologue: 32 bytes of instructions in range, but .seh directives corresponding to 28 bytes`
Issue
123808
Summary
Windows aarch64 MC assert failure: `:0: error: Incorrect size for foo prologue: 32 bytes of instructions in range, but .seh directives corresponding to 28 bytes`
Labels
new issue
Assignees
Reporter
hjyamauchi
Reproduction:
A reduced test input: `reduced.ll`
```
target datalayout = "e-m:w-p:64:64-i32:32-i64:64-i128:128-n32:64-S128-Fn32"
target triple = "aarch64-unknown-windows-msvc19.42.34436"
%swift.refcounted = type { ptr, i64 }
%TScA_pSg = type <{ [16 x i8] }>
%T5repro4TestVSg = type <{ [32 x i8] }>
%T5repro4TestV = type <{ %TSS, %TSS }>
%TSS = type <{ %Ts11_StringGutsV }>
%Ts11_StringGutsV = type <{ %Ts13_StringObjectV }>
%Ts13_StringObjectV = type <{ %Ts6UInt64V, ptr }>
%Ts6UInt64V = type <{ i64 }>
declare swiftcc ptr @swift_task_alloc()
declare swifttailcc void @bar(ptr, ptr, i64, i64, i64, ptr, i64, i64, i64, i64, i64, ptr, i64, ptr, i64, ptr, i64, ptr, i64, ptr, i64, ptr, i64, ptr, i64, ptr, i64, ptr, i64, ptr, i64, ptr, i64, ptr, i64, ptr)
define swifttailcc void @foo(ptr %0, ptr swiftasync %1, ptr swiftself %2, ptr %3, ptr %._guts2._object._object, ptr %.rid4._guts._object._object, ptr %4, ptr %.idx8, ptr %.idx8._guts._object._object, ptr %5, ptr %.rid9._guts._object._object, ptr %6) {
entry:
%7 = load i64, ptr null, align 8
%8 = load i64, ptr %3, align 8
%9 = getelementptr <{ %swift.refcounted, %TScA_pSg, %TSS, %T5repro4TestVSg, %T5repro4TestV, %TSS, %TSS, %TSS, %T5repro4TestV, %TSS, %T5repro4TestV, %T5repro4TestV, %TSS }>, ptr %2, i32 0, i32 2
%10 = load i64, ptr %9, align 8
%11 = load ptr, ptr %1, align 8
%12 = getelementptr <{ %swift.refcounted, %TScA_pSg, %TSS, %T5repro4TestVSg, %T5repro4TestV, %TSS, %TSS, %TSS, %T5repro4TestV, %TSS, %T5repro4TestV, %T5repro4TestV, %TSS }>, ptr %2, i32 0, i32 3
%13 = load i64, ptr %.rid9._guts._object._object, align 8
%14 = load i64, ptr %.idx8._guts._object._object, align 8
%15 = load i64, ptr %5, align 8
%16 = getelementptr { i64, i64, i64, i64 }, ptr %12, i32 0, i32 3
%17 = load i64, ptr %16, align 8
%18 = getelementptr <{ %swift.refcounted, %TScA_pSg, %TSS, %T5repro4TestVSg, %T5repro4TestV, %TSS, %TSS, %TSS, %T5repro4TestV, %TSS, %T5repro4TestV, %T5repro4TestV, %TSS }>, ptr %2, i32 0, i32 4
%19 = load i64, ptr %18, align 8
%.rid._guts._object._object = getelementptr %Ts13_StringObjectV, ptr %18, i32 0, i32 1
%20 = load ptr, ptr %.rid._guts._object._object, align 8
%21 = load i64, ptr %.rid4._guts._object._object, align 8
%22 = load i64, ptr %0, align 8
%23 = load ptr, ptr %6, align 8
%24 = load i64, ptr %2, align 8
%25 = load ptr, ptr %._guts2._object._object, align 8
%26 = getelementptr <{ %swift.refcounted, %TScA_pSg, %TSS, %T5repro4TestVSg, %T5repro4TestV, %TSS, %TSS, %TSS, %T5repro4TestV, %TSS, %T5repro4TestV, %T5repro4TestV, %TSS }>, ptr %2, i32 0, i32 7
%27 = load i64, ptr %26, align 8
%._guts3._object._object = getelementptr %Ts13_StringObjectV, ptr %26, i32 0, i32 1
%28 = load ptr, ptr %._guts3._object._object, align 8
%29 = getelementptr <{ %swift.refcounted, %TScA_pSg, %TSS, %T5repro4TestVSg, %T5repro4TestV, %TSS, %TSS, %TSS, %T5repro4TestV, %TSS, %T5repro4TestV, %T5repro4TestV, %TSS }>, ptr %2, i32 0, i32 8
%30 = load i64, ptr %29, align 8
%.idx5 = getelementptr %T5repro4TestV, ptr %29, i32 0, i32 1
%31 = load i64, ptr %.idx5, align 8
%.idx5._guts._object._object = getelementptr %Ts13_StringObjectV, ptr %.idx5, i32 0, i32 1
%32 = load ptr, ptr %.idx5._guts._object._object, align 8
%33 = getelementptr <{ %swift.refcounted, %TScA_pSg, %TSS, %T5repro4TestVSg, %T5repro4TestV, %TSS, %TSS, %TSS, %T5repro4TestV, %TSS, %T5repro4TestV, %T5repro4TestV, %TSS }>, ptr %2, i32 0, i32 9
%34 = load i64, ptr %33, align 8
%35 = load i64, ptr %4, align 8
%36 = load i64, ptr %.idx8, align 8
%37 = load i64, ptr %1, align 8
%38 = call swiftcc ptr @swift_task_alloc()
store ptr null, ptr %3, align 8
store ptr null, ptr %4, align 8
musttail call swifttailcc void @bar(ptr null, ptr swiftasync %.rid4._guts._object._object, i64 %7, i64 %8, i64 %10, ptr %5, i64 %13, i64 %14, i64 %15, i64 %17, i64 %19, ptr %20, i64 %21, ptr %.idx8, i64 %22, ptr %23, i64 %24, ptr %25, i64 %27, ptr %28, i64 %30, ptr %.idx8._guts._object._object, i64 %31, ptr %32, i64 %34, ptr %._guts2._object._object, i64 %35, ptr %2, i64 %36, ptr %1, i64 %37, ptr %0, i64 0, ptr null, i64 0, ptr null)
ret void
}
```
```
$ llc --filetype obj reduced.ll
:0: error: Incorrect size for foo prologue: 32 bytes of instructions in range, but .seh directives corresponding to 28 bytes
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123812] [HLSL][DirectX] determine intrinsics that need to be backported codegen for older shader models
Issue 123812 Summary [HLSL][DirectX] determine intrinsics that need to be backported codegen for older shader models Labels backend:DirectX, HLSL Assignees farzonl Reporter farzonl Tickets like `IsHelperLane` #99233 have codeGen that varier by shader model to support the use of new HLSL intrinsics with older DXIL versions. 1. Determine the list of intrinsics that need a backport strategy 2. Determine how many shader models have unique code gen per intrinsic 3. update existing intrinsic tickets to account for special backport codegen requirements. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123809] Segmentation Fault in X86TTIImpl::getCastInstrCost during Loop Vectorization of asn1_compiler.c (Linux Kernel 6.13)
Issue 123809 Summary Segmentation Fault in X86TTIImpl::getCastInstrCost during Loop Vectorization of asn1_compiler.c (Linux Kernel 6.13) Labels new issue Assignees Reporter ms178 **Description:** I am encountering a segmentation fault while compiling the `asn1_compiler` component of the Linux kernel 6.13 using a recent development snapshot of LLVM. The crash occurs during the loop vectorization optimization pass and appears to be related to the cost model for cast instructions on x86. **Environment:** * **LLVM Version:** 20.0.0git (commit: e4f03b158c97098e1835cc1f00d0175398974f98) * **Target:** x86_64-pc-linux-gnu * **Host System:** CachyOS * **Target CPU:** Intel Raptor Lake * **Kernel:** Linux Kernel 6.13 (CachyOS patched) **Steps to Reproduce:** 1. Clone the CachyOS Linux kernel 6.13 source code. I am using some extra patches available [in my repo](https://github.com/ms178/archpkgbuilds/tree/main/packages/linux-cachyos). 2. Configure the kernel build with LLVM as the compiler. 3. Build the kernel. **Expected Behavior:** The `asn1_compiler` should compile successfully without any errors. **Actual Behavior:** The compilation crashes with a segmentation fault during the optimization of `scripts/asn1_compiler.c`. Stack trace: ``` HOSTCC scripts/asn1_compiler 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/marcus/llvm20/bin/clang-20 -cc1 -triple x86_64-pc-linux-gnu -emit-obj -dumpdir scripts/asn1_compiler- -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name asn1_compiler.c -function-alignment 5 -mrelocation-model pic -pic-level 2 -pic-is-pie -mframe-pointer=none -ffp-contract=fast -fno-rounding-math -ffp-exception-behavior=ignore -mconstructor-aliases -funwind-tables=2 -target-cpu raptorlake -target-feature +prfchw -target-feature -cldemote -target-feature +avx -target-feature +sahf -target-feature -xop -target-feature +crc32 -target-feature -amx-fp8 -target-feature +xsaves -target-feature -avx512fp16 -target-feature -usermsr -target-feature -sm4 -target-feature -egpr -target-feature +sse4.1 -target-feature -avx512ifma -target-feature +xsave -target-feature +sse4.2 -target-feature -tsxldtrk -target-feature -sm3 -target-feature +ptwrite -target-feature +widekl -target-feature -movrs -target-feature +invpcid -target-feature +64bit -target-feature +xsavec -target-feature -avx10.1-512 -target-feature -avx512vpopcntdq -target-feature +cmov -target-feature -avx512vp2intersect -target-feature -avx512cd -target-feature +movbe -target-feature -avxvnniint8 -target-feature -ccmp -target-feature -amx-int8 -target-feature +kl -target-feature -avx10.1-256 -target-feature -sha512 -target-feature +avxvnni -target-feature -rtm -target-feature +adx -target-feature +avx2 -target-feature +hreset -target-feature +movdiri -target-feature +serialize -target-feature +vpclmulqdq -target-feature -avx512vl -target-feature -uintr -target-feature -cf -target-feature +clflushopt -target-feature -raoint -target-feature -cmpccxadd -target-feature +bmi -target-feature -amx-tile -target-feature +sse -target-feature -avx10.2-256 -target-feature +gfni -target-feature -avxvnniint16 -target-feature -amx-fp16 -target-feature -zu -target-feature -ndd -target-feature +xsaveopt -target-feature +rdrnd -target-feature -avx512f -target-feature -amx-bf16 -target-feature -avx512bf16 -target-feature -avx512vnni -target-feature -push2pop2 -target-feature +cx8 -target-feature -avx512bw -target-feature +sse3 -target-feature +pku -target-feature -nf -target-feature -amx-tf32 -target-feature -amx-avx512 -target-feature +fsgsbase -target-feature -clzero -target-feature -mwaitx -target-feature -lwp -target-feature +lzcnt -target-feature +sha -target-feature +movdir64b -target-feature -ppx -target-feature -wbnoinvd -target-feature -enqcmd -target-feature -amx-transpose -target-feature -avx10.2-512 -target-feature -avxneconvert -target-feature -tbm -target-feature -pconfig -target-feature -amx-complex -target-feature +ssse3 -target-feature +cx16 -target-feature +fma -target-feature +popcnt -target-feature -avxifma -target-feature +f16c -target-feature -avx512bitalg -target-feature -rdpru -target-feature +clwb -target-feature +mmx -target-feature +sse2 -target-feature +rdseed -target-feature -avx512vbmi2 -target-feature -prefetchi -target-feature -amx-movrs -target-feature +rdpid -target-feature -fma4 -target-feature -avx512vbmi -target-feature +shstk -target-feature +vaes -target-feature +waitpkg -target-feature -sgx -target-feature +fxsr -target-feature -avx512dq -target-feature -sse4a -target-feature +aes -target-feature +bmi2
[llvm-bugs] [Bug 123805] [Flang] Asynchronous I/O seems affects procedure interface characteristics.
Issue 123805 Summary [Flang] Asynchronous I/O seems affects procedure interface characteristics. Labels flang:frontend Assignees Reporter DanielCChen Consider the following code ``` module mUserData type tUserData integer :: sin character(len = 30) :: name end type tUserData interface read(formatted) subroutine readUserData(userObj, unit, iotype, v_list, iostat, iomsg) import tUserData class(tUserData), intent(inout) :: userObj integer, intent(in) :: unit character(len = *), intent(in) :: iotype integer, dimension( : ), intent(in) :: v_list integer, intent(out) :: iostat character(len = *), intent(inout) :: iomsg end subroutine readUserData end interface end module mUserData subroutine readUserData(userObj, unit, iotype, v_list, iostat, iomsg) use mUserData, only : tUserData class(tUserData), intent(inout) :: userObj integer, intent(in) :: unit character(len = *), intent(in) :: iotype integer, dimension( : ), intent(in) :: v_list integer, intent(out) :: iostat character(len = *), intent(inout) :: iomsg read(unit, '(I9," ",A30)', iomsg=iomsg,& asynchronous='yes', iostat=iostat) userObj%sin, userObj%name end subroutine readUserData ``` Flang currently issues an error as: ``` ./t.f:10:20: warning: The global subprogram 'readuserdata' is not compatible with its local procedure declaration (incompatible dummy argument #1: incompatible dummy data object attributes) subroutine readUserData(userObj, unit, iotype, v_list, iostat, iomsg) ./t.f:25:12: Declaration of 'readuserdata' subroutine readUserData(userObj, unit, iotype, v_list, iostat, iomsg) ./t.f:10:20: Declaration of 'readuserdata' subroutine readUserData(userObj, unit, iotype, v_list, iostat, iomsg) ./t.f:36:21: error: String edit descriptor in READ format _expression_ read(unit, '(I9," ",A30)', iomsg=iomsg,& ^^^ ``` If I comment out the READ statement, it compiles fine. Both ifort and XLF compiled the code fine as is. However, both gfortran and Flang has the same behavior. The READ statement is executable. It should not affect the procedure interface characteristic checking. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123807] [Flang] Incorrect diagnostic on sequence association of character type arguments
Issue 123807 Summary [Flang] Incorrect diagnostic on sequence association of character type arguments Labels flang:frontend Assignees Reporter DanielCChen Consider the following code ``` module m contains subroutine test2 (s) character(5), intent(inout) :: s(5) !s = (/character(5) :: 'POINT', 'COMMA', 'UNDEFINED', '',''/) end subroutine end module use m character(30), allocatable :: s3 allocate (s3) s3 = '' call test2(s3) end ``` Flang currently issues an error as: ``` ./t.f:18:16: error: Actual argument has fewer characters remaining in storage sequence (24) than dummy argument 's=' (25) call test2(s3) ^^ ``` This is sequence association. It is allowed to have different length between actual and dummy character type argument. All ifort, gfortran and XLF compiled the code successfully. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123791] [SPIRV] Non-deterministic compiler output for debug-type-pointer.ll
Issue 123791 Summary [SPIRV] Non-deterministic compiler output for debug-type-pointer.ll Labels backend:SPIR-V Assignees Reporter efriedma-quic Reverse-iteration bot detected that the test llvm/test/CodeGen/SPIRV/debug-info/debug-type-pointer.ll has non-determinstic output. #123764 makes the test pass by allowing the non-deterministic output, but it's still a bug: the compiler output should be deterministic. CC @VyacheslavLevytskyy @michalpaszkowski ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123823] [ClangFormat] Space removed in `g< ::f>()` except for `Standard: c++03`
Issue
123823
Summary
[ClangFormat] Space removed in `g< ::f>()` except for `Standard: c++03`
Labels
new issue
Assignees
Reporter
reventlov
In all versions of C++ supported by ClangFormat, [the alternative operator spelling ("digraph") `<:` is treated as `[`](https://en.cppreference.com/w/cpp/language/operator_alternative). However, ClangFormat will remove a space between `<` and `:` (except when `Standard: c++03` is specified, or `Standard: Auto` is specified and no double-closing `>>` is found in the source file):
```c++
g< ::T>(); // before
g<::T>();// after, compiler error
g [ : T > ( ) ; // C++ equivalent tokenization
```
This causes problems when:
* the first template parameter must use an absolute namespace (e.g., the code is in `f::g`, namespace `f::e` exists, and the parameter is `::e::T`), and
* the code is not compiled with `-fno-digraphs` (or its equivalent in other compilers)
As far as I am aware, this is the only place where the "digraph" alternative spellings can change the meaning of otherwise-valid C++ code (and I believe there is no such case in C, where the digraph operators originated).
There is a (moderately annoying) workaround of adding a dummy comment:
```c++
g(); // safe
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123825] [HLSL] Investigate, update and document the correct function attributes for DXIL ops
Issue 123825 Summary [HLSL] Investigate, update and document the correct function attributes for DXIL ops Labels HLSL Assignees Reporter inbelic When implementing https://github.com/llvm/llvm-project/pull/117072, it was noted that there are some existing DXIL ops defined in `DXIL.td` where the currently set `DXILAttributes` might be less restrictive then they could be, or, do not have any specified attributes. For example, see [here](https://github.com/llvm/llvm-project/pull/117072#discussion_r1924046903) and [here](https://github.com/llvm/llvm-project/pull/117072#discussion_r1924068104). This issue would then track the work of investigating and documenting the correct attributes for DXIL ops, and, then specifying this for existing DXIL ops in `DXIL.td` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123728] [AMDGPU][GISel] masking instructions (`and`) not necessary
Issue
123728
Summary
[AMDGPU][GISel] masking instructions (`and`) not necessary
Labels
Assignees
Reporter
qcolombet
When comparing SDISel with GISel I stumbled on a case where GISel keeps a bunch of `and` instructions to make the values to a `i8` type.
These masks are actually useless because the value is fed to a `truncstore i8` which does the masking itself.
SDISel removes all the redundant bit logic but GISel doesn't.
I haven't dug too much into the details therefore I don't know exactly how the simplification is implemented in SDISel (this is some combines for sure, but which ones I don't know.)
Note that this is likely an issue for all targets hence a generic combiner helper is likely welcome.
# To Reproduce #
Download the attached IR or copy/past the LLVM IR input in the section below.
[repro.ll.txt](https://github.com/user-attachments/files/18489129/repro.ll.txt)
Then run:
```bash
llc -march=amdgcn -mcpu=gfx942 -mtriple amdgcn-amd-hmcsa -global-isel=<0|1> repro.ll -o -
```
# Results #
GISel ends up with a bunch of bit manipulation operations, in particular `and`s, whereas SDISel doesn't.
With GISel:
```asm
s_load_dwordx2 s[0:1], s[4:5], 0x24
v_mov_b32_e32 v2, 8
v_mov_b32_e32 v0, 0xff
s_waitcnt lgkmcnt(0)
s_lshr_b32 s2, s0, 16
s_lshr_b32 s3, s1, 16
v_cvt_f32_f16_e32 v1, s2
v_cvt_f32_f16_e32 v3, s0
v_cvt_f32_f16_e32 v4, s1
v_cvt_f32_f16_e32 v5, s3
v_cvt_i32_f32_e32 v1, v1
v_cvt_i32_f32_e32 v3, v3
v_cvt_i32_f32_e32 v4, v4
v_cvt_i32_f32_e32 v5, v5
v_and_b32_e32 v6, 0xff, v1 <-- the AND I'm talking about
v_lshlrev_b32_sdwa v1, v2, v1 dst_sel:DWORD dst_unused:UNUSED_PAD src0_sel:DWORD src1_sel:BYTE_0
v_and_or_b32 v0, v3, v0, v1
v_and_b32_e32 v1, 0xff, v4 <-- here too
v_and_b32_e32 v4, 0xff, v5 <-- here too
v_lshlrev_b32_e32 v1, 16, v1
v_lshlrev_b32_e32 v4, 24, v4
v_or3_b32 v4, v0, v1, v4
v_lshlrev_b16_e32 v0, 8, v6
v_or_b32_sdwa v0, v3, v0 dst_sel:DWORD dst_unused:UNUSED_PAD src0_sel:BYTE_0 src1_sel:DWORD
v_lshrrev_b16_e32 v3, 8, v0
v_mov_b64_e32 v[0:1], 0
global_store_byte v[0:1], v4, off
v_mov_b64_e32 v[0:1], 1
global_store_byte v[0:1], v3, off
v_mov_b64_e32 v[0:1], 2
v_lshrrev_b16_sdwa v2, v2, v4 dst_sel:DWORD dst_unused:UNUSED_PAD src0_sel:DWORD src1_sel:WORD_1
global_store_byte_d16_hi v[0:1], v4, off
v_mov_b64_e32 v[0:1], 3
global_store_byte v[0:1], v2, off
```
With SDISel:
```asm
s_load_dwordx2 s[0:1], s[4:5], 0x24
v_mov_b64_e32 v[0:1], 2
s_waitcnt lgkmcnt(0)
v_cvt_i16_f16_e32 v3, s1
s_lshr_b32 s3, s1, 16
v_cvt_i16_f16_e32 v2, s0
global_store_byte v[0:1], v3, off
v_mov_b64_e32 v[0:1], 0
s_lshr_b32 s2, s0, 16
v_cvt_i16_f16_e32 v5, s3
global_store_byte v[0:1], v2, off
v_mov_b64_e32 v[0:1], 3
v_cvt_i16_f16_e32 v4, s2
global_store_byte v[0:1], v5, off
v_mov_b64_e32 v[0:1], 1
global_store_byte v[0:1], v4, off
```
# Note #
Input IR:
```llvm
target datalayout = "e-p:64:64-p1:64:64-p2:32:32-p3:32:32-p4:64:64-p5:32:32-p6:32:32-p7:160:256:256:32-p8:128:128-p9:192:256:256:32-i64:64-v16:16-v24:32-v32:32-v48:64-v96:128-v192:256-v256:256-v512:512-v1024:1024-v2048:2048-n32:64-S32-A5-G1-ni:7:8:9"
target triple = "amdgcn-amd-amdhsa"
define amdgpu_kernel void @foo(<4 x half> %i35) {
bb:
%i90 = fptosi <4 x half> %i35 to <4 x i8>
store <4 x i8> %i90, ptr addrspace(1) null, align 1
ret void
}
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123719] [C++20] [Modules] Missing vtable for explicit template instantiation in other units
Issue
123719
Summary
[C++20] [Modules] Missing vtable for explicit template instantiation in other units
Labels
clang:modules
Assignees
Reporter
ChuanqiXu9
Reproducer:
```
// RUN: rm -rf %t
// RUN: mkdir %t
// RUN: split-file %s %t
// RUN: %clang_cc1 -std=c++20 %t/a.cppm -triple %itanium_abi_triple -emit-module-interface -o %t/a.pcm
// RUN: %clang_cc1 -std=c++20 %t/a.cc -triple %itanium_abi_triple -fmodule-file=a=%t/a.pcm -emit-llvm -o - | FileCheck %t/a.cc
//
// RUN: %clang_cc1 -std=c++20 %t/a.cppm -triple %itanium_abi_triple -emit-reduced-module-interface -o %t/a.pcm
// RUN: %clang_cc1 -std=c++20 %t/a.cc -triple %itanium_abi_triple -fmodule-file=a=%t/a.pcm -emit-llvm -o - | FileCheck %t/a.cc
//--- a.cppm
export module a;
class base {
public:
~base() = default;
virtual void foo();
};
template
class a : public base {
public:
virtual void foo() override;
};
extern template class a;
//--- a.cc
module a:impl;
import a;
template
void a::foo() {}
template class a;
// CHECK: _ZTVW1a1aIiE
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123864] [ARM] Default behavior is different about mtp with gcc
Issue 123864 Summary [ARM] Default behavior is different about mtp with gcc Labels new issue Assignees Reporter Zhenhang1213 If using ARMv7-a and later architectures， gcc use cp15 and llvm uses soft, Can I modify this default behavior? I'm sure that helps with performance https://github.com/gcc-mirror/gcc/blob/e9bd9d427a9b1c080426b0b16d3704673cbf/gcc/config/arm/arm.cc#L3968-L3974 demo:https://godbolt.org/z/6cP16naW8 ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123884] [clang] Crash at -O1
Issue
123884
Summary
[clang] Crash at -O1
Labels
Assignees
Reporter
cardigan1008
This code crashes at `-O1`:
```c
int a, b, c;
unsigned char d;
short e;
int f(long g, int h) {
switch (b) {
case 2:
return g;
default:
return *(int *)(h + g * sizeof(int));
}
}
void i(long);
void j() {
e = d >> a;
i(e);
}
void i(long g) { c = f(g + 4, g); }
int main() {}
```
Compiler Explorer: https://godbolt.org/z/6dWc1cPcb
Bisected to https://github.com/llvm/llvm-project/commit/40d952b8748bf5c4a97fc82296e1fc050388472f, which was committed by @fhahn
No crash info.
Backtrace:
```console
0. Program arguments: /opt/compiler-explorer/clang-trunk/bin/clang -gdwarf-4 -g -o /app/output.s -mllvm --x86-asm-syntax=intel -fno-verbose-asm -S --gcc-toolchain=/opt/compiler-explorer/gcc-snapshot -fcolor-diagnostics -fno-crash-diagnostics -O1 -Wall -Wextra
1. parser at end of file
2. Code generation
3. Running pass 'Function Pass Manager' on module ''.
4. Running pass 'Live Variable Analysis' on function '@j'
#0 0x03a8ded8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-trunk/bin/clang+0x3a8ded8)
#1 0x03a8c024 llvm::sys::CleanupOnSignal(unsigned long) (/opt/compiler-explorer/clang-trunk/bin/clang+0x3a8c024)
#2 0x039db3a8 CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0
#3 0x70a531442520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#4 0x02dff8eb llvm::LiveVariables::HandleVirtRegUse(llvm::Register, llvm::MachineBasicBlock*, llvm::MachineInstr&) (/opt/compiler-explorer/clang-trunk/bin/clang+0x2dff8eb)
#5 0x02ec llvm::LiveVariables::runOnInstr(llvm::MachineInstr&, llvm::SmallVectorImpl&, unsigned int) (/opt/compiler-explorer/clang-trunk/bin/clang+0x2ec)
#6 0x02e00bf4 llvm::LiveVariables::runOnBlock(llvm::MachineBasicBlock*, unsigned int) (/opt/compiler-explorer/clang-trunk/bin/clang+0x2e00bf4)
#7 0x02e01b22 llvm::LiveVariables::analyze(llvm::MachineFunction&) (/opt/compiler-explorer/clang-trunk/bin/clang+0x2e01b22)
#8 0x02e01f6d llvm::LiveVariablesWrapperPass::runOnMachineFunction(llvm::MachineFunction&) (/opt/compiler-explorer/clang-trunk/bin/clang+0x2e01f6d)
#9 0x02e9acd5 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (.part.0) MachineFunctionPass.cpp:0:0
#10 0x033f3f82 llvm::FPPassManager::runOnFunction(llvm::Function&) (/opt/compiler-explorer/clang-trunk/bin/clang+0x33f3f82)
#11 0x033f4211 llvm::FPPassManager::runOnModule(llvm::Module&) (/opt/compiler-explorer/clang-trunk/bin/clang+0x33f4211)
#12 0x033f5b79 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/opt/compiler-explorer/clang-trunk/bin/clang+0x33f5b79)
#13 0x03d30a85 clang::emitBackendOutput(clang::CompilerInstance&, llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::IntrusiveRefCntPtr, std::unique_ptr>, clang::BackendConsumer*) (/opt/compiler-explorer/clang-trunk/bin/clang+0x3d30a85)
#14 0x043d90e8 clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) (/opt/compiler-explorer/clang-trunk/bin/clang+0x43d90e8)
#15 0x0630885c clang::ParseAST(clang::Sema&, bool, bool) (/opt/compiler-explorer/clang-trunk/bin/clang+0x630885c)
#16 0x043d9805 clang::CodeGenAction::ExecuteAction() (/opt/compiler-explorer/clang-trunk/bin/clang+0x43d9805)
#17 0x046b3341 clang::FrontendAction::Execute() (/opt/compiler-explorer/clang-trunk/bin/clang+0x46b3341)
#18 0x04632d6b clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/opt/compiler-explorer/clang-trunk/bin/clang+0x4632d6b)
#19 0x0479d933 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/opt/compiler-explorer/clang-trunk/bin/clang+0x479d933)
#20 0x00d10521 cc1_main(llvm::ArrayRef, char const*, void*) (/opt/compiler-explorer/clang-trunk/bin/clang+0xd10521)
#21 0x00d08d1d ExecuteCC1Tool(llvm::SmallVectorImpl&, llvm::ToolContext const&) driver.cpp:0:0
#22 0x04425109 void llvm::function_ref::callback_fn>, std::__cxx11::basic_string, std::allocator>*, bool*) const::'lambda'()>(long) Job.cpp:0:0
#23 0x039db7d3 llvm::CrashRecoveryContext::RunSafely(llvm::function_ref) (/opt/compiler-explorer/clang-trunk/bin/clang+0x39db7d3)
#24 0x04425329 clang::driver::CC1Command::Execute(llvm::ArrayRef>, std::__cxx11::basic_string, std::allocator>*, bool*) const (.part.0) Job.cpp:0:0
#25 0x043e942d clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, clang::driver::Command const*&, bool) const (/opt/compiler-explorer/clang-trunk/bin/clang+0x43e942d)
#26 0x043ea3c1 clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&, llvm::SmallVectorImpl>&, bool) const (/opt/compiler-explorer/clang-t
[llvm-bugs] [Bug 123862] Generation of Object file gets stuck in infinite loop after enabling RISCVVLOptimizer
Issue 123862 Summary Generation of Object file gets stuck in infinite loop after enabling RISCVVLOptimizer Labels new issue Assignees michaelmaitland Reporter MaheshRavishankar I hit an issue in downstream project (IREE), where the PR to enable the RISCVVLOptimizer gets stuck in an infinite loop (i.e. after https://github.com/llvm/llvm-project/pull/119461). Reverting that seems to resolve the issue. [module_three_fry_linked_embedded_elf_riscv_64.optimized.ll.txt](https://github.com/user-attachments/files/18498078/module_three_fry_linked_embedded_elf_riscv_64.optimized.ll.txt) This is the output after what is effectively `opt` phase. The downstream project uses the c++ interface to emit object files, so I cant really reproduce the command line options for the hang, But there is not much secret sauce here on how it is generating the object file (https://github.com/iree-org/iree/blob/8c7eecaadda7931724aae3ac371fb60c1fb01873/compiler/plugins/target/LLVMCPU/LLVMIRPasses.cpp#L98) . If someone can give me tips on how I can try to get the equivalent command line for `llc` that mimics what is done there, I am happy to try. @michaelmaitland could you please provide guidance here. We have been reverting this patch downstream for a while, and it is getting hard for us to carry the revert. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123880] Build libcxx with winpthreads+
Issue 123880 Summary Build libcxx with winpthreads+ Labels Assignees Reporter void2012 Hi! I want to build my custom build of libc++ using the command line with clang-cl: `cmake -G "Visual Studio 17 2022" -S runtimes -B build ^ -T "LLVM_v141_xp" ^ -DLLVM_ENABLE_RUNTIMES=libcxx ^ -DLIBCXX_ENABLE_SHARED=YES ^ -DLIBCXX_ENABLE_STATIC=YES ^ -DLIBCXX_ENABLE_FILESYSTEM=NO ^ -DLIBCXX_INCLUDE_TESTS=NO ^ -DLIBCXX_HAS_PTHREAD_API=YES ^ -DCMAKE_CXX_FLAGS="/D_WIN32_WINNT=0x0501 /DWINVER=0x0501" ^ -DCMAKE_GENERATOR_PLATFORM=Win32` However, during the build the compiler can't find `pthread.h` and `sched.h`, which is not surprising. But how do I specify the path for the winpthreads library to depend on? Thanks! ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123831] [HLSL] Move helper functions out of SemaHLSL into a common location for SemaSPIRV to use
Issue 123831 Summary [HLSL] Move helper functions out of SemaHLSL into a common location for SemaSPIRV to use Labels new issue Assignees Reporter Icohedron While working on #122992, @inbelic mentioned that the semantics checks in `clang/lib/Sema/SemaSPIRV.cpp` could be simplified by using helper functions that are currently only present in `clang/lib/Sema/SemaHLSL.cpp`. It would be useful to migrate the helper functions out of `SemaHLSL` into a common location accessible to both `SemaHLSL` and `SemaSPIRV` to make the code in `SemaSPIRV` less verbose and more readable. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123838] Request Commit Access For Icohedron
Issue 123838 Summary Request Commit Access For Icohedron Labels Assignees Reporter Icohedron ### Why Are you requesting commit access ? I am part of the team at Microsoft currently working on implementing HLSL support in Clang/LLVM for the DXIL and SPIR-V backends. I have so far created 2 PRs that have been reviewed and merged with the help of my colleagues. - #122202 - #122992 More contributions will be coming as I continue to work on the team. Therefore, I would like to request commit access to streamline the process by which my future contributions will be made. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123835] [BOLT] `llvm-bolt` sporadic assertion failure in `BinaryBasicBlock::isCold()` during shrink wrapping with `-O3`
Issue
123835
Summary
[BOLT] `llvm-bolt` sporadic assertion failure in `BinaryBasicBlock::isCold()` during shrink wrapping with `-O3`
Labels
BOLT
Assignees
Reporter
ms178
**Description:**
While trying to pinpoint another bug, I saw one assertion failure on a Clang-20git assertion build. `llvm-bolt` crashes with an assertion failure when optimizing a binary (dbus-broker in this case) with `-O3` in an assertion build of LLVM. This however didn't reproduce when using `-O2`. The crash occurs during the shrink-wrapping optimization pass.
**Environment:**
* **LLVM Version:** 20.0.0git (e4f03b158c97098e1835cc1f00d0175398974f98) plus [these BOLT-patches](https://github.com/ms178/archpkgbuilds/blob/main/toolchain-experimental/llvm-git/fixes.patch) on top.
* **Operating System:** CachyOS
* **Target Architecture:** Intel Raptor Lake
* **Build Type:** Assertion build (compiled with assertions enabled)
* **Reproducibility:** Not consistent. While it occured the first time, I can't reproduce it always.
```
export CC=clang
export CXX=clang++
export CC_LD=lld
export CXX_LD=lld
export AR=llvm-ar
export NM=llvm-nm
export STRIP=llvm-strip
export OBJCOPY=llvm-objcopy
export OBJDUMP=llvm-objdump
export READELF=llvm-readelf
export RANLIB=llvm-ranlib
export HOSTCC=clang
export HOSTCXX=clang++
export HOSTAR=llvm-ar
export CPPFLAGS="-D_FORTIFY_SOURCE=0"
export CFLAGS="-O3 -march=native -mtune=native -falign-functions=32 -fno-semantic-interposition -fcf-protection=none -mharden-sls=none -w"
export CXXFLAGS="${CFLAGS} -Wp,-U_GLIBCXX_ASSERTIONS"
export LDFLAGS="-Wl,-O3,-Bsymbolic-functions,--as-needed -fcf-protection=none -mharden-sls=none -Wl,--hash-style=gnu -Wl,--undefined-version"
export CCLDFLAGS="$LDFLAGS"
export CXXLDFLAGS="$LDFLAGS"
export ASFLAGS="-D__AVX__=1 -D__AVX2__=1 -D__FMA__=1"
```
**Steps to Reproduce:**
1. Compile `dbus-broker` (with my optimized [PKGBUILD](https://github.com/ms178/archpkgbuilds/blob/main/packages/dbus-broker-git/PKGBUILD)) with `-O3` and the flags from above using an assertion build of Clang.
2. Generate PGO data (e.g., `perf.fdata`). The neccessary steps and flags are integrated in the PKGBUILD I provided.
3. Run `llvm-bolt` on the linked binary with the following command line (adjust paths as needed):
```bash
llvm-bolt "$srcdir/build/src/dbus-broker" --data "$srcdir/bolt_profile/perf.fdata" --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 --hugify --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 -o "$srcdir/build/bolt/dbus-broker.bolt"
```
**Expected Result:**
`llvm-bolt` should successfully optimize the binary without crashing.
**Actual Result:**
`llvm-bolt` crashes with the following assertion failure:
```
llvm-bolt: /home/marcus/toolchain/llvm/llvm-project/bolt/include/bolt/Core/BinaryBasicBlock.h:677: bool llvm::bolt::BinaryBasicBlock::isCold() const: Assertion `Fragment.get() < 2 && "Function is split into more than two (hot/cold)-fragments"' failed.
```
**Stack Trace:**
```
#0 0x5d009882d785 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) Signals.cpp:0:0
#1 0x5d009882db7c SignalHandler(int) Signals.cpp:0:0
#2 0x78c0ae445f50 (/usr/lib/libc.so.6+0x45f50)
#3 0x78c0ae4b57ed pthread_kill (/usr/lib/libc.so.6+0xb57ed)
#4 0x78c0ae445e92 raise (/usr/lib/libc.so.6+0x45e92)
#5 0x78c0ae4244a3 abort (/usr/lib/libc.so.6+0x244a3)
#6 0x78c0ae4243d8 (/usr/lib/libc.so.6+0x243d8)
#7 0x78c0ae43bde2 (/usr/lib/libc.so.6+0x3bde2)
#8 0x5d0099199b65 llvm::bolt::ShrinkWrapping::perform(bool) (/home/marcus/toolchain/llvm/stage2-prof-use-lto/bin/llvm-bolt+0x4599b65)
#9 0x5d00990d0dd2 std::_Function_handler::_M_invoke(std::_Any_data const&, llvm::bolt::BinaryFunction&, unsigned short&&) FrameOptimizer.cpp:0:0
#10 0x5d009928c3d5 llvm::bolt::ParallelUtilities::runOnEachFunctionWithUniqueAllocId(llvm::bolt::BinaryContext&, llvm::bolt::ParallelUtilities::SchedulingPolicy, std::function, std::function, std::__cxx11::basic_string, std::allocator>, bool, unsigned int)::$_0::operator()(std::_Rb_tree_iterator>, std::_Rb_tree_iterator>, unsigned short) const ParallelUtilities.cpp:0:0
#11 0x5d0098984258 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
#12 0x5d00988bee01 std::__future_base::_State_baseV2::_M_d
[llvm-bugs] [Bug 123848] [compiler-rt] circular dependency on libc
Issue 123848 Summary [compiler-rt] circular dependency on libc Labels compiler-rt Assignees Reporter nickdesaulniers cc @petrhosek @frobtech @michaelrj-google @pcc @compnerd Ideally, we'd be able to build the compiler builtins without depending on the libc (for purposes of bootstrapping a system). Right now, I observe build failures for the `builtins` ninja target when attempting to bootstrap such a sysroot: - compiler-rt/lib/builtins/emutls.c depends on - compiler-rt/lib/builtins/clear_cache.c depends on - compiler-rt/lib/builtins/enable_execute_stack.c depends on - compiler-rt/lib/builtins/eprintf.c depends on - compiler-rt/lib/builtins/cpu_model/x86.c depends on It looks like `COMPILER_RT_BAREMETAL_BUILD` can be unset to disable the addition of emutls.c, enable_execute_stack.c, and eprintf.c . (Ah @petrhosek has been here before, thanks @petrhosek !) AFAICT, there's currently no cmake option to skip building the rest. Otherwise, it seems like we may have a circular dependency between the compiler builtins and the libc. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123855] [libc++] Question about __libcpp_timed_backoff_policy implementation
Issue
123855
Summary
[libc++] Question about __libcpp_timed_backoff_policy implementation
Labels
libc++
Assignees
Reporter
bobsayshilol
I'm not sure if this is the right place to ask this, but I tried using `std::barrier` and observed large sleep calls that I wasn't expecting when calling `wait()`. The issue seems to occur because of the interaction of the 2 largest checks in `__libcpp_timed_backoff_policy`:
https://github.com/llvm/llvm-project/blob/635e154bbc94342080ccba583ff6fb16ea364f4b/libcxx/include/__thread/timed_backoff_policy.h#L28-L31
Once `__elapsed` goes over 64 *micro*seconds we then backoff at increasing intervals until it reaches 128 *milli*seconds, at which point we then cap it to only 8ms. This means that it can sleep for up to 64ms before dropping down to 8ms.
As an example repro case:
```c++
int main() {
// In practice this doesn't get close to 1M entries, but play it safe.
std::vector timings(1'000'000);
std::size_t counter = 0;
chrono::nanoseconds last_elapsed = chrono::nanoseconds::zero();
auto capture_backoff_timings = [&](chrono::nanoseconds elapsed) {
// Save elapsed time to avoid an additional now() call in __poll().
last_elapsed = elapsed;
// Add the elapsed time of this call to the timings.
timings[counter] = elapsed;
++counter;
return __libcpp_timed_backoff_policy{}(elapsed);
};
auto poll_for_200ms = [&] {
// As cheap as we can make it - this is just an atomic load in std::barrier::wait().
return last_elapsed > chrono::milliseconds(250);
};
__libcpp_thread_poll_with_backoff(poll_for_200ms, capture_backoff_timings);
// Sanity check.
assert(counter < timings.size());
timings.resize(counter);
// Convert timings to how long the sleeps are.
std::vector sleeps(counter);
std::adjacent_difference(timings.begin(), timings.end(), sleeps.begin());
// Print largest sleep call.
auto max_sleep = std::max_element(sleeps.begin(), sleeps.end());
auto &os = std::cout;
os << "max sleep: "
<< chrono::duration_cast(*max_sleep).count()
<< "ms\n";
#if 0 // Print timings too for graphing.
os << "timings = [";
for (auto &t : timings) {
os << t.count() << ',';
}
os << "]\nsleeps = [";
for (auto &s : sleeps) {
os << s.count() << ',';
}
os << "]\n";
#endif
}
```
Running this locally prints `max sleep: 59ms` (it's consistently in the 40-60ms range) and plotting out the timings (with 0 markers) gives this:
I don't know if `chrono::milliseconds(128)` is meant to be in `microseconds` or if it should be `chrono::milliseconds(8)` to match the final backoff value, or if this is intentionally a large wait? I couldn't see anything on the PR that introduced this code https://reviews.llvm.org/D68480, though the "Show Older Changes" button doesn't seem to work so it might be hidden in there.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123886] Request Commit Access For hchandel
Issue 123886 Summary Request Commit Access For hchandel Labels infra:commit-access-request Assignees Reporter hchandel ### Why Are you requesting commit access ? Dear LLVM Maintainers, I am Harsh Chandel, a software developer with more than one and half years of experience in LLVM development. I am writing to request commit access to the LLVM repository on GitHub. Over the past few months, I have actively contributed to the LLVM project by submitting patches related to a RISC V extension. My work has been focused on adding assembler support for RISC V extensions, and I have collaborated with other contributors to ensure high-quality code and documentation. I am applying for commit access because I believe it will enable me to contribute more efficiently and effectively to the project. Having direct access will allow me to integrate my changes more seamlessly, respond to feedback promptly, and maintain the momentum of ongoing development efforts. I am committed to adhering to the project's guidelines and maintaining the high standards of the LLVM community. I am confident that my contributions will help advance the project and benefit the broader community of developers who rely on LLVM. Thank you for considering my request. I look forward to continuing my work with the LLVM community. Best regards, Harsh Chandel quic_hchan...@quicinc.com hchandel ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123887] Request Commit Access For vvchernov
Issue 123887 Summary Request Commit Access For vvchernov Labels infra:commit-access-request Assignees Reporter vvchernov ### Why Are you requesting commit access ? Recently I've started to work for NVIDIA on internal fork of LLVM compiler, in general on LLVM IR and NVPTX backend improvements. I plan to be more involved in the original LLVM development. We have strict policy of new patch merging only after approvals from couple of reviewers. But I have some inconveniences related to merging after approval due to time zone differences with my colleagues and LLVM reviewers. To accelerate this process I need an commit access. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
