[llvm-bugs] [Bug 121034] [19.x] [compiler-rt] Backport "Build SanitizerCommon if ctx_profile enabled" to 19.x

2024-12-23 Thread LLVM Bugs via llvm-bugs 


Issue

121034




Summary

[19.x] [compiler-rt] Backport "Build SanitizerCommon if ctx_profile enabled" to 19.x




  Labels
  
cmake,
release:backport
  



  Assignees
  
  



  Reporter
  
  mgorny
  




A trivial CMake fix:

```
commit e3389365b5d62bc9781dc9a23b14d72e333018d7
Author: Nikita Popov 
AuthorDate: 2024-08-22 09:48:05 +0200
Commit: GitHub 
CommitDate: 2024-08-22 09:48:05 +0200

 Build SanitizerCommon if ctx_profile enabled (#105495)

ctx_profile has a dependency on SanitizerCommon, so make sure it is
built even if we otherwise disable sanitizers.
```

Also hit downstream: https://bugs.gentoo.org/946871


___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 120944] [mlir] -transform-dialect-check-uses crashes

2024-12-23 Thread LLVM Bugs via llvm-bugs 


Issue

120944




Summary

[mlir] -transform-dialect-check-uses crashes




  Labels
  
mlir
  



  Assignees
  
  



  Reporter
  
  wwy6191
  




git version: bc29fc937c6cb4a210f80c93c79fc6ed97c801f8

system: `Ubuntu 18.04.6 LTS`

reproduce with: `mlir-opt  -transform-dialect-check-uses a.mlir`


a.mlir:  
``` 
func.func @foo(%arg0: index, %arg1:index, %arg2 : index) {
  scf.for %i = %arg0 to %arg1 step %arg2 {
%0 = arith.constant 0 : i32
  }
  return
}

module attributes {transform.with_named_sequence} {
  transform.named_sequence @__transform_main(%root:!transform.any_op) {
transform.with_pdl_patterns %root :!transform.any_op {
^bb0(%arg0:!transform.any_op):
 pdl.pattern @match_const : benefit(1) {
%0 = pdl.operands
 %1 = pdl.types
%2 = pdl.operation "arith.constant"(%0 :!pdl.range) -> (%1 :!pdl.range)
pdl.rewrite %2 with "transform.dialect"
  }


  sequence %arg0 :!transform.any_op failures(propagate) {
  ^bb1(%arg1:!transform.any_op):
%0 = transform.pdl_match @match_const in %arg1 : (!transform.any_op) ->!transform.any_op
%1 = transform.get_parent_op %0 {op_name = "scf.for"} : (!transform.any_op) ->!transform.any_op
alternatives %1 :!transform.any_op {
^bb2(%arg2:!transform.any_op):
}
 }
}
transform.yield
  }
}

``` 
stack trace:

``` 
mlir-opt: /data/szy/MLIR/llvm-release/llvm-project/llvm/include/llvm/Support/Casting.h:578: decltype(auto) llvm::cast(From *) [To = mlir::MemoryEffectOpInterface, From = mlir::Operation]: Assertion `isa(Val) && "cast() argument of incompatible type!"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0.  Program arguments: /data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt -transform-dialect-check-uses /data/szy/MLIR/seed/seed14/tmp.kuOGtmbIp2.mlir
 #0 0x55be46e7d508 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x11ef508)
 #1 0x55be46e7b01e llvm::sys::RunSignalHandlers() (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x11ed01e)
 #2 0x55be46e7de9d SignalHandler(int) Signals.cpp:0:0
 #3 0x7f7908752420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420)
 #4 0x7f7907d8f00b raise /build/glibc-LcI20x/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:51:1
 #5 0x7f7907d6e859 abort /build/glibc-LcI20x/glibc-2.31/stdlib/abort.c:81:7
 #6 0x7f7907d6e729 get_sysdep_segment_value /build/glibc-LcI20x/glibc-2.31/intl/loadmsgcat.c:509:8
 #7 0x7f7907d6e729 _nl_load_domain /build/glibc-LcI20x/glibc-2.31/intl/loadmsgcat.c:970:34
 #8 0x7f7907d7ffd6 (/lib/x86_64-linux-gnu/libc.so.6+0x33fd6)
 #9 0x55be4961acae void llvm::function_ref::callback_fn<(anonymous namespace)::TransformOpMemFreeAnalysis::collectFreedValues(mlir::Operation*)::'lambda'(mlir::Operation*)>(long, mlir::Operation*) CheckUses.cpp:0:0
#10 0x55be46f954ce void mlir::detail::walk(mlir::Operation*, llvm::function_ref, mlir::WalkOrder) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x13074ce)
#11 0x55be46f954ce void mlir::detail::walk(mlir::Operation*, llvm::function_ref, mlir::WalkOrder) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x13074ce)
#12 0x55be4961a20c mlir::WalkResult llvm::function_ref::callback_fn<(anonymous namespace)::TransformOpMemFreeAnalysis::TransformOpMemFreeAnalysis(mlir::Operation*)::'lambda'(mlir::Operation*)>(long, mlir::Operation*) CheckUses.cpp:0:0
#13 0x55be46faafa7 mlir::WalkResult mlir::detail::walk(mlir::Operation*, llvm::function_ref, mlir::WalkOrder) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x131cfa7)
#14 0x55be46faafa7 mlir::WalkResult mlir::detail::walk(mlir::Operation*, llvm::function_ref, mlir::WalkOrder) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x131cfa7)
#15 0x55be46faafa7 mlir::WalkResult mlir::detail::walk(mlir::Operation*, llvm::function_ref, mlir::WalkOrder) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x131cfa7)
#16 0x55be49619b1d (anonymous namespace)::CheckUsesPass::runOnOperation() CheckUses.cpp:0:0
#17 0x55be49ddeec6 mlir::detail::OpToOpPassAdaptor::run(mlir::Pass*, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x4150ec6)
#18 0x55be49ddf7f0 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+0x41517f0)
#19 0x55be49de1dc2 mlir::PassManager::run(mlir::Operation*) (/data/szy/MLIR/llvm-re

[llvm-bugs] [Bug 120945] [mlir] -buffer-deallocation crashes

2024-12-23 Thread LLVM Bugs via llvm-bugs 


Issue

120945




Summary

[mlir] -buffer-deallocation crashes




  Labels
  
mlir
  



  Assignees
  
  



  Reporter
  
  wwy6191
  




git version: bc29fc937c6cb4a210f80c93c79fc6ed97c801f8

system: `Ubuntu 18.04.6 LTS`

reproduce with: `mlir-opt  -buffer-deallocation a.mlir`


a.mlir: 
``` 
func.func @invCriticalEdge(%arg: i1) -> memref {
  %0 = memref.alloc() : memref
  cf.cond_br%arg, ^bb1(%0 :memref< f32>), ^abb(%0 : memref)
^bb1(%5: memref):
  return %5 : memref
^abb(%6: memref):
  return %6 : memref
}

``` 
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 -buffer-deallocation /data/szy/MLIR/seed/seed13/tmp.BscbK1A2NO.mlir
 #0 0x55c44daaf508 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x11ef508)
 #1 0x55c44daad01e llvm::sys::RunSignalHandlers() (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x11ed01e)
 #2 0x55c44daafe9d SignalHandler(int) Signals.cpp:0:0
 #3 0x7fd75bfd9420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420)
 #4 0x55c44e0100d0 mlir::bufferization::deallocateBuffers(mlir::Operation*) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x17500d0)
 #5 0x55c44e013a6b (anonymous namespace)::BufferDeallocationPass::runOnOperation() BufferDeallocation.cpp:0:0
 #6 0x55c450a10ec6 mlir::detail::OpToOpPassAdaptor::run(mlir::Pass*, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x4150ec6)
 #7 0x55c450a117f0 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+0x41517f0)
 #8 0x55c450a16b5e auto void mlir::parallelForEach<__gnu_cxx::__normal_iterator>>, mlir::detail::OpToOpPassAdaptor::runOnOperationAsyncImpl(bool)::$_0>(mlir::MLIRContext*, __gnu_cxx::__normal_iterator>>, __gnu_cxx::__normal_iterator>>, mlir::detail::OpToOpPassAdaptor::runOnOperationAsyncImpl(bool)::$_0&&)::'lambda'(__gnu_cxx::__normal_iterator>>&&)::operator()(__gnu_cxx::__normal_iterator>>&&) const Pass.cpp:0:0
 #9 0x55c450a12e4b mlir::detail::OpToOpPassAdaptor::runOnOperationAsyncImpl(bool) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x4152e4b)
#10 0x55c450a1101f mlir::detail::OpToOpPassAdaptor::run(mlir::Pass*, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x415101f)
#11 0x55c450a117f0 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+0x41517f0)
#12 0x55c450a13dc2 mlir::PassManager::run(mlir::Operation*) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x4153dc2)
#13 0x55c450a0c53a performActions(llvm::raw_ostream&, std::shared_ptr const&, mlir::MLIRContext*, mlir::MlirOptMainConfig const&) MlirOptMain.cpp:0:0
#14 0x55c450a0c18d 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
#15 0x55c450ab7c65 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+0x41f7c65)
#16 0x55c450a06175 mlir::MlirOptMain(llvm::raw_ostream&, std::unique_ptr>, mlir::DialectRegistry&, mlir::MlirOptMainConfig const&) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x4146175)
#17 0x55c450a0641f mlir::MlirOptMain(int, char**, llvm::StringRef, llvm::StringRef, mlir::DialectRegistry&) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x414641f)
#18 0x55c450a0674e mlir::MlirOptMain(int, char**, llvm::StringRef, mlir::DialectRegistry&) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x414674e)
#19 0x55c44da8fff7 main (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x11cfff7)
#20 0x7fd75b5f7083 __libc_start_main /build/glibc-LcI20x/glibc-2.31/csu/../csu/libc-start.c:342:3
#21 0x55c44da8fb6e _start (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x11cfb6e)
``` 


___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://list

[llvm-bugs] [Bug 120947] [mlir] -convert-tensor-to-linalg crashes

2024-12-23 Thread LLVM Bugs via llvm-bugs 


Issue

120947




Summary

[mlir] -convert-tensor-to-linalg crashes




  Labels
  
mlir
  



  Assignees
  
  



  Reporter
  
  wwy6191
  




git version: bc29fc937c6cb4a210f80c93c79fc6ed97c801f8

system: `Ubuntu 18.04.6 LTS`

reproduce with: `mlir-opt  -convert-tensor-to-linalg a.mlir`


a.mlir:  
``` 
func.func @tensor_pad_constant(%t: tensor,%l2:index,%h1:index,%h3: index) -> tensor {
 %0= tensor.pad %t low[5, %l2] high[%h1, %h3] {
  ^bb0(%arg0: index, %arg1: index):
%c = arith.constant 50 : index
tensor.yield %c : index
  } : tensor to tensor
  return %0 : tensor
}

module attributes {transform.with_named_sequence} {
 transform.named_sequence @__transform_main(%arg1:!transform.any_op {transform.readonly}) {
%0 = transform.structured.match ops{["tensor.pad"]} in %arg1
  : (!transform.any_op) ->!transform.any_op
 transform.structured.rewrite_in_destination_passing_style %0
  : (!transform.any_op) ->!transform.any_op
  transform.yield
  }
}

``` 
stack trace:

``` 
mlir-opt: /data/szy/MLIR/llvm-release/llvm-project/mlir/lib/IR/PatternMatch.cpp:182: auto mlir::RewriterBase::eraseOp(Operation *)::(anonymous class)::operator()(Operation *) const: Assertion `mayBeGraphRegion(*op->getParentRegion()) && "expected that op has no 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 -convert-tensor-to-linalg /data/szy/MLIR/seed/seed29/tmp.QEAQVRHJ7x.mlir
 #0 0x5652d744c508 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x11ef508)
 #1 0x5652d744a01e llvm::sys::RunSignalHandlers() (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x11ed01e)
 #2 0x5652d744ce9d SignalHandler(int) Signals.cpp:0:0
 #3 0x7f84ae664420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420)
 #4 0x7f84adca100b raise /build/glibc-LcI20x/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:51:1
 #5 0x7f84adc80859 abort /build/glibc-LcI20x/glibc-2.31/stdlib/abort.c:81:7
 #6 0x7f84adc80729 get_sysdep_segment_value /build/glibc-LcI20x/glibc-2.31/intl/loadmsgcat.c:509:8
 #7 0x7f84adc80729 _nl_load_domain /build/glibc-LcI20x/glibc-2.31/intl/loadmsgcat.c:970:34
 #8 0x7f84adc91fd6 (/lib/x86_64-linux-gnu/libc.so.6+0x33fd6)
 #9 0x5652da567df3 (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x430adf3)
#10 0x5652da56782f std::_Function_handler::_M_invoke(std::_Any_data const&, mlir::Operation*&&) PatternMatch.cpp:0:0
#11 0x5652da5662fc mlir::RewriterBase::eraseOp(mlir::Operation*) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x43092fc)
#12 0x5652da40c3dd mlir::OperationConverter::convertOperations(llvm::ArrayRef) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x41af3dd)
#13 0x5652da41236b mlir::applyPartialConversion(mlir::Operation*, mlir::ConversionTarget const&, mlir::FrozenRewritePatternSet const&, mlir::ConversionConfig) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x41b536b)
#14 0x5652da25a8c8 (anonymous namespace)::ConvertTensorToLinalgPass::runOnOperation() TensorToLinalgPass.cpp:0:0
#15 0x5652da3adec6 mlir::detail::OpToOpPassAdaptor::run(mlir::Pass*, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x4150ec6)
#16 0x5652da3ae7f0 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+0x41517f0)
#17 0x5652da3b0dc2 mlir::PassManager::run(mlir::Operation*) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x4153dc2)
#18 0x5652da3a953a performActions(llvm::raw_ostream&, std::shared_ptr const&, mlir::MLIRContext*, mlir::MlirOptMainConfig const&) MlirOptMain.cpp:0:0
#19 0x5652da3a918d 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
#20 0x5652da454c65 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+0x41f7c65)
#21 0x5652da3a3175 mlir::MlirOptMain(llvm::raw_ostream&, std::unique_ptr>, mlir::DialectRegistry&, mlir::MlirOptMainConfig const&) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x4146175)
#22 0x5652da3a341f mlir::MlirOptMain(int, char**, llvm::

[llvm-bugs] [Bug 120948] [mlir] -convert-openmp-to-llvm crashes

2024-12-23 Thread LLVM Bugs via llvm-bugs 


Issue

120948




Summary

[mlir] -convert-openmp-to-llvm crashes




  Labels
  
  



  Assignees
  
  



  Reporter
  
  wwy6191
  




git version: bc29fc937c6cb4a210f80c93c79fc6ed97c801f8

system: `Ubuntu 18.04.6 LTS`

reproduce with: `mlir-opt  -convert-openmp-to-llvm a.mlir`


a.mlir:  
``` 
#map = affine_map<(d0) -> (d0)>
module {
 func.func @loop_nest_depth() {
%alloc = memref.alloca() :memref<256x8xf32, #spirv.storage_class>
affine.for %arg0 = 0 to 32 step 4 {
  affine.for %arg1 = 0 to 8 step 2 {
%0 = affine.apply #map(%arg1)
%1 = affine.load %alloc[%arg0, %0] : memref<256x8xf32, #spirv.storage_class>
  }
}
 return
  }
}

``` 
stack trace:

``` 
/usr/lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/optional:438: _Tp &std::_Optional_base_impl>::_M_get() [_Tp = unsigned int, _Dp = std::_Optional_base]: Assertion 'this->_M_is_engaged()' 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 -convert-openmp-to-llvm /data/szy/MLIR/seed/seed29/tmp.lM6A8VYgS4.mlir
 #0 0x55d88dd28508 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x11ef508)
 #1 0x55d88dd2601e llvm::sys::RunSignalHandlers() (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x11ed01e)
 #2 0x55d88dd28e9d SignalHandler(int) Signals.cpp:0:0
 #3 0x7faa087b6420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420)
 #4 0x7faa07df300b raise /build/glibc-LcI20x/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:51:1
 #5 0x7faa07dd2859 abort /build/glibc-LcI20x/glibc-2.31/stdlib/abort.c:81:7
 #6 0x55d8909bb57f (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x3e8257f)
 #7 0x55d8909d7ed0 mlir::AllocLikeOpLLVMLowering::matchAndRewrite(mlir::Operation*, llvm::ArrayRef, mlir::ConversionPatternRewriter&) const (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x3e9eed0)
 #8 0x55d88e029f84 mlir::ConversionPattern::matchAndRewrite(mlir::Operation*, llvm::ArrayRef, mlir::ConversionPatternRewriter&) const (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x14f0f84)
 #9 0x55d890ce7014 mlir::ConversionPattern::matchAndRewrite(mlir::Operation*, mlir::PatternRewriter&) const (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x41ae014)
#10 0x55d893dc4791 void llvm::function_ref::callback_fn, llvm::function_ref, llvm::function_ref)::$_0>(long) PatternApplicator.cpp:0:0
#11 0x55d893dc140b 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+0x728840b)
#12 0x55d890ce80e3 (anonymous namespace)::OperationLegalizer::legalize(mlir::Operation*, mlir::ConversionPatternRewriter&) DialectConversion.cpp:0:0
#13 0x55d890ce7137 mlir::OperationConverter::convert(mlir::ConversionPatternRewriter&, mlir::Operation*) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x41ae137)
#14 0x55d890ce830f mlir::OperationConverter::convertOperations(llvm::ArrayRef) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x41af30f)
#15 0x55d890cee36b mlir::applyPartialConversion(mlir::Operation*, mlir::ConversionTarget const&, mlir::FrozenRewritePatternSet const&, mlir::ConversionConfig) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x41b536b)
#16 0x55d890a2223c (anonymous namespace)::ConvertOpenMPToLLVMPass::runOnOperation() OpenMPToLLVM.cpp:0:0
#17 0x55d890c89ec6 mlir::detail::OpToOpPassAdaptor::run(mlir::Pass*, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x4150ec6)
#18 0x55d890c8a7f0 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+0x41517f0)
#19 0x55d890c8cdc2 mlir::PassManager::run(mlir::Operation*) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x4153dc2)
#20 0x55d890c8553a performActions(llvm::raw_ostream&, std::shared_ptr const&, mlir::MLIRContext*, mlir::MlirOptMainConfig const&) MlirOptMain.cpp:0:0
#21 0x55d890c8518d 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
#22 0x55d890d30c65 mlir::splitAndProcessBuffer(std::unique_ptr>, llvm::function_ref>, llvm::raw_ostream&)>, l

[llvm-bugs] [Bug 120943] [mlir] -int-range-optimizations crashes

2024-12-23 Thread LLVM Bugs via llvm-bugs 


Issue

120943




Summary

[mlir] -int-range-optimizations crashes




  Labels
  
  



  Assignees
  
  



  Reporter
  
  wwy6191
  




git version: bc29fc937c6cb4a210f80c93c79fc6ed97c801f8

system: `Ubuntu 18.04.6 LTS`

reproduce with: `mlir-opt  -int-range-optimizations a.mlir`


a.mlir:  
``` 
func.func @test() -> i1 {
  %cst1_i1 = arith.constant 0 : i1
  %0= test.with_bounds { umin = 0 : i64, umax = 12 : i64, smin = 0 : i64, smax = 12 : i64} : i1
  %1= arith.cmpi sgt, %0, %cst1_i1 : i1
  %2= arith.cmpi slt, %0, %cst1_i1 : i1
  %3 = arith.andi %1, %2 : i1
  return %3 : i1
}

``` 
stack trace:

``` 
mlir-opt: /data/szy/MLIR/llvm-release/llvm-project/llvm/lib/Support/APInt.cpp:293: int llvm::APInt::compareSigned(const APInt &) const: Assertion `BitWidth == RHS.BitWidth && "Bit widths must be same for comparison"' 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 -int-range-optimizations /data/szy/MLIR/seed/seed29/tmp.twXBPBsQjz.mlir
 #0 0x562d78de6508 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x11ef508)
 #1 0x562d78de401e llvm::sys::RunSignalHandlers() (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x11ed01e)
 #2 0x562d78de6e9d SignalHandler(int) Signals.cpp:0:0
 #3 0x7fb44a5a7420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420)
 #4 0x7fb449be400b raise /build/glibc-LcI20x/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:51:1
 #5 0x7fb449bc3859 abort /build/glibc-LcI20x/glibc-2.31/stdlib/abort.c:81:7
 #6 0x7fb449bc3729 get_sysdep_segment_value /build/glibc-LcI20x/glibc-2.31/intl/loadmsgcat.c:509:8
 #7 0x7fb449bc3729 _nl_load_domain /build/glibc-LcI20x/glibc-2.31/intl/loadmsgcat.c:970:34
 #8 0x7fb449bd4fd6 (/lib/x86_64-linux-gnu/libc.so.6+0x33fd6)
 #9 0x562d78e5d893 (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x1266893)
#10 0x562d7e46089d isStaticallyTrue(mlir::intrange::CmpPredicate, mlir::ConstantIntRanges const&, mlir::ConstantIntRanges const&) InferIntRangeCommon.cpp:0:0
#11 0x562d7e4607a3 mlir::intrange::evaluatePred(mlir::intrange::CmpPredicate, mlir::ConstantIntRanges const&, mlir::ConstantIntRanges const&) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x68697a3)
#12 0x562d790dcf95 mlir::arith::CmpIOp::inferResultRanges(llvm::ArrayRef, llvm::function_ref) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x14e5f95)
#13 0x562d7908ca81 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+0x1495a81)
#14 0x562d7ef24016 mlir::intrange::detail::defaultInferResultRanges(mlir::InferIntRangeInterface, llvm::ArrayRef, llvm::function_ref) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x732d016)
#15 0x562d7bd31d3c mlir::dataflow::IntegerRangeAnalysis::visitOperation(mlir::Operation*, llvm::ArrayRef, llvm::ArrayRef) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x413ad3c)
#16 0x562d7bd34df9 mlir::dataflow::AbstractSparseForwardDataFlowAnalysis::visitOperation(mlir::Operation*) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x413ddf9)
#17 0x562d7bd34499 mlir::dataflow::AbstractSparseForwardDataFlowAnalysis::initializeRecursively(mlir::Operation*) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x413d499)
#18 0x562d7bd3474d mlir::dataflow::AbstractSparseForwardDataFlowAnalysis::initializeRecursively(mlir::Operation*) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x413d74d)
#19 0x562d7bd3474d mlir::dataflow::AbstractSparseForwardDataFlowAnalysis::initializeRecursively(mlir::Operation*) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x413d74d)
#20 0x562d7bd12b4e mlir::DataFlowSolver::initializeAndRun(mlir::Operation*) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x411bb4e)
#21 0x562d7911917d (anonymous namespace)::IntRangeOptimizationsPass::runOnOperation() IntRangeOptimizations.cpp:0:0
#22 0x562d7bd47ec6 mlir::detail::OpToOpPassAdaptor::run(mlir::Pass*, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x4150ec6)
#23 0x562d7bd487f0 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/bu

[llvm-bugs] [Bug 120950] [mlir] -finalize-memref-to-llvm crashes

2024-12-23 Thread LLVM Bugs via llvm-bugs 


Issue

120950




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(i64)
  func.func @loop_nest_depth() {
%alloc = memref.alloc() : memref<1024x64xf32, 1>
%cst = arith.constant 7.00e+00 : f32
affine.for %arg0 = 0 to 8 step 2 {
  affine.for %arg1 = 0 to 16 step 4 {
affine.store %cst, %alloc[%arg0, %arg1] : memref<1024x64xf32, 1>
  }
}
affine.for %arg0 = 0 to 16 {
 affine.for %arg1 = 0 to 8 {
affine.for %arg2 = 0 to 8 step 4 {
 affine.store %cst, %alloc[%arg0, %arg2] : memref<1024x64xf32, 1>
 }
  }
}
llvm.return
  }
}

``` 
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 -finalize-memref-to-llvm /data/szy/MLIR/seed/seed0/tmp.p0T3OSGcxx.mlir
 #0 0x5613db47b508 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x11ef508)
 #1 0x5613db47901e llvm::sys::RunSignalHandlers() (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x11ed01e)
 #2 0x5613db47be9d SignalHandler(int) Signals.cpp:0:0
 #3 0x7fbe5ec96420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420)
 #4 0x5613de12a673 castAllocFuncResult(mlir::ConversionPatternRewriter&, mlir::Location, mlir::Value, mlir::MemRefType, mlir::Type, mlir::LLVMTypeConverter const&) AllocLikeConversion.cpp:0:0
 #5 0x5613de12a511 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+0x3e9e511)
 #6 0x5613de129d0d (anonymous namespace)::AllocOpLowering::allocateBuffer(mlir::ConversionPatternRewriter&, mlir::Location, mlir::Value, mlir::Operation*) const MemRefToLLVM.cpp:0:0
 #7 0x5613de12aed0 mlir::AllocLikeOpLLVMLowering::matchAndRewrite(mlir::Operation*, llvm::ArrayRef, mlir::ConversionPatternRewriter&) const (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x3e9eed0)
 #8 0x5613db77cf84 mlir::ConversionPattern::matchAndRewrite(mlir::Operation*, llvm::ArrayRef, mlir::ConversionPatternRewriter&) const (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x14f0f84)
 #9 0x5613de43a014 mlir::ConversionPattern::matchAndRewrite(mlir::Operation*, mlir::PatternRewriter&) const (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x41ae014)
#10 0x5613e1517791 void llvm::function_ref::callback_fn, llvm::function_ref, llvm::function_ref)::$_0>(long) PatternApplicator.cpp:0:0
#11 0x5613e151440b 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+0x728840b)
#12 0x5613de43b0e3 (anonymous namespace)::OperationLegalizer::legalize(mlir::Operation*, mlir::ConversionPatternRewriter&) DialectConversion.cpp:0:0
#13 0x5613de43a137 mlir::OperationConverter::convert(mlir::ConversionPatternRewriter&, mlir::Operation*) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x41ae137)
#14 0x5613de43b30f mlir::OperationConverter::convertOperations(llvm::ArrayRef) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x41af30f)
#15 0x5613de44136b mlir::applyPartialConversion(mlir::Operation*, mlir::ConversionTarget const&, mlir::FrozenRewritePatternSet const&, mlir::ConversionConfig) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x41b536b)
#16 0x5613de10deab (anonymous namespace)::FinalizeMemRefToLLVMConversionPass::runOnOperation() MemRefToLLVM.cpp:0:0
#17 0x5613de3dcec6 mlir::detail::OpToOpPassAdaptor::run(mlir::Pass*, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x4150ec6)
#18 0x5613de3dd7f0 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+0x41517f0)
#19 0x5613de3dfdc2 mlir::PassManager::run(mlir::Operation*) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x4153dc2)
#20 0x5613de3d853a performActions(llvm::raw_ostream&, std::shared_ptr const&, mlir::MLIRContext*, mlir::M

[llvm-bugs] [Bug 120953] [mlir] -lower-host-to-llvm crashes

2024-12-23 Thread LLVM Bugs via llvm-bugs 


Issue

120953




Summary

[mlir] -lower-host-to-llvm crashes




  Labels
  
mlir
  



  Assignees
  
  



  Reporter
  
  wwy6191
  




git version: bc29fc937c6cb4a210f80c93c79fc6ed97c801f8

system: `Ubuntu 18.04.6 LTS`

reproduce with: `mlir-opt  -lower-host-to-llvm a.mlir`


a.mlir: 
``` 
#map = affine_map<(d0) -> (d0)>
module {
  func.func @loop_nest_depth() {
%alloc = memref.alloca() :memref<256x8xf32, #spirv.storage_class>
affine.for %arg0 = 0 to 32 step 4 {
 affine.for %arg1 = 0 to 8 step 2 {
%0 = affine.apply #map(%arg1)
 %1 = affine.load %alloc[%arg0, %0] : memref<256x8xf32, #spirv.storage_class>
  }
}
return
  }
}

``` 
stack trace:

``` 
/usr/lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/optional:438: _Tp &std::_Optional_base_impl>::_M_get() [_Tp = unsigned int, _Dp = std::_Optional_base]: Assertion 'this->_M_is_engaged()' 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 -lower-host-to-llvm /data/szy/MLIR/seed/seed29/tmp.lM6A8VYgS4.mlir
 #0 0x55f4925e2508 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x11ef508)
 #1 0x55f4925e001e llvm::sys::RunSignalHandlers() (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x11ed01e)
 #2 0x55f4925e2e9d SignalHandler(int) Signals.cpp:0:0
 #3 0x7f753f805420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420)
 #4 0x7f753ee4200b raise /build/glibc-LcI20x/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:51:1
 #5 0x7f753ee21859 abort /build/glibc-LcI20x/glibc-2.31/stdlib/abort.c:81:7
 #6 0x55f49527557f (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x3e8257f)
 #7 0x55f495291ed0 mlir::AllocLikeOpLLVMLowering::matchAndRewrite(mlir::Operation*, llvm::ArrayRef, mlir::ConversionPatternRewriter&) const (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x3e9eed0)
 #8 0x55f4928e3f84 mlir::ConversionPattern::matchAndRewrite(mlir::Operation*, llvm::ArrayRef, mlir::ConversionPatternRewriter&) const (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x14f0f84)
 #9 0x55f4955a1014 mlir::ConversionPattern::matchAndRewrite(mlir::Operation*, mlir::PatternRewriter&) const (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x41ae014)
#10 0x55f49867e791 void llvm::function_ref::callback_fn, llvm::function_ref, llvm::function_ref)::$_0>(long) PatternApplicator.cpp:0:0
#11 0x55f49867b40b 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+0x728840b)
#12 0x55f4955a20e3 (anonymous namespace)::OperationLegalizer::legalize(mlir::Operation*, mlir::ConversionPatternRewriter&) DialectConversion.cpp:0:0
#13 0x55f4955a1137 mlir::OperationConverter::convert(mlir::ConversionPatternRewriter&, mlir::Operation*) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x41ae137)
#14 0x55f4955a230f mlir::OperationConverter::convertOperations(llvm::ArrayRef) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x41af30f)
#15 0x55f4955a836b mlir::applyPartialConversion(mlir::Operation*, mlir::ConversionTarget const&, mlir::FrozenRewritePatternSet const&, mlir::ConversionConfig) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x41b536b)
#16 0x55f4953636cd (anonymous namespace)::LowerHostCodeToLLVM::runOnOperation() ConvertLaunchFuncToLLVMCalls.cpp:0:0
#17 0x55f495543ec6 mlir::detail::OpToOpPassAdaptor::run(mlir::Pass*, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x4150ec6)
#18 0x55f4955447f0 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+0x41517f0)
#19 0x55f495546dc2 mlir::PassManager::run(mlir::Operation*) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x4153dc2)
#20 0x55f49553f53a performActions(llvm::raw_ostream&, std::shared_ptr const&, mlir::MLIRContext*, mlir::MlirOptMainConfig const&) MlirOptMain.cpp:0:0
#21 0x55f49553f18d 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
#22 0x55f4955eac65 mlir::splitAndProcessBuffer(std::unique_ptr>, llvm::function_ref>, llvm::raw_ostre

[llvm-bugs] [Bug 120954] [mlir] -lower-host-to-llvm crashes

2024-12-23 Thread LLVM Bugs via llvm-bugs 


Issue

120954




Summary

[mlir] -lower-host-to-llvm crashes




  Labels
  
mlir
  



  Assignees
  
  



  Reporter
  
  wwy6191
  




git version: bc29fc937c6cb4a210f80c93c79fc6ed97c801f8

system: `Ubuntu 18.04.6 LTS`

reproduce with: `mlir-opt  -lower-host-to-llvm a.mlir`


a.mlir: 
``` 
#map = affine_map<(d0) -> (d0)>
module {
  func.func @loop_nest_depth() {
%alloc = memref.alloca() :memref<256x8xf32, #spirv.storage_class>
affine.for %arg0 = 0 to 32 step 4 {
 affine.for %arg1 = 0 to 8 step 2 {
%0 = affine.apply #map(%arg1)
 %1 = affine.load %alloc[%arg0, %0] : memref<256x8xf32, #spirv.storage_class>
  }
}
return
  }
}

``` 
stack trace:

``` 
/usr/lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/optional:438: _Tp &std::_Optional_base_impl>::_M_get() [_Tp = unsigned int, _Dp = std::_Optional_base]: Assertion 'this->_M_is_engaged()' 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 -lower-host-to-llvm /data/szy/MLIR/seed/seed29/tmp.lM6A8VYgS4.mlir
 #0 0x5573d3861508 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x11ef508)
 #1 0x5573d385f01e llvm::sys::RunSignalHandlers() (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x11ed01e)
 #2 0x5573d3861e9d SignalHandler(int) Signals.cpp:0:0
 #3 0x7f57ee10d420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420)
 #4 0x7f57ed74a00b raise /build/glibc-LcI20x/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:51:1
 #5 0x7f57ed729859 abort /build/glibc-LcI20x/glibc-2.31/stdlib/abort.c:81:7
 #6 0x5573d64f457f (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x3e8257f)
 #7 0x5573d6510ed0 mlir::AllocLikeOpLLVMLowering::matchAndRewrite(mlir::Operation*, llvm::ArrayRef, mlir::ConversionPatternRewriter&) const (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x3e9eed0)
 #8 0x5573d3b62f84 mlir::ConversionPattern::matchAndRewrite(mlir::Operation*, llvm::ArrayRef, mlir::ConversionPatternRewriter&) const (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x14f0f84)
 #9 0x5573d6820014 mlir::ConversionPattern::matchAndRewrite(mlir::Operation*, mlir::PatternRewriter&) const (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x41ae014)
#10 0x5573d98fd791 void llvm::function_ref::callback_fn, llvm::function_ref, llvm::function_ref)::$_0>(long) PatternApplicator.cpp:0:0
#11 0x5573d98fa40b 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+0x728840b)
#12 0x5573d68210e3 (anonymous namespace)::OperationLegalizer::legalize(mlir::Operation*, mlir::ConversionPatternRewriter&) DialectConversion.cpp:0:0
#13 0x5573d6820137 mlir::OperationConverter::convert(mlir::ConversionPatternRewriter&, mlir::Operation*) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x41ae137)
#14 0x5573d682130f mlir::OperationConverter::convertOperations(llvm::ArrayRef) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x41af30f)
#15 0x5573d682736b mlir::applyPartialConversion(mlir::Operation*, mlir::ConversionTarget const&, mlir::FrozenRewritePatternSet const&, mlir::ConversionConfig) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x41b536b)
#16 0x5573d65e26cd (anonymous namespace)::LowerHostCodeToLLVM::runOnOperation() ConvertLaunchFuncToLLVMCalls.cpp:0:0
#17 0x5573d67c2ec6 mlir::detail::OpToOpPassAdaptor::run(mlir::Pass*, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x4150ec6)
#18 0x5573d67c37f0 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+0x41517f0)
#19 0x5573d67c5dc2 mlir::PassManager::run(mlir::Operation*) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x4153dc2)
#20 0x5573d67be53a performActions(llvm::raw_ostream&, std::shared_ptr const&, mlir::MLIRContext*, mlir::MlirOptMainConfig const&) MlirOptMain.cpp:0:0
#21 0x5573d67be18d 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
#22 0x5573d6869c65 mlir::splitAndProcessBuffer(std::unique_ptr>, llvm::function_ref>, llvm::raw_ostre

[llvm-bugs] [Bug 120941] Crash backtrace in mltc-opt with AffineExpr operations.

2024-12-23 Thread LLVM Bugs via llvm-bugs 


Issue

120941




Summary

Crash backtrace in mltc-opt with AffineExpr operations.




  Labels
  
new issue
  



  Assignees
  
  



  Reporter
  
  wodylm
  




when  I use affineExpr's operator*:
 #0 0x7f9ebf90145f llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /home/yongliangzha/mltc/modules/llvm-project/llvm/lib/Support/Unix/Signals.inc:723:22
 #1 0x7f9ebf901912 PrintStackTraceSignalHandler(void*) /home/yongliangzha/mltc/modules/llvm-project/llvm/lib/Support/Unix/Signals.inc:798:1
 #2 0x7f9ebf8fe833 llvm::sys::RunSignalHandlers() /home/yongliangzha/mltc/modules/llvm-project/llvm/lib/Support/Signals.cpp:105:20
 #3 0x7f9ebf900b2a SignalHandler(int) /home/yongliangzha/mltc/modules/llvm-project/llvm/lib/Support/Unix/Signals.inc:413:1
 #4 0x7f9ea384e090 (/lib/x86_64-linux-gnu/libc.so.6+0x43090)
 #5 0x7f9ebb59afa2 mlir::AffineExpr::getKind() const /home/yongliangzha/mltc/modules/llvm-project/mlir/lib/IR/AffineExpr.cpp:31:16
 #6 0x7f9ebb59bc05 mlir::AffineExpr::isSymbolicOrConstant() const /home/yongliangzha/mltc/modules/llvm-project/mlir/lib/IR/AffineExpr.cpp:170:3
 #7 0x7f9ebb59bc75 mlir::AffineExpr::isSymbolicOrConstant() const /home/yongliangzha/mltc/modules/llvm-project/mlir/lib/IR/AffineExpr.cpp:184:49
 #8 0x7f9ebb59e512 simplifyMul(mlir::AffineExpr, mlir::AffineExpr) /home/yongliangzha/mltc/modules/llvm-project/mlir/lib/IR/AffineExpr.cpp:771:7
 #9 0x7f9ebb59e7d4 mlir::AffineExpr::operator*(mlir::AffineExpr) const /home/yongliangzha/mltc/modules/llvm-project/mlir/lib/IR/AffineExpr.cpp:809:49
#10 0x7f9eb411346b mltc::lnpu::CosAffineCompute::computeAffineInt(mlir::Operation*, mlir::OpBuilder)::'lambda1'(mlir::Operation*)::operator()(mlir::Operation*) const /home/yongliangzha/mltc/mltc/dialect/npu/transforms/utils.h:1035:35
#11 0x7f9eb4114685 mltc::lnpu::CosAffineCompute::computeAffineInt(mlir::Operation*, mlir::OpBuilder) /home/yongliangzha/mltc/mltc/dialect/npu/transforms/utils.h:1231:1
#12 0x7f9eb2ab6a41 mltc::lnpu::AffineCompute::visitArithOp(mlir::Operation*, mlir::OpBuilder) /home/yongliangzha/mltc/mltc/dialect/npu/transforms/utils.h:551:21



___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 120977] scan-build division by zero while calculating the stats

2024-12-23 Thread LLVM Bugs via llvm-bugs 


Issue

120977




Summary

scan-build division by zero while calculating the stats




  Labels
  
new issue
  



  Assignees
  
  



  Reporter
  
  BebeSparkelSparkel
  




```txt
scan-build: Analysis run complete.
Illegal division by zero at /home/wjr/llvm-project/build/bin/scan-build line 500.
```

Line 500

```perl
  my $PercentAborted = sprintf("%.2f", $Aborted / $TotalFunctions * 100);
```

in the function `CalcStats`

```perl
sub CalcStats {
  my $Stats = shift;

  my $TotalBlocks = 0;
  my $UnreachedBlocks = 0;
  my $TotalFunctions = scalar(@$Stats);
  my $BlockAborted = 0;
  my $WorkListAborted = 0;
  my $Aborted = 0;

  # Calculate the unique files
  my $FilesHash = {};

  foreach my $Row (@$Stats) {
$FilesHash->{$Row->{Filename}} = 1;
$TotalBlocks += $Row->{Total};
$UnreachedBlocks += $Row->{Unreachable};
 $BlockAborted++ if $Row->{Aborted} eq 'yes';
$WorkListAborted++ if $Row->{Empty} eq 'no';
$Aborted++ if $Row->{Aborted} eq 'yes' || $Row->{Empty} eq 'no';
  }

  my $TotalFiles = scalar(keys(%$FilesHash));

  # Calculations
  my $PercentAborted = sprintf("%.2f", $Aborted / $TotalFunctions * 100);
  my $PercentBlockAborted = sprintf("%.2f", $BlockAborted / $TotalFunctions
 * 100);
  my $PercentWorkListAborted = sprintf("%.2f", $WorkListAborted /
  $TotalFunctions * 100);
  my $PercentBlocksUnreached = sprintf("%.2f", $UnreachedBlocks / $TotalBlocks
  * 100);

  my $StatsString = "Analyzed $TotalBlocks blocks in $TotalFunctions functions"
. " in $TotalFiles files\n"
. "$Aborted functions aborted early ($PercentAborted%)\n"
. "$BlockAborted had aborted blocks ($PercentBlockAborted%)\n"
. "$WorkListAborted had unfinished worklists ($PercentWorkListAborted%)\n"
. "$UnreachedBlocks blocks were never reached ($PercentBlocksUnreached%)\n";

  return $StatsString;
}
```

The command was:

```sh
#!/bin/sh

# Create a clean output directory
REPORT_DIR="/tmp/iked-analysis"
mkdir -p "$REPORT_DIR"

~/llvm-project/build/bin/scan-build \
  --status-bugs \
  --use-cc=clang \
  -analyze-headers \
  -constraints range \
 -enable-checker alpha.core.PointerArithmetic \
  -enable-checker alpha.core.PointerSub \
  -enable-checker alpha.security.ArrayBound \
 -enable-checker alpha.unix.Stream \
  -enable-checker core.CallAndMessage \
  -enable-checker core.DivideZero \
  -enable-checker core.NullDereference \
  -enable-checker core.uninitialized.ArraySubscript \
  -enable-checker core.uninitialized.Assign \
  -enable-checker core.uninitialized.Branch \
  -enable-checker deadcode.DeadStores \
 -enable-checker security \
  -enable-checker unix.API \
  -enable-checker unix.Malloc \
  -enable-checker unix.cstring.BadSizeArg \
 -enable-checker unix.cstring.NullArg \
  -maxloop 30 \
  -o "$REPORT_DIR" \
  -stats \
  -v \
  make \
  CFLAGS="-Wall -I. -Wstrict-prototypes -Wmissing-prototypes \
  -Wmissing-declarations -Wshadow -Wpointer-arith -Wcast-qual \
  -Wsign-compare -DDEBUG"
```

in the OpenBSD iked src directory.


___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 120961] A few questions about programming Clang Static Analyzer checkers.

2024-12-23 Thread LLVM Bugs via llvm-bugs 


Issue

120961




Summary

A few questions about programming Clang Static Analyzer checkers.




  Labels
  
clang
  



  Assignees
  
  



  Reporter
  
  LuMingYinDetect
  




Dear LLVM Project Developers,

I apologize for the interruption. Recently, I encountered some issues during the process of writing Clang Static Analyzer checkers that I have been unable to resolve. Specifically, the test code is as follows:
`int custom_malloc(int **ptr, size_t size,struct Person *person) {
*ptr = (int *)malloc(size);
if (*ptr == NULL) {
 printf("Error: Memory allocation failed.\n");
}
return 1;
}`
In the checker, I matched the return statement using the checkEndFunction callback. I want to retrieve the SymbolRef and corresponding MemRegion for the function parameter ptr when the program reaches the return statement (in the test code, ptr points to a new memory region). However, I'm not sure which interface to use to obtain the assignment status of the function's parameters within the function at this point.I look forward to your reply!


___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 120970] "Already live at def" assertion in RegisterCoalescer

2024-12-23 Thread LLVM Bugs via llvm-bugs 


Issue

120970




Summary

"Already live at def" assertion in RegisterCoalescer




  Labels
  
llvm:regalloc
  



  Assignees
  
  



  Reporter
  
  arsenm
  




[already-live-at-def.mir.zip](https://github.com/user-attachments/files/18230543/already-live-at-def.mir.zip)


```
llc -mtriple=amdgcn-amd-amdhsa -mcpu=gfx942 -o /dev/null -run-pass=register-coalescer -verify-coalescing /Users/matt/src/llvm-project/llvm/test/CodeGen/AMDGPU/already-live-at-def.mir
Assertion failed: (SlotIndex::isEarlierInstr(Def, S->start) && "Already live at def"), function createDeadDef, file LiveInterval.cpp, line 114.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0.	Program arguments: ./bin/llc -mtriple=amdgcn-amd-amdhsa -mcpu=gfx942 -o /dev/null -run-pass=register-coalescer -verify-coalescing /Users/matt/src/llvm-project/llvm/test/CodeGen/AMDGPU/already-live-at-def.mir
1.	Running pass 'Function Pass Manager' on module '/Users/matt/src/llvm-project/llvm/test/CodeGen/AMDGPU/already-live-at-def.mir'.
2.	Running pass 'Register Coalescer' on function '@already_live_at_def'
 #0 0x0001090126fc llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/Users/matt/src/llvm-project/build_debug/bin/llc+0x106b066fc)
 #1 0x000109012c6c PrintStackTraceSignalHandler(void*) (/Users/matt/src/llvm-project/build_debug/bin/llc+0x106b06c6c)
 #2 0x000109010a64 llvm::sys::RunSignalHandlers() (/Users/matt/src/llvm-project/build_debug/bin/llc+0x106b04a64)
 #3 0x000109013584 SignalHandler(int) (/Users/matt/src/llvm-project/build_debug/bin/llc+0x106b07584)
 #4 0x0001850a0184 (/usr/lib/system/libsystem_platform.dylib+0x180484184)
 #5 0x00018506af70 (/usr/lib/system/libsystem_pthread.dylib+0x18044ef70)
 #6 0x000184f77908 (/usr/lib/system/libsystem_c.dylib+0x18035b908)
 #7 0x000184f76c1c (/usr/lib/system/libsystem_c.dylib+0x18035ac1c)
 #8 0x000106b518f8 (anonymous namespace)::CalcLiveRangeUtilBase<(anonymous namespace)::CalcLiveRangeUtilVector, llvm::LiveRange::Segment*, llvm::SmallVector>::createDeadDef(llvm::SlotIndex, llvm::BumpPtrAllocatorImpl*, llvm::VNInfo*) (/Users/matt/src/llvm-project/build_debug/bin/llc+0x1046458f8)
 #9 0x000106b50f70 llvm::LiveRange::createDeadDef(llvm::SlotIndex, llvm::BumpPtrAllocatorImpl&) (/Users/matt/src/llvm-project/build_debug/bin/llc+0x104644f70)
#10 0x000106fd0754 (anonymous namespace)::RegisterCoalescer::reMaterializeTrivialDef(llvm::CoalescerPair const&, llvm::MachineInstr*, bool&) (/Users/matt/src/llvm-project/build_debug/bin/llc+0x104ac4754)
#11 0x000106fcd000 (anonymous namespace)::RegisterCoalescer::joinCopy(llvm::MachineInstr*, bool&, llvm::SmallPtrSetImpl&) (/Users/matt/src/llvm-project/build_debug/bin/llc+0x104ac1000)
#12 0x000106fca1c4 (anonymous namespace)::RegisterCoalescer::copyCoalesceWorkList(llvm::MutableArrayRef) (/Users/matt/src/llvm-project/build_debug/bin/llc+0x104abe1c4)
#13 0x000106fc73c8 (anonymous namespace)::RegisterCoalescer::joinAllIntervals() (/Users/matt/src/llvm-project/build_debug/bin/llc+0x104abb3c8)
#14 0x000106fc4f10 (anonymous namespace)::RegisterCoalescer::runOnMachineFunction(llvm::MachineFunction&) (/Users/matt/src/llvm-project/build_debug/bin/llc+0x104ab8f10)

```

If the unused $vgpr0 block live in is removed, the assert is avoided but there is a verifier error after coalescing 


___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 120974] [DebugInfo] DW_AT_object_pointer not emitted for explicit object parameter

2024-12-23 Thread LLVM Bugs via llvm-bugs 


Issue

120974




Summary

[DebugInfo] DW_AT_object_pointer not emitted for explicit object parameter




  Labels
  
new issue
  



  Assignees
  
  



  Reporter
  
  Michael137
  




Using C++23's `deducing this`:
```
struct Foo {
void x(this Foo && self) {}
};

int main() { Foo{}.x(); }
```

Neither Clang nor GCC attach a `DW_AT_object_pointer` to the `this` parameter DIE: 
https://godbolt.org/z/h4jeT54G5

We probably should be doing so (LLDB will need to rely on this attribute in the future to distinguish static vs. non-static methods..see https://github.com/llvm/llvm-project/issues/120973).
In the DWARFv5 spec chapter "5.7.8 Member Function Entries" we state:
```
If the member function entry describes a non-static member function, then that
entry has a DW_AT_object_pointer attribute whose value is a reference to the
formal parameter entry that corresponds to the object for which the function is
called. The name attribute of that formal parameter is defined by the current
language (for example, this for C++ or self for Objective C and some other
languages). That parameter also has a DW_AT_artificial attribute whose value is
true.
Conversely, if the member function entry describes a static member function, the
entry does not have a DW_AT_object_pointer attribute.


In C++, non-static member functions can have const-volatile qualifiers, which affect the
type of the first formal parameter (the “this”-pointer).

```

Might be worth updating the non-normative text in this section. @dwblaikie @adrian-prantl 


___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 120973] [DebugInfo] DW_AT_object_pointer not attached to method declarations

2024-12-23 Thread LLVM Bugs via llvm-bugs 


Issue

120973




Summary

[DebugInfo] DW_AT_object_pointer not attached to method declarations




  Labels
  
new issue
  



  Assignees
  
  



  Reporter
  
  Michael137
  




[DWARF's `DW_AT_object_pointer`](https://dwarfstd.org/issues/050711.2.html) indicates which `DW_TAG_formal_parameter` corresponds to the function object that the method is being called on.

One motivator for this attribute from the original proposal is that it can be used to determine whether a C++ method is static or not. LLDB does need to distinguish static vs. non-static methods, but can't rely on `DW_AT_object_pointer` at the moment because Clang does not emit it on the declaration DIE (only on the definition). GCC emits it on both. See https://godbolt.org/z/3TWjTfWon

So LLDB currently relies on the existence of a `DW_TAG_formal_parameter` called `this` which is a pointer type. With C++23, we can't rely on either of these being true because of the `deducing this` feature: https://godbolt.org/z/h4jeT54G5 (though there's a bug in both Clang and GCC here where we don't emit the `DW_AT_object_pointer` for an explicit object parameter, will raise a separate issue for it)

This issue proposes adding the `DW_AT_object_pointer` to declarations too.


___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 120989] [IR][LLI] Crash on interpretation (segmentation fault)

2024-12-23 Thread LLVM Bugs via llvm-bugs 


Issue

120989




Summary

[IR][LLI] Crash on interpretation (segmentation fault)




  Labels
  
new issue
  



  Assignees
  
  



  Reporter
  
  wesuRage
  




```PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0.  Program arguments: lli --extra-module=libs/lib.ll output.ll
 #0 0x56370312089b llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/usr/local/llvm-19/bin/lli+0x13bc89b)
 #1 0x56370311de3b SignalHandler(int) Signals.cpp:0:0
 #2 0x7f26d9323d20 (/lib/x86_64-linux-gnu/libc.so.6+0x3fd20)
 #3 0x7f26d9952195 
 #4 0x7f26d995400b 
 #5 0x563702c4a9b1 llvm::orc::runAsMain(int (*)(int, char**), llvm::ArrayRef, std::allocator>>, std::optional) (/usr/local/llvm-19/bin/lli+0xee69b1)
 #6 0x56370213bd5e runOrcJIT(char const*) (/usr/local/llvm-19/bin/lli+0x3d7d5e)
 #7 0x5637020a0aa8 main (/usr/local/llvm-19/bin/lli+0x33caa8)
 #8 0x7f26d930dd68 __libc_start_call_main ./csu/../sysdeps/nptl/libc_start_call_main.h:74:3
 #9 0x7f26d930de25 call_init ./csu/../csu/libc-start.c:128:20
#10 0x7f26d930de25 __libc_start_main ./csu/../csu/libc-start.c:347:5
#11 0x56370212b4c1 _start (/usr/local/llvm-19/bin/lli+0x3c74c1)
```


___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 120992] [BOLT][AArch64] unsupported CFI opcode on Ubuntu 24.04 and AL2023

2024-12-23 Thread LLVM Bugs via llvm-bugs 


Issue

120992




Summary

[BOLT][AArch64] unsupported CFI opcode on Ubuntu 24.04 and AL2023




  Labels
  
BOLT
  



  Assignees
  
  



  Reporter
  
  salvatoredipietro
  





### Description
When attempting to use BOLT on Amazon Linux 2023 (AL2023) and Ubuntu24.04 using an AArch64  instance (AWS m7g.4xlarge), `llvm-bolt` command fails with "unsupported CFI opcode" error. This happen especially when I am trying to use long perf profile ( > 120 seconds).

### Environment
- Operating System: Amazon Linux 2023
- Hardware: AWS m7g.4xlarge instance (ARM-based)
- BOLT version: d33a2c58112bdd74225b0ff4f07acc49bed7e6ea
- Application used: PostgreSQL (build locally)

### Steps to Reproduce
1. Compile Postgres 16.4:
```bash
export CFLAGS="-g -O2 -fstack-protector-strong -fno-omit-frame-pointer -moutline-atomics -fno-reorder-blocks-and-partition"
export CPPFLAGS="-D_FORTIFY_SOURCE=2"
export LDFLAGS="-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,--emit-relocs"

## Compile it
./configure --disable-rpath --enable-debug --enable-dtrace --enable-tap-tests --enable-thread-safety --with-gnu-ld --with-icu --with-tcl --with-perl --with-python --with-openssl --with-libxml --with-libxslt --prefix=\${HOME}/usr/  
make -j\$(nproc)
sudo make install
```

2. Build BOLT on Amazon Linux 2023:
```bash
# BOLT  Installation on AL2023
sudo yum install  -y perf cmake ninja-build 
git clone https://github.com/llvm/llvm-project.git  
mkdir build   &&  cd build 
cmake -G Ninja ../llvm-project/llvm -DLLVM_TARGETS_TO_BUILD="X86;AArch64" -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=ON -DLLVM_ENABLE_PROJECTS="bolt"
ninja bolt
```

3. Run the following command:
```bash
# Get perf information
sudo perf record -e cycles:u  -u postgres -o perf.data -a -- sleep 600  

# Run perf2bolt cmd
sudo ~/build/bin/perf2bolt -p perf.data -o perf.boltdata --nl ${HOME}/usr/bin/postgres

# Run BOLT
sudo ~/build/bin/llvm-bolt ${HOME}/usr/bin/postgres -o ${HOME}/usr/bin/postgres.bolt --data perf.boltdata --reorder-blocks ext-tsp --reorder-functions hfsort --split-functions --split-all-cold --split-eh --update-debug-sections --dyno-stats --print-profile-stats  
```


### Error Message
```bash
BOLT-INFO: Starting stub-insertion pass
BOLT-INFO: Inserted 470 stubs in the hot area and 216 stubs in the cold area. Shared 0 times, iterated 3 times.
unsupported CFI opcode
UNREACHABLE executed at /home/ec2-user/llvm-project/bolt/lib/Core/BinaryFunction.cpp:2591!
 #0 0x00e3d810 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/home/ec2-user/build/bin/llvm-bolt+0xe3d810)
 #1 0x00e3b77c llvm::sys::RunSignalHandlers() (/home/ec2-user/build/bin/llvm-bolt+0xe3b77c)
 #2 0x00e3b8a8 SignalHandler(int) Signals.cpp:0:0
 #3 0xbe05d830 (linux-vdso.so.1+0x830)
 #4 0xbda83554 __pthread_kill_implementation (/lib64/libc.so.6+0x92554)
 #5 0xbda3a3e0 gsignal (/lib64/libc.so.6+0x493e0)
 #6 0xbda21224 abort (/lib64/libc.so.6+0x30224)
 #7 0x00dda54c (/home/ec2-user/build/bin/llvm-bolt+0xdda54c)
 #8 0x015d5a44 llvm::bolt::(anonymous namespace)::CFISnapshot::advanceTo(int) BinaryFunction.cpp:0:0
 #9 0x015d80b0 llvm::bolt::BinaryFunction::unwindCFIState(int, int, llvm::bolt::BinaryBasicBlock*, __gnu_cxx::__normal_iterator>>&) (/home/ec2-user/build/bin/llvm-bolt+0x15d80b0)
#10 0x015da5e0 llvm::bolt::BinaryFunction::finalizeCFIState() (/home/ec2-user/build/bin/llvm-bolt+0x15da5e0)
#11 0x0147a15c std::_Function_handler::_M_invoke(std::_Any_data const&, llvm::bolt::BinaryFunction&) BinaryPasses.cpp:0:0
#12 0x016345c8 std::_Function_handler, std::function, std::__cxx11::basic_string, std::allocator>, bool, unsigned int)::'lambda'(std::_Rb_tree_iterator>, std::_Rb_tree_iterator>) (std::_Rb_tree_iterator>, std::_Rb_tree_iterator>)>>::_M_invoke(std::_Any_data const&) ParallelUtilities.cpp:0:0
#13 0x00f1ff68 std::_Function_handler (), std::__future_base::_Task_setter, std::__future_base::_Result_base::_Deleter>, std::thread::_Invoker>>, void>>::_M_invoke(std::_Any_data const&) (/home/ec2-user/build/bin/llvm-bolt+0xf1ff68)
#14 0x00f2074c std::__future_base::_State_baseV2::_M_do_set(std::function ()>*, bool*) (/home/ec2-user/build/bin/llvm-bolt+0xf2074c)
#15 0xbda86980 __pthread_once_slow (/lib64/libc.so.6+0x95980)
#16 0x00f205bc std::__future_base::_Deferred_state>>, void>::_M_complete_async() (/home/ec2-user/build/bin/llvm-bolt+0xf205bc)
#17 0x00f24eec std::_Function_handler llvm::ThreadPoolInterface::asyncImpl(std::function, llvm::ThreadPoolTaskGroup*)::'lambda'()>::_M_invoke(std::_Any_data const&) (/home/ec2-user/build/bin/llvm-bolt+0xf24eec)
#18 0x023f057c llvm::StdThreadPool::processTasks(llvm::ThreadPoolTaskGroup*) (/home/ec2-user/build/bin/llvm-bolt+0x23f057c)
#

[llvm-bugs] [Bug 120993] [llvm] Incorrect vectorized codegen for Cortex-M 55

2024-12-23 Thread LLVM Bugs via llvm-bugs 


Issue

120993




Summary

[llvm] Incorrect vectorized codegen for Cortex-M 55




  Labels
  
backend:ARM,
llvm:codegen
  



  Assignees
  
  



  Reporter
  
  PiJoules
  




```
struct Functor {
  void assignCoeff(float &dst, const float &src) { dst += src; }
};

struct Kernel {
  float *dst;
  const float *src;
  Functor f;

  void assignCoeff(int i) {
f.assignCoeff(dst[i], src[i * 4]);
 }
};

void func(Kernel &kernel, int size) {
  //#pragma clang loop vectorize(disable)
  for (int i = 0; i < size; ++i)
 kernel.assignCoeff(i);
}
```

Clang seems to produce incorrect codegen when compiling this snippet with `/usr/local/google/home/leonardchan/misc/clang-cipd-latest-2/bin/clang++ -mcpu=cortex-m55 -mthumb -mfloat-abi=hard -march=armv8.1-m.main+mve.fp+fp.dp --target=arm-none-eabi -O2  -c /tmp/test.cc -fno-unroll-loops`

```
_Z4funcR6Kerneli:
.fnstart
@ %bb.0:
 .save   {r7, lr}
push{r7, lr}
cmp r1, #1
 it  lt
poplt   {r7, pc}
.LBB0_1:
ldrdr0, r2, [r0]
add.w   r3, r2, r1, lsl #4
subsr3, #12
 cmp r0, r3
bhs .LBB0_5
@ %bb.2:
add.w   r3, r0, r1, lsl #2
cmp r2, r3
bhs .LBB0_5
@ %bb.3:
 dls lr, r1
.p2align2
.LBB0_4: @ =>This Inner Loop Header: Depth=1
vldrs0, [r2]
 vldrs2, [r0]
addsr2, #16
vadd.f32s0, s0, s2
vstmia  r0!, {s0}
le  lr, .LBB0_4
b .LBB0_7
.LBB0_5:
adr r3, .LCPI0_0
vldrw.u32   q0, [r3]
vadd.i32q0, q0, r2
dlstp.32lr, r1
 .p2align2
.LBB0_6:@ =>This Inner Loop Header: Depth=1
vldrw.u32   q1, [q0, #256]!
 vldrw.u32   q2, [r0]
vadd.f32q1, q1, q2
 vstrw.32q1, [r0], #16
letplr, .LBB0_6
.LBB0_7:
 pop {r7, pc}
.p2align4
@ %bb.8:
.LCPI0_0:
 .long   4294967040  @ 0xff00
.long 4294967104  @ 0xff40
.long   4294967168 @ 0xff80
.long   4294967232 @ 0xffc0
```

It looks like emits two separate loops that can be taken in `func` depending on if there's potential overlap between `src` and `dst`. This check is done under `.LBB0_1` which will continue to `.LBB0_5` if no overlap is detected. At a high level, the check is `if (dst >= src + size * 16 - 12 || src >= dst + size * 4) goto .LBB0_5`. This branch is where the vectorized instructions are emitted. Effectively, `.LBB0_5` *should* add four initial negative offsets to the first multiple of four elements of src (`src[i]`, `src[(i+1) * 4]`, `src[(i+2) * 4]`, `src[(i+3) * 4]`, then `.LBB0_6` iterates through each `dst` and multiple of `src` then add and store them back to `dst`, but I think the offset calculation is slightly off.

Added some comments to the relevant bits:
```
.LBB0_5: 
 adr r3, .LCPI0_0
vldrw.u32   q0, [r3] // load the 4 32-bit vals into q0
vadd.i32q0, q0, r2   // add each val against src
 //   q0.0 = src - 256
 //   q0.1 = src - 192
 //   q0.2 = src - 128
 //   q0.3 = src - 64
dlstp.32lr, r1   // lr = size
.LBB0_6: 
vldrw.u32   q1, [q0, #256]!  // load the 4 32-bit vals from q0 into q1 + 256 and q1 += 256
 //   q1.0 = *(src)
 // q1.1 = *(src + 64)
 //   q1.2 = *(src + 128)
 //   q1.3 = *(src + 192)
vldrw.u32   q2, [r0] // load 4 32-bit values from dst
vadd.f32q1, q1, q2   // add each 32-bit val from src and dst
 //   q1.0 = *(src) + dst[0]
 //   q1.1 = *(src + 64) + dst[1]
 //   q1.2 = *(src + 128) + dst[2]
 //   q1.3 = *(src + 192) + dst[3]
vstrw.32q1, [r0], #16// store the 4 32-bit vals into dst then dst += 16
...
.LCPI0_0:
.long   4294967040 @ 0xff00 // -256
.long   4294967104 @ 0xff40 // -192
.long   4294967168  @ 0xff80 // -128
.long   4294967232  @ 0xffc0 // -64
```

Each of the offsets for the element accesses are 64 bytes apart when I think they should instead be 16 bytes since the access is `src[i * 4]` and `src` points to floats which should be 4 bytes. This can cause the `vldrw.u32 q1, [q0, #256]!` to access bad/uninitialized memory. I can verify with

```
__attribute__((optnone, noinline))
void testfunc() {
  constexpr int kSize = 2;
  float dst[kSize] = {1.0f

[llvm-bugs] [Bug 120987] [TySan] false positive with unions and placement-new

2024-12-23 Thread LLVM Bugs via llvm-bugs 


Issue

120987




Summary

[TySan] false positive with unions and placement-new




  Labels
  
false-positive
  



  Assignees
  
  



  Reporter
  
  Jannik2099
  




According to https://eel.is/c++draft/class.union#general-6 , the active union member in an union of non-POD types can be switched by invoking the dtor of the old member, and placement new-ing into the new member.

However, tysan does not seem to like this https://godbolt.org/z/nvnjzjGez

```cpp
#include 
#include 

class Foo {
   private:
short i{};

 public:
Foo() { printf("Foo nontrivial ctor\n"); }
~Foo() { printf("Foo nontrivial dtor\n"); }
};

class Bar {
   private:
 int i{};

   public:
Bar() { printf("Bar nontrivial ctor\n"); }
 ~Bar() { printf("Bar nontrivial dtor\n"); }
};

union U {
Foo foo;
Bar bar;
~U() {}
};

int main() { 
U u{ .foo = {}};
 u.foo.~Foo();
new (&u.bar) Bar;
}
```

```
==1==ERROR: TypeSanitizer: type-aliasing-violation on address 0x79117e2c (pc 0x61eed1b9b89d bp 0x79117d10 sp 0x79117cb8 tid 1)
WRITE of size 4 at 0x79117e2c with type int (in Bar at offset 0) accesses an existing object of type short (in Foo at offset 0)
#0 0x61eed1b9b89c (/app/output.s+0x2b89c)
```

This also happens with an union of POD or trivial types, but I'm not 100% sure on the standard working if placement-new is supposed to be allowed in these cases.


___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 121008] Constraints of template template parameter not checked for non-dependent arguments despite [temp.names]/8

2024-12-23 Thread LLVM Bugs via llvm-bugs 


Issue

121008




Summary

Constraints of template template parameter not checked for non-dependent arguments despite [temp.names]/8




  Labels
  
bug,
c++20,
clang:frontend,
concepts,
diverges-from:msvc,
diverges-from:edg
  



  Assignees
  
  



  Reporter
  
  hubert-reinterpretcast
  




https://wg21.link/temp.names#8 specifies that when

> all [_template-argument_](https://eel.is/c++draft/temp.names#nt:template-argument)s in the [_simple-template-id_](https://eel.is/c++draft/temp.names#nt:simple-template-id) are non-dependent ([[temp.dep.temp]](https://eel.is/c++draft/temp.dep.temp)), the associated constraints ([[temp.constr.decl]](https://eel.is/c++draft/temp.constr.decl)) of the constrained template shall be satisfied

where the "constrained template" may be a template template parameter.

Even when template is instantiated, GCC and Clang both fail to emit a diagnostic for a violation of this rule.
EDG and MSVC both diagnose without needing an instantiation.

See also: https://github.com/cplusplus/CWG/issues/658

Online compiler link: https://godbolt.org/z/fTzMnEPG8

### SOURCE (``)
```cpp
template 
concept C = false;

template  struct Q;

template  class TT>
struct A {
  TT *p; 
};

A a;
```

### COMPILER INVOCATION
```
clang++ -fsyntax-only -std=c++20 -Wall -Wextra -Werror -pedantic-errors -xc++ -
```

### ACTUAL COMPILER OUTPUT
(clean compile)

### EXPECTED COMPILER OUTPUT
(error)

### COMPILER VERSION INFO (`clang++ -v`)
```
clang version 20.0.0git (https://github.com/llvm/llvm-project.git b84218526d364cb9fda23bfca164d25a7b03a641)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /opt/wandbox/clang-head/bin
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/13
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/14
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/14
Candidate multilib: .;@m64
Selected multilib: .;@m64
```


___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 121009] ICE on invalid explicit instantiation as abbreviated function template: non-canonical or dependent type in IR-generation

2024-12-23 Thread LLVM Bugs via llvm-bugs 


Issue

121009




Summary

ICE on invalid explicit instantiation as abbreviated function template: non-canonical or dependent type in IR-generation




  Labels
  
c++20,
clang:frontend,
crash-on-invalid
  



  Assignees
  
  



  Reporter
  
  hubert-reinterpretcast
  




The following source attempts to explicitly instantiate something that is not completely-specialized.
Clang ICEs.

With assertions enabled, we see "non-canonical or dependent type in IR-generation".

Online compiler link: https://godbolt.org/z/WvKobK4P7

### SOURCE (``)
```cpp
template 
void f(auto) {}

template void f(auto);
```

### COMPILER INVOCATION
```
clang++ -std=c++20 -Wall -Wextra -Werror -pedantic-errors -S -o /dev/null -xc++ -
```

### ACTUAL COMPILER OUTPUT (without assertions enabled)
```
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/wandbox/clang-head/bin/clang++ -std=c++20 -Wall -Wextra -Werror -pedantic-errors -S -o /dev/null -xc++ -
1. :4:27: current parser token ';'
2.  :2:6: instantiating function definition 'f'
3.  :2:6: LLVM IR generation of declaration 'f'
4.  :2:6: Generating code for declaration 'f'
 #0 0x56a045979a98 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/wandbox/clang-head/bin/clang+++0x301da98)
 #1 0x56a04597788e llvm::sys::RunSignalHandlers() (/opt/wandbox/clang-head/bin/clang+++0x301b88e)
 #2 0x56a0458f75f9 CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0
 #3 0x7d1275445320 (/lib/x86_64-linux-gnu/libc.so.6+0x45320)
 #4 0x56a045c33a68 clang::CodeGen::CodeGenFunction::EmitReturnBlock() (/opt/wandbox/clang-head/bin/clang+++0x32d7a68)
 #5 0x56a045d32f3c clang::CodeGen::isAggregateTypeForABI(clang::QualType) (/opt/wandbox/clang-head/bin/clang+++0x33d6f3c)
 #6 0x56a045d27c9e (anonymous namespace)::X86_64ABIInfo::getIndirectResult(clang::QualType, unsigned int) const X86.cpp:0:0
 #7 0x56a045d2533d (anonymous namespace)::X86_64ABIInfo::computeInfo(clang::CodeGen::CGFunctionInfo&) const X86.cpp:0:0
 #8 0x56a045e7aab1 clang::CodeGen::CodeGenTypes::arrangeLLVMFunctionInfo(clang::CanQual, clang::CodeGen::FnInfoOpts, llvm::ArrayRef>, clang::FunctionType::ExtInfo, llvm::ArrayRef, clang::CodeGen::RequiredArgs) (/opt/wandbox/clang-head/bin/clang+++0x351eab1)
 #9 0x56a045e7ae8e arrangeLLVMFunctionInfo(clang::CodeGen::CodeGenTypes&, bool, llvm::SmallVectorImpl>&, clang::CanQual) CGCall.cpp:0:0
#10 0x56a045e7c3aa clang::CodeGen::CodeGenTypes::arrangeFunctionDeclaration(clang::FunctionDecl const*) (/opt/wandbox/clang-head/bin/clang+++0x35203aa)
#11 0x56a045c5d188 clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::GlobalDecl, llvm::GlobalValue*) (/opt/wandbox/clang-head/bin/clang+++0x3301188)
#12 0x56a045c565fa clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl, llvm::GlobalValue*) (/opt/wandbox/clang-head/bin/clang+++0x32fa5fa)
#13 0x56a045c5a48b clang::CodeGen::CodeGenModule::EmitGlobal(clang::GlobalDecl) (/opt/wandbox/clang-head/bin/clang+++0x32fe48b)
#14 0x56a045c55600 clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) (/opt/wandbox/clang-head/bin/clang+++0x32f9600)
#15 0x56a04601a5fc (anonymous namespace)::CodeGeneratorImpl::HandleTopLevelDecl(clang::DeclGroupRef) ModuleBuilder.cpp:0:0
#16 0x56a046013b7d clang::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef) (/opt/wandbox/clang-head/bin/clang+++0x36b7b7d)
#17 0x56a047df028f clang::Sema::InstantiateFunctionDefinition(clang::SourceLocation, clang::FunctionDecl*, bool, bool, bool) (/opt/wandbox/clang-head/bin/clang+++0x549428f)
#18 0x56a047ca8ee0 clang::Sema::ActOnExplicitInstantiation(clang::Scope*, clang::SourceLocation, clang::SourceLocation, clang::Declarator&) (/opt/wandbox/clang-head/bin/clang+++0x534cee0)
#19 0x56a04767dc34 clang::Parser::ParseDeclarationAfterDeclaratorAndAttributes(clang::Declarator&, clang::Parser::ParsedTemplateInfo const&, clang::Parser::ForRangeInit*) (/opt/wandbox/clang-head/bin/clang+++0x4d21c34)
#20 0x56a04767bfb1 clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, clang::DeclaratorContext, clang::ParsedAttributes&, clang::Parser::ParsedTemplateInfo&, clang::SourceLocation*, clang::Parser::ForRangeInit*) (/opt/wandbox/clang-head/bin/clang+++0x4d1ffb1)
#21 0x56a04770a4ee clang::Parser::ParseDeclarationAfterTemplate(clang::DeclaratorContext, clang::Parser::ParsedTemplateInfo&, clang::ParsingDeclRAIIObject&, clang::SourceLocation&, clang::ParsedAttributes&, clang::AccessSpecifier) (/opt/wandbox/clang-head/bin/clang+++0x4dae4ee)
#22 0x56a0477092d3 clang::Parser::ParseExplicitInstantiation(clang::DeclaratorContext, cl

[llvm-bugs] [Bug 121010] [HLSL] Treat structures in resources as packed

2024-12-23 Thread LLVM Bugs via llvm-bugs 


Issue

121010




Summary

[HLSL] Treat structures in resources as packed




  Labels
  
HLSL
  



  Assignees
  
  



  Reporter
  
  bogner
  




Structures in HLSL's StructuredBuffer need to be treated as packed, or otherwise made to skip adding any padding for compatibility with DXC.

Note: `dxc` does this by [hacking padding off](https://github.com/microsoft/DirectXShaderCompiler/blob/v1.8.2407/tools/clang/lib/CodeGen/CGRecordLayoutBuilder.cpp#L277) of *all* structures in CGRecordLowering::lower, like so:
```c++
#if 0 // HLSL Change - No padding for structure. Array offset will be handled when load/store is called
  Members.push_back(StorageInfo(Size, getIntNType(8)));
  clipTailPadding();
  determinePacked(NVBaseType);
 insertPadding();
  Members.pop_back();
  calculateZeroInit();
#endif // HLSL Change End
```

This is obviously not how we should handle this in upstream.


___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

[llvm-bugs] [Bug 121019] strict weak ordering check fail in SLPVectorizerPass::vectorizeGEPIndices

2024-12-23 Thread LLVM Bugs via llvm-bugs 


Issue

121019




Summary

strict weak ordering check fail in SLPVectorizerPass::vectorizeGEPIndices




  Labels
  
new issue
  



  Assignees
  
  



  Reporter
  
  sjamesr
  




I'm debugging an issue in wamrc, the ahead-of-time WASM compiler for the Web Assembly Micro Runtime (WAMR). For certain inputs, the compiler crashes with

```
assertion __comp(*(__first + __a), *(__first + __b)) failed: Your comparator is not a valid strict-weak ordering
```

Debugging this reveals a crash in LLVM:

```
* thread #1, name = 'wamrc', stop reason = SIGABRT
  * frame #0: 0x7f2cc2f20981 libc.so.6`raise + 161
frame #1: 0x7f2cc2f21df7 libc.so.6`abort + 247
frame #2: 0x561f5ec238ad wamrc`std::__u::__libcpp_verbose_abort(char const*, ...) + 173
frame #3: 0x561f5db1860e wamrc`void std::__u::__check_strict_weak_ordering_sorted>(llvm::StoreInst**, llvm::StoreInst**, llvm::function_ref&) + 574
 frame #4: 0x561f5da9dc9a wamrc`llvm::SLPVectorizerPass::vectorizeStoreChains(llvm::slpvectorizer::BoUpSLP&) + 826
frame #5: 0x561f5da9ca70 wamrc`llvm::SLPVectorizerPass::runImpl(llvm::Function&, llvm::ScalarEvolution*, llvm::TargetTransformInfo*, llvm::TargetLibraryInfo*, llvm::AAResults*, llvm::LoopInfo*, llvm::DominatorTree*, llvm::AssumptionCache*, llvm::DemandedBits*, llvm::OptimizationRemarkEmitter*) + 1824
frame #6: 0x561f5da9c199 wamrc`llvm::SLPVectorizerPass::run(llvm::Function&, llvm::AnalysisManager&) + 1385
frame #7: 0x561f5b3bd9e2 wamrc`llvm::detail::PassModel>::run(llvm::Function&, llvm::AnalysisManager&) + 18
frame #8: 0x561f5e8aa137 wamrc`llvm::PassManager>::run(llvm::Function&, llvm::AnalysisManager&) + 615
frame #9: 0x561f5b3beee2 wamrc`llvm::detail::PassModel>, llvm::AnalysisManager>::run(llvm::Function&, llvm::AnalysisManager&) + 18
frame #10: 0x561f5e8ad2f8 wamrc`llvm::ModuleToFunctionPassAdaptor::run(llvm::Module&, llvm::AnalysisManager&) + 680
frame #11: 0x561f5b3bf142 wamrc`llvm::detail::PassModel>::run(llvm::Module&, llvm::AnalysisManager&) + 18
frame #12: 0x561f5e8a9197 wamrc`llvm::PassManager>::run(llvm::Module&, llvm::AnalysisManager&) + 743
frame #13: 0x561f5b3b9aa4 wamrc`aot_apply_llvm_new_pass_manager + 6708
frame #14: 0x561f5b37f498 wamrc`aot_compile_wasm + 280
frame #15: 0x561f5b3537d2 wamrc`main + 4290
frame #16: 0x7f2cc2f0c3d4 libc.so.6`__libc_start_main + 244
frame #17: 0x561f5b3526aa wamrc`_start + 42
```

The culprit appears to be in [StoreSorter](https://github.com/llvm/llvm-project/blob/main/llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp#L21704), which contains some code that is pretty fishy for a comparison function:

```c++
if (isa(V->getValueOperand()) ||
 isa(V2->getValueOperand()))
  return false;
```

If both StoreInsts are have UndefValue operands, then the ordering between them is not defined, hence why we see the assertion failure.

Would a fix like the following work?

```patch
diff --git a/llvm-project/llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp b/llvm-project/llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp
--- a/llvm-project/llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp
+++ b/llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp
@@ -21671,28 +21671,21 @@ bool SLPVectorizerPass::vectorizeStoreCh
   // compatible (have the same opcode, same parent), otherwise it is
   // definitely not profitable to try to vectorize them.
   auto &&StoreSorter = [this](StoreInst *V, StoreInst *V2) {
-if (V->getValueOperand()->getType()->getTypeID() <
- V2->getValueOperand()->getType()->getTypeID())
-  return true;
-if (V->getValueOperand()->getType()->getTypeID() >
- V2->getValueOperand()->getType()->getTypeID())
-  return false;
-if (V->getPointerOperandType()->getTypeID() <
- V2->getPointerOperandType()->getTypeID())
-  return true;
-if (V->getPointerOperandType()->getTypeID() >
- V2->getPointerOperandType()->getTypeID())
-  return false;
-if (V->getValueOperand()->getType()->getScalarSizeInBits() <
- V2->getValueOperand()->getType()->getScalarSizeInBits())
-  return true;
-if (V->getValueOperand()->getType()->getScalarSizeInBits() >
- V2->getValueOperand()->getType()->getScalarSizeInBits())
-  return false;
-// UndefValues are compatible with all other values.
-if (isa(V->getValueOperand()) ||
- isa(V2->getValueOperand()))
-  return false;
+if (auto T1 = V->getValueOperand()->getType()->getTypeID(),
+T2 = V2->getValueOperand()->getType()->getTypeID();
+T1 != T2) {
+ return T1 > T2;
+}
+if (auto T1 = V->getPointerOperandType()->getTypeID(),
+T2 = V2->getPointerOperandType()->getTypeID();
+T1 != T2) {
+ return T1 < T2;
+}
+if (auto S1 = V->getValueOperand()->getType()->getSca

[llvm-bugs] [Bug 121020] [Mlir] --affine-loop-fusion="mode=producer fusion-maximal" crashes in LoopFusion.cpp:301: createPrivateMemRef

2024-12-23 Thread LLVM Bugs via llvm-bugs 


Issue

121020




Summary

[Mlir] --affine-loop-fusion="mode=producer fusion-maximal" crashes in LoopFusion.cpp:301: createPrivateMemRef




  Labels
  
mlir
  



  Assignees
  
  



  Reporter
  
  Emilyaxe
  




git version: 7b23f413d1f

system: `Ubuntu 18.04.6 LTS`

reproduce with: `/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt a.mlir --affine-loop-fusion="mode=producer fusion-maximal"`


a.mlir: 
``` 
#map = affine_map<()[s0] -> (s0 + 5)>
#map1 = affine_map<()[s0] -> (s0 + 17)>
module {
  func.func private @func2() {
%0 = llvm.mlir.constant(2 : index) : i64
%2 = llvm.mlir.constant(0 : index) : i64
%3 = builtin.unrealized_conversion_cast %2 : i64 to index
%alloc = memref.alloc() {alignment = 64 : i64} : memref<8x18xf32>
%alloc_1 = memref.alloc() {alignment = 64 : i64} : memref<3xf32>
%alloc_2 = memref.alloc() {alignment = 64 : i64} : memref<3xindex>
affine.for %arg3 = 0 to 3 {
  %4 = affine.load %alloc_2[%arg3] : memref<3xindex>
 %5 = builtin.unrealized_conversion_cast %4 : index to i64
  %6 = llvm.sub %0, %5 : i64
  %7 = builtin.unrealized_conversion_cast %6 : i64 to index
  affine.store %7, %alloc_2[%arg3] : memref<3xindex>
}
 affine.for %arg3 = 0 to 3 {
  %4 = affine.load %alloc_2[%arg3] : memref<3xindex>
  %5 = affine.apply #map()[%4]
  %6 = affine.apply #map1()[%3]
  %7 = memref.load %alloc[%5, %6] : memref<8x18xf32>
 affine.store %7, %alloc_1[%arg3] : memref<3xf32>
}
return
 }
}
``` 
stack trace:

``` 
mlir-opt: /data/szy/MLIR/llvm-release/llvm-project/mlir/lib/Dialect/Affine/Transforms/LoopFusion.cpp:301: Value createPrivateMemRef(AffineForOp, Operation *, unsigned int, std::optional, uint64_t): Assertion `eltSize && "memrefs with size elt types expected"' 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 a.mlir "--affine-loop-fusion=mode=producer fusion-maximal"
 #0 0x56305543f508 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x11ef508)
 #1 0x56305543d01e llvm::sys::RunSignalHandlers() (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x11ed01e)
 #2 0x56305543fe9d SignalHandler(int) Signals.cpp:0:0
 #3 0x7fa8a5f02420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420)
 #4 0x7fa8a553f00b raise /build/glibc-LcI20x/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:51:1
 #5 0x7fa8a551e859 abort /build/glibc-LcI20x/glibc-2.31/stdlib/abort.c:81:7
 #6 0x7fa8a551e729 get_sysdep_segment_value /build/glibc-LcI20x/glibc-2.31/intl/loadmsgcat.c:509:8
 #7 0x7fa8a551e729 _nl_load_domain /build/glibc-LcI20x/glibc-2.31/intl/loadmsgcat.c:970:34
 #8 0x7fa8a552ffd6 (/lib/x86_64-linux-gnu/libc.so.6+0x33fd6)
 #9 0x56305556a052 (anonymous namespace)::GreedyFusion::performFusionsIntoDest(unsigned int, unsigned int) LoopFusion.cpp:0:0
#10 0x563055566105 (anonymous namespace)::GreedyFusion::fuseProducerConsumerNodes(unsigned int) LoopFusion.cpp:0:0
#11 0x563055565bae void llvm::function_ref::callback_fn<(anonymous namespace)::LoopFusion::runOnOperation()::$_0>(long, mlir::Operation*) LoopFusion.cpp:0:0
#12 0x563074ce void mlir::detail::walk(mlir::Operation*, llvm::function_ref, mlir::WalkOrder) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x13074ce)
#13 0x563055562f2a (anonymous namespace)::LoopFusion::runOnOperation() LoopFusion.cpp:0:0
#14 0x5630583a0ec6 mlir::detail::OpToOpPassAdaptor::run(mlir::Pass*, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x4150ec6)
#15 0x5630583a17f0 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+0x41517f0)
#16 0x5630583a3dc2 mlir::PassManager::run(mlir::Operation*) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x4153dc2)
#17 0x56305839c53a performActions(llvm::raw_ostream&, std::shared_ptr const&, mlir::MLIRContext*, mlir::MlirOptMainConfig const&) MlirOptMain.cpp:0:0
#18 0x56305839c18d 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
#19 0x563058447c65 mlir::splitAndProcessBuffer(std::unique_ptr>, llvm::function_ref>, llvm::raw_ostream&)>, llvm::raw_ostream&, llvm::StringRef, llvm::StringRef) (/data/szy/MLIR/llvm-release/llvm-

[llvm-bugs] [Bug 121014] Trying TySan: assert trying to build cmake: "Cannot get layout of forward declarations!"

2024-12-23 Thread LLVM Bugs via llvm-bugs 


Issue

121014




Summary

Trying TySan: assert trying to build cmake: "Cannot get layout of forward declarations!"




  Labels
  
new issue
  



  Assignees
  
  



  Reporter
  
  seanm
  




Was excited to see in llvm-weekly that TySan is in master, so I gave it a try.  I built clang and confirmed that build of clang could build my code. Then I added `-fsanitize=type` and rebuilt, and now I get an assert:

```
Assertion failed: (D && "Cannot get layout of forward declarations!"), function getASTRecordLayout, file RecordLayoutBuilder.cpp, line 3346.
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: /Users/sean/llvm/llvm-install/bin/clang++ -DLIBARCHIVE_STATIC -I/Users/sean/external/cmake-bin/Utilities -I/Users/sean/external/cmake-bin/Source -I/Users/sean/external/cmake/Source -I/Users/sean/external/cmake/Source/LexerParser -isystem /Users/sean/external/cmake/Utilities/std -isystem /Users/sean/external/cmake/Utilities -fsanitize=type -Wnon-virtual-dtor -Wcast-align -Wchar-subscripts -Wall -W -Wshadow -Wpointer-arith -Wformat-security -Wundef -std=c++17 -arch arm64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX15.2.sdk -mmacosx-version-min=14.7 -MD -MT Source/CMakeFiles/CMakeLib.dir/cmCMakeHostSystemInformationCommand.cxx.o -MF CMakeFiles/CMakeLib.dir/cmCMakeHostSystemInformationCommand.cxx.o.d -o CMakeFiles/CMakeLib.dir/cmCMakeHostSystemInformationCommand.cxx.o -c /Users/sean/external/cmake/Source/cmCMakeHostSystemInformationCommand.cxx
1.	 parser at end of file
2.	Per-file LLVM IR generation
3.	/Users/sean/external/cmake/Source/cmCMakeHostSystemInformationCommand.cxx:566:6: Generating code for declaration '(anonymous namespace)::QueryWindowsRegistry'
[ 70%] Building CXX object Source/CMakeFiles/CMakeLib.dir/cmExecProgramCommand.cxx.o
 #0 0x000106c2d960 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/Users/sean/llvm/llvm-install/bin/clang-20+0x102345960)
 #1 0x000106c2be7c llvm::sys::RunSignalHandlers() (/Users/sean/llvm/llvm-install/bin/clang-20+0x102343e7c)
 #2 0x000106c2d158 llvm::sys::CleanupOnSignal(unsigned long) (/Users/sean/llvm/llvm-install/bin/clang-20+0x102345158)
 #3 0x000106b90d70 CrashRecoverySignalHandler(int) (/Users/sean/llvm/llvm-install/bin/clang-20+0x1022a8d70)
 #4 0x000193f5e584 (/usr/lib/system/libsystem_platform.dylib+0x18047a584)
 #5 0x000193f2dc20 (/usr/lib/system/libsystem_pthread.dylib+0x180449c20)
 #6 0x000193e3aa30 (/usr/lib/system/libsystem_c.dylib+0x180356a30)
 #7 0x000193e39d20 (/usr/lib/system/libsystem_c.dylib+0x180355d20)
 #8 0x0001095d125c clang::ASTContext::getASTRecordLayout(clang::RecordDecl const*) const (.cold.3) (/Users/sean/llvm/llvm-install/bin/clang-20+0x104ce925c)
 #9 0x000109045510 clang::ASTContext::getASTRecordLayout(clang::RecordDecl const*) const (/Users/sean/llvm/llvm-install/bin/clang-20+0x10475d510)
#10 0x000108b7e6c0 clang::ASTContext::getTypeInfoImpl(clang::Type const*) const (/Users/sean/llvm/llvm-install/bin/clang-20+0x1042966c0)
#11 0x000108b7f6a8 clang::ASTContext::getTypeInfo(clang::Type const*) const (/Users/sean/llvm/llvm-install/bin/clang-20+0x1042976a8)
#12 0x000108b7f564 clang::ASTContext::getTypeInfoInChars(clang::Type const*) const (/Users/sean/llvm/llvm-install/bin/clang-20+0x104297564)
#13 0x000108b7fc3c clang::ASTContext::getTypeSizeInChars(clang::Type const*) const (/Users/sean/llvm/llvm-install/bin/clang-20+0x104297c3c)
#14 0x0001073b66ec clang::CodeGen::CodeGenTBAA::getTypeInfoHelper(clang::Type const*) (/Users/sean/llvm/llvm-install/bin/clang-20+0x102ace6ec)
#15 0x0001073b70f4 clang::CodeGen::CodeGenTBAA::getTypeInfo(clang::QualType) (/Users/sean/llvm/llvm-install/bin/clang-20+0x102acf0f4)
#16 0x000107402274 clang::CodeGen::SanitizerMetadata::reportGlobal(llvm::GlobalVariable*, clang::SourceLocation, llvm::StringRef, clang::QualType, clang::SanitizerMask, bool) (/Users/sean/llvm/llvm-install/bin/clang-20+0x102b1a274)
#17 0x000107402550 clang::CodeGen::SanitizerMetadata::reportGlobal(llvm::GlobalVariable*, clang::VarDecl const&, bool) (/Users/sean/llvm/llvm-install/bin/clang-20+0x102b1a550)
#18 0x00010737aa14 clang::CodeGen::CodeGenModule::GetOrCreateLLVMGlobal(llvm::StringRef, llvm::Type*, clang::LangAS, clang::VarDecl const*, clang::CodeGen::ForDefinition_t) (/Users/sean/llvm/llvm-install/bin/clang-20+0x102a92a14)
#19 0x00010737cf1c clang::CodeGen::CodeGenModule::GetAddrOfGlobalVar(clang::VarDecl const*, llvm::Type*, clang::CodeGen::ForDefinition_t) (/Users/sean/llvm/llvm-install/bin/clang-20+0x102a94f1c)
#20 0x0001071f2954 clang::CodeGen::CodeGenFunction::EmitDeclRefLValue(cla

[llvm-bugs] [Bug 121004] -Wglobal-constructors is silenced for derived classes with a virtual base destructor in c++2b mode

2024-12-23 Thread LLVM Bugs via llvm-bugs 


Issue

121004




Summary

-Wglobal-constructors is silenced for derived classes with a virtual base destructor in c++2b mode




  Labels
  
new issue
  



  Assignees
  
  



  Reporter
  
  apache-hb
  




When a class that contains a non trivial member inherits from a pure virtual base class that has an explicitly declared virtual destructor in c++2b mode -Wglobal-constructors is not raised, but an entry is still added to the .init_array to initialize the objects vtable before main. This behaviour is not present in c++20 mode. The entry is only added at -O0, at -O2 and higher `__cxx_global_var_init` is elided and the vtable is placed directly in the data section which makes this very hard to track down.

Godbolt reproducer link: https://godbolt.org/z/W355314dK


___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs