[llvm-bugs] [Bug 119929] [C++][Modules] `-fmodule-output` does nothing
Issue 119929 Summary [C++][Modules] `-fmodule-output` does nothing Labels new issue Assignees Reporter davidstone Given some module in file a.cpp ``` export module b; ``` Compiling it with `clang++ -std=c++20 -x c++-module -fmodule-output=c.pcm --precompile a.cpp` I would expect to produce a file `c.pcm`. Instead it produces a file `a.pcm`. Am I misunderstanding the purpose of this option? The documentation states > `-fmodule-output=` > Save intermediate module file results when compiling a standard C++ module unit. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 119863] [mlir] -ownership-based-buffer-deallocation crashes
Issue
119863
Summary
[mlir] -ownership-based-buffer-deallocation crashes
Labels
mlir
Assignees
Reporter
wwy6191
git version: bc29fc937c6cb4a210f80c93c79fc6ed97c801f8
system: `Ubuntu 18.04.6 LTS`
reproduce with: `mlir-opt -ownership-based-buffer-deallocation a.mlir`
a.mlir:
```
func.func @simple_std_2_for(%arg0: f32) -> f32 {
cf.br ^bb1
^bb1:
%c = arith.constant 1: index
%c0 = arith.constant 0: index
%c1 = arith.constant 1: index
%c10 = arith.constant 10: index
%1 = scf.for %arg1 = %c0 to %c10 step %c1 iter_args(%arg2 = %arg0) -> f32 {
%2 = arith.addf %arg2, %arg2 : f32
scf.yield %2 : f32
}
cf.br ^bb2
^bb2:
return %1 : f32
}
```
stack trace:
```
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 -ownership-based-buffer-deallocation /data/szy/MLIR/seed/seed0/tmp.3DSEn0mx34.mlir
#0 0x555a76805348 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x111f348)
#1 0x555a76802e5e llvm::sys::RunSignalHandlers() (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x111ce5e)
#2 0x555a76805cdd SignalHandler(int) Signals.cpp:0:0
#3 0x7f33e62e8420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420)
#4 0x555a76d0c7c9 mlir::bufferization::DeallocationState::getMemrefsToRetain(mlir::Block*, mlir::Block*, mlir::ValueRange, llvm::SmallVectorImpl&) const (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x16267c9)
#5 0x555a76d9763a llvm::FailureOr (anonymous namespace)::BufferDeallocation::handleOp(mlir::Operation*) OwnershipBasedBufferDeallocation.cpp:0:0
#6 0x555a76d95977 mlir::WalkResult llvm::function_ref::callback_fn<(anonymous namespace)::BufferDeallocation::deallocate(mlir::FunctionOpInterface)::$_0>(long, mlir::Block*) OwnershipBasedBufferDeallocation.cpp:0:0
#7 0x555a76d93602 mlir::WalkResult mlir::detail::walk>(mlir::Operation*, llvm::function_ref, mlir::WalkOrder) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x16ad602)
#8 0x555a76d92691 mlir::bufferization::deallocateBuffersOwnershipBased(mlir::FunctionOpInterface, mlir::bufferization::DeallocationOptions) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x16ac691)
#9 0x555a76d9a851 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)::OwnershipBasedBufferDeallocationPass::runOnOperation()::'lambda'(mlir::func::FuncOp), mlir::func::FuncOp, mlir::WalkResult>(mlir::Operation*, (anonymous namespace)::OwnershipBasedBufferDeallocationPass::runOnOperation()::'lambda'(mlir::func::FuncOp)&&)::'lambda'(mlir::Operation*)>(long, mlir::Operation*) OwnershipBasedBufferDeallocation.cpp:0:0
#10 0x555a76931067 mlir::WalkResult mlir::detail::walk(mlir::Operation*, llvm::function_ref, mlir::WalkOrder) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x124b067)
#11 0x555a76d9a61b (anonymous namespace)::OwnershipBasedBufferDeallocationPass::runOnOperation() OwnershipBasedBufferDeallocation.cpp:0:0
#12 0x555a797103d6 mlir::detail::OpToOpPassAdaptor::run(mlir::Pass*, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x402a3d6)
#13 0x555a79710d00 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+0x402ad00)
#14 0x555a797132d2 mlir::PassManager::run(mlir::Operation*) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x402d2d2)
#15 0x555a7970ba4a performActions(llvm::raw_ostream&, std::shared_ptr const&, mlir::MLIRContext*, mlir::MlirOptMainConfig const&) MlirOptMain.cpp:0:0
#16 0x555a7970b69d llvm::LogicalResult llvm::function_ref>, llvm::raw_ostream&)>::callback_fn>, mlir::DialectRegistry&, mlir::MlirOptMainConfig const&)::$_0>(long, std::unique_ptr>, llvm::raw_ostream&) MlirOptMain.cpp:0:0
#17 0x555a797b7235 mlir::splitAndProcessBuffer(std::unique_ptr>, llvm::function_ref>, llvm::raw_ostream&)>, llvm::raw_ostream&, llvm::StringRef, llvm::StringRef) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x40d1235)
#18 0x555a79705685 mlir::MlirOptMain(llvm::raw_ostream&, std::unique_ptr>, mlir::DialectRegistry&, mlir::MlirOptMainConfig const&) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x401f685)
#19 0x555a7970592f m
[llvm-bugs] [Bug 119866] [mlir] -canonicalize crashes
Issue
119866
Summary
[mlir] -canonicalize crashes
Labels
mlir
Assignees
Reporter
wwy6191
git version: bc29fc937c6cb4a210f80c93c79fc6ed97c801f8
system: `Ubuntu 18.04.6 LTS`
reproduce with: `mlir-opt -canonicalize a.mlir`
a.mlir:
```
func.func @test_muli() -> (i32) {
%0 = "test.constant"() {value = 0x7fff} : () -> i32
%1 = "test.constant"() {value = -2147483648} : () -> i32
%2 = "test.constant"() {value = 0x8000} : () -> i32
%3 = "test.constant"() {value = 0x} : () -> i32
%4 = arith.muli %0, %1 : i32
%5 = arith.muli %4, %2 : i32
%6 = arith.muli %5, %3 : i32
return %6 : i32
}
```
stack trace:
```
:0: error: integer type bit width (32) 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 -canonicalize /data/szy/MLIR/seed/seed0/tmp.RHhs0ejHK5.mlir
#0 0x556334f26348 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x111f348)
#1 0x556334f23e5e llvm::sys::RunSignalHandlers() (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x111ce5e)
#2 0x556334f26cdd SignalHandler(int) Signals.cpp:0:0
#3 0x7f94d4d08420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420)
#4 0x7f94d434500b raise /build/glibc-LcI20x/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:51:1
#5 0x7f94d4324859 abort /build/glibc-LcI20x/glibc-2.31/stdlib/abort.c:81:7
#6 0x7f94d4324729 get_sysdep_segment_value /build/glibc-LcI20x/glibc-2.31/intl/loadmsgcat.c:509:8
#7 0x7f94d4324729 _nl_load_domain /build/glibc-LcI20x/glibc-2.31/intl/loadmsgcat.c:970:34
#8 0x7f94d4335fd6 (/lib/x86_64-linux-gnu/libc.so.6+0x33fd6)
#9 0x556337f19a91 (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x4112a91)
#10 0x556337f1990f mlir::IntegerAttr::get(mlir::Type, llvm::APInt const&) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x411290f)
#11 0x55633518d595 applyToIntegerAttrs(mlir::PatternRewriter&, mlir::Value, mlir::Attribute, mlir::Attribute, llvm::function_ref) ArithOps.cpp:0:0
#12 0x55633519480e (anonymous namespace)::MulIMulIConstant::matchAndRewrite(mlir::Operation*, mlir::PatternRewriter&) const ArithOps.cpp:0:0
#13 0x55633aef7591 void llvm::function_ref::callback_fn, llvm::function_ref, llvm::function_ref)::$_0>(long) PatternApplicator.cpp:0:0
#14 0x55633aef425b mlir::PatternApplicator::matchAndRewrite(mlir::Operation*, mlir::PatternRewriter&, llvm::function_ref, llvm::function_ref, llvm::function_ref) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x70ed25b)
#15 0x556337eaae7f (anonymous namespace)::GreedyPatternRewriteDriver::processWorklist() GreedyPatternRewriteDriver.cpp:0:0
#16 0x556337ea755f mlir::applyPatternsAndFoldGreedily(mlir::Region&, mlir::FrozenRewritePatternSet const&, mlir::GreedyRewriteConfig, bool*) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x40a055f)
#17 0x556337e4ebfb (anonymous namespace)::Canonicalizer::runOnOperation() Canonicalizer.cpp:0:0
#18 0x556337e313d6 mlir::detail::OpToOpPassAdaptor::run(mlir::Pass*, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x402a3d6)
#19 0x556337e31d00 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+0x402ad00)
#20 0x556337e342d2 mlir::PassManager::run(mlir::Operation*) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x402d2d2)
#21 0x556337e2ca4a performActions(llvm::raw_ostream&, std::shared_ptr const&, mlir::MLIRContext*, mlir::MlirOptMainConfig const&) MlirOptMain.cpp:0:0
#22 0x556337e2c69d llvm::LogicalResult llvm::function_ref>, llvm::raw_ostream&)>::callback_fn>, mlir::DialectRegistry&, mlir::MlirOptMainConfig const&)::$_0>(long, std::unique_ptr>, llvm::raw_ostream&) MlirOptMain.cpp:0:0
#23 0x556337ed8235 mlir::splitAndProcessBuffer(std::unique_ptr>, llvm::function_ref>, llvm:
[llvm-bugs] [Bug 119852] [mlir] Inconsistent output when executing MLIR program with `--linalg-fuse-elementwise-ops `
Issue
119852
Summary
[mlir] Inconsistent output when executing MLIR program with `--linalg-fuse-elementwise-ops `
Labels
mlir
Assignees
Reporter
Emilyaxe
git version: 953838dceaf
system: `Ubuntu 18.04.6 LTS`
## Description:
I am experiencing an inconsistent result when executing the same MLIR program with and without `--linalg-fuse-elementwise-ops `.
## Steps to Reproduce:
### 1. **MLIR Program (a.mlir)**:
a.mlir:
```
module {
func.func private @printMemrefI32(tensor<*xi32>)
func.func private @printMemrefF32(tensor<*xf32>)
func.func @main() {
%1 = "tosa.const"() <{value = dense<5319> : tensor<1x28x1xi32>}> : () -> tensor<1x28x1xi32>
%2 = "tosa.const"() <{value = dense<-5633> : tensor<1x28x1xi32>}> : () -> tensor<1x28x1xi32>
%8 = tosa.int_div %1, %2 : (tensor<1x28x1xi32>, tensor<1x28x1xi32>) -> tensor<1x28x1xi32>
%9 = tosa.clz %8 : (tensor<1x28x1xi32>) -> tensor<1x28x1xi32>
%12 = tosa.logical_left_shift %8, %9 : (tensor<1x28x1xi32>, tensor<1x28x1xi32>) -> tensor<1x28x1xi32>
%cast = tensor.cast %12 : tensor<1x28x1xi32> to tensor<*xi32>
call @printMemrefI32(%cast) : (tensor<*xi32>) -> ()
return
}
}
```
### 2. **Command to Run without `--linalg-fuse-elementwise-ops ` :**
```
/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt a.mlir -pass-pipeline="builtin.module(func.func(tosa-to-linalg-named,tosa-to-linalg))" | /data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt -tosa-to-arith -convert-linalg-to-loops -one-shot-bufferize="bufferize-function-boundaries" --expand-strided-metadata-convert-arith-to-llvm -test-math-polynomial-approximation -convert-arith-to-llvm -convert-math-to-llvm -convert-linalg-to-parallel-loops -finalize-memref-to-llvm -convert-scf-to-cf -convert-func-to-llvm -reconcile-unrealized-casts | timeout 10 /data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-cpu-runner -e main -entry-point-result=void --shared-libs=/data/szy/MLIR/llvm-release/llvm-project/build/lib/libmlir_c_runner_utils.so --shared-libs=/data/szy/MLIR/llvm-release/llvm-project/build/lib/libmlir_runner_utils.so --shared-libs=/data/szy/MLIR/llvm-release/llvm-project/build/lib/libmlir_async_runtime.so
```
### 3. **Output without `--linalg-fuse-elementwise-ops ` :**:
```
[[[0],
[0],
[0],
[0],
[0]]]
```
### 4. **Command to Run with `--linalg-fuse-elementwise-ops ` :**
```
/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt a.mlir -pass-pipeline="builtin.module(func.func(tosa-to-linalg-named,tosa-to-linalg))" | /data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt -tosa-to-arith --linalg-fuse-elementwise-ops -convert-linalg-to-loops -one-shot-bufferize="bufferize-function-boundaries" --expand-strided-metadata-convert-arith-to-llvm -test-math-polynomial-approximation -convert-arith-to-llvm -convert-math-to-llvm -convert-linalg-to-parallel-loops -finalize-memref-to-llvm -convert-scf-to-cf -convert-func-to-llvm -reconcile-unrealized-casts | timeout 10 /data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-cpu-runner -e main -entry-point-result=void --shared-libs=/data/szy/MLIR/llvm-release/llvm-project/build/lib/libmlir_c_runner_utils.so --shared-libs=/data/szy/MLIR/llvm-release/llvm-project/build/lib/libmlir_runner_utils.so --shared-libs=/data/szy/MLIR/llvm-release/llvm-project/build/lib/libmlir_async_runtime.so
```
### 5. **Output with `--linalg-fuse-elementwise-ops ` :**
```
[[[64],
[22050],
[1],
[0],
[0]]]
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 119853] [mlir] -arith-unsigned-when-equivalent crashes
Issue
119853
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 = 20 : ui64, smin = 20 : i64, smax = 30 : i64 } : 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.I3HZxNRNPo.mlir
#0 0x5569ec5bf348 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x111f348)
#1 0x5569ec5bce5e llvm::sys::RunSignalHandlers() (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x111ce5e)
#2 0x5569ec5bfcdd SignalHandler(int) Signals.cpp:0:0
#3 0x7f19eece8420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420)
#4 0x7f19ee32500b raise /build/glibc-LcI20x/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:51:1
#5 0x7f19ee304859 abort /build/glibc-LcI20x/glibc-2.31/stdlib/abort.c:81:7
#6 0x7f19ee304729 get_sysdep_segment_value /build/glibc-LcI20x/glibc-2.31/intl/loadmsgcat.c:509:8
#7 0x7f19ee304729 _nl_load_domain /build/glibc-LcI20x/glibc-2.31/intl/loadmsgcat.c:970:34
#8 0x7f19ee315fd6 (/lib/x86_64-linux-gnu/libc.so.6+0x33fd6)
#9 0x5569ef5b2a91 (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x4112a91)
#10 0x5569ef5b290f mlir::IntegerAttr::get(mlir::Type, llvm::APInt const&) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x411290f)
#11 0x5569ef4b3a5e mlir::dataflow::IntegerValueRangeLattice::onUpdate(mlir::DataFlowSolver*) const (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x4013a5e)
#12 0x5569ef4b5945 void llvm::function_ref::callback_fn, llvm::ArrayRef)::$_1>(long, mlir::Value, mlir::IntegerValueRange const&) IntegerRangeAnalysis.cpp:0:0
#13 0x5569f26321cc void llvm::function_ref::callback_fn, llvm::function_ref)::$_0>(long, mlir::Value, mlir::ConstantIntRanges const&) InferIntRangeInterface.cpp:0:0
#14 0x5569ec8b15e3 mlir::arith::ShLIOp::inferResultRanges(llvm::ArrayRef, llvm::function_ref) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x14115e3)
#15 0x5569ec89b921 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+0x13fb921)
#16 0x5569f2631d76 mlir::intrange::detail::defaultInferResultRanges(mlir::InferIntRangeInterface, llvm::ArrayRef, llvm::function_ref) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x7191d76)
#17 0x5569ef4b3fec mlir::dataflow::IntegerRangeAnalysis::visitOperation(mlir::Operation*, llvm::ArrayRef, llvm::ArrayRef) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x4013fec)
#18 0x5569ef4b7309 mlir::dataflow::AbstractSparseForwardDataFlowAnalysis::visitOperation(mlir::Operation*) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x4017309)
#19 0x5569ef4b69a9 mlir::dataflow::AbstractSparseForwardDataFlowAnalysis::initializeRecursively(mlir::Operation*) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x40169a9)
#20 0x5569ef4b6c5d mlir::dataflow::AbstractSparseForwardDataFlowAnalysis::initializeRecursively(mlir::Operation*) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x4016c5d)
#21 0x5569ef4b6c5d mlir::dataflow::AbstractSparseForwardDataFlowAnalysis::initializeRecursively(mlir::Operation*) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x4016c5d)
#22 0x5569ef4947be mlir::DataFlowSolver::initializeAndRun(mlir::Operation*) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x3ff47be)
#23 0x55
[llvm-bugs] [Bug 119857] [mlir] -sparsification-and-bufferization crashes
Issue
119857
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:
```
func.func @fuse_by_collapsing_dynamic_pad(%arg0 : tensor,
%s0 : index, %s1 : index, %s2 : index, %s3 : index, %s4 : index, %s5 : index,
%l0 : index, %l1 : index, %h0 : index, %h1 : index) -> tensor {
%expand = tensor.expand_shape %arg0 [[0], [1, 2], [3], [4, 5]] output_shape [%s0, %s1, %s2, %s3, %s4, %s5] : tensor into tensor
%cst = arith.constant 0.0 : f32
%padded_0 = tensor.pad %expand low[%l0, 0, 0, %l1, 0, 0] high[%h0, 0, 0, %h1, 0, 0] {
^bb0(%arg1: index, %arg2: index, %arg3: index, %arg4: index, %arg5: index, %arg6: index):
tensor.yield %cst : f32
} : tensor to tensor
return %padded_0 : tensor
}
```
stack trace:
```
mlir-opt: /data/szy/MLIR/llvm-release/llvm-project/mlir/lib/Dialect/MemRef/IR/MemRefOps.cpp:2317: 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/seed726/tmp.EwRBQX9VqT.mlir
#0 0x55ba543e9348 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x111f348)
#1 0x55ba543e6e5e llvm::sys::RunSignalHandlers() (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x111ce5e)
#2 0x55ba543e9cdd SignalHandler(int) Signals.cpp:0:0
#3 0x7f3ab15e9420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420)
#4 0x7f3ab0c2600b raise /build/glibc-LcI20x/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:51:1
#5 0x7f3ab0c05859 abort /build/glibc-LcI20x/glibc-2.31/stdlib/abort.c:81:7
#6 0x7f3ab0c05729 get_sysdep_segment_value /build/glibc-LcI20x/glibc-2.31/intl/loadmsgcat.c:509:8
#7 0x7f3ab0c05729 _nl_load_domain /build/glibc-LcI20x/glibc-2.31/intl/loadmsgcat.c:970:34
#8 0x7f3ab0c16fd6 (/lib/x86_64-linux-gnu/libc.so.6+0x33fd6)
#9 0x55ba55c37a71 (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x296da71)
#10 0x55ba568fff8b 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+0x3635f8b)
#11 0x55ba568ff70a 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 0x55ba54936990 mlir::bufferization::bufferizeOp(mlir::Operation*, mlir::bufferization::BufferizationOptions const&, mlir::bufferization::BufferizationStatistics*) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x166c990)
#13 0x55ba54970ec4 mlir::bufferization::bufferizeModuleOp(mlir::ModuleOp, mlir::bufferization::OneShotBufferizationOptions const&, mlir::bufferization::BufferizationStatistics*) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x16a6ec4)
#14 0x55ba563d3d68 mlir::sparse_tensor::SparsificationAndBufferizationPass::runDenseBufferization() (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x3109d68)
#15 0x55ba563d38bc mlir::sparse_tensor::SparsificationAndBufferizationPass::runOnOperation() (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x31098bc)
#16 0x55ba572f43d6 mlir::detail::OpToOpPassAdaptor::run(mlir::Pass*, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x402a3d6)
#17 0x55ba572f4d00 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+0x402ad00)
#18 0x55ba572f72d2 mlir::PassManager::run(mlir::Operation*) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x402d2d2)
#19 0x55ba572efa4a performActions(llvm::raw_ostream&, std::shared_ptr const&, mlir::MLIRContext*, mlir::MlirOptMainConfig const&) MlirOptMain.cpp:0:0
#20 0x55ba572ef69d llvm::LogicalResult llvm::function_ref>, llvm::raw_ostream&)>::callbac
[llvm-bugs] [Bug 119849] [x86][CF]Unable to obtain the correct CF flag bit
Issue
119849
Summary
[x86][CF]Unable to obtain the correct CF flag bit
Labels
new issue
Assignees
Reporter
zhaojiangkun-1
Retrieve the CF register flag bit through __readeflags() and verify if the parameters are equal.
Clang generates the 'and' instruction after compilation, and clears the CF flag after executing the 'and' instruction. Is this a bug or is it for some purpose? Resulting in the inability to obtain correct results through __readeflags().
https://godbolt.org/z/4oaWeKxY1
**How did I do it**
1）`clang -g test.c -o -test`
2）`cgdb test`
3) run to ` flags = readeflags_test (100, 101)` and debug in assembly
**the debug result**
**test script:**
```#include
extern void abort (void);
#ifdef __x86_64__
#define EFLAGS_TYPE unsigned long long int
#else
#define EFLAGS_TYPE unsigned int
#endif
EFLAGS_TYPE
readeflags_test (unsigned int a, unsigned int b)
{
volatile char x = (a == b);
return __readeflags ();
}
int
main ()
{
EFLAGS_TYPE flags;
flags = readeflags_test (100, 100);
if ((flags & 1) != 0) /* Read CF */
abort ();
flags = readeflags_test (100, 101);
flags = readeflags_test(101, 100);//新增测试用例，用于验证比较对CF的影响
if ((flags & 1) == 0) /* Read CF */
abort ();
#ifdef DEBUG
printf ("PASSED\n");
#endif
return 0;
}
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 119854] [Mlir][TOSA] Execution crash in mlir-cpu-runner
Issue
119854
Summary
[Mlir][TOSA] Execution crash in mlir-cpu-runner
Labels
mlir
Assignees
Reporter
Emilyaxe
git version: 953838dceaf
system: `Ubuntu 18.04.6 LTS`
reproduce with: `/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt a.mlir -one-shot-bufferize="bufferize-function-boundaries" -convert-func-to-llvm -reconcile-unrealized-casts | timeout 10 /data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-cpu-runner -e main -entry-point-result=void --shared-libs=/data/szy/MLIR/llvm-release/llvm-project/build/lib/libmlir_c_runner_utils.so --shared-libs=/data/szy/MLIR/llvm-release/llvm-project/build/lib/libmlir_runner_utils.so --shared-libs=/data/szy/MLIR/llvm-release/llvm-project/build/lib/libmlir_async_runtime.so`
a.mlir:
```
module {
func.func @main(%arg0: tensor<1x6x6xi32>) {
return
}
}
```
When executing mlir-cpu-runner, this crash occurs when the entry function requires arguments, but the command does not provide them.
stack trace:
```
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-cpu-runner -e main -entry-point-result=void --shared-libs=/data/szy/MLIR/llvm-release/llvm-project/build/lib/libmlir_c_runner_utils.so --shared-libs=/data/szy/MLIR/llvm-release/llvm-project/build/lib/libmlir_runner_utils.so --shared-libs=/data/szy/MLIR/llvm-release/llvm-project/build/lib/libmlir_async_runtime.so
#0 0x55857775e048 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-cpu-runner+0xdb6048)
#1 0x55857775bb5e llvm::sys::RunSignalHandlers() (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-cpu-runner+0xdb3b5e)
#2 0x55857775e99d SignalHandler(int) Signals.cpp:0:0
#3 0x7f6a46e2c420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420)
#4 0x7f6a46e8601b
#5 0x558577caf376 compileAndExecute((anonymous namespace)::Options&, mlir::Operation*, llvm::StringRef, (anonymous namespace)::CompileAndExecuteConfig, void**, std::unique_ptr>) JitRunner.cpp:0:0
#6 0x558577cac9e2 compileAndExecuteVoidFunction((anonymous namespace)::Options&, mlir::Operation*, llvm::StringRef, (anonymous namespace)::CompileAndExecuteConfig, std::unique_ptr>) JitRunner.cpp:0:0
#7 0x558577caacea mlir::JitRunnerMain(int, char**, mlir::DialectRegistry const&, mlir::JitRunnerConfig) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-cpu-runner+0x1302cea)
#8 0x558577527827 main (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-cpu-runner+0xb7f827)
#9 0x7f6a4644a083 __libc_start_main /build/glibc-LcI20x/glibc-2.31/csu/../csu/libc-start.c:342:3
#10 0x55857752744e _start (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-cpu-runner+0xb7f44e)
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 119855] [mlir] -nvgpu-optimize-shared-memory crashes
Issue
119855
Summary
[mlir] -nvgpu-optimize-shared-memory crashes
Labels
mlir
Assignees
Reporter
wwy6191
git version: bc29fc937c6cb4a210f80c93c79fc6ed97c801f8
system: `Ubuntu 18.04.6 LTS`
reproduce with: `mlir-opt -nvgpu-optimize-shared-memory a.mlir`
a.mlir:
```
func.func @variable_ptr_array_physical_result_unranked() -> memref> {
%0 = memref.alloc() : memref>
return %0 : memref>
}
```
stack trace:
```
mlir-opt: /data/szy/MLIR/llvm-release/llvm-project/build/tools/mlir/include/mlir/IR/BuiltinTypeInterfaces.h.inc:268: int64_t mlir::detail::ShapedTypeTrait::getDimSize(unsigned int) const [ConcreteType = mlir::MemRefType]: Assertion `idx < getRank() && "invalid index for shaped 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: /data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt -nvgpu-optimize-shared-memory /data/szy/MLIR/seed/seed0/tmp.3t229g3cRm.mlir
#0 0x558b2421f348 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x111f348)
#1 0x558b2421ce5e llvm::sys::RunSignalHandlers() (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x111ce5e)
#2 0x558b2421fcdd SignalHandler(int) Signals.cpp:0:0
#3 0x7fe7e9eb1420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420)
#4 0x7fe7e94ee00b raise /build/glibc-LcI20x/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:51:1
#5 0x7fe7e94cd859 abort /build/glibc-LcI20x/glibc-2.31/stdlib/abort.c:81:7
#6 0x7fe7e94cd729 get_sysdep_segment_value /build/glibc-LcI20x/glibc-2.31/intl/loadmsgcat.c:509:8
#7 0x7fe7e94cd729 _nl_load_domain /build/glibc-LcI20x/glibc-2.31/intl/loadmsgcat.c:970:34
#8 0x7fe7e94defd6 (/lib/x86_64-linux-gnu/libc.so.6+0x33fd6)
#9 0x558b25c610ed mlir::nvgpu::optimizeSharedMemoryReadsAndWrites(mlir::Operation*, mlir::Value) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x2b610ed)
#10 0x558b25c629b7 (anonymous namespace)::OptimizeSharedMemoryPass::runOnOperation() OptimizeSharedMemory.cpp:0:0
#11 0x558b2712a3d6 mlir::detail::OpToOpPassAdaptor::run(mlir::Pass*, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x402a3d6)
#12 0x558b2712ad00 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+0x402ad00)
#13 0x558b2712d2d2 mlir::PassManager::run(mlir::Operation*) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x402d2d2)
#14 0x558b27125a4a performActions(llvm::raw_ostream&, std::shared_ptr const&, mlir::MLIRContext*, mlir::MlirOptMainConfig const&) MlirOptMain.cpp:0:0
#15 0x558b2712569d llvm::LogicalResult llvm::function_ref>, llvm::raw_ostream&)>::callback_fn>, mlir::DialectRegistry&, mlir::MlirOptMainConfig const&)::$_0>(long, std::unique_ptr>, llvm::raw_ostream&) MlirOptMain.cpp:0:0
#16 0x558b271d1235 mlir::splitAndProcessBuffer(std::unique_ptr>, llvm::function_ref>, llvm::raw_ostream&)>, llvm::raw_ostream&, llvm::StringRef, llvm::StringRef) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x40d1235)
#17 0x558b2711f685 mlir::MlirOptMain(llvm::raw_ostream&, std::unique_ptr>, mlir::DialectRegistry&, mlir::MlirOptMainConfig const&) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x401f685)
#18 0x558b2711f92f mlir::MlirOptMain(int, char**, llvm::StringRef, llvm::StringRef, mlir::DialectRegistry&) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x401f92f)
#19 0x558b2711fc5e mlir::MlirOptMain(int, char**, llvm::StringRef, mlir::DialectRegistry&) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x401fc5e)
#20 0x558b241ffe37 main (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x10ffe37)
#21 0x7fe7e94cf083 __libc_start_main /build/glibc-LcI20x/glibc-2.31/csu/../csu/libc-start.c:342:3
#22 0x558b241ff9ae _start (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x10ff9ae)
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 119856] [mlir] -finalize-memref-to-llvm crashes
Issue
119856
Summary
[mlir] -finalize-memref-to-llvm crashes
Labels
mlir
Assignees
Reporter
wwy6191
git version: bc29fc937c6cb4a210f80c93c79fc6ed97c801f8
system: `Ubuntu 18.04.6 LTS`
reproduce with: `mlir-opt -finalize-memref-to-llvm a.mlir`
a.mlir:
```
#map = affine_map<(d0) -> (d0 + 1)>
module {
llvm.func @malloc(%arg0: i64) ->!llvm.struct<(ptr, ptr, i64)> {
%alloc = memref.alloc() : memref<1024x64xf32>
%0 = builtin.unrealized_conversion_cast %alloc : memref<1024x64xf32> to!llvm.struct<(ptr, ptr, i64)>
llvm.return %0 :!llvm.struct<(ptr, ptr, i64)>
}
}
```
stack trace:
```
mlir-opt: /data/szy/MLIR/llvm-release/llvm-project/llvm/include/llvm/Support/Casting.h:566: decltype(auto) llvm::cast(const From &) [To = mlir::LLVM::LLVMPointerType, From = mlir::Type]: 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: /data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt -finalize-memref-to-llvm /data/szy/MLIR/seed/seed0/tmp.1XEffPECLs.mlir
#0 0x55f80c4e5348 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x111f348)
#1 0x55f80c4e2e5e llvm::sys::RunSignalHandlers() (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x111ce5e)
#2 0x55f80c4e5cdd SignalHandler(int) Signals.cpp:0:0
#3 0x7f65c64bb420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420)
#4 0x7f65c5af800b raise /build/glibc-LcI20x/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:51:1
#5 0x7f65c5ad7859 abort /build/glibc-LcI20x/glibc-2.31/stdlib/abort.c:81:7
#6 0x7f65c5ad7729 get_sysdep_segment_value /build/glibc-LcI20x/glibc-2.31/intl/loadmsgcat.c:509:8
#7 0x7f65c5ad7729 _nl_load_domain /build/glibc-LcI20x/glibc-2.31/intl/loadmsgcat.c:970:34
#8 0x7f65c5ae8fd6 (/lib/x86_64-linux-gnu/libc.so.6+0x33fd6)
#9 0x55f80f1492c0 castAllocFuncResult(mlir::ConversionPatternRewriter&, mlir::Location, mlir::Value, mlir::MemRefType, mlir::Type, mlir::LLVMTypeConverter const&) AllocLikeConversion.cpp:0:0
#10 0x55f80f149081 mlir::AllocationOpLLVMLowering::allocateBufferManuallyAlign(mlir::ConversionPatternRewriter&, mlir::Location, mlir::Value, mlir::Operation*, mlir::Value) const (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x3d83081)
#11 0x55f80f14896d (anonymous namespace)::AllocOpLowering::allocateBuffer(mlir::ConversionPatternRewriter&, mlir::Location, mlir::Value, mlir::Operation*) const MemRefToLLVM.cpp:0:0
#12 0x55f80f149a40 mlir::AllocLikeOpLLVMLowering::matchAndRewrite(mlir::Operation*, llvm::ArrayRef, mlir::ConversionPatternRewriter&) const (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x3d83a40)
#13 0x55f80c7e2124 mlir::ConversionPattern::matchAndRewrite(mlir::Operation*, llvm::ArrayRef, mlir::ConversionPatternRewriter&) const (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x141c124)
#14 0x55f80f44d644 mlir::ConversionPattern::matchAndRewrite(mlir::Operation*, mlir::PatternRewriter&) const (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x4087644)
#15 0x55f8124b6591 void llvm::function_ref::callback_fn, llvm::function_ref, llvm::function_ref)::$_0>(long) PatternApplicator.cpp:0:0
#16 0x55f8124b325b mlir::PatternApplicator::matchAndRewrite(mlir::Operation*, mlir::PatternRewriter&, llvm::function_ref, llvm::function_ref, llvm::function_ref) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x70ed25b)
#17 0x55f80f44e713 (anonymous namespace)::OperationLegalizer::legalize(mlir::Operation*, mlir::ConversionPatternRewriter&) DialectConversion.cpp:0:0
#18 0x55f80f44d767 mlir::OperationConverter::convert(mlir::ConversionPatternRewriter&, mlir::Operation*) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x4087767)
#19 0x55f80f44e93f mlir::OperationConverter::convertOperations(llvm::ArrayRef) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x408893f)
#20 0x55f80f454afb mlir::applyPartialConversion(mlir::Operation*, mlir::ConversionTarget const&, mlir::FrozenRewritePatternSet const&, mlir::ConversionConfig) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x408eafb)
#21 0x55f80f12e2db (anonymous namespace)::FinalizeMemRefToLLVMConversionPass::runOnOperation() MemRefToLLVM.cpp:0:0
#22 0x55f80f3f03d6 mlir::detail::OpToOpPassAdaptor::run(mlir::Pass*, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x402a3d6)
#23 0x55f80f3f0d00 mlir::detail::OpToOpPassAdaptor::runPipeline(mlir::OpPassManager&, mlir:
[llvm-bugs] [Bug 119836] [MLIR] Inconsistent output when executing MLIR program with and without `-test-expand-math`
Issue
119836
Summary
[MLIR] Inconsistent output when executing MLIR program with and without `-test-expand-math`
Labels
mlir
Assignees
Reporter
Lambor24
My git version is [ea44647](https://github.com/llvm/llvm-project/commit/ea44647a0b49de826191eeb6e05020262b5a81e9).
## Description:
I am experiencing an inconsistent result when executing the same MLIR program with and without the `-test-expand-math`.
## Steps to Reproduce:
### 1. **MLIR Program (test.mlir)**:
test.mlir:
```
module {
func.func private @printMemrefF32(tensor<*xf32>)
func.func @main() -> () {
%arg0 = "tosa.const"() {value = dense<9.5> : tensor<10x20xf32>} : () -> tensor<10x20xf32>
%0 = tosa.reduce_prod %arg0 {axis = 1 : i32} : (tensor<10x20xf32>) -> tensor<10x1xf32>
%1 = tosa.floor %0 : (tensor<10x1xf32>) -> tensor<10x1xf32>
%rtn1 = tensor.cast %1 : tensor<10x1xf32> to tensor<*xf32>
call @printMemrefF32(%rtn1) : (tensor<*xf32>) -> ()
return
}
}
```
### 2. **Command to Run Without `-test-expand-math`:**
```
/path/llvm-project/build/bin/mlir-opt test.mlir -pass-pipeline='builtin.module(func.func(tosa-to-linalg))' | \
/path/llvm-project/build/bin/mlir-opt -tosa-to-arith -one-shot-bufferize="bufferize-function-boundaries" -convert-linalg-to-loops -convert-scf-to-cf -expand-strided-metadata -convert-cf-to-llvm -convert-arith-to-llvm -convert-math-to-llvm -finalize-memref-to-llvm -convert-func-to-llvm -reconcile-unrealized-casts | \
/path/llvm-project/build/bin/mlir-cpu-runner -e main -entry-point-result=void \
-shared-libs=/path/llvm-project/build/lib/libmlir_runner_utils.so \
-shared-libs=/path/llvm-project/build/lib/libmlir_c_runner_utils.so \
-shared-libs=/path/llvm-project/build/lib/libmlir_async_runtime.so
```
### 3. **Output Without `-test-expand-math`:**
```
[[3.58486e+19],
[3.58486e+19],
[3.58486e+19],
[3.58486e+19],
[3.58486e+19],
[3.58486e+19],
[3.58486e+19],
[3.58486e+19],
[3.58486e+19],
[3.58486e+19]]
```
### 4. **Command to Run With `-test-expand-math`:**
```
/path/llvm-project/build/bin/mlir-opt test.mlir -pass-pipeline='builtin.module(func.func(tosa-to-linalg))' | \
/path/llvm-project/build/bin/mlir-opt -tosa-to-arith -one-shot-bufferize="bufferize-function-boundaries" -convert-linalg-to-loops -test-expand-math -convert-scf-to-cf -expand-strided-metadata -convert-cf-to-llvm -convert-arith-to-llvm -convert-math-to-llvm -finalize-memref-to-llvm -convert-func-to-llvm -reconcile-unrealized-casts | \
/path/llvm-project/build/bin/mlir-cpu-runner -e main -entry-point-result=void \
-shared-libs=/path/llvm-project/build/lib/libmlir_runner_utils.so \
-shared-libs=/path/llvm-project/build/lib/libmlir_c_runner_utils.so \
-shared-libs=/path/llvm-project/build/lib/libmlir_async_runtime.so
```
### 5. **Output With `-test-expand-math`:**
```
[[9.22337e+18],
[9.22337e+18],
[9.22337e+18],
[9.22337e+18],
[9.22337e+18],
[9.22337e+18],
[9.22337e+18],
[9.22337e+18],
[9.22337e+18],
[9.22337e+18]]
```
I'm not sure if there is any bug in my program or if the wrong usage of the above passes caused this result.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 119921] [AArch64] Failure to combine bitwise not of shift into `mvn`
Issue 119921 Summary [AArch64] Failure to combine bitwise not of shift into `mvn` Labels backend:AArch64, missed-optimization Assignees Reporter Kmeakin https://godbolt.org/z/7sKhdbr4E The `mvn` (move-not) instruction produces the bitwise not of a shifted/rotated register. GCC recognizes this pattern and produces `mvn`, but clang does not clang: ```asm mvn_lsl_1_u8(unsigned char): mov w8, #-1 eor w0, w8, w0, lsl #1 ret mvn_lsl_1_u16(unsigned short): mov w8, #-1 eor w0, w8, w0, lsl #1 ret mvn_lsl_1_u32(unsigned int): mov w8, #-1 eor w0, w8, w0, lsl #1 ret mvn_lsl_1_u64(unsigned long): mov x8, #-1 eor x0, x8, x0, lsl #1 ret ``` GCC: ```asm mvn_lsl_1_u8(unsigned char): mvn w0, w0, lsl 1 ret mvn_lsl_1_u16(unsigned short): mvn w0, w0, lsl 1 ret mvn_lsl_1_u32(unsigned int): mvn w0, w0, lsl 1 ret mvn_lsl_1_u64(unsigned long): mvn x0, x0, lsl 1 ret ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 119917] clang 20 + enzymeAd crashed while clang 19 works fine
Issue 119917 Summary clang 20 + enzymeAd crashed while clang 19 works fine Labels clang Assignees Reporter minansys I use the clang 20 + enzymeAd to differentiate the C++ code automatically. It works fine with Clang 19 but crashed with Clang 20 with the following msg: clang++: /home/mixu/software/llvm-project/llvm/lib/IR/Instruction.cpp:153: void llvm::Instruction::insertBefore(llvm::BasicBlock&, llvm::iplist_impl, llvm::ilist_parent >, llvm::SymbolTableListTraits, llvm::ilist_parent > >::iterator): Assertion `!isa(this) && "Inserting PHI after debug-records!"' failed. PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script. Stack dump: 0. Program arguments: /home/mixu/software/llvm-project/build/bin/clang++ -DBOOST_ALL_NO_LIB -DBOOST_NO_AUTO_PTR -DCromwell_CommonModel_EXPORTS -DFLUID_ENABLE_PARALLEL -DFLUID_MULTIPORT_AVAILABLE -DFLUID_USE_ADJOINT -DFLUID_USE_DVS_WRITER -DFLUID_USE_METIS -DFLUID_USE_METIS_V3 -DFLUID_USE_SUNDIALS_SOLVER -DREAL_IS_DOUBLE -D_CommonModelApi -I/mnt/d/dev/v201/Cromwell/Build_3ddp_debug_cpu/generated -I/mnt/d/dev/v201/Cromwell/Dependencies/../../FBU_Dependencies/thirdparty/compilers/gcc/linx64/include/c++/8.2.0 -I/mnt/d/dev/v201/Cromwell/Dependencies/../../FBU_Dependencies/thirdparty/compilers/gcc/linx64/include/c++/8.2.0/x86_64-pc-linux-gnu -I/mnt/d/dev/v201/Cromwell/Dependencies/magma/include -D_GLIBCXX_USE_CXX11_ABI=0 -g -fPIC -stdlib=libstdc++ -Wno-deprecated-builtins -fopenmp -std=gnu++17 -w -Wno-missing-template-arg-list-after-template-kw -fplugin=/home/mixu/software/Enzyme/enzyme/build-20/Enzyme/ClangEnzyme-20.so -mllvm -enzyme-loose-types=1 -o CMakeFiles/Cromwell.CommonModel.dir/src/Operators/CellFieldMinMax.cxx.o -c /mnt/d/dev/v201/Cromwell/Cromwell/CFD/CommonModel/src/Operators/CellFieldMinMax.cxx 1. parser at end of file 2. Optimizer 3. Running pass "EnzymeNewPM" on module "/mnt/d/dev/v201/Cromwell/Cromwell/CFD/CommonModel/src/Operators/CellFieldMinMax.cxx" #0 0x562904d573cf llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/home/mixu/software/llvm-project/build/bin/clang+++0x43063cf) #1 0x562904d550fc llvm::sys::CleanupOnSignal(unsigned long) (/home/mixu/software/llvm-project/build/bin/clang+++0x43040fc) #2 0x562904c9ef18 CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0 #3 0x7fc1771ea420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420) #4 0x7fc176a0e00b raise /build/glibc-LcI20x/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:51:1 #5 0x7fc1769ed859 abort /build/glibc-LcI20x/glibc-2.31/stdlib/abort.c:81:7 #6 0x7fc1769ed729 get_sysdep_segment_value /build/glibc-LcI20x/glibc-2.31/intl/loadmsgcat.c:509:8 #7 0x7fc1769ed729 _nl_load_domain /build/glibc-LcI20x/glibc-2.31/intl/loadmsgcat.c:970:34 #8 0x7fc1769fefd6 (/lib/x86_64-linux-gnu/libc.so.6+0x33fd6) #9 0x5629046a13e7 (/home/mixu/software/llvm-project/build/bin/clang+++0x3c503e7) #10 0x5629046a141b llvm::Instruction::insertInto(llvm::BasicBlock*, llvm::ilist_iterator_w_bits, false, false>) (/home/mixu/software/llvm-project/build/bin/clang+++0x3c5041b) #11 0x56290468fb97 llvm::IRBuilderDefaultInserter::InsertHelper(llvm::Instruction*, llvm::Twine const&, llvm::ilist_iterator_w_bits, false, false>) const (/home/mixu/software/llvm-project/build/bin/clang+++0x3c3eb97) #12 0x7fc175ecd4bf llvm::PHINode* llvm::IRBuilderBase::Insert(llvm::PHINode*, llvm::Twine const&) const (/home/mixu/software/Enzyme/enzyme/build-20/Enzyme/ClangEnzyme-20.so+0x85f4bf) #13 0x7fc175ecb18b llvm::IRBuilderBase::CreatePHI(llvm::Type*, unsigned int, llvm::Twine const&) (/home/mixu/software/Enzyme/enzyme/build-20/Enzyme/ClangEnzyme-20.so+0x85d18b) #14 0x7fc1764678bc GradientUtils::fixLCSSA(llvm::Instruction*, llvm::BasicBlock*, bool) (/home/mixu/software/Enzyme/enzyme/build-20/Enzyme/ClangEnzyme-20.so+0xdf98bc) #15 0x7fc176488dcc GradientUtils::lookupM(llvm::Value*, llvm::IRBuilder&, llvm::ValueMap>> const&, bool, llvm::BasicBlock*) (/home/mixu/software/Enzyme/enzyme/build-20/Enzyme/ClangEnzyme-20.so+0xe1adcc) #16 0x7fc17645a5d0 GradientUtils::unwrapM(llvm::Value*, llvm::IRBuilder&, llvm::ValueMap>> const&, UnwrapMode, llvm::BasicBlock*, bool) (/home/mixu/software/Enzyme/enzyme/build-20/Enzyme/ClangEnzyme-20.so+0xdec5d0) #17 0x7fc176489377 GradientUtils::lookupM(llvm::Value*, llvm::IRBuilder&, llvm::ValueMap>> const&, bool, llvm::BasicBlock*) (/home/mixu/software/Enzyme/enzyme/build-20/Enzyme/ClangEnzyme-20.so+0xe1b377) #18 0x7fc176092561 AdjointGenerator::lookup(llvm::Value*, llvm::IRBuilder&) (/home/mixu/sof
[llvm-bugs] [Bug 119928] `DiagRuntimeBehavior` (and presumably the CFG in general) incorrectly determines reachability in the presence of `__builtin_is_constant_evaluated`
Issue
119928
Summary
`DiagRuntimeBehavior` (and presumably the CFG in general) incorrectly determines reachability in the presence of `__builtin_is_constant_evaluated`
Labels
new issue
Assignees
Reporter
zygoloid
[Testcase](https://godbolt.org/z/Wbf8zYfh6):
```c++
void f(int k) {
// No UB. But warns about UB.
const int m = __builtin_is_constant_evaluated() ? 0 : *(int*)0;
}
void g(int k) {
// Has UB. But does not warn about UB.
const int m = __builtin_is_constant_evaluated() ? k : *(int*)0;
}
```
Presumably we get `f` wrong because the CFG builder evaluates `__builtin_is_constant_evaluated()` to `false` when building a CFG for the conditional _expression_. But I'm unsure why we get `g` wrong too.
Perhaps the CFG builder could track whether it's within a manifestly constant evaluated context, and pass that information into the constant evaluator. However, with the likely upcoming changes [adding reflection to C++](http://wg21.link/P2996), there'll be other ways in which constant evaluation becomes context-dependent, so this might not be a particularly good solution in the longer term.
Another possible option would be to make the CFG builder entirely skip constant expressions, and instead just use the already-known constant values from them. The C++ language rules already require UB checking within constant expressions, so most additional CFG-based checks are likely to be redundant (though not all of them).
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 119953] Clang compiles an invalid program normally
Issue
119953
Summary
Clang compiles an invalid program normally
Labels
clang
Assignees
Reporter
ZY546
https://godbolt.org/z/jETK87bq7
```c
int func_2(); //note: previous declaration of 'func_2' with type 'int(void)'
int func_1() { return func_2();}
int func_2(int a) { //error: conflicting types for 'func_2'; have 'int(int)'
return 8;
}
int main() {
return func_1();
}
```
Clang compiles the program normally, and the resulting program can be executed.
Expected behavior (like gcc):
```
Could not execute the program
Build failed
Compiler returned: 1
Compiler stderr
:4:5: error: conflicting types for 'func_2'; have 'int(int)'
4 | int func_2(int a) {
| ^~
:2:5: note: previous declaration of 'func_2' with type 'int(void)'
2 | int func_2();
| ^~
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 119952] llvm-cov: Branches cannot be seen on macro definitions in source view
Issue 119952 Summary llvm-cov: Branches cannot be seen on macro definitions in source view Labels tools:llvm-cov Assignees Reporter chapuni If a macro definition has branches (`&&` `||` `?:`), they cannot be seen in source view. They can be seen in expanded subviews if expansion is enabled. They causes hidden counts between the summary and the source view. (See also #119282) This has been there since the introduction of branch coverage. https://reviews.llvm.org/D84467 https://github.com/llvm/llvm-project/commit/9f2967bcfe2f7d1fc02281f0098306c90c2c10a5#diff-44b7cba1a9d87f9ec9e067d93ea9d29ea4d9c669942d73f89233e39e28f9a5f0R680-R683 in `CoverageMapping::getCoverageForFile(StringRef Filename)`: ```C++ // Capture branch regions specific to the function (excluding expansions). for (const auto &CR : Function.CountedBranchRegions) if (FileIDs.test(CR.FileID) && (CR.FileID == CR.ExpandedFileID)) FileCoverage.BranchRegions.push_back(CR); ``` I don't understand the intent. `CountedBranchRegions` doesn't have any `Expansion`s. `CR.ExpandedFileID` will be always zero. As the result, it is handled as if `CR.FileID == 0`. This prevents branches to be seen outside the function. (Expansion subview can show them since it uses `getCoverageForFunction()`) I think it'd make sense to show branches on macro defs in the source view, to prune 2nd condition `(CR.FileID == CR.ExpandedFileID)`. What do you think, @evodius96 ? ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 119880] [flang] Incorrect debug locations in lowering of literal argument allocas
Issue
119880
Summary
[flang] Incorrect debug locations in lowering of literal argument allocas
Labels
flang:ir,
flang
Assignees
Reporter
inaki-amatria
- `flang` version is: `flang version 20.0.0 (https://github.com/llvm/llvm-project.git 88c18da37dfb10d570414bcb92ad075241f1b7c3)`
- Reduced test case:
```f90
subroutine foo(x)
x = y(1)
end
```
- `flang` invocation is: `flang -O0 -g -S -emit-llvm foo.f90`
- Expected behavior is: Flang assigns debug locations that accurately reflect the source-level expressions.
- Actual behavior: Flang generates incorrect and ambiguous debug locations during lowering for fictional allocas created to represent literal expressions passed as arguments in function calls. This leads to multiple unrelated instructions sharing the same debug location, causing ambiguity in debug information.
```llvm
define void @foo_(ptr %0) #0 !dbg !6 {
%2 = alloca i32, i64 1, align 4, !dbg !10
#dbg_declare(ptr %0, !11, !DIExpression(), !12)
store i32 1, ptr %2, align 4, !dbg !10
%3 = call contract float @y_(ptr %2), !dbg !10
store float %3, ptr %0, align 4, !dbg !10
ret void, !dbg !13
}
; ...
!10 = !DILocation(line: 2, column: 3, scope: !6)
```
- Additional info: The following test case also reproduces the issue:
```f90
subroutine foo(x)
dimension :: x(1, 1, 1)
x = y(1)
end
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 119889] [clang-format] breaks C++ code (adds space around "->")
Issue
119889
Summary
[clang-format] breaks C++ code (adds space around "->")
Labels
clang-format
Assignees
Reporter
plata
since clang 18
```c++
A::A()
: B()
{
Q_EMIT bar::instance()->exec();
}
```
formatted to:
```c++
A::A()
: B()
{
Q_EMIT bar::instance() -> exec();
}
```
This happens with any default style or even
```
---
IndentWidth: 4
---
```
original issue: https://invent.kde.org/frameworks/extra-cmake-modules/-/issues/15
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 119890] Clang-Tidy silent failures are extremely misleading
Issue
119890
Summary
Clang-Tidy silent failures are extremely misleading
Labels
clang-tidy
Assignees
Reporter
higher-performance
[Example](https://godbolt.org/z/n7Eddabrd):
```c++
int main() { return 0; }
```
```
clang-query> m expr(hasType(anyOf(type(), type(
0 matches.
```
These should really produce errors -- it's too easy to write a complicated query thinking that `anyOf` or `allOf` are working correctly when they aren't.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 119900] [VectorCombine] vectorizeLoadInsert - incorrect shuffle when folding from inserting into undef vector
Issue
119900
Summary
[VectorCombine] vectorizeLoadInsert - incorrect shuffle when folding from inserting into undef vector
Labels
llvm:transforms,
miscompilation:undef
Assignees
RKSimon
Reporter
RKSimon
As mentioned here by @nunoplopes: https://discourse.llvm.org/t/please-dont-use-undef-in-tests-part-2/83388/17?u=rksimon
```
; Transforms/VectorCombine/X86/load.ll
define <4 x float> @load_f32_insert_v4f32(ptr dereferenceable(16) align(16) %p) {
%s = load float, ptr dereferenceable(16) align(16) %p, align 16
%r = insertelement <4 x float> undef, float %s, i32 0
ret <4 x float> %r
}
=>
define <4 x float> @load_f32_insert_v4f32(ptr dereferenceable(16) align(16) %p) {
%#1 = load <4 x float>, ptr dereferenceable(16) align(16) %p, align 16
%r = shufflevector <4 x float> %#1, <4 x float> poison, 0, 4294967295, 4294967295, 4294967295
ret <4 x float> %r
}
Transformation doesn't verify! (unsound)
ERROR: Target is more poisonous than source
Source value: < poison, #x (+0.0), #x (+0.0), #x (+0.0) >
Target value: < poison, poison, poison, poison >
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 119879] clang-tidy error with the version in VS 2022 Version 17.13.0 Preview 2.0
Issue 119879 Summary clang-tidy error with the version in VS 2022 Version 17.13.0 Preview 2.0 Labels clang-tidy Assignees Reporter Dave-Lowndes I got this building one of my projects that didn't have any such issue with the clang-tidy version that was in the Preview 1.0 version. PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. Stack dump: 0. Program arguments: "C:\\Program Files\\Microsoft Visual Studio\\2022\\Preview\\VC\\Tools\\Llvm\\x64\\bin\\clang-tidy.exe" D:\\JDUtils\\CommonAboutBoxV3Reg\\AboutDlg.cpp D:\\JDUtils\\CommonAboutBoxV3Reg\\time_t_funcs.cpp D:\\JDUtils\\CommonAboutBoxV3Reg\\VerUtil.cpp D:\\JDUtils\\CommonCode\\CheckForUpdate.cpp D:\\JDUtils\\CommonCode\\extpathfuncs.cpp D:\\JDUtils\\CommonCode\\MiscFunctions.cpp D:\\JDUtils\\RegGen\\RegDecV3.cpp D:\\JDUtils\\RegGen\\RegKeyRegistryFuncs.cpp D:\\JDUtils\\ExpPrint\\ExpPrint\\Hashings.cpp D:\\JDUtils\\ExpPrint\\ExpPrint\\ExpDlg.cpp D:\\JDUtils\\ExpPrint\\ExpPrint\\ExpPrint.cpp D:\\JDUtils\\ExpPrint\\ExpPrint\\FPEdit.cpp D:\\JDUtils\\ExpPrint\\ExpPrint\\OutFmtBase.cpp D:\\JDUtils\\ExpPrint\\ExpPrint\\OutGenText.cpp D:\\JDUtils\\ExpPrint\\ExpPrint\\OutHDC.cpp D:\\JDUtils\\ExpPrint\\ExpPrint\\OutXML.cpp D:\\JDUtils\\ExpPrint\\ExpPrint\\SettingsDlg.cpp D:\\JDUtils\\ExpPrint\\ExpPrint\\StdAfx.cpp D:\\JDUtils\\ExpPrint\\ExpPrint\\uniquefsid.cpp -p=x64\\Release\\ExpPrint.ClangTidy 1. parser at end of file 2. While analyzing stack: #0 Calling std::_Fmt_write(class std::back_insert_iterator >, const basic_string_view) at line C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.43.34618\include\format:2682:16 #1 Calling std::_Default_arg_formatter>, wchar_t>::operator()(class std::basic_string_view) at line C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.43.34618\include\__msvc_ranges_tuple_formatter.hpp:323:20 #2 Calling std::basic_format_arg>, wchar_t>>::_Visit(struct std::_Default_arg_formatter >, wchar_t> &&) at line C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.43.34618\include\__msvc_ranges_tuple_formatter.hpp:467:12 #3 Calling std::visit_format_arg(struct std::_Default_arg_formatter >, wchar_t> &&, basic_format_arg >, wchar_t> >) at line C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.43.34618\include\format:2784:25 #4 Calling std::_Format_handler::_On_replacement_field(const size_t, const wchar_t *) at line C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.43.34618\include\format:1075:9 #5 Calling std::_Parse_replacement_field(const wchar_t *, const wchar_t *, struct std::_Format_handler &) at line C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.43.34618\include\format:1141:18 #6 Calling std::_Parse_format_string(basic_string_view, struct std::_Format_handler &) at line C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.43.34618\include\format:2908:9 #7 Calling std::_Format_to_it(class std::back_insert_iterator >, const basic_string_view, const basic_format_args >, wchar_t> >, const _Lazy_locale) at line C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.43.34618\include\format:2920:12 #8 Calling std::vformat_to(class std::back_insert_iterator >, const wstring_view, const wformat_args) at line C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.43.34618\include\format:2965:5 #9 Calling std::vformat(const wstring_view, const wformat_args) at line C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.43.34618\include\format:2992:12 #10 Calling std::format(const wformat_string, unsigned short &) at line 3273 #11 Calling (anonymous namespace)::GetCommonData(IShellFolder *, PCITEMID_CHILD, CRowData &, _Bool, ItemType, _Bool, vector &) 3. C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.43.34618\include\format:1748:33 : Error evaluating statement 4. C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.43.34618\include\format:1748:33 : Error evaluating statement Exception Code: 0xC005 #0 0x7ff6422d0b2e (C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-tidy.exe+0x17d0b2e) #1 0x7ff6428a195b (C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-tidy.exe+0x1da195b) #2 0x7ff641f77320 (C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-tidy.exe+0x1477320) #3 0x7ff641f877a7 (C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-tidy.exe+0x14877a7) #4 0x7ff642324db1 (C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-tidy.exe+0x1824db1) #5 0x00
[llvm-bugs] [Bug 119893] [EarlyCSE] Assertion `!FoundVal && "Key already in new map?"' failed.
Issue
119893
Summary
[EarlyCSE] Assertion `!FoundVal && "Key already in new map?"' failed.
Labels
crash-on-valid,
llvm:transforms
Assignees
Reporter
dtcxzyw
Reproducer:
```
; bin/opt -passes=early-cse reduced.ll -S
define i32 @func_207(i16 %p_208.coerce, i32 %conv, i32 %0, i64 %1, ptr %p) {
entry:
%conv1 = zext i16 %p_208.coerce to i32
%conv31 = sext i32 %conv to i64
%cmp.i = icmp eq i64 %conv31, 0
%xor = xor i32 %conv, 1
store i32 %xor, ptr %p, align 4
%cmp2.i = icmp samesign ugt i32 %conv1, 31
%shr.i601 = select i1 %cmp2.i, i32 0, i32 %conv1
%cond.i602 = ashr i32 1, %shr.i601
%conv6.i603 = trunc i32 %cond.i602 to i16
%conv245 = trunc i16 %p_208.coerce to i8
%mul.i628 = mul i8 -107, %conv245
%conv247 = sext i8 %mul.i628 to i64
%cond.i629 = call i64 @llvm.smin.i64(i64 0, i64 %conv247)
%cmp249 = icmp slt i64 %cond.i629, 0
%conv251 = zext i1 %cmp249 to i64
%cmp1.i630 = icmp ugt i32 %conv1, 31
%narrow.i631 = select i1 %cmp1.i630, i32 0, i32 %conv1
%shr.i632 = zext i32 %narrow.i631 to i64
%cond.i633 = lshr i64 %conv251, %shr.i632
%cmp258 = icmp slt i16 %p_208.coerce, 0
%2 = zext i1 %cmp258 to i16
%cmp261 = icmp ugt i16 1, %2
%conv263 = zext i1 %cmp261 to i64
%cmp344 = icmp eq i16 %p_208.coerce, 0
%conv345 = zext i1 %cmp344 to i32
store i32 %conv345, ptr %p, align 4
%conv351 = sext i32 %0 to i64
%sub.i641 = call i64 @llvm.ucmp.i64.i64(i64 0, i64 %conv351)
%conv353 = trunc i64 %sub.i641 to i16
%3 = mul i16 %conv353, -1
%conv355 = zext i16 %3 to i64
%cmp356 = icmp sle i64 1, %conv355
%conv357 = zext i1 %cmp356 to i32
%conv359 = trunc i32 %conv357 to i8
%conv.i650 = sext i8 %conv359 to i32
%4 = icmp ugt i32 %conv, 0
%shr.i652 = lshr i32 1, %conv
%cmp9.i = icmp slt i32 %shr.i652, 1
%or.cond.i = select i1 %4, i1 false, i1 %cmp9.i
%shl.i653 = shl i32 %conv.i650, 1
%5 = trunc i32 %shl.i653 to i8
%cond.i654 = select i1 %or.cond.i, i8 0, i8 %5
%conv3612 = sext i8 %cond.i654 to i32
%conv3623 = trunc i64 %1 to i32
%6 = or i32 1, %conv3612
%or.cond.i655 = icmp slt i32 %6, 0
%cmp3.i = icmp sgt i32 %conv3623, 0
%or.cond4.i = or i1 %cmp3.i, %or.cond.i655
%shr.i656 = select i1 %or.cond4.i, i32 0, i32 1
%cond.i657 = ashr i32 %conv, %shr.i656
%cmp.i658 = icmp slt i32 %cond.i657, 0
%shr.i660 = select i1 %cmp.i658, i32 0, i32 1
%cond.i661 = ashr i32 1, %shr.i660
%conv365 = trunc i32 %cond.i661 to i16
%add.i662 = or i16 1, %conv365
%conv368 = sext i16 %add.i662 to i32
ret i32 %conv368
}
```
```
opt: /data/zyw/llvm-project/llvm/include/llvm/ADT/DenseMap.h:419: void llvm::DenseMapBase::moveFromOldBuckets(BucketT*, BucketT*) [with DerivedT = llvm::DenseMap<{anonymous}::SimpleValue, llvm::ScopedHashTableVal<{anonymous}::SimpleValue, llvm::Value*>*, llvm::DenseMapInfo<{anonymous}::SimpleValue>, llvm::detail::DenseMapPair<{anonymous}::SimpleValue, llvm::ScopedHashTableVal<{anonymous}::SimpleValue, llvm::Value*>*> >; KeyT = {anonymous}::SimpleValue; ValueT = llvm::ScopedHashTableVal<{anonymous}::SimpleValue, llvm::Value*>*; KeyInfoT = llvm::DenseMapInfo<{anonymous}::SimpleValue>; BucketT = llvm::detail::DenseMapPair<{anonymous}::SimpleValue, llvm::ScopedHashTableVal<{anonymous}::SimpleValue, llvm::Value*>*>]: Assertion `!FoundVal && "Key already in new map?"' 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/zyw/llvm-build/bin/opt -passes=early-cse reduced.ll
1. Running pass "function(early-cse<>)" on module "reduced.ll"
2. Running pass "early-cse<>" on function "func_207"
#0 0x77def832 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/data/zyw/llvm-build/bin/../lib/libLLVMSupport.so.20.0git+0x1ef832)
#1 0x77dec9ef llvm::sys::RunSignalHandlers() (/data/zyw/llvm-build/bin/../lib/libLLVMSupport.so.20.0git+0x1ec9ef)
#2 0x77decb35 SignalHandler(int) Signals.cpp:0:0
#3 0x77842520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#4 0x778969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
#5 0x77842476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
#6 0x778287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
#7 0x7782871b (/lib/x86_64-linux-gnu/libc.so.6+0x2871b)
#8 0x77839e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96)
#9 0x74efa75e llvm::DenseMap<(anonymous namespace)::SimpleValue, llvm::ScopedHashTableVal<(anonymous namespace)::SimpleValue, llvm::Value*>*, llvm::DenseMapInfo<(anonymous namespace)::SimpleValue, void>, llvm::detail::DenseMapPair<(anonymous namespace)::SimpleValue, llvm::ScopedHashTableVal<(anonymous namespace)::SimpleValue, llvm::Value*>*>>::grow(unsigned int) EarlyCSE.cpp:0:
[llvm-bugs] [Bug 119876] [MLIR] Inconsistent output when executing MLIR program with and without `-test-loop-fusion=test-loop-fusion-transformation`
Issue
119876
Summary
[MLIR] Inconsistent output when executing MLIR program with and without `-test-loop-fusion=test-loop-fusion-transformation`
Labels
mlir
Assignees
Reporter
Lambor24
My git version is [ea44647](https://github.com/llvm/llvm-project/commit/ea44647a0b49de826191eeb6e05020262b5a81e9).
## Description:
I am experiencing an inconsistent result when executing the same MLIR program with and without the `-test-loop-fusion=test-loop-fusion-transformation`.
## Steps to Reproduce:
### 1. **MLIR Program (test.mlir)**:
test.mlir:
```
module {
func.func private @printMemrefI64(tensor<*xi64>)
func.func @main() -> () {
%arg0 = "tosa.const"() {value = dense<20> : tensor<36x2x3xi64>} : () -> tensor<36x2x3xi64>
%0 = tosa.reduce_sum %arg0 {axis = 0 : i32} : (tensor<36x2x3xi64>) -> tensor<1x2x3xi64>
%rtn1 = tensor.cast %0 : tensor<1x2x3xi64> to tensor<*xi64>
call @printMemrefI64(%rtn1) : (tensor<*xi64>) -> ()
return
}
}
```
### 2. **Command to Run Without `-test-loop-fusion=test-loop-fusion-transformation`:**
```
/path/llvm-project/build/bin/mlir-opt test.mlir -pass-pipeline='builtin.module(func.func(tosa-to-linalg-named,tosa-to-linalg))' | \
/path/llvm-project/build/bin/mlir-opt -tosa-to-arith -one-shot-bufferize="bufferize-function-boundaries" -convert-linalg-to-affine-loops -lower-affine -convert-scf-to-cf -expand-strided-metadata -convert-cf-to-llvm -convert-arith-to-llvm -finalize-memref-to-llvm -convert-func-to-llvm -reconcile-unrealized-casts | \
/path/llvm-project/build/bin/mlir-cpu-runner -e main -entry-point-result=void \
-shared-libs=/path/llvm-project/build/lib/libmlir_runner_utils.so \
-shared-libs=/path/llvm-project/build/lib/libmlir_c_runner_utils.so \
-shared-libs=/path/llvm-project/build/lib/libmlir_async_runtime.so
```
### 3. **Output Without `-test-loop-fusion=test-loop-fusion-transformation`:**
```
[[[720, 720,720],
[720,720,720]]]
```
### 4. **Command to Run With `-test-loop-fusion=test-loop-fusion-transformation`:**
```
/path/llvm-project/build/bin/mlir-opt test.mlir -pass-pipeline='builtin.module(func.func(tosa-to-linalg-named,tosa-to-linalg))' | \
/path/llvm-project/build/bin/mlir-opt -tosa-to-arith -one-shot-bufferize="bufferize-function-boundaries" -convert-linalg-to-affine-loops -test-loop-fusion=test-loop-fusion-transformation -lower-affine -convert-scf-to-cf -expand-strided-metadata -convert-cf-to-llvm -convert-arith-to-llvm -finalize-memref-to-llvm -convert-func-to-llvm -reconcile-unrealized-casts | \
/path/llvm-project/build/bin/mlir-cpu-runner -e main -entry-point-result=void \
-shared-libs=/path/llvm-project/build/lib/libmlir_runner_utils.so \
-shared-libs=/path/llvm-project/build/lib/libmlir_c_runner_utils.so \
-shared-libs=/path/llvm-project/build/lib/libmlir_async_runtime.so
```
### 5. **Output With `-test-loop-fusion=test-loop-fusion-transformation`:**
```
[[[20,20, 20],
[20,20,20]]]
```
I'm not sure if there is any bug in my program or if the wrong usage of the above passes caused this result.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 119945] [C++] [Strings] -- find_first_*(s, pos, n) & find_last_*(s, pos, n) give wrong result with String-Literal s, and n > than s-length
Issue
119945
Summary
[C++] [Strings] -- find_first_*(s, pos, n) & find_last_*(s, pos, n) give wrong result with String-Literal s, and n > than s-length
Labels
Assignees
Reporter
PN-03
I'm using LLVM 19.1.5 MinGW and this issue only happens with String-Literals.
Here's the code to reproduce the issue:
```c++
string s = ":";
string x = "What a wonderful day to play. Arthur the Aardvark: has the best show";
cout << "String Index: " << x.find_first_of(s.c_str(), 21, 60) << "\n";
cout << "\n";
for(size_t n = 1; n <= 10; n++){
cout << "n = " << n << ", String-Literal Index: Find_First: " << x.find_first_of(":", 10, n);
cout << ", Find_Last: " << x.find_last_of(":", x.length(), n) << endl;
}
cout << "\n";
for(size_t n = 1; n <= 100; n *= 2){
cout << "n = " << n << ", String-Literal Index: Find_First_Not: " << x.find_first_not_of(":", 10, n);
cout << ", Find_Last_Not: " << x.find_last_not_of(":", x.length(), n) << endl;
}
```
pos = 49 is the correct result for the Find_First/Find_Last Set.
pos = 10 for Find_First_Not and pos = 67 for Find_Last_Not Set
This is the Output:
String Index: 49
n = 1, String-Literal Index: Find_First: 49, Find_Last: 49
n = 2, String-Literal Index: Find_First: 49, Find_Last: 49
n = 3, String-Literal Index: Find_First: 49, Find_Last: 49
n = 4, String-Literal Index: Find_First: 33, Find_Last: 65
n = 5, String-Literal Index: Find_First: 18, Find_Last: 65
n = 6, String-Literal Index: Find_First: 18, Find_Last: 65
n = 7, String-Literal Index: Find_First: 16, Find_Last: 65
n = 8, String-Literal Index: Find_First: 16, Find_Last: 65
n = 9, String-Literal Index: Find_First: 16, Find_Last: 65
n = 10, String-Literal Index: Find_First: 16, Find_Last: 67
n = 1, String-Literal Index: Find_First_Not: 10, Find_Last_Not: 67
n = 2, String-Literal Index: Find_First_Not: 10, Find_Last_Not: 67
n = 4, String-Literal Index: Find_First_Not: 10, Find_Last_Not: 67
n = 8, String-Literal Index: Find_First_Not: 10, Find_Last_Not: 67
n = 16, String-Literal Index: Find_First_Not: 14, Find_Last_Not: 64
n = 32, String-Literal Index: Find_First_Not: 30, Find_Last_Not: 64
n = 64, String-Literal Index: Find_First_Not: 18446744073709551615, Find_Last_Not: 18446744073709551615
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 119947] [C++][Modules] Definition with same mangled name for template arguments of types defined in unnamed namespace in different files
Issue
119947
Summary
[C++][Modules] Definition with same mangled name for template arguments of types defined in unnamed namespace in different files
Labels
new issue
Assignees
Reporter
davidstone
Given the following translation units:
```c++
export module a;
struct a_inner {
~a_inner() {
}
void f(auto) {
}
};
export template
struct a {
a() {
struct local {};
inner.f(local());
}
private:
a_inner inner;
};
namespace {
struct s {
};
} // namespace
void f() {
a x;
}
```
```c++
import a;
namespace {
struct s {
};
} // namespace
void g() {
a x;
}
```
clang fails with
```console
/opt/compiler-explorer/clang-assertions-trunk/bin/clang++ --gcc-toolchain=/opt/compiler-explorer/gcc-snapshot -fcolor-diagnostics -fno-crash-diagnostics -std=c++20 -MD -MT CMakeFiles/foo.dir/b.cpp.o -MF CMakeFiles/foo.dir/b.cpp.o.d @CMakeFiles/foo.dir/b.cpp.o.modmap -o CMakeFiles/foo.dir/b.cpp.o -c /app/b.cpp
In file included from /app/b.cpp:1:
a.cpp:11:8: error: definition with same mangled name '_ZNW1a1aIN12_GLOBAL__N_11sEED2Ev' as another definition
11 | struct a {
|^
a.cpp:11:8: note: previous definition is here
```
See it live: https://godbolt.org/z/vsdznvsbP
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
