[llvm-bugs] [Bug 123920] [LoopInterchange] Interchange potentially breaks the program correctness
Issue
123920
Summary
[LoopInterchange] Interchange potentially breaks the program correctness
Labels
Assignees
Reporter
kasuga-fj
In the following program, LoopInterchange incorrectly interchanges the innermost two loops.
```c
#define N 4
int a[N*N][N*N][N*N];
void f() {
for (int i = 0; i < N; i++)
for (int j = 1; j < 2*N; j++)
for (int k = 1; k < 2*N; k++)
a[2*i][k+1][j-1] -= a[i+N-1][k][j];
}
```
See also: https://godbolt.org/z/rfev9drn7
Note that the current LoopInterchange interchanges these loops twice, therefore the order returns to the original one. So this case works fine.
The problem here is that the LoopInterchange regards `Dependence::DVEntry::LE` as '<'. As a result, the direction vector becomes `[< < >]`. Swapping the innermost loops changes this to `[< > <]`, which passes the legality check. In fact, we must also consider the direction vector such as `[= < >]`.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123960] [flang][debug] Compiler take extremely long time to finish
Issue 123960 Summary [flang][debug] Compiler take extremely long time to finish Labels flang Assignees abidh Reporter abidh The linaro reported an issue in https://linaro.atlassian.net/browse/LLVM-1528 where [this file](https://github.com/fujitsu/compiler-test-suite/blob/main/Fortran/0394/0394_0031.f90) from the fujitso testsuite will fail to compile after PR#122770. I looked at it and it seems that compiler is not crashing or stuck. The file has a lot of cyclic derived types and it is taking long time to finish with -g. The code is quite contrived but the compilation time should be reduced. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123961] [QUERY][MLIR] How to access dense resource
Issue
123961
Summary
[QUERY][MLIR] How to access dense resource
Labels
mlir
Assignees
Reporter
Abhishek-TyRnT
```
module {
func.func @Linear(%arg0: tensor<1x25x30xf32>) -> tensor<1x25x25xf32> {
%0 = "tosa.const"() <{value = dense_resource : tensor<25xf32>}> : () -> tensor<25xf32>
%1 = "tosa.const"() <{value = dense_resource : tensor<25x30xf32>}> : () -> tensor<25x30xf32>
%2 = "tosa.const"() <{value = dense<[1, 0]> : tensor<2xi32>}> : () -> tensor<2xi32>
%3 = tosa.transpose %1, %2 : (tensor<25x30xf32>, tensor<2xi32>) -> tensor<30x25xf32>
%4 = tosa.reshape %3 {new_shape = array} : (tensor<30x25xf32>) -> tensor<1x30x25xf32>
%5 = tosa.matmul %arg0, %4 : (tensor<1x25x30xf32>, tensor<1x30x25xf32>) -> tensor<1x25x25xf32>
%6 = tosa.reshape %5 {new_shape = array} : (tensor<1x25x25xf32>) -> tensor<25x25xf32>
%7 = tosa.reshape %0 {new_shape = array} : (tensor<25xf32>) -> tensor<1x25xf32>
%8 = tosa.add %6, %7 : (tensor<25x25xf32>, tensor<1x25xf32>) -> tensor<25x25xf32>
%9 = tosa.reshape %8 {new_shape = array} : (tensor<25x25xf32>) -> tensor<1x25x25xf32>
return %9 : tensor<1x25x25xf32>
}
}
{-#
dialect_resources: {
builtin: {
torch_tensor_25_torch.float32: "0x040062751EBE83E6DE3DBCF621BE9B87BA3DCE8338BE697509BE1C641DBE79DA11BDDFFDADBD546D02BD7C6D333E66B4073C032CD4BD043B333DA217223E341CC7BC1397A4BD4D5CD73D6306C1BD829429BE1B9F8A3D35F714BE25B19FBDC19A143E702EBDBD",
torch_tensor_25_30_torch.float32: "0x0400833D053D0253F5BC377B18BE16A1093E1840BABD302CA73D1E384CBC6E480FBCD019EDBD72F100BEB68F7E3D3D5A2F3E429519BE3F0FBFBD0126013EE242B93DA059ABBD36AE0DBD53F89BBD6FDBDFBC23E43ABE0F41D53CC43535BEBAA7A93D93925EBCED32103D331DB73DABAB83BD356820BE6B9FA13DD302E03C4164EF3DB4D4953D9A0F3ABEAC10D03DCAD00E3E0D848BBDC6908B3DBA9C2CBEACEE2C3EB89E8EBDE426173E67FF51BDB86413BD3C87313D4B322E3EF35F223EF058DFBD285EAE3C2C7F3A3E9FA723BE5A9F1C3EE4AD37BE0AA28EBD88375CBC030613BE682CFCBBFD9A88BA46CFEA3BBEF98E3A2E482E3D2611BEBD823FD53BCC42EB3C09850A3E42E12B3EED8AEFBC56EA16BE6A5DCA3D4D264B3D04711D3EFB1D153CC7DCDEBD6E641A3E00465C3D341524BE0C4C84BD204D53BD43F92ABEA72316BD132BEFBC6354123CCDAEA9BDF403A4BC0C527B3BCB00103ED593CE3D241E7C3DCC992F3E35B5D1BB3097123E9CD0033E14D2E63D3FE7E73DF30E03BDACBEEEBC24F29C3D221F8BBDAC3142BD6D092FBE0DFD51BC7E0F5D3DB211BABDCDD4A9BCB7FF85BDD3380CBD931DC4BC4606CF3D996E8BBDDF84ED3B58D5E7BC050A01BE327D93BD1CE02DBDA05B033ED5CCBDBA728129BEA3D722BE2F070BBE1368ABBD6DFAF8BDB59C34BD916835BE452A1CBBE91B17BDA4F825BD1A611B3E6F15023E1D4AF7BDA97C933C9DEE6C3D1EB96C3C61E41F3DEC322FBD1D528ABDEE85103DAF01283E6F21EC3D2D8FE3BDCF6BD03D017F38BE0DA3013E2B1F0FBCC6A183BD6672EEBD44F12BBCEDE6F83D0B6FE6BD9A922B3D7051A93C27B3D83DAEC372BD00F607BE11F3373E021751BD051FAE3D1A7A08BD629CD63D98A60D3E93BB06BE05AC1A3EBC3D5F3D90B5CA3DEFE5E63DE3151ABE40A8E4BDCFA7B0BB343AEBBDCB49303EB26EB3BD7A2D87BD9809C53D14F42D3D7A72033D47D6F13D5283383EC477013EE68BF4BDCEC545BD3BF42E3E091D1FBE931ECA3DA29775BDE5A97ABC208BD1BCD554DFBD72B1243DD2B0DD3A468603BE928B313D10140FBEB335AD3CEA25163E92FB40BC88A87FBD8F2186BD0B32D63D85DE96BD5A2FCFBDE0CF3FBD9A05533DA6E72C3E6792C93B6FAF46BD7BA509BD0E559A3C51A34E3CFCC0AE3D177909BD7D96D03D1ACBCCBD88FDF53CB243C4BD213D6C3D0367B9BDA104E0BDB495E6BCE0DE25BDE8BF21BE8B2C393DCEE50B3ED19A0F3E8794073E3EE6DFBD3D35EE3DAA91153EE3E68D3DEC28B8BDF51312BE15A5043EA2E78A3D65CC87BD186436BDC9BC19BE776FAA3D2DEA49BDD7E6253D1AC988BD6CABF53CB676CABCC44AD03DC626CCBCC2CBEE3D6CBB39BED3D276BDC08407BEB131F23DAF201ABE5A518EBDBF8CED3D933ABCBCBD477A3DC0B89DBDDEC1EB3D56463B3CA6278FBD8387523D1357B73BEE8C35BEC4B6B73D997CFFBD41E931BD32041A3D37C6D63BED51C43BEDA738BD867C103EF0BC6EBD93F1A73C5927DB3DA2B6A63C053A05BE741F6A3C1A35033E0B11523C0EFCF73DD39F303E0A594DBD2F62193E2816413D19CB403D51A6E9BCD809DDBDBD38993DD54032BE260780BDB0F2C63DF51B8ABDFDB6253E04F586BC6FF5B33DC440B3BDF29BA0BDAF3C8D3D0D8A0EBE094F8E3B8F17753D1F3FAC3D43D22CBE68CEDDBD57A3A4BDB097C63D1CD40D3E2E2641BD848F8DBBAC9715BEFF57553D75B112BD530CBB3D0342C5BD62C0F9BC47C7233E83B0E1BD5AB434BDC21F98BDC14F043D997B193EDFBC253C75603FBDBD418ABC293AF7BD3903DF3C7FDA73BD3794E5BD36497EBDEC5A86BCE0D51BBD27D2C13DBCD3FC3D245208BE843F913DA306CFBC3547153E44CCE13CEA21313E349124BEBE0535BE77F3DB3D5926483D84362D3E4EF4A83DE080DE3DE087C7BD02A52FBD2552C1BDFCBCB73D572519BCFDF2093E6220C83D265F223EB122D83D8669B3BDED62A0BC625C8ABDA352683BA6FDA8BDC0CECBBD27CE4E3D29DC043E8A4988BD8A9B6F3CEAB4A03DF596E6BD0290F03C2B05DE3BAADB0BBD311709BE17E8053ECCBE9A3D20ED4EBD993808BE6852E43D43A9EEBDF294A9BCDFC10BBE801DB13D950F9D3B126BCA3D12FC04BE9ADF29BEB88D033E50EE3ABEDE8AA53D5AEB953D7A20D83D2CD7CB3CB69EAF3DFDA107BEF65398BDEDCD19BEC0991F3E9CFD07BB7AA9B8BC7046A2BD202CD3BDB115303E747CC03D9D44DBBDB17532BE7BE3DCBDA4BCB2BDFC1130BEDF58B5BC7A37E8BCDA5DE1BD327F19BE9C0B6EBC93E542BDCBBC1D3E1850503B6B541ABEAF6D35BCC1E7E
[llvm-bugs] [Bug 123937] Release LLVM Lit 19.x versions to PyPi
Issue 123937 Summary Release LLVM Lit 19.x versions to PyPi Labels llvm-lit Assignees Reporter junlarsen The PyPi package for Lit has not been updated since the 18.x branches https://pypi.org/project/lit/#history. Discussion on the Discord suggests that there are problems with the release workflow for Lit. https://discord.com/channels/636084430946959380/654052269301694465/1331497658912604243 cc @tru @tstellar ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123938] [X86] Use X86ISD::BSF/BSR fall through operands to be used for general values
Issue 123938 Summary [X86] Use X86ISD::BSF/BSR fall through operands to be used for general values Labels backend:X86 Assignees Reporter RKSimon Followup to #123623 which added a fall through operand to X86ISD::BSF/BSR nodes to handle 'src is zero' behavior on supported CPUs. We can use the fall through for other cases than the bitwidth constant values which we currently handle. There are a couple of gotchas to address: - [ ] Must still be limited to CPUs that support fall through on BSF/BSR instructions - [ ] The "REP BSF" -> TZCNT performance hack in X86MCInstLower::Lower will need adjusting to only work for undef / correct constants - [ ] Additional tests (both for constant and variable fall through values) will be necessary as we can't guarantee that 32-bit BSR/BSF instructions correctly zero the upper 32-bits of a register ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123935] [X86] __int128 parameters cause wrong location for subsequent i64
Issue
123935
Summary
[X86] __int128 parameters cause wrong location for subsequent i64
Labels
backend:X86,
ABI
Assignees
Reporter
aengelke
For this code:
```c++
long call8(long, __int128, __int128, __int128, long x) {
// IR signature from Clang: define i64 @call8(i64, i64, i64, i64, i64, i128, i64)
return x;
}
```
- GCC passes parameters in (rdi), (rsi, rdx), (rcx, r8), ([rsp+8], [rsp+16]), (r9).
- Clang/LLVM passes paremeters in (rdi), (rsi, rdx), (rcx, r8), ([rsp+8], [rsp+16]), ([rsp+24]).
Since fa1b6e6b34eb6382c451f3a06a7c52d7ac6ada1d, the i128 is no longer split between register and stack, but the SysV ABI also states:
> If there are no registers available for any eightbyte of an argument, the whole argument is passed on the stack. If registers have already been assigned for some eightbytes of such an argument, the assignments get reverted.
I (and GCC) read this as: the entire i128 gets passed on the stack and r9 becomes allocatable again. ([Godbolt](https://godbolt.org/z/zE3E3n7eP)) `CCAssignToStackWithShadow`allocates `r9`, but I think this should just be an `CCAssignToStack` that doesn't allocate r9.
Originally found by @pfent; cc @nikic
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123921] [ClangFormat] Print paths with null (git)
Issue 123921 Summary [ClangFormat] Print paths with null (git) Labels Assignees Reporter createyourpersonalaccount I use `clang-format` in my git pre-commit hook to format my diffs: ```sh git clang-format --staged \ | tail -n +2 \ | xargs git add ``` *This is not a secure git hook due to tricky filenames.* The issue with `git clang-format --staged` is that it lacks an option to print the affected paths with nulls, hence it is non-composable in the shell, see e.g. . The way to fix this is to provide an option like `-z` (xargs has `-0`, find has `-z`, etc) that will make the affected paths be printed with null bytes at their end. Then the above command could be changed to: ```sh git clang-format --staged -z \ | xargs -0 git add ``` and there would not be any issues with the parsing of the filenames by xargs. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123946] va_start doesn't like precompiled headers
Issue
123946
Summary
va_start doesn't like precompiled headers
Labels
new issue
Assignees
Reporter
Alcaro
```
cmake_minimum_required(VERSION 3.16)
project(jnipch)
set(CMAKE_CXX_STANDARD 23)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_COMPILER clang++-19)
set(CMAKE_CXX_FLAGS -stdlib=libc++)
file(WRITE "pch.h" "
#include
")
file(WRITE "main.cpp" "
#include
void NewObject(int arg, ...) {
va_list args;
va_start(args, arg);
va_end(args);
}
")
add_library(jnipch SHARED main.cpp)
target_precompile_headers(jnipch PRIVATE "pch.h")
```
Expected: Compile properly
Actual:
```
[ 33%] Building CXX object CMakeFiles/jnipch.dir/cmake_pch.hxx.pch
[ 66%] Building CXX object CMakeFiles/jnipch.dir/main.cpp.o
main.cpp:5:14: error: cannot initialize a parameter of type '__va_list_tag *' with an lvalue of type 'va_list' (aka '__va_list_tag[1]')
5 | va_start(args, arg);
| ^~~~
/opt/compiler-explorer/clang-19.1.0/lib/clang/19/include/__stdarg_va_arg.h:17:48: note: expanded from macro 'va_start'
17 | #define va_start(ap, param) __builtin_va_start(ap, param)
| ^~
main.cpp:6:12: error: cannot initialize a parameter of type '__va_list_tag *' with an lvalue of type 'va_list' (aka '__va_list_tag[1]')
6 | va_end(args);
| ^~~~
/opt/compiler-explorer/clang-19.1.0/lib/clang/19/include/__stdarg_va_arg.h:19:37: note: expanded from macro 'va_end'
19 | #define va_end(ap) __builtin_va_end(ap)
| ^~
2 errors generated.
```
https://godbolt.org/z/9vzoEabPj
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123947] Finalise setup of buildbot for RISC-V RVA23 EVL tail folding
Issue 123947 Summary Finalise setup of buildbot for RISC-V RVA23 EVL tail folding Labels backend:RISC-V Assignees Reporter asb This requires a builder with: `-march=rva23u64 -mllvm -force-tail-folding-style=data-with-evl -mllvm -prefer-predicate-over-epilogue=predicate-else-scalar-epilogue'` and ideally qemu settings `rvv_ta_all_1s=true,rvv_ma_all_1s=true,rvv_vl_half_avl=true` to maximise the chance of finding bugs. This will be done using the same cross-compile and then execute under qemu-system setup used for the RVA20 bot. Not all items below are specific to the RVA23 bot. This requires: * [x] Update to QEMU 9.2.0 and check for no regressions * [x] Redeploy x86-64 host with appropriate config * [x] Resolve sporadic failures due to running out of disk space. * Bumping the size of llvm-project.img worked. Issues were sporadic seemingly due to varying test order meaning disk size limits were sometimes reached with temporary files but sometimes not. * [x] Get a working local debug flow for subsets of the LLVM tests (`ninja check-llvm-executionengine` for instance fails to work due to llvm-lit being invoked from a different subdirectory and lit-on-qemu not handling this) * [x] Investigate and fix failures for MCJIT/ExecutionEngine tests * Issue was a failure to set `-DLLVM_HOST_TRIPLE=riscv64-linux-gnu` leading to a confusing compilation flow for mcjit/executionengine * [x] Resolve issues with host python3 path not matching the one under qemu-system (e.g. when using pip on the host) * Explicitly passing `-DPython3_EXECUTABLE=/usr/bin/python3` resolves this * [x] Resolve issues with buildbot running under python3.13 on the host * Manual fix for pipes.quote usage and depend on legacy-cgi installed via pip * [ ] (non-blocking issue) Document Python 3.13 workarounds in docs on local builder testing * [ ] Resolve test failures for small subset of tests that try to use lit-on-qemu (set through `-DLLVM_EXTERNAL_LIT`) internally. Seems to primarily be the update_test_checks tests. * Could potentially mask these tests, or alternatively find a way to override the lit path for just these tests, or set up lit-on-qemu in the correct path under qemu-system that just forwards to lit. * [ ] (non-blocking issue) Figure out why MCJIT/ExecutionEngine tests aren't running with e.g. `ninja check-llvm-executionengine` (marked as 'unsupported', even the RISC-V ones). * [ ] Receive review on PR to switch over rva23 evl builder https://github.com/llvm/llvm-zorg/pull/358 * [ ] Finalise x86-64 host deployment for rva23 evl builder once llvm-zorg#358 lands * [ ] Test enabling the test suite locally and resolve any issues * [ ] Enable the running of the test suite on rva23 evl builder * [ ] Evaluate what other LLVM subprojects can/should be enabled in this setup (and expand this list to cover that work) ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123948] [flang][openmp] omp_lib does not work when `-fdefault-integer-8` is specified
Issue 123948 Summary [flang][openmp] omp_lib does not work when `-fdefault-integer-8` is specified Labels flang:openmp Assignees Reporter jeanPerier ``` subroutine bug_with_default_integer_8(i) use omp_lib, only : omp_set_num_threads integer :: i call omp_set_num_threads(i) end subroutine ``` `flang -fdefault-integer-8 -fopenmp -c`: ``` error: Actual argument type 'INTEGER(8)' is not compatible with dummy argument type 'INTEGER(4)' ``` The opemp standard mandates the signature of omp_set_num_threads to be the default integer, so I think it should work even when the default integer is mapped to something else than integer(4). gfortran succeeds compiling this example with -fdefault-integer-8, and so does nvfortran with `-i8`. Note that ifort/ifx however compiles with a warning about interface mismatch and most likely produces broken code. Maybe omp_lib methods should be implemented as generic interfaces allowing multiple kinds? ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123970] RegAllocPBQP inaccessible
Issue
123970
Summary
RegAllocPBQP inaccessible
Labels
new issue
Assignees
Reporter
Bob64375
Hi,
I am having difficulty getting llvm to use the RegAllocPBQP algorithm in 19.1.0, not that that's an issue in 19, I had the same difficulty in 15 before upgrading.
I have examined these ways to choose RegAllocPBQP:
1. "-regalloc={greedy,default,fast,basic}" does not support pbqp.
2. std::unique_ptr fpm;
fpm->add( llvm::createDefaultPBQPRegisterAllocator() );
Asserts with "Pass [llvm::SlotIndexesWrapperPass] is not initialized"
Some thoughts:
A. Is RegAllocPBQP deprecated and I shouldn't bother?
B. Am I unaware of another way besides legacy FunctionPassManager to add the PBQP allocator? - which it seems would also require disabling "-regalloc" since otherwise it would seem two different allocators would be requested.
C. No one's gotten around to integrating RegAllocPBQP into the "-regalloc" methodology?
Notes:
- Target is x64
- Other than trying PBQP is there an option to block spilling?
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123968] [DirectX] Figure out vector alignments and data layout
Issue 123968 Summary [DirectX] Figure out vector alignments and data layout Labels backend:DirectX Assignees Reporter llvm-beanz A few years ago I posted a patch to phabricator to try and represent DXIL's odd vector alignment rules in the LLVM data layout (https://reviews.llvm.org/D133379). That patch isn't quite right, but we likely need to figure out something in order to get correct vector alignment especially as we're trying to add vectors to DXIL in SM 6.9. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123972] BackPort 2719a5d7ef30908de9e140ab4fd1b01c9e11d51c to 19.x
Issue 123972 Summary BackPort 2719a5d7ef30908de9e140ab4fd1b01c9e11d51c to 19.x Labels new issue Assignees Reporter Arteiimis https://github.com/llvm/llvm-project/issues/121242 https://github.com/fnc12/sqlite_orm/pull/1373 https://github.com/fnc12/sqlite_orm/issues/1358 ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 124014] Deprecate the use of `LLVM_ENABLE_PROJECTS` for openmp
Issue 124014 Summary Deprecate the use of `LLVM_ENABLE_PROJECTS` for openmp Labels openmp Assignees Reporter petrhosek We should deprecate the use of `LLVM_ENABLE_PROJECTS` for openmp in favor of `LLVM_ENABLE_RUNTIMES` which would greatly simplify the build and allow improvements that are currently not possible. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123999] [AArch64] negate + exctract high half can be done with vsubhn
Issue
123999
Summary
[AArch64] negate + exctract high half can be done with vsubhn
Labels
new issue
Assignees
Reporter
dzaima
https://godbolt.org/z/hbGc6M3K6
The following functions:
```c
uint8x8_t neg_narrow(uint16x8_t a) {
uint16x8_t b = vmvnq_u16(a);
return vshrn_n_u16(b, 8);
}
uint8x8_t neg_narrow_vsubhn(uint16x8_t a) {
uint16x8_t _ones_ = vdupq_n_u16(0x);
return vsubhn_u16(ones, a);
}
```
produce:
```asm
mvn v0.16b, v0.16b
shrnv0.8b, v0.8h, #8
```
whereas they could produce:
```asm
mvniv31.4s, 0
subhn v0.8b, v31.8h, v0.8h
```
This is especially meaningful in a loop, where the constant can be initialized outside of the loop. (whether it's better or worse for a single use depends on architecture)
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 124001] Cannot select SystemZISD::GET_CCMASK with PGO instrumentation
Issue
124001
Summary
Cannot select SystemZISD::GET_CCMASK with PGO instrumentation
Labels
new issue
Assignees
Reporter
cuviper
Using this reduced IR from Rust:
```llvm-ir
; ModuleID = 'reduced.bc'
target datalayout = "E-m:e-i1:8:16-i8:8:16-i64:64-f128:64-v128:64-a:8:16-n32:64"
target triple = "s390x-unknown-linux-gnu"
define void @"_ZN4core3num22_$LT$impl$u20$u128$GT$14from_str_radix17hca3660e94cc40985E"(ptr %0, i128 %.sroa.0.0) #0 {
br label %2
2: ; preds = %2, %1
%.sroa.0.01 = phi i128 [ %.sroa.0.0, %1 ], [ %.sroa.01.1, %2 ]
%3 = load i32, ptr %0, align 4
%4 = zext i32 %3 to i128
%5 = call { i128, i1 } @llvm.uadd.with.overflow.i128(i128 %.sroa.0.01, i128 %4)
%6 = extractvalue { i128, i1 } %5, 1
%.sroa.01.1 = select i1 %6, i128 %.sroa.0.0, i128 0
br label %2
}
; Function Attrs: nocallback nofree nosync nounwind speculatable willreturn memory(none)
declare { i128, i1 } @llvm.uadd.with.overflow.i128(i128, i128) #1
attributes #0 = { "target-cpu"="z13" }
attributes #1 = { nocallback nofree nosync nounwind speculatable willreturn memory(none) }
```
A simple `opt -O1 | llc` pipeline works.
However, adding PGO instrumentation fails:
```
$ opt -pgo-kind=pgo-instr-gen-pipeline -O1 , Constant:i32<3>
t168: i32 = truncate t167
t167: i128 = AssertZext t165, ValueType:ch:i1
t165: i128 = SystemZISD::VACC t212, t73
t212: i128 = SystemZISD::SELECT_CCMASK t23, Constant:i128<0>, TargetConstant:i32<14>, TargetConstant:i32<6>, t211
t23: i128,ch = CopyFromReg t0, Register:i128 %4
t22: i128 = Register %4
t24: i128 = Constant<0>
t206: i32 = TargetConstant<14>
t207: i32 = TargetConstant<6>
t211: i32 = SystemZISD::ICMP t178, Constant:i32<0>, TargetConstant:i32<0>
t178: i32 = truncate t177
t177: i128 = AssertZext t176, ValueType:ch:i1
t176: i128 = SystemZISD::VACC t210, t89
t210: i128 = SystemZISD::SELECT_CCMASK t23, Constant:i128<0>, TargetConstant:i32<14>, TargetConstant:i32<6>, t209
t89: i128,ch = load<(load (s32) from %ir.0), zext from i32> t95, t9, undef:i64
t157: i32 = Constant<0>
t204: i32 = TargetConstant<0>
t73: i128,ch = load<(load (s32) from %ir.0), zext from i32> t79, t9, undef:i64
t9: i64,ch = CopyFromReg t0, Register:i64 %2
t8: i64 = Register %2
t3: i64 = undef
t153: i32 = Constant<15>
t152: i32 = Constant<3>
In function: _ZN4core3num22_$LT$impl$u20$u128$GT$14from_str_radix17hca3660e94cc40985E
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0. Program arguments: llc
1. Running pass 'Function Pass Manager' on module ''.
2. Running pass 'SystemZ DAG->DAG Pattern Instruction Selection' on function '@"_ZN4core3num22_$LT$impl$u20$u128$GT$14from_str_radix17hca3660e94cc40985E"'
#0 0x01aec96b llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /home/jistone/llvm-project-bisect/llvm/lib/Support/Unix/Signals.inc:798:3
#1 0x01aea0a4 llvm::sys::RunSignalHandlers() /home/jistone/llvm-project-bisect/llvm/lib/Support/Signals.cpp:105:20
#2 0x01aea486 SignalHandler(int) /home/jistone/llvm-project-bisect/llvm/lib/Support/Unix/Signals.inc:411:1
#3 0x7f7fda940090 __restore_rt (/lib64/libc.so.6+0x1a090)
#4 0x7f7fda9990f4 __pthread_kill_implementation (/lib64/libc.so.6+0x730f4)
#5 0x7f7fda93ffde gsignal (/lib64/libc.so.6+0x19fde)
#6 0x7f7fda927942 abort (/lib64/libc.so.6+0x1942)
#7 0x00407e3b std::mutex::lock() /usr/include/c++/14/bits/std_mutex.h:117:22
#8 0x00407e3b std::lock_guard::lock_guard(std::mutex&) /usr/include/c++/14/bits/std_mutex.h:250:23
#9 0x00407e3b llvm::install_bad_alloc_error_handler(void (*)(void*, char const*, bool), void*) (.cold) /home/jistone/llvm-project-bisect/llvm/lib/Support/ErrorHandling.cpp:132:61
#10 0x018933ee llvm::SDNode::getOperand(unsigned int) const /home/jistone/llvm-project-bisect/llvm/include/llvm/CodeGen/SelectionDAGNodes.h:993:5
#11 0x018933ee llvm::SDNode::getConstantOperandVal(unsigned int) const /home/jistone/llvm-project-bisect/llvm/include/llvm/CodeGen/SelectionDAGNodes.h:1724:61
#12 0x018933ee llvm::SelectionDAGISel::CannotYetSelect(llvm::SDNode*) /home/jistone/llvm-project-bisect/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:4425:44
#13 0x0189a41f llvm::SelectionDAGISel::SelectCodeCommon(llvm::SDNode*, unsigned char const*, unsigned int) /home/jistone/llvm-project-bisect/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:4135:35
#14 0x0188f456 llvm::SmallVectorTemplateCommon::isSmall() const /home/jistone/llvm-project-bisect/llvm/include/llvm/ADT/SmallVector.h:143:39
#15 0x
[llvm-bugs] [Bug 124032] [libc] pthread_setspecific has wrong fn signature in generated header
Issue 124032 Summary [libc] pthread_setspecific has wrong fn signature in generated header Labels good first issue, libc Assignees Reporter nickdesaulniers impl looks correct, generated header looks incorrect: ```c void * pthread_setspecific(pthread_key_t, const void *) __NOEXCEPT; ``` fix libc/include/pthread.yaml for `pthread_setspecific` should return `int`, not `void*`. Otherwise the following error is observed when building libcxxabi against llvm-libc: ``` /llvm-project-main/build/include/c++/v1/__thread/support/pthread.h:216:10: error: cannot initialize return object of type 'int' with an rvalue of type 'void *' 216 | return pthread_setspecific(__key, __p); | ^~~ ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 124027] [libc] build libcxxabi
Issue 124027 Summary [libc] build libcxxabi Labels metabug, libc Assignees Reporter nickdesaulniers meta/parent bug to track the issues related to building libcxxabi on top of llvm-libc. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 124031] [clang] Support __builtin_c23_va_start
Issue 124031 Summary [clang] Support __builtin_c23_va_start Labels c23 Assignees Reporter nathanchance GCC added `__builtin_c23_va_start()` to diagnose improper arguments to `va_start`. Some projects may want to take advantage of this. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107980 ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 124009] Deprecate the use of `LLVM_ENABLE_PROJECTS` for all runtimes
Issue 124009 Summary Deprecate the use of `LLVM_ENABLE_PROJECTS` for all runtimes Labels cmake, compiler-rt, openmp, pstl, libclc Assignees Reporter petrhosek We have already deprecate the use of `LLVM_ENABLE_PROJECTS` for libc++, libc++abi, libunwind and libc. We should deprecate the use of `LLVM_ENABLE_PROJECTS` for all remaining runtimes, most notably compiler-rt, which would unblock a lot of build system cleanup and improvements that are currently not possible. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 124013] Deprecate the use of `LLVM_ENABLE_PROJECTS` for libclc
Issue 124013 Summary Deprecate the use of `LLVM_ENABLE_PROJECTS` for libclc Labels libclc Assignees Reporter petrhosek We should deprecate the use of `LLVM_ENABLE_PROJECTS` for libclc in favor of `LLVM_ENABLE_RUNTIMES` which would greatly simplify the build and allow improvements that are currently not possible. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 124015] Deprecate the use of `LLVM_ENABLE_PROJECTS` for pstl
Issue 124015 Summary Deprecate the use of `LLVM_ENABLE_PROJECTS` for pstl Labels pstl Assignees Reporter petrhosek We should deprecate the use of `LLVM_ENABLE_PROJECTS` for pstl in favor of `LLVM_ENABLE_RUNTIMES` which would greatly simplify the build and allow improvements that are currently not possible. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 124010] [libcxxabi] option for c11 threads api
Issue 124010 Summary [libcxxabi] option for c11 threads api Labels libc++abi Assignees Reporter nickdesaulniers libcxxabi has the cmake options LIBCXXABI_ENABLE_THREADS and LIBCXXABI_HAS_PTHREAD_API. I think it would be nice if there was an option for using c11 threads. In the case of llvm-libc, pthreads is a much larger surface area than pthreads. We have c11 threads support, but not yet all of pthreads. Perhaps a cmake option for libcxxabi and code changes to use c11 threads instead of pthreads would help us boostrap a c++ runtime on top of llvm-libc. cc @petrhosek ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 124023] [LLDB] RISC-V has missing aliases for registers
Issue 124023 Summary [LLDB] RISC-V has missing aliases for registers Labels new issue Assignees Reporter patryk4815 Same issue as in https://github.com/llvm/llvm-project/issues/123903 When debugging with qemu-riscv64, some registers lack their standard aliases. How to reproduce ``` (lldb) target create -p qemu-user ./result/bin/hello (lldb) settings set platform.plugin.qemu-user.architecture riscv64 (lldb) b main (lldb) run (lldb) register read $x0 ``` ``` (lldb) register read x0 zero = 0x (lldb) register read x1 ra = 0xa6ca08c0 (lldb) register read x2 sp = 0xa760b7f0 (lldb) register read x3 gp = 0x0001a800 (lldb) register read x3 gp = 0x0001a800 (lldb) register read x4 error: Invalid register name 'x4'. (lldb) register read x5 error: Invalid register name 'x5'. (lldb) register read x6 error: Invalid register name 'x6'. (lldb) register read x7 error: Invalid register name 'x7'. ``` ``` python3 < 49> send packet: $qXfer:features:read:riscv-64bit-cpu.xml:0,fff#68 python3 < 1> read packet: + python3 <1829> read packet: $l ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123979] [HLSL] Alignment of boolean vector should be 4
Issue 123979 Summary [HLSL] Alignment of boolean vector should be 4 Labels new issue Assignees Reporter spall The Alignment of boolean vectors, when represented in memory as a vector of i32 has alignment of 1 but should have an alignment of 4. See #123977 ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123965] BOLT assert fails when attempting to instrument chromium
Issue 123965 Summary BOLT assert fails when attempting to instrument chromium Labels BOLT Assignees Reporter ebenupton Using AArch64 tools built from top of tree today. Looks like the overhead of the stubs in a large binary is exceeding a branch offset limit. Crash report attached. [bolt_assert_fail.txt](https://github.com/user-attachments/files/18509030/bolt_assert_fail.txt) ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 124012] Deprecate the use of `LLVM_ENABLE_PROJECTS` for compiler-rt
Issue 124012 Summary Deprecate the use of `LLVM_ENABLE_PROJECTS` for compiler-rt Labels compiler-rt Assignees Reporter petrhosek We should deprecate the use of `LLVM_ENABLE_PROJECTS` for compiler-rt in favor of `LLVM_ENABLE_RUNTIMES` which would greatly simplify the build and allow improvements that are currently not possible. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 124049] Fortran test with many self-referencing types takes "forever" to compile with -g
Issue 124049 Summary Fortran test with many self-referencing types takes "forever" to compile with -g Labels regression, debuginfo, flang Assignees Reporter eugeneepshteyn Test: https://github.com/fujitsu/compiler-test-suite/blob/main/Fortran/0394/0394_0031.f90 This test used to compile quickly (less than 2 min), even with -g, but now takes "forever" to compile. (I waited for more than 20 min, then killed compilation.) `flang -c 0394_0031.f90` compiles quickly. `flang -c -g 0394_0031.f90` compiles "forever" Compiler used: ``` $ flang --version flang version 20.0.0git (https://github.com/llvm/llvm-project.git 630177ccdde44b0dd8faa13b34002d15c4b0af8d) Target: x86_64-unknown-linux-gnu ``` It was pointed out to me that this slow-down may be related to https://github.com/llvm/llvm-project/pull/122770 ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 124045] [SPIRV] Investigate usage of `report_fatal_error` in `SPIRVInstructionSelector`
Issue 124045 Summary [SPIRV] Investigate usage of `report_fatal_error` in `SPIRVInstructionSelector` Labels new issue Assignees Reporter inbelic Throughout `SPIRVInstructionSelector` there are many uses of `report_fatal_error` to indicate various errors, however, none of these have any associated testing. As part of https://github.com/llvm/llvm-project/pull/123853, this pattern was propagated to report an error and a test was added to ensure the correct error message was received. This caused the `hwasan` build bot to [fail](https://github.com/llvm/llvm-project/pull/123853#issuecomment-2608389396). It is assumed that all of the other `report_fatal_error` instances would cause a similar failure if executed on the build-bot, or at the least, the other instance that outputs a diagnostics message printing out the current instruction [here](https://github.com/Icohedron/llvm-project/blob/def10ad82c6e527ba5c3aa29b76041dc94acff1d/llvm/lib/Target/SPIRV/SPIRVInstructionSelector.cpp#L3132). This issue is to track an investigation of which uses of `report_fatal_error` cause the sanitization build-bot to fail, and apply a fix correspondingly. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 124064] [HLSL] Determine how should `cbuffer` in a namespace work
Issue
124064
Summary
[HLSL] Determine how should `cbuffer` in a namespace work
Labels
HLSL
Assignees
Reporter
hekota
Constant buffers declared by `cbuffer` blocks can occur inside a namespace scope. DXC ignores the namespace and the constant buffer elements must be referenced without the namespace qualifier while in Clang the element names must use fully qualified name.
For example this constant buffer:
```
namespace ns {
cbuffer CB {
float a;
}
}
```
The float value must be referenced as `a` in DXC and as `ns::a` in Clang, otherwise it fails to compile.
https://godbolt.org/z/GMzzMnh6s
This task is to determine:
- which behavior we want to support
- document it in the language spec
- make sure it gets implemented (tracked by issue llvm-project/llvm#118524).
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 124067] [Tablegen] CodeEmitterGen::run in CodeEmitterGen.cpp doesn't grow Bitwidth
Issue
124067
Summary
[Tablegen] CodeEmitterGen::run in CodeEmitterGen.cpp doesn't grow Bitwidth
Labels
tablegen
Assignees
Reporter
farzonl
## Bug
If all instruction records are TargetOpcode or isPseudo we never grows BitWidth above zero.
## Why?
On line 487 BitWidth is set to 0.
https://github.com/llvm/llvm-project/blob/de209fa11b5455155228bcdba012b6074388b917/llvm/utils/TableGen/CodeEmitterGen.cpp#L487
We never get to line 506
https://github.com/llvm/llvm-project/blob/de209fa11b5455155228bcdba012b6074388b917/llvm/utils/TableGen/CodeEmitterGen.cpp#L506-L506
that could have set BitWidth Because of
https://github.com/llvm/llvm-project/blob/de209fa11b5455155228bcdba012b6074388b917/llvm/utils/TableGen/CodeEmitterGen.cpp#L490-L492
The reason why it is like this is because `TargetOpcode` do not have a `Inst` field.
## The problem
If we only have TargetOpcode or isPseudo then We never add any `UINT64_C(0)`
to `NEW_TARGETGenMCCodeEmitter.inc` in
```cpp
uint64_t DirectXMCCodeEmitter::getBinaryCodeForInstr(const MCInst &MI,
SmallVectorImpl &Fixups,
const MCSubtargetInfo &STI) const {
static const uint64_t InstBits[] = {
```
That causes a compile error because `InstBits` is just full of commas with no data in the array.
## How to debug
```bash
lldb -- /mnt/DevDrive/projects/llvm_debug_build/bin/llvm-tblgen -gen-emitter -I /mnt/DevDrive/projects/llvm-project/llvm/lib/Target/NEW_TARGET -I/mnt/DevDrive/projects/llvm_debug_build/include -I/mnt/DevDrive/projects/llvm-project/llvm/include -I /mnt/DevDrive/projects/llvm-project/llvm/lib/Target /mnt/DevDrive/projects/llvm-project/llvm/lib/Target/NEW_TARGET/NEW_TARGET.td --write-if-changed -o /mnt/DevDrive/projects/llvm_debug_build/lib/Target/NEW_TARGET/NEW_TARGETGenMCCodeEmitter.inc -d /mnt/DevDrive/projects/llvm_debug_build/lib/Target/NEW_TARGET/NEW_TARGETGenMCCodeEmiter.inc
```
## Potential Fixes
### Fix 1
On line 487 Set BitWidth to 1.
https://github.com/llvm/llvm-project/blob/de209fa11b5455155228bcdba012b6074388b917/llvm/utils/TableGen/CodeEmitterGen.cpp#L487
### Fix 2
Maybe you are thinking what does it mean to have a target with only TargetOpcode. Well then at least Pseudo instructions need to set the Bit width
```cpp
if( R->getValueAsBit("isPseudo")) {
const BitsInit *BI = R->getValueAsBitsInit("Inst");
BitWidth = std::max(BitWidth, BI->getNumBits());
}
```
Of the Two I think fix one is more correct. a 0 bitwidth doesn't make any sense and could cause problems for others. I don't know if 1 for the bitwidth makes sense though.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 124043] [Flang] flang/lib/Lower/ConvertCall.cpp:1252: auto prepare[Flang] Assertion `baseBoxTy && "expect non simply contiguous variables to be boxes"' failed.
Issue 124043 Summary [Flang] flang/lib/Lower/ConvertCall.cpp:1252: auto prepare[Flang] Assertion `baseBoxTy && "expect non simply contiguous variables to be boxes"' failed. Labels flang Assignees Reporter k-arrows Crash itself is reproducible on Godbolt: https://godbolt.org/z/dWrxK9nnq Reproducer: ```f90 type t real, dimension(1:10) :: m end type real :: y = 1.0 type(t), allocatable :: b allocate(b) b%m = (/0.0,1.0,2.0,3.0,4.0,5.0,6.0,7.0,8.0,9.0/) associate(a => b%m(4:8:2) * f(y)) call s(a) end associate contains subroutine s(d) real, dimension(1:2) :: d end subroutine end real function f(x) real :: x f = x end ``` With assertion-enabled flang-new, the compilation results in the following assertion failure: ```txt llvm-project/flang/lib/Lower/ConvertCall.cpp:1252: auto preparePresentUserCallActualArgument(mlir::Location, fir::FirOpBuilder &, const Fortran::lower::PreparedActualArgument &, mlir::Type, const Fortran::lower::CallerInterface::PassedEntity &, (anonymous namespace)::CallContext &)::(anonymous class)::operator()(hlfir::Entity, bool) const: Assertion `baseBoxTy && "expect non simply contiguous variables to be boxes"' failed. ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 124057] clang format: incorrect indentation of lambda inside nested function calls
Issue
124057
Summary
clang format: incorrect indentation of lambda inside nested function calls
Labels
clang
Assignees
Reporter
malytomas
```c++
// correct / intended
const auto engineInitListener = controlThread().initialize.listen(
[]()
{
if (connectionState() == ConnectionStateEnum::None)
setScreenMainMenu();
},
9);
// wrong
const auto escKeyPressListener = engineEvents().listen(inputFilter(
[](input::KeyPress in)
{
if (in.key != 256) // esc
return false;
if (escCallback)
{
escCallback();
return true;
}
return false;
}),
-1099);
```
The cause is the nested function call `inputFilter`. Without it the lambda is formatted correctly.
Note: github uses 8 spaces per tab, whereas the code uses 4 space per tab. clang-format tries to align the code with middle of `inputFilter` function.
```
# requires clang-format version 16 or later
---
AccessModifierOffset: -4
AlignAfterOpenBracket: DontAlign
AlignEscapedNewlines: DontAlign
AlignOperands: DontAlign
AlignTrailingComments:
Kind: Never
AllowShortFunctionsOnASingleLine: Inline
AlwaysBreakTemplateDeclarations: Yes
BasedOnStyle: Microsoft
BraceWrapping:
AfterCaseLabel: true
AfterClass: true
AfterControlStatement: true
AfterEnum: true
AfterExternBlock: true
AfterFunction: true
AfterNamespace: true
AfterObjCDeclaration: true
AfterStruct: true
AfterUnion: true
BeforeCatch: true
BeforeElse: true
BeforeLambdaBody: true
BeforeWhile: false
IndentBraces: false
SplitEmptyFunction: false
SplitEmptyNamespace: false
SplitEmptyRecord: false
BreakBeforeBraces: Custom
ColumnLimit: 1000
Cpp11BracedListStyle: false
EmptyLineBeforeAccessModifier: Always
FixNamespaceComments: false
IncludeBlocks: Preserve
IndentCaseLabels: true
IndentPPDirectives: BeforeHash
IndentWidth: 4
Language: Cpp
LineEnding: DeriveLF
NamespaceIndentation: All
QualifierAlignment: Custom
QualifierOrder: ['friend', 'static', 'inline', 'constexpr', 'const', 'volatile', 'restrict', 'type']
ReflowComments: false
RequiresClausePosition: WithPreceding
SpaceAfterTemplateKeyword: false
SpaceInEmptyBlock: false
Standard: Latest
TabWidth: 4
UseTab: AlignWithSpaces
...
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 124061] extractvalue with packed struct with vector off-by-one error
Issue
124061
Summary
extractvalue with packed struct with vector off-by-one error
Labels
new issue
Assignees
Reporter
Chobbes
This bug was initially discovered in this [issue](https://github.com/vellvm/vellvm/issues/283)
We believe there is an off-by-one error with code generation for the
extractvalue instruction when a vector is contained within a packed
structure. We have two example programs, one which exhibits what we
believe to be a miscompilation that uses a `<{<3 x i8>, i8}>`
structure, and one where we have replaced the vector with an array
type instead, and miscompilation does not occur.
- [ptrtoint2.ll](https://github.com/vellvm/vellvm/blob/dev/qc-test-failures/ptrtoint-roundtrip/ptrtoint2.ll), which uses `<{<3 x i8>, i8}>`. This one we believe miscompiles.
- [ptrtoint7.ll](https://github.com/vellvm/vellvm/blob/dev/qc-test-failures/ptrtoint-roundtrip/ptrtoint7.ll), which uses `<{[3 x i8], i8}>`. This gives us the behavior we expect.
The program which we believe miscompiles is as follows:
```
define i8 @main() {
%v0 = alloca i32
store i32 0, i32* %v0, align 1
%v1 = ptrtoint i32* %v0 to i64
%v2 = inttoptr i64 %v1 to <{<3 x i8>, i8}>*
%v3 = load <{<3 x i8>, i8}>, <{<3 x i8>, i8}>* %v2, align 1
%v4 = extractvalue <{<3 x i8>, i8}> %v3, 1
ret i8 %v4
}
```
We expect this to return 0, because we are essentially bitcasting a
32-bit 0 value to this 32-bit packed structure, and fetching the last
byte of it (which should be 0). After compiling this on an intel mac,
and an intel linux machine we get a different return value instead
(e.g., 46 is returned instead of 0 on the mac).
If we replace the vector with an array:
```
define i8 @main() {
%v0 = alloca i32
store i32 0, i32* %v0, align 1
%v1 = ptrtoint i32* %v0 to i64
%v2 = inttoptr i64 %v1 to <{[3 x i8], i8}>*
%v3 = load <{[3 x i8], i8}>, <{[3 x i8], i8}>* %v2, align 1
%v4 = extractvalue <{[3 x i8], i8}> %v3, 1
ret i8 %v4
}
```
We get the expected value of 0 on all platforms we've tried.
We believe that this is caused by an off-by-one error somewhere in the
code generation for extractvalue. For instance, we tried generating
RISC-V assembly code to see what code was generated for both of these
programs. Both the vector and array versions compile to identical
assembly language *except* for the load of the return value.
The vector version:
```
.text
.attribute 4, 16
.attribute 5, "rv64i2p1_m2p0_a2p1_c2p0_zmmul1p0"
.file "ptrtoint2.ll"
.globl main # -- Begin function main
.p2align 1
.type main,@function
main: # @main
.cfi_startproc
# %bb.0:
addi sp, sp, -16
.cfi_def_cfa_offset 16
li a0, 0
sb a0, 15(sp)
sb a0, 14(sp)
sb a0, 13(sp)
sb a0, 12(sp)
lbu a0, 16(sp)
addi sp, sp, 16
ret
.Lfunc_end0:
.size main, .Lfunc_end0-main
.cfi_endproc
# -- End function
.section ".note.GNU-stack","",@progbits
.addrsig
```
The array version:
```
.text
.attribute 4, 16
.attribute 5, "rv64i2p1_m2p0_a2p1_c2p0_zmmul1p0"
.file "ptrtoint7.ll"
.globl main # -- Begin function main
.p2align 1
.type main,@function
main: # @main
.cfi_startproc
# %bb.0:
addi sp, sp, -16
.cfi_def_cfa_offset 16
li a0, 0
sb a0, 15(sp)
sb a0, 14(sp)
sb a0, 13(sp)
sb a0, 12(sp)
lbu a0, 15(sp)
addi sp, sp, 16
ret
.Lfunc_end0:
.size main, .Lfunc_end0-main
.cfi_endproc
# -- End function
.section ".note.GNU-stack","",@progbits
.addrsig
```
In the vector version the instruction `lbu a0, 16(sp)` should be `lbu
a0, 15(sp)`, as in the array version. A similar issue can be seen in
the ARM code that's generated as well. Presumably something similar
happens in x86 as well, but there are larger differences between the
assembly files generated between the two files as well.
This test was ran using the following machines
- Clang 13
```
Homebrew clang version 13.0.1
Target: x86_64-apple-darwin21.6.0
Thread model: posix
InstalledDir: /usr/local/opt/llvm@13/bin
```
- Clang 19
```
Homebrew clang version 19.1.7
Target: x86_64-apple-darwin21.6.0
Thread model: posix
InstalledDir: /usr/local/Cellar/llvm/19.1.7/bin
Configuration file: /usr/local/etc/clang/x86_64-apple-darwin21.cfg
```
We believe that the structure in both of the examples should be of the same size as the `i32` value because of the following statements from the LLVM Language Reference:
- "In general vector elements are laid out in memory in the same way as array types. Such an analogy works fine as long as the vector elements are byte sized"
- "Structures may optionally be 'packed' structures, which indicate that the alignment of the struct is one byte, and that there is no padding between the elements."
Notice the following
- It is true that, according to this [mail]
[llvm-bugs] [Bug 124073] [clang-format] Misformatted reference with PointerAlignment Left on main versus 19
Issue
124073
Summary
[clang-format] Misformatted reference with PointerAlignment Left on main versus 19
Labels
clang-format
Assignees
Reporter
rmarker
While testing with the main branch, I discovered this formatting change from 19.1.0.
Using 19.1.0 and `-style="{PointerAlignment: Left}"` I get the following:
```cpp
[](decltype(foo)& Bar) {};
```
Using main (20.0.0git 19834b4623fd1e7ae5185ed76031b407c3fa7a47) and the same style `-style="{PointerAlignment: Left}"`:
```cpp
[](decltype(foo) & Bar) {};
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 124079] The test clang/test/Parser/cuda-check-input-kind-assoc.cuh is never run
Issue 124079 Summary The test clang/test/Parser/cuda-check-input-kind-assoc.cuh is never run Labels clang Assignees Reporter HighCommander4 In a local build, if I run: `/bin/llvm-lit /clang/test/Parser/cuda-check-input-kind-assoc.cuh` I get: ```console llvm-lit: llvm/utils/lit/lit/llvm/config.py:506: note: using clang: build/bin/clang llvm-lit: llvm/utils/lit/lit/discovery.py:276: warning: input 'src/clang/test/Parser/cuda-check-input-kind-assoc.cuh' contained no tests error: did not discover any tests for provided path(s) ``` I think this suggests this test case is never actually run. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123903] [LLDB] LoongArch has missing aliases for register
Issue
123903
Summary
[LLDB] LoongArch has missing aliases for register
Labels
Assignees
Reporter
patryk4815
I have compiled LLDB from main branch commit ( ebb27ccb08e0579825a53b218ff5b2ddc492626a )
We found out that LLDB has missing aliases for some registers.
We discovered this in pwndbg-lldb PR https://github.com/pwndbg/pwndbg/pull/2691
Missing `S*` and `T*` registers:
Docs:
Register list:
```
pwndbg-lldb> register read -a
general:
r0 = 0x
r1 = 0xa236d1d0 libc.so.6`__libc_start_call_main + 104 libc.so.6`__libc_start_call_main + 104
r2 = 0xa3b0b320 -> 0xa24dd228 _nl_global_locale
r3 = 0xa2d1b7c0
r4 = 0x0001
r5 = 0xa2d1b928
r6 = 0xa2d1b938
r7 = 0x
r8 = 0x
r9 = 0xa24ef790 ld-linux-loongarch-lp64d.so.1`_dl_fini
r10 = 0xa2d1b920
r11 = 0x
r12 = 0x000120001940 hello`main
r13 = 0xa2d1b7e8
r14 = 0x
r15 = 0xa24e3100 libc.so.6`__environ
r16 = 0x
r17 = 0x
r18 = 0x
r19 = 0x
r20 = 0x
r21 = 0x
r22 = 0x
r23 = 0xa2d1b928
r24 = 0x0001
r25 = 0x
r26 = 0x00012000faa0 hello`__do_global_dtors_aux_fini_array_entry
r27 = 0x000120001940 hello`main
r28 = 0xa2d1b938
r29 = 0xa251bc78 ld-linux-loongarch-lp64d.so.1`_rtld_global_ro
r30 = 0x00012000faa0 hello`__do_global_dtors_aux_fini_array_entry
r31 = 0xa251c008 ld-linux-loongarch-lp64d.so.1`_rtld_global
orig_a0 = 0x
pc = 0x000120001940 hello`main hello`main
badv = 0x
float:
f0 = 0x637261676e6f6f6c
f1 = 0x122040a1
f2 = 0x40a1
f3 = 0x1220
f4 = 0x40a1
f5 = 0x1000
f6 = 0x
f7 = 0x
f8 = 0x
f9 = 0x
f10 = 0x
f11 = 0x
f12 = 0x
f13 = 0x
f14 = 0x
f15 = 0x
f16 = 0x
f17 = 0x
f18 = 0x
f19 = 0x
f20 = 0x
f21 = 0x
f22 = 0x
f23 = 0x
f24 = 0x
f25 = 0x
f26 = 0x
f27 = 0x
f28 = 0x
f29 = 0x
f30 = 0x
f31 = 0x
fcc0 = 0x00
fcc1 = 0x00
fcc2 = 0x00
fcc3 = 0x00
fcc4 = 0x00
fcc5 = 0x00
fcc6 = 0x00
fcc7 = 0x00
fcsr = 0x
lsx:
vr0 = 0x637261676e6f6f6c0068
vr1 = 0x122040a1
vr2 = 0x40a1
vr3 = 0x1220
vr4 = 0x40a1
vr5 = 0x1000
vr6 = 0x
vr7 = 0x
vr8 = 0x
vr9 = 0x
vr10 = 0x
vr11 = 0x
vr12 = 0x
vr13 = 0x
vr14 = 0x
vr15 = 0x
vr16 = 0x
vr17 = 0x
vr18 = 0x
vr19 = 0x
vr20 = 0x
vr21 = 0x
vr22 = 0x
vr23 = 0x
vr26 = 0x
vr25 = 0x
vr26 = 0x
vr27 = 0x
vr28 = 0x
vr29 = 0x
vr30 = 0x
vr31 = 0x
lasx:
xr0 = {0x6c 0x6f 0x6f 0x6e 0x67 0x61 0x72 0x63 0x68 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x2f 0x72 0x6f 0x6f
