[llvm-bugs] [Bug 128656] [libc++] P3372R3: constexpr `deque`
Issue 128656 Summary [libc++] P3372R3: constexpr `deque` Labels libc++, c++26 Assignees Reporter frederick-vs-ja Make `deque` constexpr as part of P3372R3. Feature-test macro: ```C++ #define __cpp_lib_constexpr_deque 202502L // also in ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128657] False positive warning `warning: instantiation of variable 'declvar' required here, but no definition is available`, when the definition is not required
Issue
128657
Summary
False positive warning `warning: instantiation of variable 'declvar' required here, but no definition is available`, when the definition is not required
Labels
new issue
Assignees
Reporter
HolyBlackCat
Consider the following code:
```cpp
#include
struct A {explicit constexpr operator bool() const {return true;}};
struct B {int x = 1; explicit constexpr operator bool() const {return x;}};
template
extern T declvar;
template
concept C = requires{typename std::bool_constant ? true : false>;};
static_assert(C);
static_assert(!C);
```
This works correctly on all 3 bug compilers including Clang (and seems to be the only good way of doing this).
But Clang emits a useless warning:
```none
:10:50: warning: instantiation of variable 'declvar' required here, but no definition is available [-Wundefined-var-template]
10 | concept C = requires{typename std::bool_constant ? true : false>;};
| ^
:7:10: note: forward declaration of template entity is here
7 | extern T declvar;
| ^
:10:50: note: add an explicit instantiation declaration to suppress this warning if 'declvar' is explicitly instantiated in another translation unit
10 | concept C = requires{typename std::bool_constant ? true : false>;};
| ^
```
The variable definition isn't needed here, so it shouldn't warn.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128658] [libc++] P3372R3: constexpr `forward_list`
Issue 128658 Summary [libc++] P3372R3: constexpr `forward_list` Labels libc++, c++26 Assignees Reporter frederick-vs-ja Make `forward_list` constexpr as part of P3372R3. Feature-test macro: ```C++ #define __cpp_lib_constexpr_forward_list 202502L // also in ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128659] [libc++] P3372R3: constexpr `list`
Issue 128659 Summary [libc++] P3372R3: constexpr `list` Labels libc++, c++26 Assignees Reporter frederick-vs-ja Make `list` constexpr as part of P3372R3. Feature-test macro: ```C++ #define __cpp_lib_constexpr_list 202502L // also in ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128660] [libc++] P3372R3: constexpr `map`
Issue 128660 Summary [libc++] P3372R3: constexpr `map` Labels libc++, c++26 Assignees Reporter frederick-vs-ja Make `map` constexpr as part of P3372R3. Note that `node-handle::key()` is intentionally left not constexpr. Feature-test macro (also covers constexpr `multimap`): ```C++ #define __cpp_lib_constexpr_map 202502L // also in ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128661] [libc++] P3372R3: constexpr `multimap`
Issue 128661 Summary [libc++] P3372R3: constexpr `multimap` Labels libc++, c++26 Assignees Reporter frederick-vs-ja Make `multimap` constexpr as part of P3372R3. Note that `node-handle::key()` is intentionally left not constexpr. Feature-test macro (also covers constexpr `map`): ```C++ #define __cpp_lib_constexpr_map 202502L // also in ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128663] [libc++] P3372R3: constexpr `set`
Issue 128663 Summary [libc++] P3372R3: constexpr `set` Labels libc++, c++26 Assignees Reporter frederick-vs-ja Make `set` constexpr as part of P3372R3. Feature-test macro (also covers constexpr `multiset`): ```C++ #define __cpp_lib_constexpr_set 202502L // also in ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128664] [libc++] P3372R3: constexpr `multiset`
Issue 128664 Summary [libc++] P3372R3: constexpr `multiset` Labels libc++, c++26 Assignees Reporter frederick-vs-ja Make `multiset` constexpr as part of P3372R3. Feature-test macro (also covers constexpr `set`): ```C++ #define __cpp_lib_constexpr_set 202502L // also in ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128665] Suboptimal boolean reduction vectorization
Issue 128665 Summary Suboptimal boolean reduction vectorization Labels new issue Assignees Reporter psiha Both Clang and GCC struggle, ARM and x86, but GCC does a better job overall (yet still suboptimal/worse than the handwritten version). If you make the accumulation variable (occurrences) 32 bit at least that helps them use horizontal adds/addv (and it again helps GCC more than Clang). https://godbolt.org/z/bjT819fPE [minbench.zip](https://github.com/user-attachments/files/18960269/minbench.zip) ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128667] [libc++] P3372R3: constexpr `unordered_multimap`
Issue 128667 Summary [libc++] P3372R3: constexpr `unordered_multimap` Labels libc++, c++26 Assignees Reporter frederick-vs-ja Make `unordered_multimap` constexpr as part of P3372R3. Note that `node-handle::key()` is intentionally left not constexpr, and the constexpr-ness largely requires a user-defined hash functor. Feature-test macro (also covers constexpr `unordered_map`): ```C++ #define __cpp_lib_constexpr_unordered_map 202502L // also in ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128666] [libc++] P3372R3: constexpr `unordered_map`
Issue 128666 Summary [libc++] P3372R3: constexpr `unordered_map` Labels libc++, c++26 Assignees Reporter frederick-vs-ja Make `unordered_map` constexpr as part of P3372R3. Note that `node-handle::key()` is intentionally left not constexpr, and the constexpr-ness largely requires a user-defined hash functor. Feature-test macro (also covers constexpr `unordered_multimap`): ```C++ #define __cpp_lib_constexpr_unordered_map 202502L // also in ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128668] [libc++] P3372R3: constexpr `unordered_set`
Issue 128668 Summary [libc++] P3372R3: constexpr `unordered_set` Labels libc++, c++26 Assignees Reporter frederick-vs-ja Make `unordered_set` constexpr as part of P3372R3. Note that the constexpr-ness largely requires a user-defined hash functor. Feature-test macro (also covers constexpr `unordered_multiset`): ```C++ #define __cpp_lib_constexpr_unordered_set 202502L // also in ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128669] [libc++] P3372R3: constexpr `unordered_multiset`
Issue 128669 Summary [libc++] P3372R3: constexpr `unordered_multiset` Labels libc++, c++26 Assignees Reporter frederick-vs-ja Make `unordered_multiset` constexpr as part of P3372R3. Note that the constexpr-ness largely requires a user-defined hash functor. Feature-test macro (also covers constexpr `unordered_set`): ```C++ #define __cpp_lib_constexpr_unordered_set 202502L // also in ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128671] [libc++] P3372R3: constexpr `priority_queue`
Issue 128671 Summary [libc++] P3372R3: constexpr `priority_queue` Labels libc++, c++26 Assignees Reporter frederick-vs-ja Make `priority_queue` constexpr as part of P3372R3. Feature-test macro (also covers constexpr `queue`): ```C++ #define __cpp_lib_constexpr_queue 202502L // also in ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128670] [libc++] P3372R3: constexpr `queue`
Issue 128670 Summary [libc++] P3372R3: constexpr `queue` Labels libc++, c++26 Assignees Reporter frederick-vs-ja Make `queue` constexpr as part of P3372R3. Feature-test macro (also covers constexpr `priority_queue`): ```C++ #define __cpp_lib_constexpr_queue 202502L // also in ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128672] [libc++] P3372R3: constexpr `stack`
Issue 128672 Summary [libc++] P3372R3: constexpr `stack` Labels libc++, c++26 Assignees Reporter frederick-vs-ja Make `stack` constexpr as part of P3372R3. Feature-test macro: ```C++ #define __cpp_lib_constexpr_stack 202502L // also in ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128674] [libc++] P3372R3: constexpr `flat_multimap`
Issue 128674 Summary [libc++] P3372R3: constexpr `flat_multimap` Labels libc++, c++26 Assignees Reporter frederick-vs-ja Make `flat_multimap` constexpr as part of P3372R3. Feature-test macro (also covers constexpr `flat_map`): ```C++ #define __cpp_lib_constexpr_flat_map 202502L // also in ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128673] [libc++] P3372R3: constexpr `flat_map`
Issue 128673 Summary [libc++] P3372R3: constexpr `flat_map` Labels libc++, c++26 Assignees Reporter frederick-vs-ja Make `flat_map` constexpr as part of P3372R3. Feature-test macro (also covers constexpr `flat_multimap`): ```C++ #define __cpp_lib_constexpr_flat_map 202502L // also in ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128676] [libc++] P3372R3: constexpr `flat_multiset`
Issue 128676 Summary [libc++] P3372R3: constexpr `flat_multiset` Labels libc++, c++26 Assignees Reporter frederick-vs-ja Make `flat_multiset` constexpr as part of P3372R3. Feature-test macro (also covers constexpr `flat_set`): ```C++ #define __cpp_lib_constexpr_flat_set 202502L // also in ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128675] [libc++] P3372R3: constexpr `flat_set`
Issue 128675 Summary [libc++] P3372R3: constexpr `flat_set` Labels libc++, c++26 Assignees Reporter frederick-vs-ja Make `flat_set` constexpr as part of P3372R3. Feature-test macro (also covers constexpr `flat_multiset`): ```C++ #define __cpp_lib_constexpr_flat_set 202502L // also in ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128691] clang assert: "Assertion `getDepthAndIndex(NewParam).first == 0 && "Unexpected template parameter depth"' failed."
Issue
128691
Summary
clang assert: "Assertion `getDepthAndIndex(NewParam).first == 0 && "Unexpected template parameter depth"' failed."
Labels
clang:frontend
Assignees
Reporter
hokein
https://godbolt.org/z/TPjf1YYY3
A regression from https://github.com/llvm/llvm-project/pull/43
```
template
class NewDeleteAllocator;
template <>
struct NewDeleteAllocator<> {
template
NewDeleteAllocator();
};
template
struct NewDeleteAllocator : NewDeleteAllocator<> {
using NewDeleteAllocator<>::NewDeleteAllocator;
};
void test() { NewDeleteAllocator abc; }
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128685] AMDGPU SALU pseudos should not have side effects
Issue 128685 Summary AMDGPU SALU pseudos should not have side effects Labels backend:AMDGPU Assignees Reporter jayfoad The following pseudos do not have an explicit `hasSideEffects = 0` in the *.td files, so the MCInstrs are marked as `MCID::UnmodeledSideEffects`: ``` S_ADD_CO_PSEUDO S_MUL_I64_I32_PSEUDO S_MUL_U64_U32_PSEUDO S_SUB_CO_PSEUDO S_UADDO_PSEUDO S_USUBO_PSEUDO ``` These are all regular ALU operations without side effects. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128688] clang-cl writes preprocessed assembly source to current dir in some invocations
Issue 128688 Summary clang-cl writes preprocessed assembly source to current dir in some invocations Labels new issue Assignees Reporter iskunk I am using Clang/LLVM 19.1.2, and encountered an [error](https://issues.chromium.org/398489345) in a cross build of Chromium (host = Linux on AMD64, target = Windows on ARM64), along these lines: ``` FAILED: clang_x64/obj/third_party/ffmpeg/ffmpeg_nasm/autorename_libavcodec_x86_videodsp.o python3 ../../build/gn_run_binary.py clang_x64/nasm -DPIC -felf64 -DARCH_X86_64 -W+error=all -Wno-macro-params-legacy -P../../third_party/ffmpeg/chromium/config/Chrome/linux/x64/config.asm -I../../third_party/ffmpeg/chromium/config/Chrome/linux/x64/ -I../../third_party/ffmpeg/libavcodec/x86/ -I../../third_party/ffmpeg/libavutil/x86/ -I../../third_party/ffmpeg/ -I./ -I../../ -Iclang_x64/gen/ -DPIC -MD clang_x64/obj/third_party/ffmpeg/ffmpeg_nasm/autorename_libavcodec_x86_videodsp.o.d -o clang_x64/obj/third_party/ffmpeg/ffmpeg_nasm/autorename_libavcodec_x86_videodsp.o ../../third_party/ffmpeg/libavcodec/x86/autorename_libavcodec_x86_videodsp.asm ../../third_party/ffmpeg/libavutil/aarch64/asm.S:47: error: parser: instruction expected ../../third_party/ffmpeg/libavutil/aarch64/asm.S:82: error: parser: instruction expected ../../third_party/ffmpeg/libavutil/aarch64/asm.S:83: error: parser: instruction expected [...] clang_x64/nasm failed with exit code 1 ``` This error occurred due to the presence of a `videodsp.asm` file in the assembler's working directory. This file had been generated in a previous build step, and it contained preprocessed assembler source for aarch64. The assembler picked it up for some reason and attempted to generate AMD64 code from it. Further investigation showed where the `videodsp.asm` file came from: an invocation of `clang-cl`. But it was not the Chromium build's intended invocation, which is as follows: ``` /opt/llvm/bin/clang-cl --target=aarch64-pc-windows -c -oobj/third_party/ffmpeg/ffmpeg_internal/videodsp.obj /showIncludes [various -D flags elided] [various -I flags elided] ../../third_party/ffmpeg/libavcodec/aarch64/videodsp.S ``` That works as expected, with an `.obj` file written out, and no other side effects. However, when `ccache` is in use, the command is modified slightly into the following: ``` /opt/llvm/bin/clang-cl --target=aarch64-pc-windows [various -D flags elided] [various -I flags elided] -c /showIncludes -fcolor-diagnostics -Foobj/third_party/ffmpeg/ffmpeg_internal/videodsp.obj ../../third_party/ffmpeg/libavcodec/aarch64/videodsp.S ``` And for reasons unknown, this invocation generates a `videodsp.asm` file in the current working directory. Here is the full output from an invocation of the first command above, with `-v` added: ``` clang version 19.1.2 (/home/runner/work/llvm-project/llvm-project/clang 7ba7d8e2f7b6445b60679da826210cdde29eaf8b) Target: aarch64-pc-windows-msvc Thread model: posix InstalledDir: /opt/llvm/bin "/opt/llvm/bin/clang-19" -cc1 -triple aarch64-pc-windows-msvc19.33.0 -E -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name videodsp.S -mrelocation-model pic -pic-level 2 -mframe-pointer=none -relaxed-aliasing -fmath-errno -ffp-contract=on -fno-rounding-math -mconstructor-aliases -funwind-tables=2 -target-cpu generic -target-feature +v8a -target-feature +fp-armv8 -target-feature +neon -target-abi aapcs -D_MT -flto-visibility-public-std --dependent-lib=libcmt --dependent-lib=oldnames --show-includes -sys-header-deps -stack-protector 2 -fdiagnostics-format msvc -fdebug-compilation-dir=/home/build/u-c-windows/cross-build/build/src/out/Default-arm64 -v -fcoverage-compilation-dir=/home/build/u-c-windows/cross-build/build/src/out/Default-arm64 -resource-dir /opt/llvm/lib/clang/19 -D HAVE_AV_CONFIG_H -D _POSIX_C_SOURCE=200112 -D _XOPEN_SOURCE=600 -D PIC -D FFMPEG_CONFIGURATION=NULL -D CHROMIUM_NO_LOGGING -D _ISOC99_SOURCE -D _LARGEFILE_SOURCE -D USE_AURA=1 -D OFFICIAL_BUILD -D __ARM_NEON__=1 -D _LIBCPP_HARDENING_MODE=_LIBCPP_HARDENING_MODE_EXTENSIVE -D _LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS -D _LIBCPP_INSTRUMENTED_WITH_ASAN=0 -D CR_LIBCXX_REVISION=1f7db7501cf902d5d3ad5fd9b31bea33bb8bf9da -D TMP_REBUILD_HACK -D __STD_C -D _CRT_RAND_S -D _CRT_SECURE_NO_DEPRECATE -D _SCL_SECURE_NO_DEPRECATE -D _ATL_NO_OPENGL -D _WINDOWS -D CERT_CHAIN_PARA_HAS_EXTRA_FIELDS -D PSAPI_VERSION=2 -D WIN32 -D _SECURE_ATL -D WINAPI_FAMILY=WINAPI_FAMILY_DESKTOP_APP -D WIN32_LEAN_AND_MEAN -D NOMINMAX -D _UNICODE -D UNICODE -D NTDDI_VERSION=NTDDI_WIN10_NI -D _WIN32_WINNT=0x0A00 -D WINVER=0x0A00 -D NDEBUG -D NVALGRIND -D DYNAMIC_ANNOTATIONS_ENABLED=0 -D _CRT_NONSTDC_NO_WARNINGS -D _WINSOCK_DEPRECATED_NO_WARNINGS -I ../../third_party/ffmpeg/chromium/config/Chrome/win/arm64 -I ../../third_
[llvm-bugs] [Bug 128689] [backport] backport https://github.com/llvm/llvm-project/commit/366daddfad9aa38ebb7d40055cf65f4ecb7dd6f9#commitcomment-152968765 to LLVM20
Issue 128689 Summary [backport] backport https://github.com/llvm/llvm-project/commit/366daddfad9aa38ebb7d40055cf65f4ecb7dd6f9#commitcomment-152968765 to LLVM20 Labels new issue Assignees Reporter ChuanqiXu9 This is a simple change that I directly landed to address post commit review https://github.com/llvm/llvm-project/pull/119333#pullrequestreview-2637471908 And this should be backported to LLVM20. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128778] [AArch64] `!struct.x && !struct.y` produces worse code than `(struct.x == 0) && (struct.y == 0)`
Issue
128778
Summary
[AArch64] `!struct.x && !struct.y` produces worse code than `(struct.x == 0) && (struct.y == 0)`
Labels
backend:AArch64,
llvm:instcombine
Assignees
Reporter
Kmeakin
`!it.x && !it.y` produces worse code than `(it.x == 0) && (it.y == 0)` if `it` is a struct type with `bool` members `x` and `y`.
Oddly using a `uint8_t` for `x` and `y` does not suffer from this problem.
# Real-world motivation
[This struct from mimalloc](https://github.com/microsoft/mimalloc/blob/a857a04803175cb51e1016339bda5b7993530729/include/mimalloc/types.h#L255)
```c++
// The `in_full` and `has_aligned` page flags are put in a union to efficiently
// test if both are false (`full_aligned == 0`) in the `mi_free` routine.
typedef union mi_page_flags_s {
uint8_t full_aligned;
struct {
uint8_t in_full : 1;
uint8_t has_aligned : 1;
} x;
} mi_page_flags_t;
```
# C++ code
https://godbolt.org/z/1387M789s
```c++
#include
struct S1 {
bool x;
bool y;
};
struct S2 {
bool x : 1;
bool y : 1;
};
struct S3 {
uint8_t x : 1;
uint8_t y : 1;
};
struct S4 {
uint8_t x ;
uint8_t y ;
};
extern "C" {
auto src1(S1 it) -> bool { return !it.x && !it.y; }
auto tgt1(S1 it) -> bool { return (it.x == 0) && (it.y == 0); }
auto src2(S2 it) -> bool { return !it.x && !it.y; }
auto tgt2(S2 it) -> bool { return (it.x == 0) && (it.y == 0); }
auto src3(S3 it) -> bool { return !it.x && !it.y; }
auto tgt3(S3 it) -> bool { return (it.x == 0) && (it.y == 0); }
auto src4(S4 it) -> bool { return !it.x && !it.y; }
auto tgt4(S4 it) -> bool { return (it.x == 0) && (it.y == 0); }
}
```
# AArch64 assembly
```asm
src1:
tst x0, #0x100
eor w9, w0, #0x1
csetw8, eq
and w0, w8, w9
ret
tgt1:
mov w8, #257
tst x0, x8
csetw0, eq
ret
src2:
tst x0, #0x2
eor w9, w0, #0x1
csetw8, eq
and w0, w8, w9
ret
tgt2:
tst x0, #0x3
csetw0, eq
ret
src3:
tst x0, #0x3
csetw0, eq
ret
tgt3:
tst x0, #0x3
csetw0, eq
ret
src4:
tst x0, #0x
csetw0, eq
ret
tgt4:
tst x0, #0x
csetw0, eq
ret
```
# Alive proof
https://alive2.llvm.org/ce/z/JRwXu7
```llvm
define i1 @src1(i64 %#0) nofree willreturn memory(none) {
#1:
%#2 = trunc i64 %#0 to i1
%#3 = and i64 %#0, 256
%#4 = icmp eq i64 %#3, 0
%#5 = xor i1 %#2, 1
%#6 = and i1 %#4, %#5
ret i1 %#6
}
=>
define i1 @tgt1(i64 %#0) nofree willreturn memory(none) {
#1:
%#2 = and i64 %#0, 257
%#3 = icmp eq i64 %#2, 0
ret i1 %#3
}
Transformation seems to be correct!
define i1 @src2(i64 %#0) nofree willreturn memory(none) {
#1:
%#2 = trunc i64 %#0 to i1
%#3 = and i64 %#0, 2
%#4 = icmp eq i64 %#3, 0
%#5 = xor i1 %#2, 1
%#6 = and i1 %#4, %#5
ret i1 %#6
}
=>
define i1 @tgt2(i64 %#0) nofree willreturn memory(none) {
#1:
%#2 = and i64 %#0, 3
%#3 = icmp eq i64 %#2, 0
ret i1 %#3
}
Transformation seems to be correct!
define i1 @src3(i64 %#0) nofree willreturn memory(none) {
#1:
%#2 = and i64 %#0, 3
%#3 = icmp eq i64 %#2, 0
ret i1 %#3
}
=>
define i1 @tgt3(i64 %#0) nofree willreturn memory(none) {
#1:
%#2 = and i64 %#0, 3
%#3 = icmp eq i64 %#2, 0
ret i1 %#3
}
Transformation seems to be correct!
define i1 @src4(i64 %#0) nofree willreturn memory(none) {
#1:
%#2 = and i64 %#0, 65535
%#3 = icmp eq i64 %#2, 0
ret i1 %#3
}
=>
define i1 @tgt4(i64 %#0) nofree willreturn memory(none) {
#1:
%#2 = and i64 %#0, 65535
%#3 = icmp eq i64 %#2, 0
ret i1 %#3
}
Transformation seems to be correct!
Summary:
4 correct transformations
0 incorrect transformations
0 failed-to-prove transformations
0 Alive2 errors
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128790] [LLD] Implement NOCROSREFS support for overlays in linker script handling of LLD
Issue
128790
Summary
[LLD] Implement NOCROSREFS support for overlays in linker script handling of LLD
Labels
lld
Assignees
Reporter
Prabhuk
Consider the following incomplete linker script snippet:
```
OVERLAY : NOCROSSREFS {
.overlay.ob1 {*ob1*.o (.text*)}
.overlay.ob2 {*ob2*.o (.text*)}
} >SOME_MEMORY
```
LLD fails with `{ expected, but got NOCROSSREFS` while processing this.
Ideally, we would like to match the BFD linker behavior for NOCROSSREFS in this case.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128804] [MLIR] Assertion `getImpl() && "Uninitialized SparseTensorEncodingAttr"' failed.
Issue
128804
Summary
[MLIR] Assertion `getImpl() && "Uninitialized SparseTensorEncodingAttr"' failed.
Labels
mlir
Assignees
Reporter
RiRi114
Test on commit：0f9720a6
steps to reproduce:
`mlir-opt temp.mlir-sparse-tensor-codegen `
test case:
```mlir
#sparse = #sparse_tensor.encoding<{ map = (d0, d1) -> (d0 : dense, d1 : compressed) }>
func.func @sparse_tensor_demo(%arg0: tensor<128x64xf32, #sparse>) -> tensor<128x64xf32> {
%0 = sparse_tensor.convert %arg0 : tensor<128x64xf32, #sparse> to tensor<128x64xf32>
%1 = linalg.generic {
indexing_maps = [
affine_map<(i, j) -> (i, j)>, // input
affine_map<(i, j) -> (i, j)> // output
],
iterator_types = ["parallel", "parallel"]
}
ins(%arg0: tensor<128x64xf32, #sparse>)
outs(%0: tensor<128x64xf32>) {
^bb(%a: f32, %b: f32):
%sum = arith.addf %a, %b : f32
linalg.yield %sum : f32
} -> tensor<128x64xf32>
return %1 : tensor<128x64xf32>
}
```
crash trace:
```
mlir-opt: /home/fuzzing/llvm-project/mlir/lib/Dialect/SparseTensor/IR/SparseTensorDialect.cpp:462: bool mlir::sparse_tensor::SparseTensorEncodingAttr::isSlice() const: Assertion `getImpl() && "Uninitialized SparseTensorEncodingAttr"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0. Program arguments: /home/fuzzing/llvm-project/build/bin/mlir-opt temp.mlir -sparse-tensor-codegen
#0 0x0113ce77 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/home/fuzzing/llvm-project/build/bin/mlir-opt+0x113ce77)
#1 0x0113aa0e llvm::sys::RunSignalHandlers() (/home/fuzzing/llvm-project/build/bin/mlir-opt+0x113aa0e)
#2 0x0113d855 SignalHandler(int, siginfo_t*, void*) Signals.cpp:0:0
#3 0x7c3974382520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#4 0x7c39743d69fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
#5 0x7c3974382476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
#6 0x7c39743687f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
#7 0x7c397436871b (/lib/x86_64-linux-gnu/libc.so.6+0x2871b)
#8 0x7c3974379e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96)
#9 0x031b9ae2 (/home/fuzzing/llvm-project/build/bin/mlir-opt+0x31b9ae2)
#10 0x0331e647 (anonymous namespace)::SparseConvertConverter::matchAndRewrite(mlir::sparse_tensor::ConvertOp, mlir::sparse_tensor::ConvertOpGenericAdaptor >, mlir::ConversionPatternRewriter&) const SparseTensorCodegen.cpp:0:0
#11 0x0331e31b mlir::OpConversionPattern::matchAndRewrite(mlir::Operation*, llvm::ArrayRef, mlir::ConversionPatternRewriter&) const (/home/fuzzing/llvm-project/build/bin/mlir-opt+0x331e31b)
#12 0x042a5af6 mlir::ConversionPattern::matchAndRewrite(mlir::Operation*, mlir::PatternRewriter&) const (/home/fuzzing/llvm-project/build/bin/mlir-opt+0x42a5af6)
#13 0x06a1e891 void llvm::function_ref::callback_fn, llvm::function_ref, llvm::function_ref)::$_2>(long) PatternApplicator.cpp:0:0
#14 0x06a1b28f mlir::PatternApplicator::matchAndRewrite(mlir::Operation*, mlir::PatternRewriter&, llvm::function_ref, llvm::function_ref, llvm::function_ref) (/home/fuzzing/llvm-project/build/bin/mlir-opt+0x6a1b28f)
#15 0x042a6bb2 (anonymous namespace)::OperationLegalizer::legalize(mlir::Operation*, mlir::ConversionPatternRewriter&) DialectConversion.cpp:0:0
#16 0x042a5c27 mlir::OperationConverter::convert(mlir::ConversionPatternRewriter&, mlir::Operation*) (/home/fuzzing/llvm-project/build/bin/mlir-opt+0x42a5c27)
#17 0x042a6dcf mlir::OperationConverter::convertOperations(llvm::ArrayRef) (/home/fuzzing/llvm-project/build/bin/mlir-opt+0x42a6dcf)
#18 0x042ad1eb mlir::applyPartialConversion(mlir::Operation*, mlir::ConversionTarget const&, mlir::FrozenRewritePatternSet const&, mlir::ConversionConfig) (/home/fuzzing/llvm-project/build/bin/mlir-opt+0x42ad1eb)
#19 0x0326b18b (anonymous namespace)::SparseTensorCodegenPass::runOnOperation() SparseTensorPasses.cpp:0:0
#20 0x042452f7 mlir::detail::OpToOpPassAdaptor::run(mlir::Pass*, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int) (/home/fuzzing/llvm-project/build/bin/mlir-opt+0x42452f7)
#21 0x04245b61 mlir::detail::OpToOpPassAdaptor::runPipeline(mlir::OpPassManager&, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int, mlir::PassInstrumentor*, mlir::PassInstrumentation::PipelineParentInfo const*) (/home/fuzzing/llvm-project/build/bin/mlir-opt+0x4245b61)
#22 0x0424825b mlir::PassManager::run(mlir::Operation*) (/home/fuzzing/llvm-project/build/bin/mlir-opt+0x424825b)
#23 0x042408af performActions(llvm::raw_ostream&, std::shared_ptr const&, mlir::MLIRContext*, mlir::MlirOptMainConfig const&) MlirOptMain.cpp:0:0
#24
[llvm-bugs] [Bug 128805] [MLIR] invalid bound type
Issue
128805
Summary
[MLIR] invalid bound type
Labels
mlir
Assignees
Reporter
RiRi114
Test on commit : 0f9720a6
steps to reproduce:
`
mlir-opt temp.mlir -pass-pipeline='builtin.module(func.func(test-affine-reify-value-bounds))'
`
test case:
```mlir
module {
func.func @reify_bounds_example(%size1: index, %size2: index) -> (index, index) {
%c1 = arith.constant 1 : index
%tensor0 = tensor.empty(%size1, %size2) : tensor
%pos0 = arith.constant 0 : index
%element_value = arith.constant 1.0 : f64
%tensor1 = tensor.insert %element_value into %tensor0[%pos0, %pos0] : tensor
%dim0 = tensor.dim %tensor1, %c1 : tensor
%dim1 = tensor.dim %tensor1, %c1 : tensor
%lower_bound = "test.reify_bound"(%dim0) {type = "LB"} : (index) -> (index)
%upper_bound = "test.reify_bound"(%dim1) {type = "UB"} : (index) -> (index)
return %lower_bound, %upper_bound : index, index
}
func.func @test_scalable_bounds(%dimX: index) -> index {
%constant_bound = arith.constant 10 : index
%scalable_bound = "test.reify_bound"(%dimX) {type = "scalable", vscaleMin = 1, vscaleMax = 4} : (index) -> (index)
%result = arith.addi %constant_bound, %scalable_bound : index
return %result : index
}
func.func @loop_with_bound_reification(%start: index, %end: index, %step: index) {
scf.for %i = %start to %end step %step {
%reified_bound = "test.reify_bound"(%i) {type = "EQ"} : (index) -> (index)
"test.some_use"(%reified_bound) : (index) -> ()
}
return
}
}
```
crash trace:
```
invalid bound type
UNREACHABLE executed at /home/fuzzing/llvm-project/mlir/test/lib/Dialect/Test/TestOpDefs.cpp:844!
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
#0 0x0113ce77 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/home/fuzzing/llvm-project/build/bin/mlir-opt+0x113ce77)
#1 0x0113aa0e llvm::sys::RunSignalHandlers() (/home/fuzzing/llvm-project/build/bin/mlir-opt+0x113aa0e)
#2 0x0113d855 SignalHandler(int, siginfo_t*, void*) Signals.cpp:0:0
#3 0x75758e08b520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#4 0x75758e0df9fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
#5 0x75758e08b476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
#6 0x75758e0717f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
#7 0x01124c11 (/home/fuzzing/llvm-project/build/bin/mlir-opt+0x1124c11)
#8 0x04469c44 (/home/fuzzing/llvm-project/build/bin/mlir-opt+0x4469c44)
#9 0x04415a03 mlir::WalkResult llvm::function_ref::callback_fn::value)) && (std::is_same::value), mlir::WalkResult>::type mlir::detail::walk<(mlir::WalkOrder)1, mlir::ForwardIterator, testReifyValueBounds(mlir::FunctionOpInterface, bool, bool)::$_1, test::ReifyBoundOp, mlir::WalkResult>(mlir::Operation*, testReifyValueBounds(mlir::FunctionOpInterface, bool, bool)::$_1&&)::'lambda'(mlir::Operation*)>(long, mlir::Operation*) TestReifyValueBounds.cpp:0:0
#10 0x012714f7 mlir::WalkResult mlir::detail::walk(mlir::Operation*, llvm::function_ref, mlir::WalkOrder) (/home/fuzzing/llvm-project/build/bin/mlir-opt+0x12714f7)
#11 0x04415641 (anonymous namespace)::TestReifyValueBounds::runOnOperation() TestReifyValueBounds.cpp:0:0
#12 0x042452f7 mlir::detail::OpToOpPassAdaptor::run(mlir::Pass*, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int) (/home/fuzzing/llvm-project/build/bin/mlir-opt+0x42452f7)
#13 0x04245b61 mlir::detail::OpToOpPassAdaptor::runPipeline(mlir::OpPassManager&, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int, mlir::PassInstrumentor*, mlir::PassInstrumentation::PipelineParentInfo const*) (/home/fuzzing/llvm-project/build/bin/mlir-opt+0x4245b61)
#14 0x0424aede auto void mlir::parallelForEach<__gnu_cxx::__normal_iterator > >, mlir::detail::OpToOpPassAdaptor::runOnOperationAsyncImpl(bool)::$_15>(mlir::MLIRContext*, __gnu_cxx::__normal_iterator > >, __gnu_cxx::__normal_iterator > >, mlir::detail::OpToOpPassAdaptor::runOnOperationAsyncImpl(bool)::$_15&&)::'lambda'(__gnu_cxx::__normal_iterator > >&&)::operator()(__gnu_cxx::__normal_iterator > >&&) const Pass.cpp:0:0
#15 0x0424be92 std::_Function_handler > >, void mlir::parallelForEach<__gnu_cxx::__normal_iterator > >, mlir::detail::OpToOpPassAdaptor::runOnOperationAsyncImpl(bool)::$_15>(mlir::MLIRContext*, __gnu_cxx::__normal_iterator > >, __gnu_cxx::__normal_iterator > >, mlir::detail::OpToOpPassAdaptor::runOnOperationAsyncImpl(bool)::$_15&&)::'lambda'(__gnu_cxx::__normal_iterator > >&&)>(mlir::MLIRContext*, __gnu_cxx::__normal_iterator > >, __gnu_cxx::__normal_iterator > >, mlir::detail::OpToOpPassAdaptor::runOnOperationAsyncImpl(bool)::$_15&&)::'lambda'()>::_M_invoke(std::_Any_data c
[llvm-bugs] [Bug 128807] [MLIR] Assertion `*dim < shapedType.getRank() && "invalid dim value"' failed.
Issue
128807
Summary
[MLIR] Assertion `*dim < shapedType.getRank() && "invalid dim value"' failed.
Labels
mlir
Assignees
Reporter
RiRi114
Test on commit : 0f9720a6
steps to reproduce:
`
mlir-opt temp.mlir -pass-pipeline='builtin.module(func.func(test-affine-reify-value-bounds))'
`
test case:
```mlir
func.func @test_reify_example(%size: index) -> (index, index) {
%zero = arith.constant 0 : index
%tensor_val = tensor.empty(%size) : tensor
%tensor_cast = tensor.cast %tensor_val : tensor to tensor
%element_zero = arith.constant 0.0 : f32
%inserted_tensor = tensor.insert %element_zero into %tensor_cast[%zero] : tensor
%dim_0 = tensor.dim %inserted_tensor, %zero : tensor
%dim_1 = "test.reify_bound"(%inserted_tensor) {dim = 0} : (tensor) -> (index)
%dim_2 = "test.reify_bound"(%inserted_tensor) {dim = 1 : i64} : (tensor) -> index
return %dim_1, %dim_2 : index, index
}
```
crash trace:
```
mlir-opt: /home/fuzzing/llvm-project/mlir/lib/Interfaces/ValueBoundsOpInterface.cpp:170: void assertValidValueDim(mlir::Value, std::optional): Assertion `*dim < shapedType.getRank() && "invalid dim value"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0. Program arguments: /home/fuzzing/llvm-project/build/bin/mlir-opt temp.mlir -pass-pipeline=builtin.module(func.func(test-affine-reify-value-bounds))
#0 0x0113ce77 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/home/fuzzing/llvm-project/build/bin/mlir-opt+0x113ce77)
#1 0x0113aa0e llvm::sys::RunSignalHandlers() (/home/fuzzing/llvm-project/build/bin/mlir-opt+0x113aa0e)
#2 0x0113d855 SignalHandler(int, siginfo_t*, void*) Signals.cpp:0:0
#3 0x7cd102bec520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#4 0x7cd102c409fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
#5 0x7cd102bec476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
#6 0x7cd102bd27f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
#7 0x7cd102bd271b (/lib/x86_64-linux-gnu/libc.so.6+0x2871b)
#8 0x7cd102be3e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96)
#9 0x06a101a2 (/home/fuzzing/llvm-project/build/bin/mlir-opt+0x6a101a2)
#10 0x06a0fb97 mlir::ValueBoundsConstraintSet::getExpr(mlir::Value, std::optional) (/home/fuzzing/llvm-project/build/bin/mlir-opt+0x6a0fb97)
#11 0x06a11052 llvm::SmallVector > const*, mlir::ValueBoundsConstraintSet::insert(mlir::AffineMap, llvm::SmallVector >, 2u>, bool)::$_1, mlir::AffineExpr> >&>(>::type>::type, CalculateSmallVectorDefaultInlinedElements > const*, mlir::ValueBoundsConstraintSet::insert(mlir::AffineMap, llvm::SmallVector >, 2u>, bool)::$_1, mlir::AffineExpr> >&>(>::type>::type>::value> llvm::to_vector > const*, mlir::ValueBoundsConstraintSet::insert(mlir::AffineMap, llvm::SmallVector >, 2u>, bool)::$_1, mlir::AffineExpr> > >(llvm::iterator_range > const*, mlir::ValueBoundsConstraintSet::insert(mlir::AffineMap, llvm::SmallVector >, 2u>, bool)::$_1, mlir::AffineExpr> >&&) ValueBoundsOpInterface.cpp:0:0
#12 0x06a10ef4 mlir::ValueBoundsConstraintSet::insert(mlir::AffineMap, llvm::SmallVector >, 2u>, bool) (/home/fuzzing/llvm-project/build/bin/mlir-opt+0x6a10ef4)
#13 0x06a12273 mlir::ValueBoundsConstraintSet::computeBound(mlir::AffineMap&, llvm::SmallVector >, 2u>&, mlir::presburger::BoundType, mlir::ValueBoundsConstraintSet::Variable const&, std::function, mlir::ValueBoundsConstraintSet&)>, bool) (/home/fuzzing/llvm-project/build/bin/mlir-opt+0x6a12273)
#14 0x05f73977 mlir::affine::reifyValueBound(mlir::OpBuilder&, mlir::Location, mlir::presburger::BoundType, mlir::ValueBoundsConstraintSet::Variable const&, std::function, mlir::ValueBoundsConstraintSet&)>, bool) (/home/fuzzing/llvm-project/build/bin/mlir-opt+0x5f73977)
#15 0x04415e3f mlir::WalkResult llvm::function_ref::callback_fn::value)) && (std::is_same::value), mlir::WalkResult>::type mlir::detail::walk<(mlir::WalkOrder)1, mlir::ForwardIterator, testReifyValueBounds(mlir::FunctionOpInterface, bool, bool)::$_1, test::ReifyBoundOp, mlir::WalkResult>(mlir::Operation*, testReifyValueBounds(mlir::FunctionOpInterface, bool, bool)::$_1&&)::'lambda'(mlir::Operation*)>(long, mlir::Operation*) TestReifyValueBounds.cpp:0:0
#16 0x012714f7 mlir::WalkResult mlir::detail::walk(mlir::Operation*, llvm::function_ref, mlir::WalkOrder) (/home/fuzzing/llvm-project/build/bin/mlir-opt+0x12714f7)
#17 0x04415641 (anonymous namespace)::TestReifyValueBounds::runOnOperation() TestReifyValueBounds.cpp:0:0
#18 0x042452f7 mlir::detail::OpToOpPassAdaptor::run(mlir::Pass*, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int) (/home/fuzzing/llvm-project/build/bin/mli
[llvm-bugs] [Bug 128801] [MLIR] Assertion `mesh.getRank() == 1 && "Only 1D meshes are currently supported."' failed.
Issue
128801
Summary
[MLIR] Assertion `mesh.getRank() == 1 && "Only 1D meshes are currently supported."' failed.
Labels
mlir
Assignees
Reporter
RiRi114
Test on commit: release 19.1.4
steps to reproduce:
`mlir-opttest.mlir -test-mesh-resharding-spmdization`
test case:
```mlir
func.func @sharding_example(
%arg0: tensor<4x3xf32>
) -> tensor<4x3xf32> {
%0 = mesh.shard %arg0 to <@mesh_2d, [[]]> : tensor<4x3xf32>
%1 = mesh.shard %0 to <@mesh_2d, [[0]]> annotate_for_users : tensor<4x3xf32>
%2 = tosa.add %1, %1 : (tensor<4x3xf32>, tensor<4x3xf32>) -> tensor<4x3xf32>
%3 = mesh.shard %2 to <@mesh_2d, [[0]]> : tensor<4x3xf32>
%4 = mesh.shard %3 to <@mesh_2d, [[]]> annotate_for_users : tensor<4x3xf32>
return %4 : tensor<4x3xf32>
}
mesh.mesh @mesh_2d(shape = 4x3)
```
crash trace:
```
mlir-opt: /home/fuzzing/llvm-project-llvmorg-19.1.4/mlir/lib/Dialect/Mesh/Transforms/Spmdization.cpp:447: TypedValue mlir::mesh::reshardOn1DMesh(mlir::ImplicitLocOpBuilder &, mlir::mesh::MeshOp, mlir::mesh::MeshShardingAttr, mlir::mesh::MeshShardingAttr, TypedValue, TypedValue): Assertion `mesh.getRank() == 1 && "Only 1D meshes are currently supported."' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0. Program arguments: /home/fuzzing/llvm-project-llvmorg-19.1.4/build/bin/mlir-opt test.mlir -test-mesh-resharding-spmdization
#0 0x013906e7 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /home/fuzzing/llvm-project-llvmorg-19.1.4/llvm/lib/Support/Unix/Signals.inc:723:13
#1 0x0138c27a llvm::sys::RunSignalHandlers() /home/fuzzing/llvm-project-llvmorg-19.1.4/llvm/lib/Support/Signals.cpp:0:5
#2 0x01391c24 SignalHandler(int) /home/fuzzing/llvm-project-llvmorg-19.1.4/llvm/lib/Support/Unix/Signals.inc:413:1
#3 0x78919a72f520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#4 0x78919a7839fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
#5 0x78919a72f476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
#6 0x78919a7157f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
#7 0x78919a71571b (/lib/x86_64-linux-gnu/libc.so.6+0x2871b)
#8 0x78919a726e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96)
#9 0x049c4903 mlir::mesh::handlePartialAxesDuringResharding(mlir::OpBuilder&, mlir::mesh::MeshShardingAttr, mlir::mesh::MeshShardingAttr, mlir::detail::TypedValue) /home/fuzzing/llvm-project-llvmorg-19.1.4/mlir/lib/Dialect/Mesh/Transforms/Spmdization.cpp:75:3
#10 0x049c4903 mlir::mesh::reshardOn1DMesh(mlir::ImplicitLocOpBuilder&, mlir::mesh::MeshOp, mlir::mesh::MeshShardingAttr, mlir::mesh::MeshShardingAttr, mlir::detail::TypedValue, mlir::detail::TypedValue) /home/fuzzing/llvm-project-llvmorg-19.1.4/mlir/lib/Dialect/Mesh/Transforms/Spmdization.cpp:450:7
#11 0x049c4c82 mlir::mesh::reshard(mlir::OpBuilder&, mlir::mesh::MeshOp, mlir::mesh::ShardOp, mlir::mesh::ShardOp, mlir::detail::TypedValue) /home/fuzzing/llvm-project-llvmorg-19.1.4/mlir/lib/Dialect/Mesh/Transforms/Spmdization.cpp:500:1
#12 0x0795203e (anonymous namespace)::TestMeshReshardingRewritePattern::matchAndRewrite(mlir::mesh::ShardOp, mlir::PatternRewriter&) const /home/fuzzing/llvm-project-llvmorg-19.1.4/mlir/test/lib/Dialect/Mesh/TestReshardingSpmdization.cpp:75:11
#13 0x0d79e74a mlir::PatternApplicator::matchAndRewrite(mlir::Operation*, mlir::PatternRewriter&, llvm::function_ref, llvm::function_ref, llvm::function_ref)::$_2::operator()() const /home/fuzzing/llvm-project-llvmorg-19.1.4/mlir/lib/Rewrite/PatternApplicator.cpp:212:13
#14 0x0d79e74a void llvm::function_ref::callback_fn, llvm::function_ref, llvm::function_ref)::$_2>(long) /home/fuzzing/llvm-project-llvmorg-19.1.4/llvm/include/llvm/ADT/STLFunctionalExtras.h:45:12
#15 0x0d797912 mlir::PatternApplicator::matchAndRewrite(mlir::Operation*, mlir::PatternRewriter&, llvm::function_ref, llvm::function_ref, llvm::function_ref) /home/fuzzing/llvm-project-llvmorg-19.1.4/mlir/lib/Rewrite/PatternApplicator.cpp:233:9
#16 0x08919a48 (anonymous namespace)::GreedyPatternRewriteDriver::processWorklist() /home/fuzzing/llvm-project-llvmorg-19.1.4/mlir/lib/Transforms/Utils/GreedyPatternRewriteDriver.cpp:0:17
#17 0x08914773 (anonymous namespace)::RegionPatternRewriteDriver::simplify(bool*) &&::$_8::operator()() const /home/fuzzing/llvm-project-llvmorg-19.1.4/mlir/lib/Transforms/Utils/GreedyPatternRewriteDriver.cpp:874:11
#18 0x08914773 void llvm::function_ref::callback_fn<(anonymous namespace)::RegionPatternRewriteDriver::simplify(bool*) &&::$_8>(long) /home/fuzzing/llvm-project-llvmorg-19.1.4/llvm/include/llvm/ADT/STLFunctionalExtras.h:45:12
#19 0x08914773 llvm::function_ref::operator()() const /ho
[llvm-bugs] [Bug 128802] [MLIR] Assertion `Index < Length && "Invalid index!"' failed.
Issue
128802
Summary
[MLIR] Assertion `Index < Length && "Invalid index!"' failed.
Labels
mlir
Assignees
Reporter
RiRi114
Test on commit: release19.1.4
steps to reproduce:
`
mlir-opttest.mlir -test-mesh-resharding-spmdization
`
test case:
```mlir
module {
mesh.mesh @mesh_1d(shape = 4)
func.func @reshard_example(
%arg0: tensor<4xf32>
) -> tensor<4xf32> {
%0 = mesh.shard %arg0 to <@mesh_1d, [[]]> : tensor<4xf32>
%1 = mesh.shard %0 to <@mesh_1d, [[]]> annotate_for_users : tensor<4xf32>
return %1 : tensor<4xf32>
}
func.func @another_example(
%arg0: tensor<4xf32>
) -> tensor<4xf32> {
%0 = mesh.shard %arg0 to <@mesh_1d, [[]]> : tensor<4xf32>
%1 = mesh.shard %0 to <@mesh_1d, [[], [0]]> annotate_for_users : tensor<4xf32>
return %1 : tensor<4xf32>
}
}
```
crash trace:
```
mlir-opt: /home/fuzzing/llvm-project-llvmorg-19.1.4/llvm/include/llvm/ADT/ArrayRef.h:257: const T &llvm::ArrayRef::operator[](size_t) const [T = long]: Assertion `Index < Length && "Invalid index!"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0. Program arguments: /home/fuzzing/llvm-project-llvmorg-19.1.4/build/bin/mlir-opt test.mlir -test-mesh-resharding-spmdization
#0 0x013906e7 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /home/fuzzing/llvm-project-llvmorg-19.1.4/llvm/lib/Support/Unix/Signals.inc:723:13
#1 0x0138c27a llvm::sys::RunSignalHandlers() /home/fuzzing/llvm-project-llvmorg-19.1.4/llvm/lib/Support/Signals.cpp:0:5
#2 0x01391c24 SignalHandler(int) /home/fuzzing/llvm-project-llvmorg-19.1.4/llvm/lib/Support/Unix/Signals.inc:413:1
#3 0x73198aacc520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#4 0x73198ab209fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
#5 0x73198aacc476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
#6 0x73198aab27f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
#7 0x73198aab271b (/lib/x86_64-linux-gnu/libc.so.6+0x2871b)
#8 0x73198aac3e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96)
#9 0x048d80c9 llvm::SmallVectorTemplateCommon::operator[](unsigned long) /home/fuzzing/llvm-project-llvmorg-19.1.4/llvm/include/llvm/ADT/SmallVector.h:305:5
#10 0x048d80c9 void shardShape, llvm::ArrayRef, llvm::ArrayRef >, llvm::SmallVector >(llvm::ArrayRef const&, llvm::ArrayRef const&, llvm::ArrayRef > const&, llvm::SmallVector&) /home/fuzzing/llvm-project-llvmorg-19.1.4/mlir/lib/Dialect/Mesh/IR/MeshOps.cpp:157:5
#11 0x048d80c9 mlir::mesh::shardShapedType(mlir::ShapedType, mlir::mesh::MeshOp, mlir::mesh::MeshShardingAttr) /home/fuzzing/llvm-project-llvmorg-19.1.4/mlir/lib/Dialect/Mesh/IR/MeshOps.cpp:167:3
#12 0x049c01b5 mlir::mesh::reshardOn1DMesh(mlir::ImplicitLocOpBuilder&, mlir::mesh::MeshOp, mlir::mesh::MeshShardingAttr, mlir::mesh::MeshShardingAttr, mlir::detail::TypedValue, mlir::detail::TypedValue) /home/fuzzing/llvm-project-llvmorg-19.1.4/mlir/lib/Dialect/Mesh/Transforms/Spmdization.cpp:0:7
#13 0x049c4c82 mlir::mesh::reshard(mlir::OpBuilder&, mlir::mesh::MeshOp, mlir::mesh::ShardOp, mlir::mesh::ShardOp, mlir::detail::TypedValue) /home/fuzzing/llvm-project-llvmorg-19.1.4/mlir/lib/Dialect/Mesh/Transforms/Spmdization.cpp:500:1
#14 0x0795203e (anonymous namespace)::TestMeshReshardingRewritePattern::matchAndRewrite(mlir::mesh::ShardOp, mlir::PatternRewriter&) const /home/fuzzing/llvm-project-llvmorg-19.1.4/mlir/test/lib/Dialect/Mesh/TestReshardingSpmdization.cpp:75:11
#15 0x0d79e74a mlir::PatternApplicator::matchAndRewrite(mlir::Operation*, mlir::PatternRewriter&, llvm::function_ref, llvm::function_ref, llvm::function_ref)::$_2::operator()() const /home/fuzzing/llvm-project-llvmorg-19.1.4/mlir/lib/Rewrite/PatternApplicator.cpp:212:13
#16 0x0d79e74a void llvm::function_ref::callback_fn, llvm::function_ref, llvm::function_ref)::$_2>(long) /home/fuzzing/llvm-project-llvmorg-19.1.4/llvm/include/llvm/ADT/STLFunctionalExtras.h:45:12
#17 0x0d797912 mlir::PatternApplicator::matchAndRewrite(mlir::Operation*, mlir::PatternRewriter&, llvm::function_ref, llvm::function_ref, llvm::function_ref) /home/fuzzing/llvm-project-llvmorg-19.1.4/mlir/lib/Rewrite/PatternApplicator.cpp:233:9
#18 0x08919a48 (anonymous namespace)::GreedyPatternRewriteDriver::processWorklist() /home/fuzzing/llvm-project-llvmorg-19.1.4/mlir/lib/Transforms/Utils/GreedyPatternRewriteDriver.cpp:0:17
#19 0x08914773 (anonymous namespace)::RegionPatternRewriteDriver::simplify(bool*) &&::$_8::operator()() const /home/fuzzing/llvm-project-llvmorg-19.1.4/mlir/lib/Transforms/Utils/GreedyPatternRewriteDriver.cpp:874:11
#20 0x08914773 void llvm::function_ref::callback_fn<(anonymo
[llvm-bugs] [Bug 128803] [MLIR] Assertion `dimSize % shardCount == 0' failed.
Issue
128803
Summary
[MLIR] Assertion `dimSize % shardCount == 0' failed.
Labels
mlir
Assignees
Reporter
RiRi114
Test on commit: release 19.1.4
steps to reproduce:
`mlir-opt -test-mesh-resharding-spmdization temp.mlir`
test case:
```mlir
module {
mesh.mesh @mesh_1d(shape = 4)
func.func @sharded_tensor_operations(
%arg0: tensor<4xi32>
) -> tensor<4xi32> {
%0 = mesh.shard %arg0 to <@mesh_1d, [[]]> : tensor<4xi32>
%1 = mesh.shard %0 to <@mesh_1d, [[0]]> annotate_for_users: tensor<4xi32>
%2 = tosa.add %1, %1 : (tensor<4xi32>, tensor<4xi32>) -> tensor<4xi32>
%3 = mesh.shard %2 to <@mesh_1d, [[1]]> : tensor<4xi32>
%4 = mesh.shard %3 to <@mesh_1d, [[]]> annotate_for_users: tensor<4xi32>
return %4 : tensor<4xi32>
}
}
```
crash trace:
```
mlir-opt: /home/fuzzing/llvm-project-llvmorg-19.1.4/mlir/include/mlir/Dialect/Mesh/IR/MeshOps.h:116: int64_t mlir::mesh::shardDimension(int64_t, int64_t): Assertion `dimSize % shardCount == 0' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0. Program arguments: /home/fuzzing/llvm-project-llvmorg-19.1.4/build/bin/mlir-opt -split-input-file -allow-unregistered-dialect -test-mesh-resharding-spmdization /home/fuzzing/llvm-project-llvmorg-19.1.4/xmr_fuzzing/test_generate/needed_file/temp.mlir
#0 0x013906e7 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /home/fuzzing/llvm-project-llvmorg-19.1.4/llvm/lib/Support/Unix/Signals.inc:723:13
#1 0x0138c27a llvm::sys::RunSignalHandlers() /home/fuzzing/llvm-project-llvmorg-19.1.4/llvm/lib/Support/Signals.cpp:0:5
#2 0x01391c24 SignalHandler(int) /home/fuzzing/llvm-project-llvmorg-19.1.4/llvm/lib/Support/Unix/Signals.inc:413:1
#3 0x72fd2fc96520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#4 0x72fd2fcea9fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
#5 0x72fd2fc96476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
#6 0x72fd2fc7c7f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
#7 0x72fd2fc7c71b (/lib/x86_64-linux-gnu/libc.so.6+0x2871b)
#8 0x72fd2fc8de96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96)
#9 0x048d8117 (/home/fuzzing/llvm-project-llvmorg-19.1.4/build/bin/mlir-opt+0x48d8117)
#10 0x07951f49 (anonymous namespace)::TestMeshReshardingRewritePattern::matchAndRewrite(mlir::mesh::ShardOp, mlir::PatternRewriter&) const /home/fuzzing/llvm-project-llvmorg-19.1.4/mlir/test/lib/Dialect/Mesh/TestReshardingSpmdization.cpp:0:11
#11 0x0d79e74a mlir::PatternApplicator::matchAndRewrite(mlir::Operation*, mlir::PatternRewriter&, llvm::function_ref, llvm::function_ref, llvm::function_ref)::$_2::operator()() const /home/fuzzing/llvm-project-llvmorg-19.1.4/mlir/lib/Rewrite/PatternApplicator.cpp:212:13
#12 0x0d79e74a void llvm::function_ref::callback_fn, llvm::function_ref, llvm::function_ref)::$_2>(long) /home/fuzzing/llvm-project-llvmorg-19.1.4/llvm/include/llvm/ADT/STLFunctionalExtras.h:45:12
#13 0x0d797912 mlir::PatternApplicator::matchAndRewrite(mlir::Operation*, mlir::PatternRewriter&, llvm::function_ref, llvm::function_ref, llvm::function_ref) /home/fuzzing/llvm-project-llvmorg-19.1.4/mlir/lib/Rewrite/PatternApplicator.cpp:233:9
#14 0x08919a48 (anonymous namespace)::GreedyPatternRewriteDriver::processWorklist() /home/fuzzing/llvm-project-llvmorg-19.1.4/mlir/lib/Transforms/Utils/GreedyPatternRewriteDriver.cpp:0:17
#15 0x08914773 (anonymous namespace)::RegionPatternRewriteDriver::simplify(bool*) &&::$_8::operator()() const /home/fuzzing/llvm-project-llvmorg-19.1.4/mlir/lib/Transforms/Utils/GreedyPatternRewriteDriver.cpp:874:11
#16 0x08914773 void llvm::function_ref::callback_fn<(anonymous namespace)::RegionPatternRewriteDriver::simplify(bool*) &&::$_8>(long) /home/fuzzing/llvm-project-llvmorg-19.1.4/llvm/include/llvm/ADT/STLFunctionalExtras.h:45:12
#17 0x08914773 llvm::function_ref::operator()() const /home/fuzzing/llvm-project-llvmorg-19.1.4/llvm/include/llvm/ADT/STLFunctionalExtras.h:68:12
#18 0x08914773 void mlir::MLIRContext::executeAction<(anonymous namespace)::GreedyPatternRewriteIteration, long&>(llvm::function_ref, llvm::ArrayRef, long&) /home/fuzzing/llvm-project-llvmorg-19.1.4/mlir/include/mlir/IR/MLIRContext.h:275:7
#19 0x08914773 (anonymous namespace)::RegionPatternRewriteDriver::simplify(bool*) && /home/fuzzing/llvm-project-llvmorg-19.1.4/mlir/lib/Transforms/Utils/GreedyPatternRewriteDriver.cpp:872:10
#20 0x08914773 mlir::applyPatternsAndFoldGreedily(mlir::Region&, mlir::FrozenRewritePatternSet const&, mlir::GreedyRewriteConfig, bool*) /home/fuzzing/llvm-project-llvmorg-19.1.4/mlir/lib/Transforms/Utils/GreedyPa
[llvm-bugs] [Bug 128806] [MLIR] Assertion `isa(Val) && "cast() argument of incompatible type!"' failed.
Issue
128806
Summary
[MLIR] Assertion `isa(Val) && "cast() argument of incompatible type!"' failed.
Labels
mlir
Assignees
Reporter
RiRi114
Test on commit : release19.1.4
steps to reproduce:
`
mlir-opttest.mlir --pass-pipeline="builtin.module(func.func(mesh-spmdization,test-constant-fold))"
`
test case:
```mlir
module {
func.func @spmdization_example(
%arg0: tensor<4x4xf32>
) -> tensor<4x4xf32> {
%0 = mesh.shard %arg0 to <@mesh_1d, [[]]> : tensor<4x4xf32>
%1 = mesh.shard %0 to <@mesh_1d, [[0]]> annotate_for_users : tensor<4x4xf32>
%2 = tosa.add %1, %1 : (tensor<4x4xf32>, tensor<4x4xf32>) -> tensor<4x4xf32>
%3 = mesh.shard %2 to <@mesh_1d, [[]]> : tensor<4x4xf32>
%4 = tosa.mul %3, %3 {shift = 0 : i8} : (tensor<4x4xf32>, tensor<4x4xf32>) -> tensor<4x4xf32>
return %4 : tensor<4x4xf32>
}
mesh.mesh @mesh_1d(shape = 4)
}
```
crash trace:
```
mlir-opt: /home/fuzzing/llvm-project-llvmorg-19.1.4/llvm/include/llvm/Support/Casting.h:578: decltype(auto) llvm::cast(From *) [To = mlir::mesh::ShardOp, From = mlir::Operation]: Assertion `isa(Val) && "cast() argument of incompatible type!"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0. Program arguments: /home/fuzzing/llvm-project-llvmorg-19.1.4/build/bin/mlir-opt test.mlir --pass-pipeline=builtin.module(func.func(mesh-spmdization,test-constant-fold))
#0 0x013906e7 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /home/fuzzing/llvm-project-llvmorg-19.1.4/llvm/lib/Support/Unix/Signals.inc:723:13
#1 0x0138c27a llvm::sys::RunSignalHandlers() /home/fuzzing/llvm-project-llvmorg-19.1.4/llvm/lib/Support/Signals.cpp:0:5
#2 0x01391c24 SignalHandler(int) /home/fuzzing/llvm-project-llvmorg-19.1.4/llvm/lib/Support/Unix/Signals.inc:413:1
#3 0x71e282a00520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#4 0x71e282a549fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
#5 0x71e282a00476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
#6 0x71e2829e67f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
#7 0x71e2829e671b (/lib/x86_64-linux-gnu/libc.so.6+0x2871b)
#8 0x71e2829f7e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96)
#9 0x049cd18c mlir::mesh::spmdizeOperation(mlir::Operation&, mlir::IRMapping&, mlir::SymbolTableCollection&, mlir::OpBuilder&) /home/fuzzing/llvm-project-llvmorg-19.1.4/mlir/lib/Dialect/Mesh/Transforms/Spmdization.cpp:0:0
#10 0x049cd18c mlir::mesh::spmdizeBlock(mlir::Block&, mlir::IRMapping&, mlir::SymbolTableCollection&, mlir::OpBuilder&) /home/fuzzing/llvm-project-llvmorg-19.1.4/mlir/lib/Dialect/Mesh/Transforms/Spmdization.cpp:677:16
#11 0x049c9b33 mlir::mesh::spmdizeFuncOp(mlir::FunctionOpInterface, mlir::IRMapping&, mlir::SymbolTableCollection&) /home/fuzzing/llvm-project-llvmorg-19.1.4/mlir/lib/Dialect/Mesh/Transforms/Spmdization.cpp:0:16
#12 0x049c9b33 mlir::mesh::(anonymous namespace)::Spmdization::runOnOperation() /home/fuzzing/llvm-project-llvmorg-19.1.4/mlir/lib/Dialect/Mesh/Transforms/Spmdization.cpp:735:16
#13 0x08792bb3 mlir::detail::OpToOpPassAdaptor::run(mlir::Pass*, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int)::$_7::operator()() const /home/fuzzing/llvm-project-llvmorg-19.1.4/mlir/lib/Pass/Pass.cpp:0:17
#14 0x08792bb3 void llvm::function_ref::callback_fn(long) /home/fuzzing/llvm-project-llvmorg-19.1.4/llvm/include/llvm/ADT/STLFunctionalExtras.h:45:12
#15 0x08792bb3 llvm::function_ref::operator()() const /home/fuzzing/llvm-project-llvmorg-19.1.4/llvm/include/llvm/ADT/STLFunctionalExtras.h:68:12
#16 0x08792bb3 void mlir::MLIRContext::executeAction(llvm::function_ref, llvm::ArrayRef, mlir::Pass&) /home/fuzzing/llvm-project-llvmorg-19.1.4/mlir/include/mlir/IR/MLIRContext.h:275:7
#17 0x08792bb3 mlir::detail::OpToOpPassAdaptor::run(mlir::Pass*, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int) /home/fuzzing/llvm-project-llvmorg-19.1.4/mlir/lib/Pass/Pass.cpp:521:21
#18 0x08793940 mlir::detail::OpToOpPassAdaptor::runPipeline(mlir::OpPassManager&, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int, mlir::PassInstrumentor*, mlir::PassInstrumentation::PipelineParentInfo const*) /home/fuzzing/llvm-project-llvmorg-19.1.4/mlir/lib/Pass/Pass.cpp:0:16
#19 0x087a1e67 mlir::detail::OpToOpPassAdaptor::runOnOperationAsyncImpl(bool)::$_15::operator()(mlir::detail::OpToOpPassAdaptor::runOnOperationAsyncImpl(bool)::OpPMInfo&) const /home/fuzzing/llvm-project-llvmorg-19.1.4/mlir/lib/Pass/Pass.cpp:818:5
#20 0x087963e3 llvm::LogicalResult mlir::failableParallelForEach<__gnu_cxx::__normal_iterator > >, mlir::detail::OpToOpPassAdaptor::runOnOperationAs
[llvm-bugs] [Bug 128781] [libc] clean up use of __builtin_popcountl in sched_getcpucount
Issue 128781 Summary [libc] clean up use of __builtin_popcountl in sched_getcpucount Labels good first issue, libc Assignees Reporter michaelrj-google In [`libc/src/sched/linux/sched_getcpucount.cpp`](https://github.com/llvm/llvm-project/blob/main/libc/src/sched/linux/sched_getcpucount.cpp) we currently use `__builtin_popcountl`. Ideally we'd instead use `cpp::popcount` defined in [`libc/src/__support/CPP/bit.h`](https://github.com/llvm/llvm-project/blob/main/libc/src/__support/CPP/bit.h#L268). ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128795] [clang] conversion function lookup is unnecessarily slow with many conversion functions and no conversion function templates
Issue
128795
Summary
[clang] conversion function lookup is unnecessarily slow with many conversion functions and no conversion function templates
Labels
clang
Assignees
Reporter
zygoloid
Here's a technique for doing K member lookups in a type list of N elements in O(N+K) time (note that most techniques require O(NK) time):
```c++
template
struct TypeList;
struct MembershipTesterBaseA {
template operator T();
};
struct MembershipTesterBaseB {
template operator T();
};
template
struct MembershipTester : MembershipTesterBaseA, MembershipTesterBaseB {
using MembershipTesterBaseA::operator T...;
};
template
using Contains = std::bool_constant;
template struct TypeList {
using MT = MembershipTester;
};
```
The idea is that `MembershipTester::operator U` is ambiguous if `U` is not in `T...` and is valid otherwise.
With Clang, this ends up still being O(NK), because [name lookup for a conversion function does an unnecessary linear scan through all conversion functions declared in the class](https://github.com/llvm/llvm-project/blob/c8b40867d144395ad3c306a3cf87f970e0f97f07/clang/lib/Sema/SemaLookup.cpp#L1162).
Suggestion: When building the class's list of conversions, reorder the conversions to put all the template conversions before all the non-template conversions. Then terminate this loop in name lookup when we reach a non-template conversion.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128831] -Wshadow false negative for function parameter shadowing (partially; incorrectly) a global variable (incorrectly used as array length expression)
Issue 128831 Summary -Wshadow false negative for function parameter shadowing (partially; incorrectly) a global variable (incorrectly used as array length _expression_) Labels false-negative Assignees Reporter alejandro-colomar ```c alx@debian:~/tmp$ cat f.c extern int n; void f(int a[n], int n); alx@debian:~/tmp$ gcc -Wall -Wextra -Wshadow -S f.c alx@debian:~/tmp$ clang -Weverything -Wno-vla -S f.c alx@debian:~/tmp$ ``` That program obviously has a bug. The number of elements of 'a' is intended to be $2, but it is actually controlled by the global variable 'n'. I think -Wshadow should diagnose this. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128840] clangd false positive redefinition error of type traits template when #include after import with type_traits include
Issue
128840
Summary
clangd false positive redefinition error of type traits template when #include after import with type_traits include
Labels
false-positive
Assignees
Reporter
FalcoGer
So when I define such a module
```cpp
// Math.cppm
module;
#include
#include
#include
export module Math;
export template
requires std::is_arithmetic_v
auto add(const T& lhs, const T& rhs)
{
return lhs + rhs;
}
```
and try to use it
```cpp
#include
import Math;
auto main() -> int
{
std::println("{}", add(2.0F, 1.0F));
}
```
it works fine.
When I switch `#include ` and `import Math;`, it still compiles fine and gives the same results. But clangd explodes in my face telling me that it's not fine with
```text
Too many errors emitted, stopping now (clang fatal_too_many_errors)
In included file: type alias template redefinition with different types ('__is_one_of<[6 * ...], (no argument)>' vs '__is_one_of<[6 * ...], __int128>')
Related information:
* type_traits#808,11: Error occurred here
* type_traits#808,11: Previous definition is here
(clang redefinition_different_typedef)
```
Compiled against libstdc++ from gcc 15.0.1.
```text
$ clang --version
Ubuntu clang version 21.0.0 (++20250224081945+0770afb88ec1-1~exp1~20250224082103.749)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/lib/llvm-21/bin
```
`.clangd`:
```yaml
CompileFlags:
Add:
- -fprebuilt-module-path=build/CMakeFiles/MathModule.dir
```
Built with cmake
`CMakeLists.txt`:
```cmake
cmake_minimum_required(VERSION 3.28)
project(TemplateModulesTest)
# REF: selecting-a-specific-libstdc-version-with-clang
# https://stackoverflow.com/a/50964601/10263660
set(GCC_TOOLCHAIN_PATH "/usr/local/gcc/15.0.1")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} --gcc-toolchain=${GCC_TOOLCHAIN_PATH}")
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} --gcc-toolchain=${GCC_TOOLCHAIN_PATH}")
set(CMAKE_CXX_STANDARD 23)
set(CMAKE_CXX_STANDARD_REQUIRED YES)
add_library(MathModule)
target_sources(MathModule
PUBLIC
FILE_SET cxx_modules TYPE CXX_MODULES FILES
Math.cppm
)
set_target_properties(MathModule PROPERTIES CXX_SCAN_FOR_MODULES YES)
add_executable(main main.cpp)
target_link_libraries(main PRIVATE MathModule)
```
Building first is required for clangd to find the module and not freak out about it not existing.
```bash
mkdir build
cmake -DCMAKE_C_COMPILER=/usr/bin/clang -DCMAKE_CXX_COMPILER=/usr/bin/clang++ -G Ninja ..
ninja
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128838] Assertion `!NodePtr->isKnownSentinel()' failed.
Issue
128838
Summary
Assertion `!NodePtr->isKnownSentinel()' failed.
Labels
new issue
Assignees
Reporter
TatyanaDoubts
To reproduce run opt with the test below, -passes=loop-vectorize
```
; ModuleID = './reduced.ll'
source_filename = "./reduced.ll"
target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128-ni:1-p2:32:8:8:32-ni:2"
target triple = "x86_64-unknown-linux-gnu"
define void @wombat() gc "statepoint-example" personality ptr null {
bb:
%invoke = invoke i32 null(ptr addrspace(1) null, i32 0, i32 0, i32 0)
to label %bb1 unwind label %bb5
bb1: ; preds = %bb1, %bb
%phi = phi i64 [ %add, %bb1 ], [ 0, %bb ]
%phi2 = phi i32 [ %add3, %bb1 ], [ 0, %bb ]
%add = add i64 %phi, 1
%sitofp = sitofp i32 %phi2 to double
store double %sitofp, ptr addrspace(1) null, align 8
%add3 = add i32 %phi2, %invoke
%icmp = icmp ult i64 %phi, 161
br i1 %icmp, label %bb1, label %bb4
bb4: ; preds = %bb1
ret void
bb5: ; preds = %bb
%landingpad = landingpad { ptr, i32 }
cleanup
ret void
}
```
Reproducer: https://godbolt.org/z/3do96adnn
Stack dump:
```
opt: /root/llvm-project/llvm/include/llvm/ADT/ilist_iterator.h:322: llvm::ilist_iterator_w_bits::reference llvm::ilist_iterator_w_bits::operator*() const [with OptionsT = llvm::ilist_detail::node_options; bool IsReverse = false; bool IsConst = false; llvm::ilist_iterator_w_bits::reference = llvm::Instruction&]: Assertion `!NodePtr->isKnownSentinel()' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0. Program arguments: /opt/compiler-explorer/clang-assertions-trunk/bin/opt -o /app/output.s -S -passes=loop-vectorize
1. Running pass "function(loop-vectorize)" on module ""
2. Running pass "loop-vectorize" on function "wombat"
#0 0x05452b98 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x5452b98)
#1 0x05450554 SignalHandler(int, siginfo_t*, void*) Signals.cpp:0:0
#2 0x7b16e6242520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#3 0x7b16e62969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
#4 0x7b16e6242476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
#5 0x7b16e62287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
#6 0x7b16e622871b (/lib/x86_64-linux-gnu/libc.so.6+0x2871b)
#7 0x7b16e6239e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96)
#8 0x044f6c23 (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x44f6c23)
#9 0x0450ebb3 llvm::VPTransformState::get(llvm::VPValue*, bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x450ebb3)
#10 0x04543138 llvm::VPInstruction::generate(llvm::VPTransformState&) (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x4543138)
#11 0x04544ba4 llvm::VPInstruction::execute(llvm::VPTransformState&) (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x4544ba4)
#12 0x044f82e7 llvm::VPBasicBlock::executeRecipes(llvm::VPTransformState*, llvm::BasicBlock*) (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x44f82e7)
#13 0x045038f9 llvm::VPIRBasicBlock::execute(llvm::VPTransformState*) (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x45038f9)
#14 0x04510249 llvm::VPlan::execute(llvm::VPTransformState*) (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x4510249)
#15 0x043e llvm::LoopVectorizationPlanner::executePlan(llvm::ElementCount, unsigned int, llvm::VPlan&, llvm::InnerLoopVectorizer&, llvm::DominatorTree*, bool, llvm::DenseMap, llvm::detail::DenseMapPair> const*) (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x43e)
#16 0x043e15d8 llvm::LoopVectorizePass::processLoop(llvm::Loop*) (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x43e15d8)
#17 0x043e2f49 llvm::LoopVectorizePass::runImpl(llvm::Function&) (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x43e2f49)
#18 0x043e35c3 llvm::LoopVectorizePass::run(llvm::Function&, llvm::AnalysisManager&) (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x43e35c3)
#19 0x0318aaae llvm::detail::PassModel>::run(llvm::Function&, llvm::AnalysisManager&) (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x318aaae)
#20 0x0524cd90 llvm::PassManager>::run(llvm::Function&, llvm::AnalysisManager&) (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x524cd90)
#21 0x00e6f54e llvm::detail::PassModel>, llvm::AnalysisManager>::run(llvm::Function&, llvm::AnalysisManager&) (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0xe6f54e)
#22 0x0524b6ab llvm::ModuleToFunctionPassAdaptor::run(llvm::Module&, llvm
[llvm-bugs] [Bug 128837] [MLIR] --gpu-kernel-outlining triggers Assertion `isa(Val) && "cast() argument of incompatible type!"' failed.
Issue
128837
Summary
[MLIR] --gpu-kernel-outlining triggers Assertion `isa(Val) && "cast() argument of incompatible type!"' failed.
Labels
mlir
Assignees
Reporter
RiRi114
Test on commit : 0f9720a6
steps to reproduce:
`
mlir-opt temp.mlir --gpu-kernel-outlining
`
test case:
```mlir
module {
func.func @kernel_function() {
// Placeholder for kernel functionality, operates on input data
%data = "" : memref<4x8xf32>
%result = memref.alloc() : memref<4xf32>
%c1 = arith.constant 1 : index
gpu.launch blocks(%bx, %by, %bz) in (%grid_x = %c1, %grid_y = %c1, %grid_z = %c1)
threads(%tx, %ty, %tz) in (%block_x = %c1, %block_y = %c1, %block_z = %c1) {
%val = memref.load %data[%bx, %tx] : memref<4x8xf32>
%sum_result = gpu.all_reduce add %val uniform {} : (f32) -> (f32)
memref.store %sum_result, %result[%bx] : memref<4xf32>
gpu.terminator
}
return
}
func.func @main() {
%data_init = memref.alloc() : memref<4x8xf32>
%result_init = memref.alloc() : memref<4xf32>
// Kernel launch with specific grid and block sizes
%c2 = arith.constant 2 : index
gpu.launch blocks(%bx, %by, %bz) in (%grid_x = %c2, %grid_y = %c2, %grid_z = %c2)
threads(%tx, %ty, %tz) in (%block_x = %c2, %block_y = %c2, %block_z = %c2) {
// Kernel computation
func.call @kernel_function() : () -> ()
gpu.terminator
}
return
}
}
```
crash trace:
```
mlir-opt: /home/fuzzing/llvm-project/llvm/include/llvm/Support/Casting.h:566: decltype(auto) llvm::cast(const From &) [To = mlir::FlatSymbolRefAttr, From = mlir::SymbolRefAttr]: Assertion `isa(Val) && "cast() argument of incompatible type!"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0. Program arguments: /home/fuzzing/llvm-project/build/bin/mlir-opt temp.mlir --gpu-kernel-outlining
#0 0x0113ce77 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/home/fuzzing/llvm-project/build/bin/mlir-opt+0x113ce77)
#1 0x0113aa0e llvm::sys::RunSignalHandlers() (/home/fuzzing/llvm-project/build/bin/mlir-opt+0x113aa0e)
#2 0x0113d855 SignalHandler(int, siginfo_t*, void*) Signals.cpp:0:0
#3 0x718280502520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#4 0x7182805569fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
#5 0x718280502476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
#6 0x7182804e87f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
#7 0x7182804e871b (/lib/x86_64-linux-gnu/libc.so.6+0x2871b)
#8 0x7182804f9e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96)
#9 0x0193c5be mlir::WalkResult llvm::function_ref::callback_fn::value)) && (std::is_same::value), mlir::WalkResult>::type mlir::detail::walk<(mlir::WalkOrder)1, mlir::ForwardIterator, (anonymous namespace)::GpuKernelOutliningPass::runOnOperation()::'lambda'(mlir::gpu::LaunchOp), mlir::gpu::LaunchOp, mlir::WalkResult>(mlir::Operation*, (anonymous namespace)::GpuKernelOutliningPass::runOnOperation()::'lambda'(mlir::gpu::LaunchOp)&&)::'lambda'(mlir::Operation*)>(long, mlir::Operation*) KernelOutlining.cpp:0:0
#10 0x012714f7 mlir::WalkResult mlir::detail::walk(mlir::Operation*, llvm::function_ref, mlir::WalkOrder) (/home/fuzzing/llvm-project/build/bin/mlir-opt+0x12714f7)
#11 0x0193ae42 (anonymous namespace)::GpuKernelOutliningPass::runOnOperation() KernelOutlining.cpp:0:0
#12 0x042452f7 mlir::detail::OpToOpPassAdaptor::run(mlir::Pass*, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int) (/home/fuzzing/llvm-project/build/bin/mlir-opt+0x42452f7)
#13 0x04245b61 mlir::detail::OpToOpPassAdaptor::runPipeline(mlir::OpPassManager&, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int, mlir::PassInstrumentor*, mlir::PassInstrumentation::PipelineParentInfo const*) (/home/fuzzing/llvm-project/build/bin/mlir-opt+0x4245b61)
#14 0x0424825b mlir::PassManager::run(mlir::Operation*) (/home/fuzzing/llvm-project/build/bin/mlir-opt+0x424825b)
#15 0x042408af performActions(llvm::raw_ostream&, std::shared_ptr const&, mlir::MLIRContext*, mlir::MlirOptMainConfig const&) MlirOptMain.cpp:0:0
#16 0x04240503 llvm::LogicalResult llvm::function_ref >, llvm::raw_ostream&)>::callback_fn >, mlir::DialectRegistry&, mlir::MlirOptMainConfig const&)::$_3>(long, std::unique_ptr >, llvm::raw_ostream&) MlirOptMain.cpp:0:0
#17 0x042ec4e8 mlir::splitAndProcessBuffer(std::unique_ptr >, llvm::function_ref >, llvm::raw_ostream&)>, llvm::raw_ostream&, llvm::StringRef, llvm::StringRef) (/home/fuzzing/llvm-project/build/bin/mlir-opt+0x42ec4e8)
#18 0x0423a151 mlir::MlirOptMain(llvm::raw_ostream&, std::unique_ptr >, mlir::DialectRegistry&, mlir::MlirOptMainConfig const&) (/home/f
[llvm-bugs] [Bug 128775] Assertion `VT.getSizeInBits() == Operand.getValueSizeInBits() && "Cannot BITCAST between types of different sizes!"
Issue
128775
Summary
Assertion `VT.getSizeInBits() == Operand.getValueSizeInBits() && "Cannot BITCAST between types of different sizes!"
Labels
bug,
backend:Hexagon
Assignees
iajbar
Reporter
androm3da
The `./reduced_matrix_types.ll` test case below asserts at O2. This case was reduced from https://github.com/llvm/llvm-test-suite/blob/589a966491ac5edc64c6f915d7301351e309db65/SingleSource/UnitTests/matrix-types-spec.cpp
```
target datalayout = "e-m:e-p:32:32:32-a:0-n16:32-i64:64:64-i32:32:32-i16:16:16-i1:8:8-f32:32:32-f64:64:64-v32:32:32-v64:64:64-v512:512:512-v1024:1024:1024-v2048:2048:2048"
target triple = "hexagon-unknown-linux-musl"
define void @_Z13testTransposeIjLj8ELj7EEvv(<56 x i32> %matins.7.6.i, ptr %ResSpec) #0 {
entry:
%split = shufflevector <56 x i32> %matins.7.6.i, <56 x i32> zeroinitializer, <7 x i32>
store <7 x i32> %split, ptr %ResSpec, align 32
ret void
}
attributes #0 = { "target-features"="+hvx-ieee-fp,+hvx-length128b,+hvxv68,+v68,-long-calls" }
```
Test build:
```
./bin/llc -O2 --mtriple=hexagon ./reduced_matrix_types.ll
[44/44] Linking CXX executable bin/llc
llc: /local/mnt/workspace/upstream/toolchain_for_hexagon/llvm-project/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp:5444: SDValue llvm::SelectionDAG::getNode(unsigned int, const SDLoc &, EVT, SDValue, const SDNodeFlags): Assertion `VT.getSizeInBits() == Operand.getValueSizeInBits() && "Cannot BITCAST between types of different sizes!"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0. Program arguments: ./bin/llc -O2 --mtriple=hexagon ./reduced_matrix_types.ll
1. Running pass 'Function Pass Manager' on module './reduced_matrix_types.ll'.
2. Running pass 'Hexagon DAG->DAG Pattern Instruction Selection' on function '@_Z13testTransposeIjLj8ELj7EEvv'
#0 0x557da88ed474 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (./bin/llc+0x24e9474)
#1 0x557da88eb14e llvm::sys::RunSignalHandlers() (./bin/llc+0x24e714e)
#2 0x557da88ed93a SignalHandler(int) Signals.cpp:0:0
#3 0x7f35d0ec1520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#4 0x7f35d0f159fc __pthread_kill_implementation ./nptl/pthread_kill.c:44:76
#5 0x7f35d0f159fc __pthread_kill_internal ./nptl/pthread_kill.c:78:10
#6 0x7f35d0f159fc pthread_kill ./nptl/pthread_kill.c:89:10
#7 0x7f35d0ec1476 gsignal ./signal/../sysdeps/posix/raise.c:27:6
#8 0x7f35d0ea77f3 abort ./stdlib/abort.c:81:7
#9 0x7f35d0ea771b _nl_load_domain ./intl/loadmsgcat.c:1177:9
#10 0x7f35d0eb8e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96)
#11 0x557da8617cc9 llvm::SelectionDAG::getNode(unsigned int, llvm::SDLoc const&, llvm::EVT, llvm::SDValue, llvm::SDNodeFlags) (./bin/llc+0x2213cc9)
#12 0x557da8607907 llvm::SelectionDAG::getBitcast(llvm::EVT, llvm::SDValue) (./bin/llc+0x2203907)
#13 0x557da759a738 llvm::HexagonTargetLowering::extractHvxSubvectorReg(llvm::SDValue, llvm::SDValue, llvm::SDValue, llvm::SDLoc const&, llvm::MVT, llvm::SelectionDAG&) const HexagonISelLoweringHVX.cpp:0:0
#14 0x557da759f48c llvm::HexagonTargetLowering::LowerHvxExtractSubvector(llvm::SDValue, llvm::SelectionDAG&) const HexagonISelLoweringHVX.cpp:0:0
#15 0x557da75a9b50 llvm::HexagonTargetLowering::LowerHvxOperation(llvm::SDValue, llvm::SelectionDAG&) const HexagonISelLoweringHVX.cpp:0:0
#16 0x557da758cd87 llvm::HexagonTargetLowering::LowerOperation(llvm::SDValue, llvm::SelectionDAG&) const HexagonISelLowering.cpp:0:0
#17 0x557da870f9c8 (anonymous namespace)::SelectionDAGLegalize::LegalizeOp(llvm::SDNode*) LegalizeDAG.cpp:0:0
#18 0x557da870eb96 llvm::SelectionDAG::Legalize() (./bin/llc+0x230ab96)
#19 0x557da865588f llvm::SelectionDAGISel::CodeGenAndEmitDAG() (./bin/llc+0x225188f)
#20 0x557da8653abc llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) (./bin/llc+0x224fabc)
#21 0x557da864fefd llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) (./bin/llc+0x224befd)
#22 0x557da768e4e4 llvm::HexagonDAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&) HexagonISelDAGToDAG.cpp:0:0
#23 0x557da7b786e3 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (./bin/llc+0x17746e3)
#24 0x557da806a6d2 llvm::FPPassManager::runOnFunction(llvm::Function&) (./bin/llc+0x1c666d2)
#25 0x557da8072b32 llvm::FPPassManager::runOnModule(llvm::Module&) (./bin/llc+0x1c6eb32)
#26 0x557da806b227 llvm::legacy::PassManagerImpl::run(llvm::Module&) (./bin/llc+0x1c67227)
#27 0x557da7534936 main (./bin/llc+0x1130936)
#28 0x7f35d0ea8d90 __libc_start_call_main ./csu/../sysdeps/nptl/libc_start_call_main.h:58:16
#29 0x7f35d0ea8e40 call_init ./csu/../csu/libc-start.c:128:20
#30 0x7f35d0ea8
[llvm-bugs] [Bug 128797] [clang-tidy] misc-confusable-identifiers checker is very slow
Issue 128797 Summary [clang-tidy] misc-confusable-identifiers checker is very slow Labels clang-tidy Assignees Reporter zygoloid We're seeing the misc-confusable-identifiers checker be easily 10x slower than any other clang-tidy check. I think this check becomes slow in the presence of an identifier declared many times -- such as a large overload set. The current implementation appears to be quadratic in the number of redeclarations of a given identifier. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128796] how to dynamically load a pass plug in llc?
Issue 128796 Summary how to dynamically load a pass plug in llc? Labels new issue Assignees Reporter H4ckF0rFun ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128798] [MLIR] Assertion `rankedTensorArg.hasOneUse()' failed.
Issue
128798
Summary
[MLIR] Assertion `rankedTensorArg.hasOneUse()' failed.
Labels
mlir
Assignees
Reporter
RiRi114
Test on commit: release 19.1.4
steps to reproduce:
`mlir-opt--pass-pipeline="builtin.module(func.func(mesh-spmdization,test-constant-fold))" test.mlir `
test case：
> module {
func.func @sharded_operations_example(%arg0: tensor<4x4xf32>) -> tensor<4x4xf32> {
%0 = mesh.shard %arg0 to <@mesh_2d, [[]]> : tensor<4x4xf32>
%1 = mesh.shard %0 to <@mesh_2d, [[0]]> annotate_for_users: tensor<4x4xf32>
%2 = tosa.add %1, %arg0 : (tensor<4x4xf32>, tensor<4x4xf32>) -> tensor<4x4xf32>
%3 = mesh.shard %2 to <@mesh_2d, [[1]]> : tensor<4x4xf32>
return %3 : tensor<4x4xf32>
}
mesh.mesh @mesh_2d(shape = 4)
}
crash trace:
>
mlir-opt: /home/fuzzing/llvm-project-llvmorg-19.1.4/mlir/lib/Dialect/Mesh/Transforms/Spmdization.cpp:535: auto mlir::mesh::shardedBlockArgumentTypes(mlir::Block &, mlir::SymbolTableCollection &)::(anonymous class)::operator()(mlir::BlockArgument) const: Assertion `rankedTensorArg.hasOneUse()' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0. Program arguments: /home/fuzzing/llvm-project-llvmorg-19.1.4/build/bin/mlir-opt --pass-pipeline=builtin.module(func.func(mesh-spmdization,test-constant-fold)) test.mlir
#0 0x013906e7 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /home/fuzzing/llvm-project-llvmorg-19.1.4/llvm/lib/Support/Unix/Signals.inc:723:13
#1 0x0138c27a llvm::sys::RunSignalHandlers() /home/fuzzing/llvm-project-llvmorg-19.1.4/llvm/lib/Support/Signals.cpp:0:5
#2 0x01391c24 SignalHandler(int) /home/fuzzing/llvm-project-llvmorg-19.1.4/llvm/lib/Support/Unix/Signals.inc:413:1
#3 0x7fab7e466520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#4 0x7fab7e4ba9fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
#5 0x7fab7e466476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
#6 0x7fab7e44c7f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
#7 0x7fab7e44c71b (/lib/x86_64-linux-gnu/libc.so.6+0x2871b)
#8 0x7fab7e45de96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96)
#9 0x049c57ce decltype(auto) llvm::dyn_cast, mlir::BlockArgument>(mlir::BlockArgument&) /home/fuzzing/llvm-project-llvmorg-19.1.4/llvm/include/llvm/Support/Casting.h:656:3
#10 0x049c57ce mlir::mesh::shardedBlockArgumentTypes(mlir::Block&, mlir::SymbolTableCollection&)::$_1::operator()(mlir::BlockArgument) const /home/fuzzing/llvm-project-llvmorg-19.1.4/mlir/lib/Dialect/Mesh/Transforms/Spmdization.cpp:530:32
#11 0x049c57ce std::back_insert_iterator > std::transform >, mlir::mesh::shardedBlockArgumentTypes(mlir::Block&, mlir::SymbolTableCollection&)::$_1>(mlir::BlockArgument*, mlir::BlockArgument*, std::back_insert_iterator >, mlir::mesh::shardedBlockArgumentTypes(mlir::Block&, mlir::SymbolTableCollection&)::$_1) /usr/lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/stl_algo.h:4296:14
#12 0x049c57ce std::back_insert_iterator > llvm::transform, std::back_insert_iterator >, mlir::mesh::shardedBlockArgumentTypes(mlir::Block&, mlir::SymbolTableCollection&)::$_1>(llvm::MutableArrayRef&&, std::back_insert_iterator >, mlir::mesh::shardedBlockArgumentTypes(mlir::Block&, mlir::SymbolTableCollection&)::$_1) /home/fuzzing/llvm-project-llvmorg-19.1.4/llvm/include/llvm/ADT/STLExtras.h:1929:10
#13 0x049c57ce mlir::mesh::shardedBlockArgumentTypes(mlir::Block&, mlir::SymbolTableCollection&) /home/fuzzing/llvm-project-llvmorg-19.1.4/mlir/lib/Dialect/Mesh/Transforms/Spmdization.cpp:527:3
#14 0x049ca603 mlir::mesh::spmdizeBlock(mlir::Block&, mlir::IRMapping&, mlir::SymbolTableCollection&, mlir::OpBuilder&) /home/fuzzing/llvm-project-llvmorg-19.1.4/mlir/lib/Dialect/Mesh/Transforms/Spmdization.cpp:0:7
#15 0x049c9b33 mlir::mesh::spmdizeFuncOp(mlir::FunctionOpInterface, mlir::IRMapping&, mlir::SymbolTableCollection&) /home/fuzzing/llvm-project-llvmorg-19.1.4/mlir/lib/Dialect/Mesh/Transforms/Spmdization.cpp:0:16
#16 0x049c9b33 mlir::mesh::(anonymous namespace)::Spmdization::runOnOperation() /home/fuzzing/llvm-project-llvmorg-19.1.4/mlir/lib/Dialect/Mesh/Transforms/Spmdization.cpp:735:16
#17 0x08792bb3 mlir::detail::OpToOpPassAdaptor::run(mlir::Pass*, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int)::$_7::operator()() const /home/fuzzing/llvm-project-llvmorg-19.1.4/mlir/lib/Pass/Pass.cpp:0:17
#18 0x08792bb3 void llvm::function_ref::callback_fn(long) /home/fuzzing/llvm-project-llvmorg-19.1.4/llvm/include/llvm/ADT/STLFunctionalExtras.h:45:12
#19 0x08792bb3 llvm::function_ref::operator()() const /home/fuzzing/llvm-project-llvmorg-19.1.4/llvm/include/llvm/ADT/STLFunctionalExtras
[llvm-bugs] [Bug 128799] [MLIR] Assertion `llvm::isa(memorySpace) && "Using `getMemorySpaceInteger` with non-Integer attribute"' failed.
Issue
128799
Summary
[MLIR] Assertion `llvm::isa(memorySpace) && "Using `getMemorySpaceInteger` with non-Integer attribute"' failed.
Labels
mlir
Assignees
Reporter
RiRi114
Test on commit: release 19.1.4
steps to reproduce:
`mlir-opt -affine-data-copy-generate=generate-dma=falsetest.mlir `
test case:
```mlir
module {
func.func @tensor_computation(%X: memref<1024x1024xf32, "slowMemorySpace">, %Y: memref<1024x1024xf32, "slowMemorySpace">, %Z: memref<1024x1024xf32, "slowMemorySpace">) -> memref<1024x1024xf32, "slowMemorySpace"> {
affine.for %i = 0 to 1024 step 64 {
affine.for %j = 0 to 1024 step 64 {
%valX = affine.load %X[%i, %j] : memref<1024x1024xf32, "slowMemorySpace">
%valY = affine.load %Y[%i, %j] : memref<1024x1024xf32, "slowMemorySpace">
%result = arith.addf %valX, %valY : f32
affine.store %result, %Z[%i, %j] : memref<1024x1024xf32, "slowMemorySpace">
}
}
return %Z : memref<1024x1024xf32, "slowMemorySpace">
}
}
```
crash trace:
```
mlir-opt: /home/fuzzing/llvm-project-llvmorg-19.1.4/mlir/lib/IR/BuiltinTypes.cpp:518: unsigned int mlir::detail::getMemorySpaceAsInt(mlir::Attribute): Assertion `llvm::isa(memorySpace) && "Using `getMemorySpaceInteger` with non-Integer attribute"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0. Program arguments: /home/fuzzing/llvm-project-llvmorg-19.1.4/build/bin/mlir-opt -affine-data-copy-generate=generate-dma=false test.mlir
#0 0x013906e7 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /home/fuzzing/llvm-project-llvmorg-19.1.4/llvm/lib/Support/Unix/Signals.inc:723:13
#1 0x0138c27a llvm::sys::RunSignalHandlers() /home/fuzzing/llvm-project-llvmorg-19.1.4/llvm/lib/Support/Signals.cpp:0:5
#2 0x01391c24 SignalHandler(int) /home/fuzzing/llvm-project-llvmorg-19.1.4/llvm/lib/Support/Unix/Signals.inc:413:1
#3 0x736cc1d27520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#4 0x736cc1d7b9fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
#5 0x736cc1d27476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
#6 0x736cc1d0d7f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
#7 0x736cc1d0d71b (/lib/x86_64-linux-gnu/libc.so.6+0x2871b)
#8 0x736cc1d1ee96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96)
#9 0x08b1b412 decltype(auto) llvm::cast(mlir::Attribute&) /home/fuzzing/llvm-project-llvmorg-19.1.4/llvm/include/llvm/Support/Casting.h:572:3
#10 0x08b1b412 mlir::detail::getMemorySpaceAsInt(mlir::Attribute) /home/fuzzing/llvm-project-llvmorg-19.1.4/mlir/lib/IR/BuiltinTypes.cpp:520:32
#11 0x016ecd4b mlir::affine::affineDataCopyGenerate(llvm::ilist_iterator, false, false>, llvm::ilist_iterator, false, false>, mlir::affine::AffineCopyOptions const&, std::optional, llvm::DenseSet >&)::$_5::operator()(mlir::Operation*) const /home/fuzzing/llvm-project-llvmorg-19.1.4/mlir/lib/Dialect/Affine/Utils/LoopUtils.cpp:2305:12
#12 0x016ecd4b void llvm::function_ref::callback_fn, false, false>, llvm::ilist_iterator, false, false>, mlir::affine::AffineCopyOptions const&, std::optional, llvm::DenseSet >&)::$_5>(long, mlir::Operation*) /home/fuzzing/llvm-project-llvmorg-19.1.4/llvm/include/llvm/ADT/STLFunctionalExtras.h:45:12
#13 0x01601201 void mlir::detail::walk(mlir::Operation*, llvm::function_ref, mlir::WalkOrder) /home/fuzzing/llvm-project-llvmorg-19.1.4/mlir/include/mlir/IR/Visitors.h:0:9
#14 0x01601201 void mlir::detail::walk(mlir::Operation*, llvm::function_ref, mlir::WalkOrder) /home/fuzzing/llvm-project-llvmorg-19.1.4/mlir/include/mlir/IR/Visitors.h:0:9
#15 0x016d5f2b void mlir::Block::walk<(mlir::WalkOrder)1, mlir::ForwardIterator, mlir::affine::affineDataCopyGenerate(llvm::ilist_iterator, false, false>, llvm::ilist_iterator, false, false>, mlir::affine::AffineCopyOptions const&, std::optional, llvm::DenseSet >&)::$_5, void>(llvm::ilist_iterator, false, false>, llvm::ilist_iterator, false, false>, mlir::affine::affineDataCopyGenerate(llvm::ilist_iterator, false, false>, llvm::ilist_iterator, false, false>, mlir::affine::AffineCopyOptions const&, std::optional, llvm::DenseSet >&)::$_5&&) /home/fuzzing/llvm-project-llvmorg-19.1.4/mlir/include/mlir/IR/Block.h:343:19
#16 0x016d5f2b mlir::affine::affineDataCopyGenerate(llvm::ilist_iterator, false, false>, llvm::ilist_iterator, false, false>, mlir::affine::AffineCopyOptions const&, std::optional, llvm::DenseSet >&) /home/fuzzing/llvm-project-llvmorg-19.1.4/mlir/lib/Dialect/Affine/Utils/LoopUtils.cpp:2300:10
#17 0x015ff886 (anonymous namespace)::AffineDataCopyGeneration::runOnBlock(mlir::Block*, llvm::DenseSet >&) /home/fuzzing
[llvm-bugs] [Bug 128752] [Flang] Missing diagnostic on duplicate defined I/O
Issue 128752 Summary [Flang] Missing diagnostic on duplicate defined I/O Labels flang:frontend Assignees Reporter DanielCChen Consider the following code: ``` module m type base integer id contains generic :: write (formatted) => write procedure, private :: write => writeb end type abstract interface subroutine absWrite (dtv, unit, iotype, v_list, iostat, iomsg) import class(base), intent(in) :: dtv integer, intent(in) :: unit character(*), intent(in) :: iotype integer, intent(in) :: v_list(:) integer, intent(out) :: iostat character(*), intent(inout) :: iomsg end subroutine end interface procedure(absWrite) writeb, writebaseext interface write(formatted) procedure writebaseext end interface end module end ``` Both `writeb` and `writebaseext` have identical interface for the same defined I/O for type `base`. This should be diagnosed as duplicate. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128755] [Flang] Missing diagnostic on type-spec with deferred length being used in array constructor
Issue 128755 Summary [Flang] Missing diagnostic on type-spec with deferred length being used in array constructor Labels flang:frontend Assignees Reporter DanielCChen Consider the following code ``` module n character(:), allocatable :: c1(:) end module program deferLenMoveAlloc002 use n print *, (/ character(:) :: /) !! Incorrect. allocate ( c1(0), source = (/ character(:) :: /) ). !! Incorrect. end program ``` Both case should be diagnosed. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128757] [Flang] Missing diagnostic on mixed function and subroutine with the same generic name.
Issue 128757 Summary [Flang] Missing diagnostic on mixed function and subroutine with the same generic name. Labels flang:frontend Assignees Reporter DanielCChen Consider the following code: ``` module m type dt contains procedure :: foo procedure :: bar generic :: gen => foo, bar ! Error: foo is function, but bar is a sub end type contains integer function foo(a) class(dt) a foo = 3 end function subroutine bar(a) class(dt) a end subroutine end module ``` `foo` and `bar` shall not be mixed into the same generic name `gen`. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128770] SLP: Instruction does not dominate all uses (insertelement/shufflevector)
Issue 128770 Summary SLP: Instruction does not dominate all uses (insertelement/shufflevector) Labels new issue Assignees alexey-bataev Reporter vzakhari [slp.ll.gz](https://github.com/user-attachments/files/18972113/slp.ll.gz) Reproducer: `opt -passes=slp-vectorizer slp.ll -mcpu=skylake` @alexey-bataev can you please take a look? ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128701] libcxx and clang-cl Visual Studio IDE integration
Issue 128701 Summary libcxx and clang-cl Visual Studio IDE integration Labels libc++ Assignees Reporter void2012 Hi! I would like to know how to use libcxx + clang-cl in Visual Studio 2022 IDE for Windows. Could someone write a guide or something on how to make it possible? Specifying your own VS directories and redirecting them to libcxx path doesn't work and breaks at random places. Thanks! ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128746] -Wsign-compare false positive with comparison against literal -1
Issue
128746
Summary
-Wsign-compare false positive with comparison against literal -1
Labels
false-positive
Assignees
Reporter
alejandro-colomar
In C, comparing an unsigned integer (of rank no less than that of `int`) to a literal `-1` is a common idiom in error-handling code, and is harmless. The -1 is first sign-extended to the width of the unsigned integer, and then is converted into an unsigned value, which is The Right Thing to do.
However, `-Wsign-compare` (in `-Wextra`) diagnoses about it:
```c
alx@debian:~/tmp$ cat f.c
int
main(void)
{
unsigned long i = 3;
if (i == -1)
return 1;
return 0;
}
alx@debian:~/tmp$ clang -Wsign-compare f.c
f.c:6:8: warning: comparison of integers of different signs: 'unsigned long' and 'int' [-Wsign-compare]
6 | if (i == -1)
| ~ ^ ~~
1 warning generated.
```
A user wanting to turn off the diagnostic, may choose to add a cast somewhere in that comparison, and chances are decent that it will put it in the non-literal part (I've seen code like that). And the problem is that such code has a bug, which cannot even be diagnosed (because the cast turns off the diagnostic).
Or maybe it adds a cast in the right place, but the type of the cast is erroneous, which would similarly result in a silent bug.
Another approach that a user might take, to prevent both the diagnostic and a cast, would be to use a suffix in the literal, such as `if (i == -1u)`. This will similarly result in a silent (non-diagnosable) bug. And since we don't have a way to create a suffix for a `time_t`, the programmer has to do a good guess (or write a lot of macros that might get it correctly.
All workarounds result in worse code than a literal `-1`, both in terms of safety, and in terms of readability.
Let's just not warn when comparing an unsigned integer against literal `-1` (with no suffixes), as long as the unsigned integer type has rank no less than `int` (so that the promotions result in an unsigned type, and the -1 is sign-extended).
Here's a bug I opened against GCC:
Cc: @jwakely , @AaronBallman , @ThePhD
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128747] [LLD] LTO internalizing global marked with 'STV_PROTECTED'
Issue
128747
Summary
[LLD] LTO internalizing global marked with 'STV_PROTECTED'
Labels
lld
Assignees
Reporter
jhuber6
I'm trying to compile the following files targeting the AMDGPU architecture.
```llvm
target triple = "amdgcn-amd-amdhsa"
@__llvm_libc_heap_ptr = external hidden addrspace(1) global ptr, align 8
; Function Attrs: convergent mustprogress noinline nounwind optnone
define protected amdgpu_kernel void @kernel(ptr noundef %out) #0 {
entry:
%out.addr = alloca ptr, align 8, addrspace(5)
%out.addr.ascast = addrspacecast ptr addrspace(5) %out.addr to ptr
store ptr %out, ptr %out.addr.ascast, align 8
%0 = load ptr, ptr addrspacecast (ptr addrspace(1) @__llvm_libc_heap_ptr to ptr), align 8
%1 = load ptr, ptr %out.addr.ascast, align 8
store ptr %0, ptr %1, align 8
ret void
}
attributes #0 = { convergent mustprogress noinline nounwind optnone "frame-pointer"="all" "no-builtin-printf" "no-trapping-math"="true" "stack-protector-buffer-size"="8" }
!llvm.module.flags = !{!0, !1, !2, !3}
!llvm.ident = !{!4}
!0 = !{i32 1, !"amdhsa_code_object_version", i32 500}
!1 = !{i32 1, !"wchar_size", i32 4}
!2 = !{i32 8, !"PIC Level", i32 2}
!3 = !{i32 7, !"frame-pointer", i32 2}
!4 = !{!"clang version 21.0.0git"}
```
```llvm
target triple = "amdgcn-amd-amdhsa"
@__llvm_libc_heap_ptr = protected local_unnamed_addr addrspace(1) global ptr null, align 8
@__llvm_libc_heap_size = protected local_unnamed_addr addrspace(1) global i64 0, align 8
!llvm.module.flags = !{!0, !1, !2, !3, !4}
!llvm.ident = !{!5}
!0 = !{i32 1, !"wchar_size", i32 4}
!1 = !{i32 8, !"PIC Level", i32 2}
!2 = !{i32 7, !"frame-pointer", i32 2}
!3 = !{i32 1, !"ThinLTO", i32 0}
!4 = !{i32 1, !"EnableSplitLTOUnit", i32 1}
!5 = !{!"clang version 21.0.0git"}
```
If I take these two files and run them through `ld.lld` I notice that the reference to the protected variable gets internalized. In the resolutions.txt file, it claims that it is not visible to the regular object because it is not exported. But, this is a `-shared` build and a protected symbol should not be internalized like this.
```
ld.lld foo.o bar.o -shared -save-temps
```
Reading the temporary outputs shows the internalization happening.
```console
$ opt -S a.out.0.0.preopt.bc
@__llvm_libc_heap_size = protected local_unnamed_addr addrspace(1) global i64 0, align 8
@__llvm_libc_heap_ptr = protected local_unnamed_addr addrspace(1) global ptr null, align 8
...
$ opt -S a.out.0.2.internalize.bc
@__llvm_libc_heap_size = protected addrspace(1) global i64 0, align 8
@__llvm_libc_heap_ptr = internal addrspace(1) global ptr null, align 8
...
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128736] Assertion `I->use_empty() && "trying to erase instruction with users."' failed.
Issue
128736
Summary
Assertion `I->use_empty() && "trying to erase instruction with users."' failed.
Labels
new issue
Assignees
Reporter
TatyanaDoubts
To reproduce run opt with the test below using -passes=slp-vectorizer.
```
; ModuleID = './reduced.ll'
source_filename = "./reduced.ll"
target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128-ni:1-p2:32:8:8:32-ni:2"
target triple = "x86_64-unknown-linux-gnu"
define i32 @wombat(i32 %arg) #0 gc "statepoint-example" {
bb:
br label %bb1
bb1: ; preds = %bb1, %bb
%phi = phi i32 [ 0, %bb ], [ %mul37, %bb1 ]
%mul = mul i64 0, 0
%trunc = trunc i64 %mul to i32
%or = or i32 0, %trunc
%or2 = or i32 0, %or
%or3 = or i32 %or2, 0
%mul4 = mul i32 0, %or3
%mul5 = mul i32 %or3, 0
%mul6 = mul i32 %mul5, %mul4
%mul7 = mul i32 %mul6, %mul4
%mul8 = mul i32 %mul7, %or3
%mul9 = mul i64 0, 0
%trunc10 = trunc i64 %mul9 to i32
%or11 = or i32 0, %trunc10
%or12 = or i32 %arg, %or11
%or13 = or i32 %or12, 0
%mul14 = mul i32 %or13, %mul8
%mul15 = mul i32 %mul14, 0
%mul16 = mul i32 %mul15, 0
%mul17 = mul i32 %mul16, %or13
%shl = shl i64 0, 0
%mul18 = mul i64 %shl, 0
%trunc19 = trunc i64 %mul18 to i32
%or20 = or i32 0, %trunc19
%or21 = or i32 0, %or20
%or22 = or i32 %or21, 0
%mul23 = mul i32 %or22, %mul17
%mul24 = mul i32 %mul23, 0
%mul25 = mul i32 %mul24, 0
%mul26 = mul i32 %mul25, %or22
%shl27 = shl i64 0, 0
%mul28 = mul i64 %shl27, 0
%trunc29 = trunc i64 %mul28 to i32
%or30 = or i32 0, %trunc29
%or31 = or i32 0, %or30
%or32 = or i32 %or31, 0
%mul33 = mul i32 0, %or32
%mul34 = mul i32 %or32, %mul26
%mul35 = mul i32 %mul34, %mul33
%mul36 = mul i32 %mul35, %mul33
%mul37 = mul i32 %mul36, %or32
br label %bb1
}
attributes #0 = { "target-cpu"="znver2" }
```
Reproducer: https://godbolt.org/z/4PPzsMbP3
Stack dump:
```
opt: /root/llvm-project/llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp:4570: llvm::slpvectorizer::BoUpSLP::~BoUpSLP(): Assertion `I->use_empty() && "trying to erase instruction with users."' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0. Program arguments: /opt/compiler-explorer/clang-assertions-trunk/bin/opt -o /app/output.s -S -passes=slp-vectorizer
1. Running pass "function(slp-vectorizer)" on module ""
2. Running pass "slp-vectorizer" on function "wombat"
#0 0x054546a8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x54546a8)
#1 0x05452064 SignalHandler(int, siginfo_t*, void*) Signals.cpp:0:0
#2 0x7b5c5f242520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#3 0x7b5c5f2969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
#4 0x7b5c5f242476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
#5 0x7b5c5f2287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
#6 0x7b5c5f22871b (/lib/x86_64-linux-gnu/libc.so.6+0x2871b)
#7 0x7b5c5f239e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96)
#8 0x0440d177 (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x440d177)
#9 0x044d46ae llvm::SLPVectorizerPass::runImpl(llvm::Function&, llvm::ScalarEvolution*, llvm::TargetTransformInfo*, llvm::TargetLibraryInfo*, llvm::AAResults*, llvm::LoopInfo*, llvm::DominatorTree*, llvm::AssumptionCache*, llvm::DemandedBits*, llvm::OptimizationRemarkEmitter*) (.part.0) SLPVectorizer.cpp:0:0
#10 0x044d50cb llvm::SLPVectorizerPass::run(llvm::Function&, llvm::AnalysisManager&) (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x44d50cb)
#11 0x0318a35e llvm::detail::PassModel>::run(llvm::Function&, llvm::AnalysisManager&) (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x318a35e)
#12 0x0524e9e0 llvm::PassManager>::run(llvm::Function&, llvm::AnalysisManager&) (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x524e9e0)
#13 0x00e6f88e llvm::detail::PassModel>, llvm::AnalysisManager>::run(llvm::Function&, llvm::AnalysisManager&) (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0xe6f88e)
#14 0x0524d2fb llvm::ModuleToFunctionPassAdaptor::run(llvm::Module&, llvm::AnalysisManager&) (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x524d2fb)
#15 0x00e6eb7e llvm::detail::PassModel>::run(llvm::Module&, llvm::AnalysisManager&) (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0xe6eb7e)
#16 0x0524cd00 llvm::PassManager>::run(llvm::Module&, llvm::AnalysisManager&) (/opt/compiler-explorer/clang-assertions-trunk/bin/opt+0x524cd00)
#17 0x00935e7a llvm::runPassPipeline(llvm::StringRef, llvm::Module&, llvm::TargetMachine*, llvm::TargetLibraryInfoImpl*, llvm::ToolOutputFile*, llvm::ToolO
[llvm-bugs] [Bug 128733] [libc++] Add benchmarks with vector input and segmented iterator outputs for copy/move and friends
Issue 128733 Summary [libc++] Add benchmarks with vector input and segmented iterator outputs for copy/move and friends Labels libc++ Assignees Reporter ldionne > I think we should also add benchmarks for cases where the output is a segmented iterator (i.e. output to a deque) for the `_copy` versions of algorithms. _Originally posted by @philnik777 in https://github.com/llvm/llvm-project/pull/127354#discussion_r1968424899_ ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128749] Invalid BTF produced with IPO globalopts pass
Issue
128749
Summary
Invalid BTF produced with IPO globalopts pass
Labels
new issue
Assignees
Reporter
ayles
Consider the following minimal example (https://godbolt.org/z/YqbTb1znd):
```
// bpf.c
static int foo;
void init() {
foo = 1000;
}
int get() {
return foo;
}
```
When it is compiled with `globalopts` pass enabled (`clang -g -c bpf.c -O1 -target bpf`), `foo` converts to one-byte bool
https://github.com/llvm/llvm-project/blob/148111fdcf0e807fe74274b18fcf65c4cff45d63/llvm/lib/Transforms/IPO/GlobalOpt.cpp#L1160
and its new size propagates through all of meta information, including BTF.
Verifier rejects such BTF after checking entry size inside `DATASEC` against referred type size.
I believe that this is not intended behavior for BTF, but not so sure about generated DWARF/symtab.
```
$ bpftool btf dump file ./result/bpf.o
[1] FUNC_PROTO '(anon)' ret_type_id=0 vlen=0
[2] FUNC 'init' type_id=1 linkage=global
[3] FUNC_PROTO '(anon)' ret_type_id=4 vlen=0
[4] INT 'int' size=4 bits_offset=0 nr_bits=32 encoding=SIGNED
[5] FUNC 'get' type_id=3 linkage=global
[6] VAR 'foo' type_id=4, linkage=static
[7] DATASEC '.bss' size=0 vlen=1
type_id=6 offset=0 size=1 (VAR 'foo')
```
```
$ readelf --syms ./result/bpf.o
Symbol table '.symtab' contains 14 entries:
Num:Value Size TypeBind Vis Ndx Name
...
3: 1 OBJECT LOCAL DEFAULT 4 foo
...
```
```
$ llvm-dwarfdump ./result/bpf.o
...
0x0023: DW_TAG_variable
DW_AT_name ("foo")
DW_AT_type (0x0037 "int")
DW_AT_decl_file ("/build/source/bpf.c")
DW_AT_decl_line (1)
DW_AT_location (DW_OP_addrx 0x0, DW_OP_deref_size 0x1, DW_OP_constu 0x3e8, DW_OP_mul, DW_OP_lit0, DW_OP_plus, DW_OP_stack_value)
...
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128737] [libc++] Benchmark non-trivial types for the copy/move family of algorithms
Issue 128737 Summary [libc++] Benchmark non-trivial types for the copy/move family of algorithms Labels libc++ Assignees ldionne Reporter ldionne > For the copy family of algorithms I think it would be interesting to test some non-trivial type. Specifically, that the compiler would not be able to see through the operation. That could be achieved by an out-of-line definition or a `[[gnu::noinline]]` on the function. Maybe just an optimization barrier would work to. _Originally posted by @philnik777 in https://github.com/llvm/llvm-project/pull/127354#discussion_r1968301004_ ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128744] [Flang] Missing diagnostic on abstract interface name being the same as the keyword of an intrinsic type
Issue 128744 Summary [Flang] Missing diagnostic on abstract interface name being the same as the keyword of an intrinsic type Labels flang:frontend Assignees Reporter DanielCChen Consider the following code. ``` abstract interface function integer() ! Error: intrinsic name is illegal here end function end interface end ``` The standard has: ``` C1503 (R1503) If the interface-stmt is ABSTRACT INTERFACE, then the function-name in the function-stmt or the subroutine-name in the subroutine-stmt shall not be the same as a keyword that specifies an intrinsic type. ``` The above code should be diagnosed. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128760] [Flang] Missing diagnostic on ambiguous generic type-bound procedure
Issue 128760 Summary [Flang] Missing diagnostic on ambiguous generic type-bound procedure Labels flang:frontend Assignees Reporter DanielCChen Consider the following code: ``` module m type base integer :: i contains procedure, nopass :: printa generic :: print => printa end type contains subroutine printa() print *, 'a' end subroutine subroutine printb() print *, 'b' end subroutine end module module n use m type,extends(base) :: child integer :: j contains procedure, nopass :: printb generic :: print => printb end type end module ``` `printa` and `printb` have the same interface. They bound to the same generic `print`. This usage should be diagnosed. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128705] [clang-tidy] Check request: bugprone-avoid-dangling-in-std-filesystem
Issue
128705
Summary
[clang-tidy] Check request: bugprone-avoid-dangling-in-std-filesystem
Labels
clang-tidy
Assignees
Reporter
denzor200
Needs a check that will find usage of invalidated references to something that was owned by `std::filesystem::directory_iterator` before the invalidation. Since `std::filesystem::directory_iterator`'s increment has to invalidate all copies of the previous value of `*this`(look at https://en.cppreference.com/w/cpp/filesystem/directory_iterator/increment ), this check will suggest to make a copy instead of taking a reference.
BEFORE
```
namespace fs = std::filesystem;
fs::directory_iterator it("sandbox");
fs::directory_iterator end;
while (it != end) {
const fs::directory_entry& dir_entry = *it;
const fs::path& dir_path = it->path();
++it;
std::cout << dir_entry; // UB
std::cout << " (" << dir_path << ")" << '\n'; // UB
}
```
AFTER
```
namespace fs = std::filesystem;
fs::directory_iterator it("sandbox");
fs::directory_iterator end;
while (it != end) {
const fs::directory_entry dir_entry = *it;
const fs::path dir_path = it->path();
++it;
std::cout << dir_entry;
std::cout << " (" << dir_path << ")" << '\n';
}
```
https://godbolt.org/z/3Wzoq4rP4
All of the above applies to `std::filesystem::recursive_directory_iterator` as well.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128722] Suboptimal register use on x86-64
Issue
128722
Summary
Suboptimal register use on x86-64
Labels
new issue
Assignees
Reporter
tavianator
Saw this while looking at https://github.com/llvm/llvm-project/issues/128441, but this seems like a more general issue. This C code
```c
int foo(int *a, int *b, int size) {
int ret = 0;
for (int i = 0; i < size; ++i) {
int diff = a[i] ^ b[i];
ret += diff;
if (!diff) {
break;
}
}
return ret;
}
```
[compiles](https://godbolt.org/z/dK74hY1r4) at all optimization levels to:
```asm
foo:
testedx, edx
jle .LBB0_1
mov ecx, edx
dec rcx
xor edx, edx
xor eax, eax
.LBB0_3:
mov r8d, eax
mov r9d, dword ptr [rdi + 4*rdx]
mov r10d, dword ptr [rsi + 4*rdx]
mov eax, r10d
xor eax, r9d
add eax, r8d
xor r10d, r9d
je .LBB0_5
lea r8, [rdx + 1]
cmp rcx, rdx
mov rdx, r8
jne .LBB0_3
.LBB0_5:
ret
.LBB0_1:
xor eax, eax
ret
```
It keeps moving the accumulator from `eax` to `r8d` and back. It also materializes the `xor` result twice when it doesn't need to. Ideally I think it would look more like this:
```asm
.LBB0_3:
mov r8d, dword ptr [rdi + 4*rdx]
xor r8d, dword ptr [rsi + 4*rdx]
je .LBB0_5
add eax, r8d
inc edx
cmp ecx, edx
jne .LBB0_3
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128725] Trivial relocatability follow up
Issue 128725 Summary Trivial relocatability follow up Labels new issue Assignees Reporter cor3ntin - [ ] Deprecate `__builtin_trivially_relocate` - [ ] Enforce that `[[trivial_abi]]` is applied only to relocatable types - [ ] Add logic to static assert / overload resolution diagnostics to explain _why_ a type is no relocatable ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128716] AMDGPU should try to shrink 64-bit defs to 32-bit when rematerializing
Issue 128716 Summary AMDGPU should try to shrink 64-bit defs to 32-bit when rematerializing Labels backend:AMDGPU, llvm:regalloc, missed-optimization Assignees Reporter arsenm If we are rematerializing a wide instruction, we should try harder to rewrite it to set the minimal set of required lanes at the use point. In the most basic case, this means folding a use of s_mov_b64: ``` %0:sreg_64 = S_MOV_B64 0 // Should rematerialize here to undef %0.sub0 = S_MOV_B32 0 S_NOP 0, implicit %0.sub0 ``` [0001-WIP-AMDGPU-Fold-64-bit-moves-into-32-bit-when-materi.patch](https://github.com/user-attachments/files/18965526/0001-WIP-AMDGPU-Fold-64-bit-moves-into-32-bit-when-materi.patch) Attaching WIP patch to start investigation. I'm not sure the starting point is useful, we try something similar already for scalar loads but I don't think the reMaterialize hook has enough context to see the uses here. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128713] Parsing of cutom pragma is out of order.
Issue
128713
Summary
Parsing of cutom pragma is out of order.
Labels
new issue
Assignees
Reporter
preoteasa
The interaction between parsing custom pragmas PragmaHandler::HandlePragma
and ASTConsumer::HandleTopLevelDecl is wrong.
For example parsing the following file:
```
void fnA() { }
#pragma enable_annotate
void fn1() { }
void fn2() { }
```
results in calling PragmaHandler::HandlePragma before calling ASTConsumer::HandleTopLevelDecl for
declaration fnA.
This problem can be reproduced when using the example plugin AnnotateFunctions.so
`CLANG_DIR/bin/clang -fplugin=CLANG_DIR/lib/AnnotateFunctions.so -emit-llvm -S annotate.c -o annotate.S`
for the file annotate.c which has the content given above. The result of this call results in adding an annotation attribute to fnA instead of generating an error because pragma enable_annotate is after the
first declaration.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128714] Assertion `VNI && "No live value at use"
Issue
128714
Summary
Assertion `VNI && "No live value at use"
Labels
bug,
backend:Hexagon
Assignees
iajbar
Reporter
androm3da
This reduced test case from `llvm-test-suite/External/ffmpeg`'s `checkasm_check_v210enc()` asserts when compiling at O2:
```
target datalayout = "e-m:e-p:32:32:32-a:0-n16:32-i64:64:64-i32:32:32-i16:16:16-i1:8:8-f32:32:32-f64:64:64-v32:32:32-v64:64:64-v512:512:512-v1024:1024:1024-v2048:2048:2048"
target triple = "hexagon-unknown-linux-musl"
define void @checkasm_check_v210enc(i32 %.pre) {
entry:
br label %for.body147
for.body147: ; preds = %for.body170, %entry
%add11.i526 = or i32 %.pre, 1
br label %for.body158
for.body158: ; preds = %for.body158, %for.body147
%i154.0604 = phi i32 [ 0, %for.body147 ], [ %add166.3, %for.body158 ]
%add11.i536602603 = phi i32 [ %add11.i526, %for.body147 ], [ 0, %for.body158 ]
%and8.i534 = and i32 %add11.i536602603, 1
%arrayidx9.i535 = getelementptr [64 x i32], ptr null, i32 0, i32 %and8.i534
store i32 0, ptr %arrayidx9.i535, align 4
%add166.3 = add i32 %i154.0604, 1
%cmp157.3 = icmp ult i32 %i154.0604, 510
br i1 %cmp157.3, label %for.body158, label %for.body170
for.body170: ; preds = %for.body170, %for.body158
%i154.1608 = phi i32 [ %add182.1, %for.body170 ], [ 0, %for.body158 ]
%add11.i556606607 = phi i32 [ 0, %for.body170 ], [ 1, %for.body158 ]
%add.ptr179 = getelementptr i16, ptr null, i32 %i154.1608
store i32 0, ptr %add.ptr179, align 8
%add182 = or disjoint i32 %i154.1608, 2
%sub.i547.1 = add i32 %add11.i556606607, 1
%and.i548.1 = and i32 %sub.i547.1, 1
%arrayidx.i549.1 = getelementptr [64 x i32], ptr null, i32 0, i32 %and.i548.1
%0 = load i32, ptr %arrayidx.i549.1, align 4
%add.ptr178.1 = getelementptr i16, ptr null, i32 %add182
store i32 %0, ptr %add.ptr178.1, align 4
%add182.1 = add i32 %i154.1608, 1
%cmp169.1 = icmp ult i32 %i154.1608, 254
br i1 %cmp169.1, label %for.body170, label %for.body147
}
```
I have bisected this failure to b6bf4024a031a5e7b58aff1425d94841a88002d6
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 128706] lld-link.exe fails to find DATA imports without __declspec(dllimport)
Issue
128706
Summary
lld-link.exe fails to find DATA imports without __declspec(dllimport)
Labels
new issue
Assignees
Reporter
stasoid
clang/lld-link version: 19.1.0.
This issue was encountered while porting Ladybird to Windows. Ladybird discord discussions: [one](https://discord.com/channels/1247070541085671459/1306918361732616212/1339658967214723112) [two](https://discord.com/channels/1247070541085671459/1306918361732616212/1343462676839530538).
If data item (global or class static variable) is imported, lld-link refuses to link it unless `__declspec(dllimport)` is specified. Functions (global and member functions) don't have this problem. See also: [WINDOWS_EXPORT_ALL_SYMBOLS](https://cmake.org/cmake/help/latest/prop_tgt/WINDOWS_EXPORT_ALL_SYMBOLS.html) in CMake.
I don't know if it is a bug or a feature, I could not find a similar issue. Is lld-link intentionally matches the behavior of Visual Studio link.exe here? It would be great if it behaved like on Linux instead. This is just confusing.
Simplified reproduction:
mylib.h:
```cpp
struct A
{
static int static_member; // error
void member_function(); // OK
};
extern int global; // error
void global_function(); // OK
```
mylib.cpp:
```cpp
#include "mylib.h"
int global;
int A::static_member;
void global_function()
{
}
void A::member_function()
{
}
```
myprog.cpp:
```cpp
#include "mylib.h"
int main()
{
global = 1;
global_function();
A::static_member = 1;
A().member_function();
}
```
build.bat:
```cmd
:: create dll.o
clang -c mylib.cpp
:: create exports.def
echo mylib.o > objs
cmake -E __create_def exports.def objs
:: create mylib.dll and mylib.lib
lld-link mylib.o /dll libcmt.lib /DEF:exports.def
:: create myprog.o
clang -c myprog.cpp
:: create myprog.exe
lld-link myprog.o mylib.lib libcmt.lib
```
The last command fails with these errors:
```
lld-link: error: undefined symbol: int global
>>> referenced by myprog.o:(main)
lld-link: error: undefined symbol: public: static int A::static_member
>>> referenced by myprog.o:(main)
```
The def/lib/dll export all 4 symbols:
```
> cat exports.def
EXPORTS
?global@@3HA DATA
?static_member@A@@2HADATA
?global_function@@YAXXZ
?member_function@A@@QEAAXXZ
> dumpbin /exports mylib.lib
(some output skipped)
?global@@3HA (int global)
?global_function@@YAXXZ (void __cdecl global_function(void))
?member_function@A@@QEAAXXZ (public: void __cdecl A::member_function(void))
?static_member@A@@2HA (public: static int A::static_member)
> dumpbin /exports mylib.dll
(some output skipped)
10 0001AAC8 ?global@@3HA
21 1000 ?global_function@@YAXXZ
3 2 1010 ?member_function@A@@QEAAXXZ
43 0001AACC ?static_member@A@@2HA
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
