[llvm-bugs] [Bug 129479] [flang] flang issues error for transfer intrinsic
Issue 129479 Summary [flang] flang issues error for transfer intrinsic Labels flang Assignees Reporter shivaramaarao Consider the following program program main integer, parameter :: n2 = 2 integer, parameter :: n = 1 integer :: in(n) real :: r_in2(n2) integer :: in2(n2) in = transfer(r_in2, in2) end program the above program compiles fine with gfortran and classic flang. However llvm flang issues following error error: Semantic errors in xx.f90 ./xx.f90:7:4: error: Dimension 1 of left-hand side has extent 1, but right-hand side has extent 2 in = transfer(r_in2, in2) >From the standard: Return value: The result has the same type as MOLD, with the bit level representation of SOURCE. If SIZE is present, the result is a one-dimensional array of length SIZE. If SIZE is absent but MOLD is an array (of any size or shape), the result is a one- dimensional array of the minimum length needed to contain the entirety of the bitwise representation of SOURCE. If SIZE is absent and MOLD is a scalar, the result is a scalar. I am not sure if gfortran is wrong not to give error or llvm-flang is wrong issuing the error. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129443] [mlir] Testing infra improvements ideas
Issue
129443
Summary
[mlir] Testing infra improvements ideas
Labels
mlir
Assignees
banach-space
Reporter
banach-space
Meta-ticket to collect ideas for improving the testing infrastructure in MLIR.
At the moment, this is a collection of suggestions extracted from:
* https://discourse.llvm.org/t/rfc-should-we-aim-for-more-consistency-in-tests/, and
* https://github.com/llvm/mlir-www/pull/216.
The order of these items is random. I will try to add more data/notes over time.
_Please, if you decide to work on any of these, leave a comment so that we avoid duplicating efforts._
### IDEA 1
Separate examples from ODS definitions into a new field: `let examples = {}`. Build infra so that `ninja check-mlir` would extra those examples and sanity-check them with `mlir-opt` (to avoid the examples becoming out-dated).
This could be used to demonstrate both "valid" and invalid usage.
### IDEA 2
Generate, somehow, examples from the ODS `assemblyFormat` (even if we will likely want to update them manually).
### IDEA 3
Revisit the concept of round-trip tests in "ops.mlir" files. They shouldn't be strictly necessary for ops with `let assemblyFormat` MLIR thoroughly tests the printer/parser generator.
### IDEA 4
Improve "split" locations when encountering errors. Currently these are OK for humans to read - make them easier for tools to parse (and to jump to locations).
### IDEA 5
Add more metadata to “splits” so that one could do something like:
```
Test: Verify the folding behavior with single dynamic rank.
```
This would then be printed alongside the error/failure message. This should be integrated with the existing metadata like [here](https://github.com/llvm/llvm-project/blob/1aea0241f1cce9eb4eba3e4add3be9370e30e415/mlir/test/Dialect/Vector/vector-transfer-permutation-lowering.mlir#L8-L13).
### IDEA 6
Make [generate-test-checks.py](https://github.com/llvm/llvm-project/blob/main/mlir/utils/generate-test-checks.py) generate better names. For example:
```mlir
// Automatically generated - possible near-future version (mild improvement)
// CHECK-LABEL: func.func @bitcast_2d(
// CHECK-SAME: %[[ARG_0]]: vector<2x4xi32>) -> vector<2x16xi8> {
// CHECK: %[[BITCAST_1:.*]] = vector.bitcast %[[ARG_0]] : vector<2x4xi32> to vector<2x2xi64>
// CHECK: %[[BITCAST_2.:*]] = vector.bitcast %[[BITCAST_1]] : vector<2x2xi64> to vector<2x16xi8>
// CHECK: return %[[BITCAST_2]] : vector<2x16xi8>
func.func @bitcast_2d(%arg0: vector<2x4xi32>) -> vector<2x16xi8> {
%0 = vector.bitcast %arg0 : vector<2x4xi32> to vector<2x2xi64>
%1 = vector.bitcast %0 : vector<2x2xi64> to vector<2x16xi8>
return %1 : vector<2x16xi8>
}
```
instead of:
```mlir
// Automatically generated - today’s version
// CHECK-LABEL: func.func @bitcast_2d(
// CHECK-SAME: %[[VAL_0:[0-9]+|[a-zA-Z$._-][a-zA-Z0-9$._-]*]]: vector<2x4xi32>) -> vector<2x16xi8> {
// CHECK: %[[VAL_1:.*]] = vector.bitcast %[[VAL_0]] : vector<2x4xi32> to vector<2x2xi64>
// CHECK: %[[VAL_2:.*]] = vector.bitcast %[[VAL_1]] : vector<2x2xi64> to vector<2x16xi8>
// CHECK: return %[[VAL_2]] : vector<2x16xi8>
func.func @bitcast_2d(%arg0: vector<2x4xi32>) -> vector<2x16xi8> {
%0 = vector.bitcast %arg0 : vector<2x4xi32> to vector<2x2xi64>
%1 = vector.bitcast %0 : vector<2x2xi64> to vector<2x16xi8>
return %1 : vector<2x16xi8>
}
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129447] Request Commit Access For pedroclobo
Issue 129447 Summary Request Commit Access For pedroclobo Labels infra:commit-access-request Assignees Reporter pedroclobo ### Why Are you requesting commit access Hi! I've recently started contributing to LLVM (mainly replacing uses of `undef` with `poison`). So far, I have had about 15 PRs merged. I intend to continue contributing, and commit access would be quite helpful so I can tag issues, request specific reviewers and merge PRs after approval. Thank you! ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129458] 【BOLT】【RISC-V】createInstrumentedIndCallHandlerExitBB() seems not to be implemented.
Issue 129458 Summary 【BOLT】【RISC-V】createInstrumentedIndCallHandlerExitBB() seems not to be implemented. Labels BOLT Assignees Reporter dinyy When I want to run this command on RISC-V platform： ` llvm-bolt mcf_s_base.mytest-64 -instrument -o mcf_s_base.mytest-64.instr_before ` it occurs： ` BOLT-INFO: shared object or position-independent executable detected BOLT-INFO: Target architecture: riscv64 BOLT-INFO: BOLT version: BOLT-INFO: first alloc address is 0x0 BOLT-INFO: creating new program header table at address 0x20, offset 0x20 BOLT-WARNING: debug info will be stripped from the binary. Use -update-debug-sections to keep it. BOLT-INFO: enabling relocation mode BOLT-INFO: forcing -jump-tables=move for instrumentation BOLT-INFO: 0 out of 49 functions in the binary (0.0%) have non-empty execution profile not implemented UNREACHABLE executed at /home/yjn/th1520_build/llvm-project-llvmorg-19.1.7/bolt/include/bolt/Core/MCPlusBuilder.h:2001! #0 0x003fb936bb64 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/home/sipeed/work_bolt/bolt_install/bin/../lib/libLLVMSupport.so.19.1+0x16bb64) #1 0x003fb9369d36 llvm::sys::RunSignalHandlers() (/home/sipeed/work_bolt/bolt_install/bin/../lib/libLLVMSupport.so.19.1+0x169d36) #2 0x003fb9369e90 SignalHandler(int) Signals.cpp:0:0 #3 0x003fba35c800 (linux-vdso.so.1+0x800) #4 0x003fb90f7812 __pthread_kill_implementation ./nptl/pthread_kill.c:44:76 #5 0x003fb90b6be8 raise ./signal/../sysdeps/posix/raise.c:27:6 #6 0x003fb90a6612 abort ./stdlib/abort.c:81:7 #7 0x003fb92c04fe llvm::report_bad_alloc_error(char const*, bool) (/home/sipeed/work_bolt/bolt_install/bin/../lib/libLLVMSupport.so.19.1+0xc04fe) #8 0x003fb9c16c6c llvm::bolt::MCPlusBuilder::createInstrumentedIndirectCall(llvm::MCInst&&, llvm::MCSymbol*, int, llvm::MCContext*) (/home/sipeed/work_bolt/bolt_install/bin/../lib/../lib/libLLVMBOLTTargetRISCV.so.19.1+0x2c6c) #9 0x003fb852e8dc llvm::bolt::Instrumentation::createAuxiliaryFunctions(llvm::bolt::BinaryContext&) (/home/sipeed/work_bolt/bolt_install/bin/../lib/../lib/libLLVMBOLTPasses.so.19.1+0x8e8dc) #10 0x003fb852f47a llvm::bolt::Instrumentation::runOnFunctions(llvm::bolt::BinaryContext&) (/home/sipeed/work_bolt/bolt_install/bin/../lib/../lib/libLLVMBOLTPasses.so.19.1+0x8f47a) #11 0x003fb9d1e6a0 llvm::bolt::BinaryFunctionPassManager::runPasses() (/home/sipeed/work_bolt/bolt_install/bin/../lib/libLLVMBOLTRewrite.so.19.1+0x316a0) #12 0x003fb9d20636 llvm::bolt::BinaryFunctionPassManager::runAllPasses(llvm::bolt::BinaryContext&) (/home/sipeed/work_bolt/bolt_install/bin/../lib/libLLVMBOLTRewrite.so.19.1+0x33636) #13 0x003fb9d6cae0 llvm::bolt::RewriteInstance::runOptimizationPasses() (/home/sipeed/work_bolt/bolt_install/bin/../lib/libLLVMBOLTRewrite.so.19.1+0x7fae0) #14 0x003fb9db90c4 llvm::bolt::RewriteInstance::run() (/home/sipeed/work_bolt/bolt_install/bin/../lib/libLLVMBOLTRewrite.so.19.1+0xcc0c4) #15 0x002ad7d93914 main (/home/sipeed/work_bolt/bolt_install/bin/llvm-bolt+0x3914) #16 0x003fb90a6bf0 __libc_start_call_main ./csu/../sysdeps/nptl/libc_start_call_main.h:74:3 #17 0x003fb90a6c98 call_init ./csu/libc-start.c:128:20 #18 0x003fb90a6c98 __libc_start_main ./csu/libc-start.c:347:5 #19 0x002ad7d94078 _start (/home/sipeed/work_bolt/bolt_install/bin/llvm-bolt+0x4078) PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. Stack dump: 0. Program arguments: llvm-bolt mcf_s_base.mytest-64 -instrument -o mcf_s_base.mytest-64.instr_before Aborted ` I think this is becase createInstrumentedIndCallHandlerExitBB() not to be implemented. I don't find it in bolt/lib/Target/RISCV/RISCVMCPlusBuilder.cpp. I want know can I use this command on RISCV. or maybe have other alternative solution？ ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129457] [Flang][OpenMP] No error checking of a continuation line that does not have a line to be continued in Fixed Source Form Conditional Compilation Sentinel
Issue 129457 Summary [Flang][OpenMP] No error checking of a continuation line that does not have a line to be continued in Fixed Source Form Conditional Compilation Sentinel Labels flang:openmp Assignees Reporter ohno-fj ``` Version of flang : 21.0.0(c8b40867d144395ad3c306a3cf87f970e0f97f07)/AArch64 ``` The attached program is incorrect. In `Fixed Source Form Conditional Compilation Sentinel`, flang does not output an error message during compilation for a continuation line that does not have a line to be continued. The following are the test program, Flang, Gfortran and ifx compilation/execution result. err_sngg081g_2.f: ```fortran c$ ! 0 ! print *,'pass' end ``` ``` $ export OMP_NUM_THREADS=2; flang -fopenmp err_sngg081g_2.f; ./a.out flang-20: warning: OpenMP support in flang is still experimental [-Wexperimental-option] pass $ ``` ``` $ export OMP_NUM_THREADS=2; gfortran -fopenmp err_sngg081g_2.f; ./a.out pass $ ``` ``` $ ifx -qopenmp err_sngg081g_2.f err_sngg081g_2.f(1): error #5118: First statement in file must not be continued c$ ! 0 ! -^ err_sngg081g_2.f(1): error #5082: Syntax error, found INTEGER_CONSTANT '0' when expecting one of: ; TYPE MODULE ELEMENTAL IMPURE NON_RECURSIVE ... c$ ! 0 ! -^ err_sngg081g_2.f(1): error #6905: A label cannot be zero; it must be an integer in the range 1 through 9. [0] c$ ! 0 ! -^ err_sngg081g_2.f(1): error #6321: An unterminated block exists. c$ ! 0 ! ^ err_sngg081g_2.f(1): error #6323: This label is not defined in this scoping unit. [0] c$ ! 0 ! -^ compilation aborted for err_sngg081g_2.f (code 1) $ ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129456] [Flang] Compile error when when a statement label is specified in function statement
Issue 129456 Summary [Flang] Compile error when when a statement label is specified in function statement Labels flang:frontend Assignees Reporter ohno-fj ``` Version of flang : 21.0.0(c8b40867d144395ad3c306a3cf87f970e0f97f07)/AArch64 ``` When a `statement label` is specified in `function` statement, a compilation error occurs. The above program is `dwarf6c_2.f`. According to `Fortran Standard 2023: 6.2.5 Statement labels`, there is no problem with this program. When no `statement label` is specified in `function` statement, the compilation succeeds. The above program is `dwarf6c_3.f`. The following are the test program, Flang, Gfortran and ifx compilation/execution result. dwarf6c_2.f: ```fortran 1function fun() 2end function 3write(6,*) "pass" 4end ``` ``` $ flang dwarf6c_2.f error: Could not parse dwarf6c_2.f ./dwarf6c_2.f:1:21: error: expected '=' 1function fun() ^ ./dwarf6c_2.f:1:7: in the context: statement function definition 1 function fun() ^ ./dwarf6c_2.f:1:2: in the context: declaration construct 1function fun() ^ ./dwarf6c_2.f:1:2: in the context: specification part 1function fun() ^ ./dwarf6c_2.f:1:2: in the context: main program 1function fun() ^ ./dwarf6c_2.f:2:11: error: expected end of statement 2end function ^ ./dwarf6c_2.f:2:7: in the context: END PROGRAM statement 2end function ^ ./dwarf6c_2.f:1:2: in the context: main program 1 function fun() ^ $ ``` ``` $ gfortran dwarf6c_2.f; ./a.out pass $ ``` ``` $ ifx ; dwarf6c_2.f./a.out dwarf6c_2.f(1): warning #6178: The return value of this FUNCTION has not been defined. [FUN] 1 function fun() ---^ pass $ ``` dwarf6c_3.f: ```fortran function fun() 2end function 3write(6,*) "pass" 4 end ``` ``` $ flang dwarf6c_3.f ./dwarf6c_3.f:1:16: warning: Function result is never defined function fun() ^^^ pass $ ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129455] [Flang] Preprocessor does not work correctly when C old-style comments immediately precedes a continuation line.
Issue 129455 Summary [Flang] Preprocessor does not work correctly when C old-style comments immediately precedes a continuation line. Labels flang Assignees Reporter ohno-fj ``` Version of flang : 21.0.0(c8b40867d144395ad3c306a3cf87f970e0f97f07)/AArch64 ``` `C old-style comments` specified in the program are removed by the preprocessor. When `C old-style comments` is specified on the line immediately preceding a continuation line, the continuation of the statement is not successful. The following are the test program, Flang, Gfortran and ifx compilation/execution result. flang snggo770_2.F90: ```fortran integer & i(1) /* \\\*/ i(1)& /* \\\*/ =1 /* \*/ if (i(1)/=1)write(6,*)'error',i(1) print *,'pass' end ``` ``` $ flang snggo770_2.F90 error: Could not parse snggo770_2.F90 ./snggo770_2.F90:4:3: error: expected ')' i(1)& ^ ./snggo770_2.F90:4:1: in the context: statement function definition i(1)& ^ ./snggo770_2.F90:4:1: in the context: declaration construct i(1)& ^ ./snggo770_2.F90:1:1: in the context: specification part integer & ^ ./snggo770_2.F90:1:1: in the context: main program integer & ^ ./snggo770_2.F90:6:2: error: expected declaration construct =1 ^ ./snggo770_2.F90:1:1: in the context: specification part integer & ^ ./snggo770_2.F90:1:1: in the context: main program integer & ^ $ ``` ``` $ flang snggo770_2.F90 -E #line "./snggo770_2.F90" 1 integer i(1) i(1) =1 if(i(1)/=1)write(6,*)'error',i(1) print *,'pass' end $ ``` ``` $ gfortran snggo770_2.F90; ./a.out pass $ ``` ``` $ gfortran snggo770_2.F90 -E # 1 "snggo770_2.F90" # 1 "" # 1 "" # 1 "snggo770_2.F90" integer & i(1) i(1)& =1 if (i(1)/=1)write(6,*)'error',i(1) print *,'pass' end $ ``` ``` $ ifx snggo770_2.F90; ./a.out pass $ ``` ``` $ ifx snggo770_2.F90 -E # 1 "snggo770_2.F90" integer & i(1) i(1)& =1 if (i(1)/=1)write(6,*)'error',i(1) print *,'pass' end ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129438] [clang tools] build failure
Issue 129438 Summary [clang tools] build failure Labels clang Assignees Reporter trcrsired ``` /home/csrg/toolchains_build/llvm-project/clang/tools/c-index-test/c-index-test.c:693:3: error: unknown type name 'xmlRelaxNGParserCtxtPtr'; did you mean 'xmlParserCtxtPtr'? 693 | xmlRelaxNGParserCtxtPtr RNGParser; | ^~~ | xmlParserCtxtPtr /home/csrg/toolchains/llvm/x86_64-linux-gnu/x86_64-linux-gnu/usr/include/libxml2/libxml/tree.h:50:24: note: 'xmlParserCtxtPtr' declared here 50 | typedef xmlParserCtxt *xmlParserCtxtPtr; | ^ /home/csrg/toolchains_build/llvm-project/clang/tools/c-index-test/c-index-test.c:694:3: error: unknown type name 'xmlRelaxNGPtr'; did you mean 'xmlRegexpPtr'? 694 | xmlRelaxNGPtr Schema; | ^ | xmlRegexpPtr /home/csrg/toolchains/llvm/x86_64-linux-gnu/x86_64-linux-gnu/usr/include/libxml2/libxml/xmlregexp.h:31:20: note: 'xmlRegexpPtr' declared here 31 | typedef xmlRegexp *xmlRegexpPtr; | ^ /home/csrg/toolchains_build/llvm-project/clang/tools/c-index-test/c-index-test.c:696:3: error: unknown type name 'xmlRelaxNGValidCtxtPtr'; did you mean 'xmlValidCtxtPtr'? ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129439] [llvm-c] `ConstantDataArray` constructors for element types other than `i8`
Issue 129439 Summary [llvm-c] `ConstantDataArray` constructors for element types other than `i8` Labels new issue Assignees Reporter HertzDevil We from the Crystal programming language would like to support embedding large amounts of scalar data as LLVM constants during code generation, but without having to go through the `LLVMValueRef`s, since we found that step to be relatively time-consuming. It came to our attention that arrays of `i8`s are already essentially supported via `LLVMConstStringInContext2`, but the underlying `llvm::ConstantDataArray` supports a few more data types. We would like to close this gap in the official C API: ```c const char *LLVMGetRawDataValues(LLVMValueRef c, size_t *SizeInBytes); LLVMValueRef LLVMConstDataArray(LLVMTypeRef ElementTy, const char *Data, size_t SizeInBytes); ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129432] powerpc: failure to optimize manual `vec_nmsub` implementation
Issue
129432
Summary
powerpc: failure to optimize manual `vec_nmsub` implementation
Labels
new issue
Assignees
Reporter
folkertdev
given this code
https://godbolt.org/z/3WxTM4Yao
```c
#include
vector float old(vector float a, vector float b, vector float c) {
return vec_nmsub(a, b, c);
}
vector float new(vector float a, vector float b, vector float c) {
return vec_neg(vec_madd(a, b, vec_neg(c)));
}
```
on newer powerpc cpus, these both generate the exact same assembly as expected:
```asm
xvnmsubasp 36, 34, 35
vmr 2, 4
blr
```
however for older cpus, the non-intrinsic implementation fails to optimize
```asm
old:
vnmsubfp 2, 2, 3, 4
blr
new:
vspltisb 5, -1
vslw 5, 5, 5
vsubfp 4, 5, 4
vmaddfp 2, 2, 3, 4
vsubfp 2, 5, 2
blrasm
```
this came up here https://github.com/rust-lang/stdarch/pull/1734
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129441] wasm: `__builtin_reduce_and` does not optimize well
Issue
129441
Summary
wasm: `__builtin_reduce_and` does not optimize well
Labels
new issue
Assignees
Reporter
folkertdev
given this C code
https://godbolt.org/z/YMo1qqccT
```c
#include
#include
bool foo(v128_t a) { return wasm_i8x16_all_true(a); }
bool bar(v128_t a) {
v128_t zero = wasm_i8x16_splat(0);
return __builtin_reduce_and(wasm_i8x16_ne(a, zero));
}
bool baz(v128_t a) {
v128_t zero = wasm_i8x16_splat(0);
return __builtin_reduce_and((a != zero));
}
```
I'd expect these all to optimize to
```asm
foo:
local.get 0
i8x16.all_true
end_function
```
or some variation in it. However, the other variants optimize much worse.
```asm
bar:
local.get 0
v128.const 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
i8x16.ne
local.tee 0
local.get 0
local.get 0
i8x16.shuffle 8, 9, 10, 11, 12, 13, 14, 15, 0, 1, 2, 3, 0, 1, 2, 3
v128.and
local.tee 0
local.get 0
local.get 0
i8x16.shuffle 4, 5, 6, 7, 0, 1, 2, 3, 0, 1, 2, 3, 0, 1, 2, 3
v128.and
i32x4.extract_lane 0
i32.const 0
i32.ne
end_function
baz:
local.get 0
v128.const 0, 0, 0, 0
i32x4.eq
v128.any_true
i32.const -1
i32.xor
i32.const 1
i32.and
end_function
```
Binary size is especially important for wasm, and it looks like `__builtin_reduce_and` just does not optimize well (I suspect the same is true for `__builtin_reduce_or).
s390x has the same limitation https://github.com/llvm/llvm-project/issues/129434, so maybe some work can be shared between backends?
This came up while working on the rust standard library, which would rather use the generic implementation of operations than a target-specific one.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129448] [clangd] Show Value on hover for objects representable at constexpr
Issue 129448 Summary [clangd] Show Value on hover for objects representable at constexpr Labels new issue Assignees Reporter torshepherd Currently, hovers on basic values like `const char*` display their constexpr value:  However, hovers on structs and other objects don't show a value:  They _could_ feasibly use one of three strategies for displaying a value: 1. Do the same thing that P2741R3 does; if the type has .data() and .size() methods, treat it as a way to display the values and use them to render characters in the hover. 2. if the type has a constexpr ostream operator, constexpr formatter specialization, etc. use that. 3. __builtin_dump_struct or similar method of displaying the fields I think #1 is the cleanest, and as more things become possible at constexpr this could be useful for debugging constexpr code more easily. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129434] s390x: `__builtin_reduce_and` does not optimize well
Issue
129434
Summary
s390x: `__builtin_reduce_and` does not optimize well
Labels
new issue
Assignees
Reporter
folkertdev
given this C code
https://godbolt.org/z/WvfG8TTxf
```c
#include
#include
bool vectors_equal_builtin(vector int a, vector int b) {
return vec_all_eq(a, b);
}
typedef int vec4i __attribute__((vector_size(16)));
bool vectors_equal_manual(vec4i a, vec4i b) {
return __builtin_reduce_and(a == b);
}
```
The manual implementation fails to optimize to the builtin one.
```asm
vectors_equal_builtin:
vceqfs %v0, %v24, %v26
lghi%r2, 0
locghie %r2, 1
br %r14
vectors_equal_manual:
aghi%r15, -168
vceqf %v0, %v24, %v26
vno %v0, %v0, %v0
vlgvf %r1, %v0, 0
vlgvf %r0, %v0, 1
sll %r1, 3
rosbg %r1, %r0, 61, 61, 2
vlgvf %r0, %v0, 2
rosbg %r1, %r0, 62, 62, 1
vlgvf %r0, %v0, 3
rosbg %r1, %r0, 63, 63, 0
tmll %r1, 15
lghi%r2, 0
locghie %r2, 1
aghi %r15, 168
br %r14
```
```llvm
define dso_local noundef zeroext i1 @vectors_equal_manual(<4 x i32> noundef %a, <4 x i32> noundef %b) local_unnamed_addr {
entry:
%0 = icmp ne <4 x i32> %a, %b
%1 = bitcast <4 x i1> %0 to i4
%2 = icmp eq i4 %1, 0
ret i1 %2
}
```
There are many varitions on `vec_all_eq` (see https://www.ibm.com/docs/en/zos/2.4.0?topic=functions-any-predicates), and it would be neat if those all optimized. It might be possible to simplify clang's `vecintrin.h` too.
This came up while implementing `vec_all_eq` in the rust standard library, where fewer custom intrinsics are better in every way.
cc @uweigand (posted here so it can be linked to)
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129427] Unexpected behaviour - Clang does not consider a partial specialization with a concept more specialized than the primary template when the parameter order is changed.
Issue 129427 Summary Unexpected behaviour - Clang does not consider a partial specialization with a concept more specialized than the primary template when the parameter order is changed. Labels Assignees Reporter alkut Here is a link to the issue on Compiler Explorer: [Compiler Explorer](https://godbolt.org/z/zv1jcPaEW). When we change the order of specialization parameters (#define SWAP_SPECIALIZATION_PARAMETERS 1), Clang produces the following error: error: class template partial specialization is not more specialized than the primary template [-Winvalid-partial-specialization] However, the error disappears if we keep the parameter order the same as in the primary template (#define SWAP_SPECIALIZATION_PARAMETERS 0). Meanwhile, both GCC and MSVC compile both versions without errors or warnings ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129429] Bogus new error on Wparentheses
Issue
129429
Summary
Bogus new error on Wparentheses
Labels
Assignees
Reporter
dcb314
For this C++ code:
extern void g( int);
void f( int a, int b, int c)
{
if (a <= b <= c)
{
g( a);
}
}
given to a couple of recent builds of clang, does this:
Alphasrc $ /home/dcb40b/llvm/results.20250221/bin/clang++ -c -g -O2 -Wall mar2b.cc
mar2b.cc:6:13: warning: comparisons like 'X<=Y<=Z' don't have their mathematical meaning [-Wparentheses]
6 | if (a <= b <= c)
|^
1 warning generated.
Alphasrc $ /home/dcb40b/llvm/results.20250223/bin/clang++ -c -g -O2 -Wall mar2b.cc
mar2b.cc:6:13: error: comparisons like 'X<=Y<=Z' don't have their mathematical meaning [-Wparentheses]
6 | if (a <= b <= c)
|^
1 error generated.
Alphasrc $
I think it is an error to error on this code and a warning is fine.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129437] [clang-17] [BPF] Crash to compile bpf code with .percpu section
Issue
129437
Summary
[clang-17] [BPF] Crash to compile bpf code with .percpu section
Labels
new issue
Assignees
Reporter
Asphaltt
I'm going to implement a new feature to support global percpu data in bpf. But it crashed to compile the following bpf code with clang-17:
```c
// SPDX-License-Identifier: GPL-2.0
#include
#include
int data SEC(".percpu") = -1;
char run SEC(".percpu") = 0;
int nums[7] SEC(".percpu");
struct {
char set;
int i;
int nums[7];
} struct_data SEC(".percpu") = {
.set = 0,
.i = -1,
};
SEC("raw_tp/task_rename")
int update_percpu_data(struct __sk_buff *skb)
{
data = ""
run = 1;
nums[6] = 0xc0de;
struct_data.i = 1;
struct_data.set = 1;
struct_data.nums[6] = 0xc0de;
return 0;
}
char _license[] SEC("license") = "GPL";
```
Here is the crash log:
```crash
fatal error: error in backend: unable to write nop sequence of 3 bytes
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments: clang-17 -g -Wall -Werror -D__TARGET_ARCH_x86 -mlittle-endian -I/tmp/work/bpf/bpf/tools/testing/selftests/bpf/tools/include -I/tmp/work/bpf/bpf/tools/testing/selftests/bpf -I/tmp/work/bpf/bpf/tools/include/uapi -I/tmp/work/bpf/bpf/tools/testing/selftests/usr/include -std=gnu11 -fno-strict-aliasing -Wno-compare-distinct-pointer-types -idirafter /usr/lib/llvm-17/lib/clang/17/include -idirafter /usr/local/include -idirafter /usr/include/x86_64-linux-gnu -idirafter /usr/include -DENABLE_ATOMICS_TESTS -O2 --target=bpfel -c progs/test_global_percpu_data.c -mcpu=v3 -o /tmp/work/bpf/bpf/tools/testing/selftests/bpf/test_global_percpu_data.bpf.o
1. parser at end of file
2. Code generation
Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it):
CLNG-BPF [test_progs] test_ksyms.bpf.o
CLNG-BPF [test_progs] test_ksyms_module.bpf.o
CLNG-BPF [test_progs] test_ksyms_weak.bpf.o
0 libLLVM-17.so.10x7fc1d214dbbf llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 63
1 libLLVM-17.so.10x7fc1d214bee9 llvm::sys::RunSignalHandlers() + 89
2 libLLVM-17.so.10x7fc1d209ce43
3 libLLVM-17.so.1 0x7fc1d209cdf2
4 libLLVM-17.so.10x7fc1d2148720 llvm::sys::Process::Exit(int, bool) + 48
5 clang-17 0x5575c8e4452b
6 libLLVM-17.so.10x7fc1d20aaffc llvm::report_fatal_error(llvm::Twine const&, bool) + 284
7 libLLVM-17.so.10x7fc1d3747512 llvm::MCAssembler::writeSectionData(llvm::raw_ostream&, llvm::MCSection const*, llvm::MCAsmLayout const&) const + 4658
8 libLLVM-17.so.1 0x7fc1d37324b9
9 libLLVM-17.so.10x7fc1d3730fd4
10 libLLVM-17.so.10x7fc1d3747eef llvm::MCAssembler::Finish() + 79
11 libLLVM-17.so.1 0x7fc1d3[767](https://github.com/kernel-patches/bpf/actions/runs/13483517280/job/37671704896?pr=8543#step:9:769)00a llvm::MCELFStreamer::finishImpl() + 202
12 libLLVM-17.so.1 0x7fc1d2a1f876 llvm::AsmPrinter::doFinalization(llvm::Module&) + 6214
13 libLLVM-17.so.10x7fc1d229d4d1 llvm::FPPassManager::doFinalization(llvm::Module&) + 65
14 libLLVM-17.so.1 0x7fc1d2297ca1 llvm::legacy::PassManagerImpl::run(llvm::Module&) + 1249
CLNG-BPF [test_progs] test_l4lb.bpf.o
15 libclang-cpp.so.17 0x7fc1da51e2be clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::IntrusiveRefCntPtr, std::unique_ptr>) + 6878
16 libclang-cpp.so.17 0x7fc1da89fee2
CLNG-BPF [test_progs] test_l4lb_noinline.bpf.o
17 libclang-cpp.so.17 0x7fc1d9534ec6 clang::ParseAST(clang::Sema&, bool, bool) + 598
18 libclang-cpp.so.17 0x7fc1db2916dc clang::FrontendAction::Execute() + 92
19 libclang-cpp.so.17 0x7fc1db20efa4 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 708
20 libclang-cpp.so.17 0x7fc1db30c8d3 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 675
21 clang-17 0x5575c8e44126 cc1_main(llvm::ArrayRef, char const*, void*) + 2454
22 clang-17 0x5575c8e41b94
23 libclang-cpp.so.17 0x7fc1daecf372
24 libLLVM-17.so.1 0x7fc1d209cdc7 llvm::CrashRecoveryContext::RunSafely(llvm::function_ref) + 151
25 libclang-cpp.so.17 0x7fc1daeceb07 clang::driver::CC1Command::Execute(llvm::ArrayRef>, std::__cxx11::basic_string, std::allocator>*, bool*) const + 407
26 libclang-cpp.so.17 0x7fc1dae97b8f clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, clang::driver::Command const*&, bool) const + 879
27
[llvm-bugs] [Bug 129483] UNREACHABLE executed at /root/llvm-project/clang/lib/CodeGen/CodeGenModule.cpp:1961!
Issue
129483
Summary
UNREACHABLE executed at /root/llvm-project/clang/lib/CodeGen/CodeGenModule.cpp:1961!
Labels
Assignees
Reporter
bi6c
Compiler Explorer: https://godbolt.org/z/Tzh1o37Mx
Testcase is generated by a fuzzer.
console:
```console
:15:1: warning: non-void function does not return a value [-Wreturn-type]
15 | }
| ^
:26:1: warning: non-void function does not return a value [-Wreturn-type]
26 | }
| ^
None multiversion type isn't valid here
UNREACHABLE executed at /root/llvm-project/clang/lib/CodeGen/CodeGenModule.cpp:1961!
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments: /opt/compiler-explorer/clang-assertions-trunk/bin/clang -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
1. parser at end of file
2. :17:5: LLVM IR generation of declaration 'copyQueryResult'
3. :17:5: Generating code for declaration 'copyQueryResult'
4. :21:18: LLVM IR generation of compound statement ('{}')
#0 0x03e53898 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x3e53898)
#1 0x03e51554 llvm::sys::CleanupOnSignal(unsigned long) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x3e51554)
#2 0x03d9de88 CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0
#3 0x77a3f9c42520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#4 0x77a3f9c969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
#5 0x77a3f9c42476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
#6 0x77a3f9c287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
#7 0x03da97ea (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x3da97ea)
#8 0x043c2bba getMangledNameImpl(clang::CodeGen::CodeGenModule&, clang::GlobalDecl, clang::NamedDecl const*, bool) CodeGenModule.cpp:0:0
#9 0x043d9cbd clang::CodeGen::CodeGenModule::getMangledName(clang::GlobalDecl) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x43d9cbd)
#10 0x04413ed1 clang::CodeGen::CodeGenModule::GetAddrOfFunction(clang::GlobalDecl, llvm::Type*, bool, bool, clang::CodeGen::ForDefinition_t) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x4413ed1)
#11 0x04190e6e clang::CodeGen::CodeGenModule::getRawFunctionPointer(clang::GlobalDecl, llvm::Type*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x4190e6e)
#12 0x0419d1e4 EmitDirectCallee(clang::CodeGen::CodeGenFunction&, clang::GlobalDecl) CGExpr.cpp:0:0
#13 0x041bba6b clang::CodeGen::CodeGenFunction::EmitCallee(clang::Expr const*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x41bba6b)
#14 0x041bba17 clang::CodeGen::CodeGenFunction::EmitCallee(clang::Expr const*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x41bba17)
#15 0x041bd2b3 clang::CodeGen::CodeGenFunction::EmitCallExpr(clang::CallExpr const*, clang::CodeGen::ReturnValueSlot, llvm::CallBase**) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x41bd2b3)
#16 0x0422d534 (anonymous namespace)::ScalarExprEmitter::VisitCallExpr(clang::CallExpr const*) CGExprScalar.cpp:0:0
#17 0x04220a40 clang::StmtVisitorBase::Visit(clang::Stmt*) CGExprScalar.cpp:0:0
#18 0x04222a8b (anonymous namespace)::ScalarExprEmitter::Visit(clang::Expr*) CGExprScalar.cpp:0:0
#19 0x0422d7a1 (anonymous namespace)::ScalarExprEmitter::VisitBinAssign(clang::BinaryOperator const*) CGExprScalar.cpp:0:0
#20 0x04221e6b clang::StmtVisitorBase::Visit(clang::Stmt*) CGExprScalar.cpp:0:0
#21 0x04222a8b (anonymous namespace)::ScalarExprEmitter::Visit(clang::Expr*) CGExprScalar.cpp:0:0
#22 0x04220d83 clang::StmtVisitorBase::Visit(clang::Stmt*) CGExprScalar.cpp:0:0
#23 0x0422ea8d clang::CodeGen::CodeGenFunction::EmitPromotedScalarExpr(clang::Expr const*, clang::QualType) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x422ea8d)
#24 0x0422f63e (anonymous namespace)::ScalarExprEmitter::EmitBinOps(clang::BinaryOperator const*, clang::QualType) CGExprScalar.cpp:0:0
#25 0x0422fd65 (anonymous namespace)::ScalarExprEmitter::EmitCompare(clang::BinaryOperator const*, llvm::CmpInst::Predicate, llvm::CmpInst::Predicate, llvm::CmpInst::Predicate, bool) CGExprScalar.cpp:0:0
#26 0x04221c86 clang::StmtVisitorBase::Visit(clang::Stmt*) CGExprScalar.cpp:0:0
#27 0x0422657c clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x422657c)
#28 0x0418
[llvm-bugs] [Bug 129474] [LV] Inefficient gather/scatter address calculation for strided access
Issue
129474
Summary
[LV] Inefficient gather/scatter address calculation for strided access
Labels
new issue
Assignees
Reporter
kinoshita-fj
LLVM generates inefficient code for strided array access in loops. Address calculations within the loop use vector operations on offset vectors instead of the scalar base register, leading to performance degradation.
For example:
```c
void func(double* a, int n)
{
for (int i = 0; i < n; i++) {
a[i*5] = 1;
}
}
```
SVE
```
.LBB0_4:
add z3.d, z2.d, z0.d
mul z2.d, z2.d, #40
subsx11, x11, x9
st1d{ z1.d }, p0, [x0, z2.d]
mov z2.d, z3.d
b.ne .LBB0_4
```
AVX-512
```
.LBB0_4:
vpmullq ymm4, ymm0, ymm1
kxnorw k1, k0, k0
vscatterqpd qword ptr [rdi + ymm4] {k1}, ymm2
vpaddq ymm0, ymm0, ymm3
add rdx, -4
jne .LBB0_4
```
https://godbolt.org/z/9MPnPvKG8
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129444] [RFC] [mingw-w64] Reduce stack protector overhead by marking `__stack_chk_guard` as DSO-local
Issue
129444
Summary
[RFC] [mingw-w64] Reduce stack protector overhead by marking `__stack_chk_guard` as DSO-local
Labels
platform:windows
Assignees
Reporter
alvinhochun
Currently `__stack_chk_guard` is not DSO-local on mingw-w64 target to support linking to libssp as a DLL, as per 78a57069b53a08d5aef98a8472fcfa73dbbc8771. As a result, the stack protector code needs to perform an additional address dereference through the `.refptr` stub, compared to MSVC target.
Since mingw-w64 v11, the functionality of `libssp` has been integrated into mingw-w64-crt, so libssp is no longer necessary and `__stack_chk_guard` is guaranteed to be statically linked. Therefore, I suggest we should start marking `__stack_chk_guard` as DSO-local in LLVM 21 to remove the need to go through `.refptr`, which should give a slight performance boost when stack protector is used.
Demo code:
```c++
#ifdef DSO_LOCAL_STACK_CHK_GUARD
void *__stack_chk_guard __asm__("__stack_chk_guard");
#endif
extern "C" void other(void *);
int func(int v) {
int buf[16];
buf[0] = v;
other(buf);
return *buf;
}
```
Output: https://godbolt.org/z/5xhsKPqhG
### Backward compatibility issues:
By the time LLVM 21 releases, mingw-w64 v11 would have been released for over 2 years. Nevertheless, some users may be stuck with an older version of mingw-w64 runtime, so we need to consider the backward compatibility.
- If libssp is linked statically, this will still work normally.
- If libssp is linked dynamically, then the linker is forced to generate 32-bit pseudo relocations for `__stack_chk_guard`, and on x86_64, these can fail during run-time if the address offset is larger than 32-bit. LLD does emit warnings for them. This is a breaking change. (The user can work around this by linking libssp statically.)
Is this acceptable?
CC @mstorsjo @lhmouse @lazka @brechtsanders
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
