[llvm-bugs] [Bug 120879] [C++23] I want `[[assume(p1 != p2)]]` can be optimized as __restrict
Issue
120879
Summary
[C++23] I want `[[assume(p1 != p2)]]` can be optimized as __restrict
Labels
new issue
Assignees
Reporter
GoodenoughPhysicsLab
```cpp
int f(int *a, int *__restrict b) noexcept {
*a = 1;
*b = 2;
return *a + *b;
}
int f2(int *a, int *b) noexcept {
[[assume(a != b)]];
*a = 1;
*b = 2;
return *a + *b;
}
```
```asm
f(int*, int*):
mov dword ptr [rdi], 1
mov dword ptr [rsi], 2
mov eax, 3
ret
f2(int*, int*):
mov dword ptr [rdi], 1
mov dword ptr [rsi], 2
mov eax, dword ptr [rdi]
add eax, 2
ret
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120939] Incorrect using of `final` triggers a clang frontend crash
Issue
120939
Summary
Incorrect using of `final` triggers a clang frontend crash
Labels
clang
Assignees
Reporter
Rush10233
Consider the following invalid code:
```c++
template
char f(int);
struct A {
virtual ~A() = 0 final;
};
auto a = f(0);
```
The `final` specifier here erroneously appears after the pure virtual destructor declaration, which causes a clang frontend command failure with the following output:
```c++
:5:13: error: initializer on function does not look like a pure-specifier
5 | virtual ~A() = 0 final;
| ^ ~
:5:21: error: expected ';' at end of declaration list
5 | virtual ~A() = 0 final;
| ^
| ;
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments: /opt/compiler-explorer/clang-trunk/bin/clang++ -gdwarf-4 -g -o /app/output.s -mllvm --x86-asm-syntax=intel -fno-verbose-asm -S --gcc-toolchain=/opt/compiler-explorer/gcc-snapshot -fcolor-diagnostics -fno-crash-diagnostics
1. :8:16: current parser token ')'
#0 0x03a2b6e8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x3a2b6e8)
#1 0x03a29834 llvm::sys::CleanupOnSignal(unsigned long) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x3a29834)
#2 0x03979e38 CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0
#3 0x7a51ac842520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#4 0x0679b663 clang::Sema::MarkFunctionReferenced(clang::SourceLocation, clang::FunctionDecl*, bool) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x679b663)
#5 0x06840a81 clang::Sema::ActOnDecltypeExpression(clang::Expr*) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x6840a81)
#6 0x06d9414b clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformType(clang::TypeLocBuilder&, clang::TypeLoc) SemaTemplateInstantiate.cpp:0:0
#7 0x06d9764b clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformType(clang::TypeSourceInfo*) SemaTemplateInstantiate.cpp:0:0
#8 0x06dad5c1 clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformTemplateArgument(clang::TemplateArgumentLoc const&, clang::TemplateArgumentLoc&, bool) SemaTemplateInstantiate.cpp:0:0
#9 0x06dadf42 clang::Sema::SubstTemplateArgument(clang::TemplateArgumentLoc const&, clang::MultiLevelTemplateArgumentList const&, clang::TemplateArgumentLoc&, clang::SourceLocation, clang::DeclarationName const&) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x6dadf42)
#10 0x06c0cf7e clang::Sema::SubstDefaultTemplateArgumentIfAvailable(clang::TemplateDecl*, clang::SourceLocation, clang::SourceLocation, clang::Decl*, llvm::ArrayRef, llvm::ArrayRef, bool&) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x6c0cf7e)
#11 0x06cf764b clang::TemplateDeductionResult ConvertDeducedTemplateArguments(clang::Sema&, clang::FunctionTemplateDecl*, bool, llvm::SmallVectorImpl&, clang::sema::TemplateDeductionInfo&, llvm::SmallVectorImpl&, llvm::SmallVectorImpl&, clang::LocalInstantiationScope*, unsigned int, bool*) (.constprop.0) SemaTemplateDeduction.cpp:0:0
#12 0x06d16ffe clang::Sema::FinishTemplateArgumentDeduction(clang::FunctionTemplateDecl*, llvm::SmallVectorImpl&, unsigned int, clang::FunctionDecl*&, clang::sema::TemplateDeductionInfo&, llvm::SmallVectorImpl const*, bool, llvm::function_ref) (.constprop.0) SemaTemplateDeduction.cpp:0:0
#13 0x06d1800a void llvm::function_ref::callback_fn, clang::FunctionDecl*&, clang::sema::TemplateDeductionInfo&, bool, bool, clang::QualType, clang::Expr::Classification, llvm::function_ref)>)::'lambda1'()>(long) SemaTemplateDeduction.cpp:0:0
#14 0x07947f91 clang::StackExhaustionHandler::runWithSufficientStackSpace(clang::SourceLocation, llvm::function_ref) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x7947f91)
#15 0x06d0d6e7 clang::Sema::DeduceTemplateArguments(clang::FunctionTemplateDecl*, clang::TemplateArgumentListInfo*, llvm::ArrayRef, clang::FunctionDecl*&, clang::sema::TemplateDeductionInfo&, bool, bool, clang::QualType, clang::Expr::Classification, llvm::function_ref)>) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x6d0d6e7)
#16 0x06b67d66 clang::Sema::AddTemplateOverloadCandidate(clang::FunctionTemplateDecl*, clang::DeclAccessPair, clang::TemplateArgumentListInfo*, llvm::ArrayRef, clang::OverloadCandidateSet&, bool, bool, bool, clang::CallExpr::ADLCallKind, clang::OverloadCandidateParamOrder, bool) (.constprop.1) SemaOverload.cpp:0:0
#17 0x06b69ffc clang::Sema::AddOverloadedCallCandidates(clang::UnresolvedLookupExpr
[llvm-bugs] [Bug 120933] Request Commit Access For RossComputerGuy
Issue 120933 Summary Request Commit Access For RossComputerGuy Labels infra:commit-access-request Assignees Reporter RossComputerGuy ### Why Are you requesting commit access ? I'm working on LLVM libc and with UEFI support inside LLVM. Being able to merge PR's for LLVM libc from other people or myself can be useful when the rest of the LLVM libc folks are not available can be useful. I'll also be able to subscribe to LLVM libc PR's when they're opened. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120932] [FuncAttrs] volatile memcpy should not be eliminated
Issue
120932
Summary
[FuncAttrs] volatile memcpy should not be eliminated
Labels
miscompilation,
llvm::Attributor
Assignees
Reporter
dtcxzyw
Reproducer: https://godbolt.org/z/n4j66We8h
```
; bin/opt -O3 test.ll -S
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"
target triple = "x86_64-unknown-linux-gnu"
%struct.S0 = type { i32, i32, i64, i16 }
@g_148 = constant %struct.S0 { i32 568401685, i32 -1, i64 -1, i16 -1 }
define i32 @main() {
entry:
%call2 = call i32 @func_127()
ret i32 0
}
define i32 @func_127() {
entry:
%call241 = call ptr @func_144(ptr null)
%call58 = call i32 @func_139(ptr %call241)
ret i32 0
}
define internal i32 @func_139(ptr %p_140) {
entry:
ret i32 0
}
define ptr @func_144(ptr %p_145) {
entry:
%agg.tmp.ensured = alloca %struct.S0, align 8
call void @llvm.memcpy.p0.p0.i64(ptr %agg.tmp.ensured, ptr @g_148, i64 24, i1 true)
ret ptr %p_145
}
```
Output:
```
%struct.S0 = type { i32, i32, i64, i16 }
define noundef i32 @main() local_unnamed_addr #0 {
ret i32 0
}
define noundef i32 @func_127() local_unnamed_addr #0 {
ret i32 0
}
define ptr @func_144(ptr readnone returned %p_145) local_unnamed_addr #0 {
%agg.tmp.ensured = alloca %struct.S0, align 8
call void @llvm.memcpy.p0.p0.i64(ptr nonnull %agg.tmp.ensured, ptr @g_148, i64 24, i1 true)
ret ptr %p_145
}
declare void @llvm.memcpy.p0.p0.i64(ptr noalias nocapture writeonly, ptr noalias nocapture readonly, i64, i1 immarg) #1
attributes #0 = { mustprogress nofree norecurse nosync nounwind willreturn memory(none) }
attributes #1 = { mustprogress nocallback nofree nounwind willreturn memory(argmem: readwrite) }
```
The memory effect of `func_144` should not be `memory(none)`.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120937] Missing AST matcher: dependentScopeDeclRefExpr
Issue 120937 Summary Missing AST matcher: dependentScopeDeclRefExpr Labels good first issue, clang:frontend, clang:tooling Assignees Reporter HighCommander4 The AST matchers library seems to be missing a matcher that matches an _expression_ of type `DependentScopeDeclRefExpr`. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120913] LLVM cannot constant fold memchr with constant size
Issue
120913
Summary
LLVM cannot constant fold memchr with constant size
Labels
Assignees
Reporter
philnik777
```c++
void* test1(char* first, char val) {
return __builtin_memchr(first, val, 2);
}
```
always generates a call to `memchr`, even though it could just check the two chars. I can't really see a case where calling `memchr` is faster than just checking the two chars. For larger N it would also be interesting to use vector comparisons for this instead of calling a function.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120908] [clang-tidy] Check request: don't use `reset` for a smart pointer to Resetable
Issue
120908
Summary
[clang-tidy] Check request: don't use `reset` for a smart pointer to Resetable
Labels
clang-tidy
Assignees
Reporter
denzor200
Assume we have a user-defined type `A`:
```
struct A {
void reset() { /* A's own logic to reset something */ }
};
```
And then this type was instantiated using `std::unique_ptr` (`std::shared_ptr` also acceptable):
```
auto a = std::make_unique();
```
Since both `std::unique_ptr` and `A` have `reset` method with different meaning, it might be ambiguous to use them:
```
a->reset(); // performs the logic defined in A, "a" stays alive
a.reset(); // "a" becomes nullptr
```
It might be surprised for a programmer to call not the `reset` he expects, and it's easy to make such typo because the difference between `.` and `->` really small.
Suppose a better way to implement the code above:
```
a.get().reset(); // performs the logic defined in A, "a" stays alive
a = nullptr; // "a" becomes nullptr
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120915] llvm-symbolizer can fail due to asan-compiled dependency libraries in LD_LIBRARY_PATH; SIGPIPE exit results
Issue 120915 Summary llvm-symbolizer can fail due to asan-compiled dependency libraries in LD_LIBRARY_PATH; SIGPIPE exit results Labels new issue Assignees Reporter greghudson This issue only affects developers of libraries in the dependency chain of llvm-symbolizer, and it might be tough to fix. I maintain MIT krb5. Our `make check` runs various binaries with LD_LIBRARY_PATH set to a subdirectory of the build directory containing the built versions of libgssapi_krb5/libkrb5/etc.. If we have built everything with -fsanitizer=address and asan wants to report a problem with a stack trace when one of the binaries exits, llvm-symbolizer gets run to convert addresses into symbol names. When llvm-symbolizer starts, the dynamic linker sees a bunch of asan-compiled krb5 libraries in LD_LIBRARY_PATH. Since llvm-symbolizer itself wasn't built with asan, one of these libraries will cause a dynamic linker error like: /usr/bin/llvm-symbolizer-18: symbol lookup error: /home/runner/work/krb5/krb5/src/./lib/libkrb5support.so.0: undefined symbol: __asan_option_detect_stack_use_after_return The program then attempts to write to the llvm-symbolizer pipe and gets a SIGPIPE because the subprocess has exited. If SIGPIPE isn't ignored, the process exits immediately without displaying the un-symbolized stack trace. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120902] [mlir] `-DLLVM_DISTRIBUTION_COMPONENTS=mlir_c_runner_utils` seems to unnecessarily require installing `MLIRSparseTensorRuntime`
Issue 120902 Summary [mlir] `-DLLVM_DISTRIBUTION_COMPONENTS=mlir_c_runner_utils` seems to unnecessarily require installing `MLIRSparseTensorRuntime` Labels mlir Assignees Reporter mgorny I'm finally working on packaging MLIR for Gentoo. The current main seems to work really great, for standalone builds and dylib installation both. However, there's one thing that seems wrong. I'm using `-DLLVM_DISTRIBUTION_COMPONENTS` to skip installing the static libraries. However, if I include `mlir_c_runner_utils` shared library in them, CMake fails: ``` -- Configuring done (5.1s) CMake Error: install(EXPORT "MLIRTargets" ...) includes target "mlir_c_runner_utils" which requires target "MLIRSparseTensorEnums" that is not in any export set. CMake Error: install(EXPORT "MLIRTargets" ...) includes target "mlir_c_runner_utils" which requires target "MLIRSparseTensorRuntime" that is not in any export set. -- Generating done (3.4s) CMake Generate step failed. Build files cannot be regenerated correctly. ``` Please correct me if I'm wrong, but if I understand correctly, `MLIRSparseTensorRuntime` is only used as an implementation detail of `mlir_c_runner_utils` and isn't used otherwise. So I don't think it should be necessary to install the static library at all, and something is going wrong within the build system dependencies. My current (work-in-progress) CMake invocation is the following: ``` cmake -C /tmp/portage/llvm-core/mlir-20.0.0_pre20241221/work/mlir_build/gentoo_common_config.cmake -G Ninja -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_INSTALL_PREFIX=/usr/lib/llvm/20 -DLLVM_ROOT=/usr/lib/llvm/20 -DBUILD_SHARED_LIBS=OFF -DLLVM_BUILD_LLVM_DYLIB=ON -DMLIR_BUILD_MLIR_C_DYLIB=OFF -DMLIR_LINK_MLIR_DYLIB=ON -DMLIR_INCLUDE_TESTS=no -DLLVM_DISTRIBUTION_COMPONENTS=mlir-cmake-exports;mlir-headers;MLIR;mlir_arm_runner_utils;mlir_arm_sme_abi_stubs;mlir_async_runtime;mlir_c_runner_utils;mlir_float16_utils;mlir_runner_utils;mlir-cpu-runner;mlir-linalg-ods-yaml-gen;mlir-lsp-server;mlir-opt;mlir-pdll;mlir-pdll-lsp-server;mlir-query;mlir-reduce;mlir-rewrite;mlir-tblgen;mlir-translate;tblgen-lsp-server;tblgen-to-irdl; -DLLVM_BUILD_UTILS=ON -DPython3_EXECUTABLE=/usr/bin/python3.13 -DLLVM_BUILD_TOOLS=ON -DMLIR_ENABLE_CUDA_RUNNER=OFF -DMLIR_ENABLE_ROCM_RUNNER=OFF -DMLIR_ENABLE_SYCL_RUNNER=OFF -DMLIR_ENABLE_SPIRV_CPU_RUNNER=OFF -DMLIR_ENABLE_VULKAN_RUNNER=OFF -DMLIR_ENABLE_BINDINGS_PYTHON=OFF -DMLIR_INSTALL_AGGREGATE_OBJECTS=OFF -DCMAKE_BUILD_TYPE=RelWithDebInfo -DCMAKE_TOOLCHAIN_FILE=/tmp/portage/llvm-core/mlir-20.0.0_pre20241221/work/mlir_build/gentoo_toolchain.cmake /tmp/portage/llvm-core/mlir-20.0.0_pre20241221/work/mlir ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120922] [Flang] Compilation error when a constructor of derived type with extends (derived type with private attribute is specified in extends)
Issue
120922
Summary
[Flang] Compilation error when a constructor of derived type with extends (derived type with private attribute is specified in extends)
Labels
flang
Assignees
Reporter
ohno-fj
```
Version of flang : 20.0.0(8d550aa0f027eb2cf32850f3905dc1db22317587)/AArch64
```
When a constructor of `derived type` with `extends` (`derived type` with `private` attribute is specified in `extends`) is accessed, a compilation error occurs.
The following are the test program, Flang, Gfortran and ifx compilation/execution result.
snfm0301_027_2.f90:
```fortran
program main
call test02()
print *,"pass"
end program main
module mod2
type,private:: tt
integer :: ip = 1
end type tt
type,extends(tt):: ty1
integer :: i1 = 1
type(tt) :: i1p = tt(2)
integer,allocatable :: i1a(:)
end type ty1
type(ty1) :: str
end module mod2
subroutine test02()
use mod2
integer,allocatable :: ia(:)
allocate(ia(10))
ia=2
str=ty1(i1a=ia)
if (str%i1.ne.1) print *,'ng'
end subroutine test02
```
```
$ flang snfm0301_027_2.f90
flang: /work/groups/ssoft/compiler/llvm/src/llvm-main/flang/lib/Lower/ConvertExprToHLFIR.cpp:1715: hlfir::EntityWithAttributes {anonymous}::HlfirBuilder::gen(const Fortran::evaluate::StructureConstructor&): Assertion `parentCompType && "failed to retrieve parent component 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: /work/groups/ssoft/compiler/llvm/aarch64/main-20241216-8d550aa0f027/bin/flang -fc1 -triple aarch64-unknown-linux-gnu -emit-obj -mrelocation-model pic -pic-level 2 -pic-is-pie -target-cpu generic -target-feature +outline-atomics -target-feature +v8a -target-feature +fp-armv8 -target-feature +neon -resource-dir /work/groups/ssoft/compiler/llvm/aarch64/main-20241216-8d550aa0f027/lib/clang/20 -mframe-pointer=non-leaf -o /tmp/snfm0301_027_2-cb3172.o -x f95-cpp-input snfm0301_027_2.f90
#0 0x400017702180 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/work/groups/ssoft/compiler/llvm/aarch64/main-latest/lib/libLLVM.so.20.0git+0x5952180)
#1 0x400017700208 llvm::sys::RunSignalHandlers() (/work/groups/ssoft/compiler/llvm/aarch64/main-latest/lib/libLLVM.so.20.0git+0x5950208)
#2 0x400017700360 SignalHandler(int) Signals.cpp:0:0
#3 0x4ce507a0 (linux-vdso.so.1+0x7a0)
#4 0x40001c516274 raise (/lib64/libc.so.6+0x36274)
#5 0x40001c500a2c abort (/lib64/libc.so.6+0x20a2c)
#6 0x40001c50fba0 __assert_fail_base (/lib64/libc.so.6+0x2fba0)
#7 0x40001c50fc18 __assert_perror_fail (/lib64/libc.so.6+0x2fc18)
#8 0x0546359c (anonymous namespace)::HlfirBuilder::gen(Fortran::evaluate::StructureConstructor const&) ConvertExprToHLFIR.cpp:0:0
#9 0x05463618 std::__detail::__variant::__gen_vtable_impl>(Fortran::evaluate::Expr> const&)::'lambda'(Fortran::evaluate::SomeKind<(Fortran::common::TypeCategory)5> const&)&&, std::variant>, Fortran::evaluate::ArrayConstructor>, Fortran::evaluate::StructureConstructor, Fortran::evaluate::Designator>, Fortran::evaluate::FunctionRef>, Fortran::evaluate::Parentheses>> const&)>, std::tuple>, Fortran::evaluate::ArrayConstructor>, Fortran::evaluate::StructureConstructor, Fortran::evaluate::Designator>, Fortran::evaluate::FunctionRef>, Fortran::evaluate::Parentheses>> const&>, std::integer_sequence>::__visit_invoke(hlfir::EntityWithAttributes (anonymous namespace)::HlfirBuilder::gen>(Fortran::evaluate::Expr> const&)::'lambda'(Fortran::evaluate::SomeKind<(Fortran::common::TypeCategory)5> const&)&&, std::variant>, Fortran::evaluate::ArrayConstructor>, Fortran::evaluate::StructureConstructor, Fortran::evaluate::Designator>, Fortran::evaluate::FunctionRef>, Fortran::evaluate::Parentheses>> const&) ConvertExprToHLFIR.cpp:0:0
#10 0x0541ff34 hlfir::EntityWithAttributes (anonymous namespace)::HlfirBuilder::gen>(Fortran::evaluate::Expr> const&) ConvertExprToHLFIR.cpp:0:0
#11 0x0541ff68 std::__detail::__variant::__gen_vtable_impl(Fortran::evaluate::Expr const&)::'lambda'(Fortran::evaluate::SomeType const&)&&, std::variant, Fortran::evaluate::NullPointer, Fortran::evaluate::ProcedureDesignator, Fortran::evaluate::ProcedureRef, Fortran::evaluate::Expr>, Fortran::evaluate::Expr>, Fortran::evaluate::Expr>, Fortran::evaluate::Expr>, Fortran::evaluate::Expr>, Fortran::evaluate::Expr>> const&)>, std::tuple, Fortran::evaluate::NullPointer, Fortran::evaluate::ProcedureDesignator, Fortran::evaluate::ProcedureRef, Fortran::evaluate::Expr>, Fortran::evaluate::Expr>, Fortran::evaluate::Expr>, Fortran::evaluate::Expr>, Fortran::evaluate::Expr>, Fortran::evaluate::Expr>> const&>, std::integer_sequence>::__visit_invoke(hlfir::EntityWithAttributes (anonymous namespace)::HlfirBuil
[llvm-bugs] [Bug 120906] [X86][SDAG] llc hang with constant vector splats
Issue
120906
Summary
[X86][SDAG] llc hang with constant vector splats
Labels
backend:X86,
llvm:hang,
llvm:SelectionDAG
Assignees
Reporter
dtcxzyw
Reproducer: https://godbolt.org/z/PnsfYrfnf
```
; bin/llc test.ll -o -
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"
target triple = "x86_64-unknown-linux-gnu"
define i32 @test(ptr %p) {
entry:
store i32 564341309, ptr %p, align 4
%0 = load i32, ptr %p, align 4
%broadcast.splatinsert.1 = insertelement <4 x i32> zeroinitializer, i32 %0, i64 0
%broadcast.splat.1 = shufflevector <4 x i32> %broadcast.splatinsert.1, <4 x i32> zeroinitializer, <4 x i32> zeroinitializer
%1 = icmp ugt <4 x i32> %broadcast.splat.1, splat (i32 -9)
%2 = zext <4 x i1> %1 to <4 x i8>
%3 = shl <4 x i8> splat (i8 11), %2
%4 = or <4 x i8> %3, splat (i8 11)
%bin.rdx = zext <4 x i8> %4 to <4 x i32>
%5 = tail call i32 @llvm.vector.reduce.or.v4i32(<4 x i32> %bin.rdx)
ret i32 %5
}
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120894] llvm-objcopy MachO: does not support localizing and globalizing symbols
Issue 120894 Summary llvm-objcopy MachO: does not support localizing and globalizing symbols Labels tools:llvm-objcopy/strip, platform:macos Assignees RIscRIpt Reporter RIscRIpt On some occasions, there is a need to modify the behavior of a translation unit in a static library. There are many ways to achieve the same result, but the least hacky option might be exposing private symbols in an object file. Currently, llvm-objcopy for Mach-O does not support either `--localize-symbol` or `--globalize-symbol`. https://github.com/RIscRIpt/llvm-project/blob/b28412d5397dc5a23f172d6ebeac760c82a82248/llvm/lib/ObjCopy/ConfigManager.cpp#L36-L37 ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120892] Segfault when using LTO
Issue 120892 Summary Segfault when using LTO Labels Assignees Reporter mr-cheff Clang 18 segfaults when using thin LTO and PGO data. Please let me know if you need anything else Logs: ``` 02:23:45 143:44.96 PLEASE submit a bug report to [https://github.com/llvm/llvm-project/issues/](https://github.com/llvm/llvm-project/issues/?q=sort%3Aupdated-desc+is%3Aissue+is%3Aopen) and include the crash backtrace. 02:23:45 143:45.03 #0 0x7f1d9abebb18 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/home/runner/.mozbuild/clang/bin/../lib/libLLVM.so.18.1+0x25ebb18) 02:23:45 143:45.03 #1 0x7f1d9abebfec SignalHandler(int) Signals.cpp:0:0 02:23:45 143:45.03 #2 0x7f1d97e42520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520) 02:23:45 143:45.03 #3 0x7f1d9a5c9570 llvm::slpvectorizer::BoUpSLP::vectorizeTree(llvm::slpvectorizer::BoUpSLP::TreeEntry*, bool) (/home/runner/.mozbuild/clang/bin/../lib/libLLVM.so.18.1+0x1fc9570) 02:23:45 143:45.03 #4 0x7f1d9a5c89dd llvm::slpvectorizer::BoUpSLP::vectorizeOperand(llvm::slpvectorizer::BoUpSLP::TreeEntry*, unsigned int, bool) (/home/runner/.mozbuild/clang/bin/../lib/libLLVM.so.18.1+0x1fc89dd) 02:23:45 143:45.03 #5 0x7f1d9a5ca0b7 llvm::slpvectorizer::BoUpSLP::vectorizeTree(llvm::slpvectorizer::BoUpSLP::TreeEntry*, bool) (/home/runner/.mozbuild/clang/bin/../lib/libLLVM.so.18.1+0x1fca0b7) 02:23:45 143:45.03 #6 0x7f1d9a42334a llvm::slpvectorizer::BoUpSLP::vectorizeTree(llvm::MapVector, llvm::DenseMap, llvm::detail::DenseMapPair>, llvm::SmallVector>, 0u>> const&, llvm::SmallVectorImpl>&, llvm::Instruction*) (/home/runner/.mozbuild/clang/bin/../lib/libLLVM.so.18.1+0x1e2334a) 02:23:45 143:45.03 #7 0x7f1d9a422694 llvm::slpvectorizer::BoUpSLP::vectorizeTree() (/home/runner/.mozbuild/clang/bin/../lib/libLLVM.so.18.1+0x1e22694) 02:23:45 143:45.03 #8 0x7f1d9a451197 llvm::SLPVectorizerPass::tryToVectorizeList(llvm::ArrayRef, llvm::slpvectorizer::BoUpSLP&, bool) (/home/runner/.mozbuild/clang/bin/../lib/libLLVM.so.18.1+0x1e51197) 02:23:45 143:45.03 #9 0x7f1d9a440b5c bool tryToVectorizeSequence(llvm::SmallVectorImpl&, llvm::function_ref, llvm::function_ref, llvm::function_ref, bool)>, bool, llvm::slpvectorizer::BoUpSLP&) SLPVectorizer.cpp:0:0 02:23:45 143:45.03 #10 0x7f1d9a449e8f llvm::SLPVectorizerPass::vectorizeChainsInBlock(llvm::BasicBlock*, llvm::slpvectorizer::BoUpSLP&) (/home/runner/.mozbuild/clang/bin/../lib/libLLVM.so.18.1+0x1e49e8f) 02:23:45 143:45.03 #11 0x7f1d9a445570 llvm::SLPVectorizerPass::runImpl(llvm::Function&, llvm::ScalarEvolution*, llvm::TargetTransformInfo*, llvm::TargetLibraryInfo*, llvm::AAResults*, llvm::LoopInfo*, llvm::DominatorTree*, llvm::AssumptionCache*, llvm::DemandedBits*, llvm::OptimizationRemarkEmitter*) (/home/runner/.mozbuild/clang/bin/../lib/libLLVM.so.18.1+0x1e45570) 02:23:45 143:45.03 #12 0x7f1d9a51 llvm::SLPVectorizerPass::run(llvm::Function&, llvm::AnalysisManager&) (/home/runner/.mozbuild/clang/bin/../lib/libLLVM.so.18.1+0x1e44451) 02:23:45 143:45.03 #13 0x7f1d9a44424d llvm::detail::PassModel>::run(llvm::Function&, llvm::AnalysisManager&) PassBuilder.cpp:0:0 02:23:45 143:45.03 #14 0x7f1d9a010bbd llvm::PassManager>::run(llvm::Function&, llvm::AnalysisManager&) (/home/runner/.mozbuild/clang/bin/../lib/libLLVM.so.18.1+0x1a10bbd) 02:23:45 143:45.03 #15 0x7f1d9a01088d llvm::detail::PassModel>, llvm::PreservedAnalyses, llvm::AnalysisManager>::run(llvm::Function&, llvm::AnalysisManager&) X86CodeGenPassBuilder.cpp:0:0 02:23:45 143:45.03 #16 0x7f1d9a01f816 llvm::ModuleToFunctionPassAdaptor::run(llvm::Module&, llvm::AnalysisManager&) (/home/runner/.mozbuild/clang/bin/../lib/libLLVM.so.18.1+0x1a1f816) 02:23:45 143:45.03 #17 0x7f1d9a01f44d llvm::detail::PassModel>::run(llvm::Module&, llvm::AnalysisManager&) X86CodeGenPassBuilder.cpp:0:0 02:23:45 143:45.03 #18 0x7f1d9a82d3a1 llvm::PassManager>::run(llvm::Module&, llvm::AnalysisManager&) (/home/runner/.mozbuild/clang/bin/../lib/libLLVM.so.18.1+0x222d3a1) 02:23:45 143:45.03 #19 0x7f1d9b8790ed llvm::lto::opt(llvm::lto::Config const&, llvm::TargetMachine*, unsigned int, llvm::Module&, bool, llvm::ModuleSummaryIndex*, llvm::ModuleSummaryIndex const*, std::vector> const&) (/home/runner/.mozbuild/clang/bin/../lib/libLLVM.so.18.1+0x32790ed) 02:23:45 143:45.04 #20 0x7f1d9b87cad2 llvm::lto::thinBackend(llvm::lto::Config const&, unsigned int, std::function>> (unsigned int, llvm::Twine const&)>, llvm::Module&, llvm::ModuleSummaryIndex const&, llvm::DenseMap, std::equal_to, std::allocator>, llvm::DenseMapInfo, llvm::detail::DenseMapPair, std::equal_to, std::allocator>>> const&, llvm::DenseMap, llvm::detail::DenseMapPair> const&, llvm::MapVector, llvm::detail::DenseMapPair>, llvm::SmallVector, 0u>>*, std::vector> const&)::$_0::operator()(l
[llvm-bugs] [Bug 120898] `{Small, }BitVector.reset(unsigned I, unsigned E)` has off-by-one error
Issue
120898
Summary
`{Small,}BitVector.reset(unsigned I, unsigned E)` has off-by-one error
Labels
new issue
Assignees
Reporter
natanelh-mobileye
consider the following crashing code:
```c++
SmallBitVector BV(31, true);
BV.reset(30, 32);
```
expected behavior: bits 30, 31 are reset
actual behavior: assertion crash:
```sh
at llvm-project/llvm/include/llvm/ADT/SmallBitVector.h:420
420 assert(E <= size() && "Attempted to reset out-of-bounds range!");
```
it should check `E <= size() + 1` since the end is not included in the range (at least according to the docs).
I am not good enough with bits and bytes to solve the algorithm however and a dumb change of adding one in that check may or may not cause UB later without special handling.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120923] [clang-tidy] Check request: detect suspicious deleted constructor and assignment operator
Issue
120923
Summary
[clang-tidy] Check request: detect suspicious deleted constructor and assignment operator
Labels
clang-tidy
Assignees
Reporter
denzor200
In C++20 mode it becomes possible to use `auto` in a function parameter declaration, so thus it's possible to write strange code like this:
```
struct A {
A() = default;
A(const auto& other) = delete;
A& operator=(const auto& other) = delete;
};
```
These two deleted functions don't make sense indeed and they look suspicious - looks like someone tried to make `A` noncopyable.
The root of the problem is that `A` still remains copyable, which might be bugproned.
In my opinion it's easy to make such typo in the code, especially if you are following guideline that orders you to always use `auto` everywhere it's possible.
Suppose we need a check that will automatically provide the fix for the code above:
```
struct A {
A() = default;
A(const A& other) = delete;
A& operator=(const A& other) = delete;
};
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120924] [clang-tidy] Check request: never capture `shared_from_this` by a field
Issue
120924
Summary
[clang-tidy] Check request: never capture `shared_from_this` by a field
Labels
clang-tidy
Assignees
Reporter
denzor200
```
#include
#include
struct A : std::enable_shared_from_this {
std::function captured;
void init() {
captured =
[self=shared_from_this()]() { // INCORRECT
};
}
};
int main()
{
auto a = std::make_shared();
a->init();
}
```
The example above contains circular reference, so `A` will never be deleted, that's a memory leak 100%.
One of the possible fix is to use `weak_from_this` instead. Suppose a check to discover the bug like this will be simple
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120882] [mlir] -arith-unsigned-when-equivalent crashes
Issue
120882
Summary
[mlir] -arith-unsigned-when-equivalent crashes
Labels
mlir
Assignees
Reporter
wwy6191
git version: bc29fc937c6cb4a210f80c93c79fc6ed97c801f8
system: `Ubuntu 18.04.6 LTS`
reproduce with: `mlir-opt -arith-unsigned-when-equivalent a.mlir`
a.mlir:
```
func.func @test_shl_i8_nowrap() -> i8 {
%cst3 = arith.constant 3 : i8
%0 = test.with_bounds { umin = 10 : i64, umax = 15 : ui64, smin = 10 : si64, smax = 15 : si64 } : i8
%1 = arith.shli %0, %cst3 overflow : i8
%2 = test.reflect_bounds %1 : i8
return %2: i8
}
```
stack trace:
```
:0: error: integer type bit width (8) doesn't match value bit width (64)
mlir-opt: /data/szy/MLIR/llvm-release/llvm-project/mlir/include/mlir/IR/StorageUniquerSupport.h:180: static ConcreteT mlir::detail::StorageUserBase::get(MLIRContext *, Args &&...) [ConcreteT = mlir::IntegerAttr, BaseT = mlir::Attribute, StorageT = mlir::detail::IntegerAttrStorage, UniquerT = mlir::detail::AttributeUniquer, Traits = , Args = ]: Assertion `succeeded( ConcreteT::verifyInvariants(getDefaultDiagnosticEmitFn(ctx), args...))' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0. Program arguments: /data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt -arith-unsigned-when-equivalent /data/szy/MLIR/seed726/tmp.M9zUoiOZMu.mlir
#0 0x55a9d52aa418 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x11ee418)
#1 0x55a9d52a7f2e llvm::sys::RunSignalHandlers() (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x11ebf2e)
#2 0x55a9d52aadad SignalHandler(int) Signals.cpp:0:0
#3 0x7f919dfba420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420)
#4 0x7f919d5f700b raise /build/glibc-LcI20x/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:51:1
#5 0x7f919d5d6859 abort /build/glibc-LcI20x/glibc-2.31/stdlib/abort.c:81:7
#6 0x7f919d5d6729 get_sysdep_segment_value /build/glibc-LcI20x/glibc-2.31/intl/loadmsgcat.c:509:8
#7 0x7f919d5d6729 _nl_load_domain /build/glibc-LcI20x/glibc-2.31/intl/loadmsgcat.c:970:34
#8 0x7f919d5e7fd6 (/lib/x86_64-linux-gnu/libc.so.6+0x33fd6)
#9 0x55a9d82f37b1 (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x42377b1)
#10 0x55a9d82f362f mlir::IntegerAttr::get(mlir::Type, llvm::APInt const&) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x423762f)
#11 0x55a9d8438c02 test::TestReflectBoundsOp::inferResultRanges(llvm::ArrayRef, llvm::function_ref) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x437cc02)
#12 0x55a9d87d9291 mlir::detail::InferIntRangeInterfaceInterfaceTraits::Model::inferResultRanges(mlir::detail::InferIntRangeInterfaceInterfaceTraits::Concept const*, mlir::Operation*, llvm::ArrayRef, llvm::function_ref) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x471d291)
#13 0x55a9db3e4066 mlir::intrange::detail::defaultInferResultRanges(mlir::InferIntRangeInterface, llvm::ArrayRef, llvm::function_ref) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x7328066)
#14 0x55a9d81f4bdc mlir::dataflow::IntegerRangeAnalysis::visitOperation(mlir::Operation*, llvm::ArrayRef, llvm::ArrayRef) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x4138bdc)
#15 0x55a9d81f7c99 mlir::dataflow::AbstractSparseForwardDataFlowAnalysis::visitOperation(mlir::Operation*) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x413bc99)
#16 0x55a9d81f7339 mlir::dataflow::AbstractSparseForwardDataFlowAnalysis::initializeRecursively(mlir::Operation*) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x413b339)
#17 0x55a9d81f75ed mlir::dataflow::AbstractSparseForwardDataFlowAnalysis::initializeRecursively(mlir::Operation*) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x413b5ed)
#18 0x55a9d81f75ed mlir::dataflow::AbstractSparseForwardDataFlowAnalysis::initializeRecursively(mlir::Operation*) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x413b5ed)
#19 0x55a9d81d59ee mlir::DataFlowSolver::initializeAndRun(mlir::Operation*) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x41199ee)
#20 0x55a9d55e1854 (anonymous namespace)::ArithUnsignedWhenEquivalentPass::runOnOperation() UnsignedWhenEquivalent.cpp:0:0
#21 0x55a9d820ad66 mlir::detail::OpToOpPassAdaptor::run(mlir::Pass*, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x414ed66)
#22 0x55a9d820b690 mlir::detail::OpToOpPassAdaptor::runPipeline(mlir::OpPassManager&, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int, mlir::PassInstrumentor*, mlir
[llvm-bugs] [Bug 120884] [mlir] -sparsification-and-bufferization crashes
Issue
120884
Summary
[mlir] -sparsification-and-bufferization crashes
Labels
mlir
Assignees
Reporter
wwy6191
git version: bc29fc937c6cb4a210f80c93c79fc6ed97c801f8
system: `Ubuntu 18.04.6 LTS`
reproduce with: `mlir-opt -sparsification-and-bufferization a.mlir`
a.mlir:
```
#map = affine_map<()[s0,s1,s2] -> ((s0 * s1) * s1)>
module {
func.func @test_reshape_3d_same_d2d_explicit_empty(%arg0: tensor<3x?x?xf32>) -> tensor {
%c2 = arith.constant 2 : index
%c1 = arith.constant 1 : index
%c3 = arith.constant 3 : index
%collapsed = tensor.collapse_shape %arg0 [[0, 1, 2]] : tensor<3x?x?xf32> into tensor
%dim = tensor.dim %arg0, %c1 : tensor<3x?x?xf32>
%dim_0 = tensor.dim %collapsed, %c2 : tensor
%dim_1 = tensor.dim %collapsed, %c3 : tensor
%0 = affine.apply #map()[%dim, %dim_0, %dim_1]
%1 = arith.divui %0, %c1 : index
%expanded = tensor.expand_shape %collapsed [[0, 1, 2]] output_shape [%1, 3, %0] : tensor into tensor
%cast = tensor.cast %expanded : tensor to tensor
return %cast : tensor
}
}
```
stack trace:
```
mlir-opt: /data/szy/MLIR/llvm-release/llvm-project/mlir/lib/Dialect/MemRef/IR/MemRefOps.cpp:2315: static void mlir::memref::ExpandShapeOp::build(OpBuilder &, OperationState &, Type, Value, ArrayRef): Assertion `succeeded(outputShape) && "unable to infer output shape"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0. Program arguments: /data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt -sparsification-and-bufferization /data/szy/MLIR/seed/seed14/tmp.hNYivZemUi.mlir
#0 0x556e46049418 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x11ee418)
#1 0x556e46046f2e llvm::sys::RunSignalHandlers() (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x11ebf2e)
#2 0x556e46049dad SignalHandler(int) Signals.cpp:0:0
#3 0x7f218845a420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420)
#4 0x7f2187a9700b raise /build/glibc-LcI20x/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:51:1
#5 0x7f2187a76859 abort /build/glibc-LcI20x/glibc-2.31/stdlib/abort.c:81:7
#6 0x7f2187a76729 get_sysdep_segment_value /build/glibc-LcI20x/glibc-2.31/intl/loadmsgcat.c:509:8
#7 0x7f2187a76729 _nl_load_domain /build/glibc-LcI20x/glibc-2.31/intl/loadmsgcat.c:970:34
#8 0x7f2187a87fd6 (/lib/x86_64-linux-gnu/libc.so.6+0x33fd6)
#9 0x556e478b5681 (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x2a5a681)
#10 0x556e48590b6b mlir::memref::ExpandShapeOp mlir::OpBuilder::create, mlir::Value&, llvm::SmallVector, 4u>>(mlir::Location, llvm::ArrayRef&&, mlir::Value&, llvm::SmallVector, 4u>&&) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x3735b6b)
#11 0x556e485902ea mlir::bufferization::detail::BufferizableOpInterfaceInterfaceTraits::FallbackModel::bufferize(mlir::bufferization::detail::BufferizableOpInterfaceInterfaceTraits::Concept const*, mlir::Operation*, mlir::RewriterBase&, mlir::bufferization::BufferizationOptions const&) BufferizableOpInterfaceImpl.cpp:0:0
#12 0x556e465a1340 mlir::bufferization::bufferizeOp(mlir::Operation*, mlir::bufferization::BufferizationOptions const&, mlir::bufferization::BufferizationStatistics*) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x1746340)
#13 0x556e465dc1e4 mlir::bufferization::bufferizeModuleOp(mlir::ModuleOp, mlir::bufferization::OneShotBufferizationOptions const&, mlir::bufferization::BufferizationStatistics*) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x17811e4)
#14 0x556e4805e588 mlir::sparse_tensor::SparsificationAndBufferizationPass::runDenseBufferization() (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x3203588)
#15 0x556e4805e0dc mlir::sparse_tensor::SparsificationAndBufferizationPass::runOnOperation() (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x32030dc)
#16 0x556e48fa9d66 mlir::detail::OpToOpPassAdaptor::run(mlir::Pass*, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x414ed66)
#17 0x556e48faa690 mlir::detail::OpToOpPassAdaptor::runPipeline(mlir::OpPassManager&, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int, mlir::PassInstrumentor*, mlir::PassInstrumentation::PipelineParentInfo const*) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x414f690)
#18 0x556e48facc62 mlir::PassManager::run(mlir::Operation*) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x4151c62)
#19 0x556e48fa53da performActions(llvm::raw_ostream&, std::shared_ptr const&, mlir::MLIRContext*, mlir
[llvm-bugs] [Bug 120883] [mlir] -lift-cf-to-scf crashes
Issue
120883
Summary
[mlir] -lift-cf-to-scf crashes
Labels
mlir
Assignees
Reporter
wwy6191
git version: bc29fc937c6cb4a210f80c93c79fc6ed97c801f8
system: `Ubuntu 18.04.6 LTS`
reproduce with: `mlir-opt -lift-cf-to-scf a.mlir`
a.mlir:
```
module {
func.func private @ext_func_result_attrs(%arg0: f32) -> (i32, i32) {
%cst0_i32 = spirv.Constant 0 : i32
%cst-1_i32 = spirv.Constant -1 : i32
%0 = spirv.Variable :!spirv.ptr
%1 = spirv.Variable :!spirv.ptr
spirv.mlir.loop {
spirv.Branch ^bb1(%cst0_i32, %cst-1_i32 : i32, i32)
^bb1(%3: i32, %4: i32): // 2 preds: ^bb0, ^bb2
%5 = spirv.SLessThan %3, %cst-1_i32 : i32
spirv.BranchConditional %5, ^bb2, ^bb3
^bb2: // pred: ^bb1
%6 = spirv.IAdd %3, %4 : i32
spirv.Store "Function" %0, %6 : i32
%7 = spirv.IAdd %3, %cst0_i32 : i32
spirv.Branch ^bb1(%7, %6 : i32, i32)
^bb3: // pred: ^bb1
spirv.mlir.merge
}
%2 = spirv.Load "Function" %1 : i32
%3 = spirv.Load "Function" %0 : i32
return %3, %2 : i32, i32
}
}
```
stack trace:
```
/data/szy/MLIR/seed/seed29/tmp.1nu1IKGsQn.mlir:11:7: error: 'spirv.BranchConditional' op Cannot convert unknown control flow op to structured control flow
spirv.BranchConditional %5, ^bb2, ^bb3
^
/data/szy/MLIR/seed/seed29/tmp.1nu1IKGsQn.mlir:11:7: note: see current operation: "spirv.BranchConditional"(%10, %6, %6, %7, %8)[INVALIDBLOCK, ^bb1] <{operandSegmentSizes = array}> : (i1, i32, i32, i32, i32) -> ()
mlir-opt: /data/szy/MLIR/llvm-release/llvm-project/mlir/include/mlir/IR/UseDefLists.h:198: mlir::IRObjectWithUseList::~IRObjectWithUseList() [OperandType = mlir::BlockOperand]: Assertion `use_empty() && "Cannot destroy a value that still has uses!"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0. Program arguments: /data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt -lift-cf-to-scf /data/szy/MLIR/seed/seed29/tmp.1nu1IKGsQn.mlir
#0 0x56551cfda418 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x11ee418)
#1 0x56551cfd7f2e llvm::sys::RunSignalHandlers() (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x11ebf2e)
#2 0x56551cfdadad SignalHandler(int) Signals.cpp:0:0
#3 0x7f25fa8ce420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420)
#4 0x7f25f9f0b00b raise /build/glibc-LcI20x/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:51:1
#5 0x7f25f9eea859 abort /build/glibc-LcI20x/glibc-2.31/stdlib/abort.c:81:7
#6 0x7f25f9eea729 get_sysdep_segment_value /build/glibc-LcI20x/glibc-2.31/intl/loadmsgcat.c:509:8
#7 0x7f25f9eea729 _nl_load_domain /build/glibc-LcI20x/glibc-2.31/intl/loadmsgcat.c:970:34
#8 0x7f25f9efbfd6 (/lib/x86_64-linux-gnu/libc.so.6+0x33fd6)
#9 0x56552001baf9 (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x422faf9)
#10 0x5655200f65e6 llvm::iplist_impl, llvm::ilist_traits>::erase(llvm::ilist_iterator, false, false>) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x430a5e6)
#11 0x5655200f4fab mlir::Region::~Region() (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x4308fab)
#12 0x56551ff89278 mlir::transformCFGToSCF(mlir::Region&, mlir::CFGToSCFInterface&, mlir::DominanceInfo&) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x419d278)
#13 0x56551fa8b20f mlir::WalkResult llvm::function_ref::callback_fn<(anonymous namespace)::LiftControlFlowToSCF::runOnOperation()::'lambda'(mlir::func::FuncOp)::operator()(mlir::func::FuncOp) const::'lambda'(mlir::Operation*)>(long, mlir::Operation*) ControlFlowToSCF.cpp:0:0
#14 0x56551d107e27 mlir::WalkResult mlir::detail::walk(mlir::Operation*, llvm::function_ref, mlir::WalkOrder) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x131be27)
#15 0x56551fa8adfe 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)::LiftControlFlowToSCF::runOnOperation()::'lambda'(mlir::func::FuncOp), mlir::func::FuncOp, mlir::WalkResult>(mlir::Operation*, (anonymous namespace)::LiftControlFlowToSCF::runOnOperation()::'lambda'(mlir::func::FuncOp)&&)::'lambda'(mlir::Operation*)>(long, mlir::Operation*) ControlFlowToSCF.cpp:0:0
#16 0x56551d107e27 mlir::WalkResult mlir::detail::walk(mlir::Operation*, llvm::function_ref, mlir::WalkOrder) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x131be27)
#17 0x56551fa8ab97 (anonymous namespace)::LiftControlFlowToSCF::runOnOperation() ControlFlowToSCF.cpp:0:0
#18 0x56551ff3ad66 mlir::detail::OpToOpPassAdaptor::r
[llvm-bugs] [Bug 120878] [AArch64][GISel] Optimize bitreverse intrinsic for vector types
Issue 120878 Summary [AArch64][GISel] Optimize bitreverse intrinsic for vector types Labels new issue Assignees Reporter madhur13490 2 x s32, 2 x i64, 4 x s16, 4 x s32, 8 x s16 types are going through suboptimal lowering. Looking at SDAG, `revXX` followed by `rbit` is more optimal. godbolt: https://godbolt.org/z/nP8jssKh8 ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120886] [mlir] -one-shot-bufferize crashes
Issue
120886
Summary
[mlir] -one-shot-bufferize crashes
Labels
mlir
Assignees
Reporter
wwy6191
git version: bc29fc937c6cb4a210f80c93c79fc6ed97c801f8
system: `Ubuntu 18.04.6 LTS`
reproduce with: `mlir-opt -one-shot-bufferize a.mlir`
a.mlir:
```
module {
func.func @test_reshape_3d_same_d2d(%arg0: tensor<2x?xf32>) -> (tensor, tensor, tensor) {
%collapsed = tensor.collapse_shape %arg0 [[0, 1]] : tensor<2x?xf32> into tensor
%c0 = arith.constant 0 : index
%dim = tensor.dim %collapsed, %c0 : tensor
%c2 = arith.constant 2 : index
%0 = arith.divui %dim, %c2 : index
%expanded = tensor.expand_shape %collapsed [[0, 1]] output_shape [2, %0] : tensor into tensor<2x?xf32>
%cast = tensor.cast %expanded : tensor<2x?xf32> to tensor
%dim_replaced = tensor.dim %cast, %c0 : tensor
%c1 = arith.constant 1 : index
%1 = arith.divui %dim_replaced, %c1 : index
%expanded_0 = tensor.expand_shape %collapsed [[0, 1]] output_shape [2, %1] : tensor into tensor<2x?xf32>
%cast_1 = tensor.cast %expanded_0 : tensor<2x?xf32> to tensor
%c0_2 = arith.constant 0 : index
%dim_replaced_3 = tensor.dim %cast_1, %c0_2 : tensor
%c1_4 = arith.constant 1 : index
%expanded_5 = tensor.expand_shape %collapsed [[0, 1]] output_shape [%dim_replaced_3, %c1_4] : tensor into tensor
return %cast, %cast_1, %expanded_5 : tensor, tensor, tensor
}
}
```
stack trace:
```
mlir-opt: /data/szy/MLIR/llvm-release/llvm-project/mlir/lib/Dialect/MemRef/IR/MemRefOps.cpp:2315: static void mlir::memref::ExpandShapeOp::build(OpBuilder &, OperationState &, Type, Value, ArrayRef): Assertion `succeeded(outputShape) && "unable to infer output shape"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0. Program arguments: /data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt -one-shot-bufferize /data/szy/MLIR/seed/seed14/tmp.hNYivZemUi.mlir
#0 0x55c527a4a418 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x11ee418)
#1 0x55c527a47f2e llvm::sys::RunSignalHandlers() (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x11ebf2e)
#2 0x55c527a4adad SignalHandler(int) Signals.cpp:0:0
#3 0x7f548ef53420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420)
#4 0x7f548e59000b raise /build/glibc-LcI20x/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:51:1
#5 0x7f548e56f859 abort /build/glibc-LcI20x/glibc-2.31/stdlib/abort.c:81:7
#6 0x7f548e56f729 get_sysdep_segment_value /build/glibc-LcI20x/glibc-2.31/intl/loadmsgcat.c:509:8
#7 0x7f548e56f729 _nl_load_domain /build/glibc-LcI20x/glibc-2.31/intl/loadmsgcat.c:970:34
#8 0x7f548e580fd6 (/lib/x86_64-linux-gnu/libc.so.6+0x33fd6)
#9 0x55c5292b6681 (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x2a5a681)
#10 0x55c529f91b6b mlir::memref::ExpandShapeOp mlir::OpBuilder::create, mlir::Value&, llvm::SmallVector, 4u>>(mlir::Location, llvm::ArrayRef&&, mlir::Value&, llvm::SmallVector, 4u>&&) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x3735b6b)
#11 0x55c529f912ea mlir::bufferization::detail::BufferizableOpInterfaceInterfaceTraits::FallbackModel::bufferize(mlir::bufferization::detail::BufferizableOpInterfaceInterfaceTraits::Concept const*, mlir::Operation*, mlir::RewriterBase&, mlir::bufferization::BufferizationOptions const&) BufferizableOpInterfaceImpl.cpp:0:0
#12 0x55c527fa2340 mlir::bufferization::bufferizeOp(mlir::Operation*, mlir::bufferization::BufferizationOptions const&, mlir::bufferization::BufferizationStatistics*) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x1746340)
#13 0x55c527fa604d (anonymous namespace)::OneShotBufferizePass::runOnOperation() Bufferize.cpp:0:0
#14 0x55c52a9aad66 mlir::detail::OpToOpPassAdaptor::run(mlir::Pass*, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x414ed66)
#15 0x55c52a9ab690 mlir::detail::OpToOpPassAdaptor::runPipeline(mlir::OpPassManager&, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int, mlir::PassInstrumentor*, mlir::PassInstrumentation::PipelineParentInfo const*) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x414f690)
#16 0x55c52a9adc62 mlir::PassManager::run(mlir::Operation*) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x4151c62)
#17 0x55c52a9a63da performActions(llvm::raw_ostream&, std::shared_ptr const&, mlir::MLIRContext*, mlir::MlirOptMainConfig const&) MlirOptMain.cpp:0:0
#18 0x55c52a9a602d llvm::LogicalResult llvm::function_ref>, llvm::raw_ostream&)>::callback_fn>, mlir::DialectRegistry&, mlir::MlirOpt
[llvm-bugs] [Bug 120891] Clang generates the fake /usr/include/tgmath.h dependency
Issue 120891 Summary Clang generates the fake /usr/include/tgmath.h dependency Labels clang Assignees Reporter hjl-tools On Linux, the fake /usr/include/tgmath.h dependency is generated by clang even though clang never reads /usr/include/tgmath.h: ``` [hjl@gnu-tgl-3 tmp]$ cat f.c #include [hjl@gnu-tgl-3 tmp]$ clang -M -c f.c f.o: f.c /usr/bin/../lib/clang/19/include/tgmath.h /usr/include/math.h \ /usr/include/bits/libc-header-start.h /usr/include/features.h \ /usr/include/features-time64.h /usr/include/bits/wordsize.h \ /usr/include/bits/timesize.h /usr/include/stdc-predef.h \ /usr/include/sys/cdefs.h /usr/include/bits/long-double.h \ /usr/include/gnu/stubs.h /usr/include/gnu/stubs-64.h \ /usr/include/bits/types.h /usr/include/bits/typesizes.h \ /usr/include/bits/time64.h /usr/include/bits/math-vector.h \ /usr/include/bits/libm-simd-decl-stubs.h /usr/include/bits/floatn.h \ /usr/include/bits/floatn-common.h /usr/include/bits/flt-eval-method.h \ /usr/include/bits/fp-logb.h /usr/include/bits/fp-fast.h \ /usr/include/bits/mathcalls-helper-functions.h \ /usr/include/bits/mathcalls.h /usr/include/complex.h \ /usr/include/bits/mathdef.h /usr/include/bits/cmathcalls.h [hjl@gnu-tgl-3 tmp]$ ls /usr/include/tgmath.h* /usr/include/tgmath.h.saved [hjl@gnu-tgl-3 tmp]$ clang -M -c f.c f.o: f.c /usr/bin/../lib/clang/19/include/tgmath.h /usr/include/math.h \ /usr/include/bits/libc-header-start.h /usr/include/features.h \ /usr/include/features-time64.h /usr/include/bits/wordsize.h \ /usr/include/bits/timesize.h /usr/include/stdc-predef.h \ /usr/include/sys/cdefs.h /usr/include/bits/long-double.h \ /usr/include/gnu/stubs.h /usr/include/gnu/stubs-64.h \ /usr/include/bits/types.h /usr/include/bits/typesizes.h \ /usr/include/bits/time64.h /usr/include/bits/math-vector.h \ /usr/include/bits/libm-simd-decl-stubs.h /usr/include/bits/floatn.h \ /usr/include/bits/floatn-common.h /usr/include/bits/flt-eval-method.h \ /usr/include/bits/fp-logb.h /usr/include/bits/fp-fast.h \ /usr/include/bits/mathcalls-helper-functions.h \ /usr/include/bits/mathcalls.h /usr/include/complex.h \ /usr/include/bits/mathdef.h /usr/include/bits/cmathcalls.h [hjl@gnu-tgl-3 tmp]$ ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
