[llvm-bugs] [Bug 129022] Please diagnose on _Noreturn calls within [[gnu::const]], [[gnu::pure]], [[reproducible]], [[unsequenced]]
Issue 129022 Summary Please diagnose on _Noreturn calls within [[gnu::const]], [[gnu::pure]], [[reproducible]], [[unsequenced]] Labels new issue Assignees Reporter alejandro-colomar Please diagnose on _Noreturn calls within the body of a function with one of these attributes: [[gnu::const]], [[gnu::pure]], [[reproducible]], [[unsequenced]]. This is UB, and could be easily diagnosed. I'd put it in -Wextra for the moment, to be careful. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129021] clang++-21 crashed when using precompiled header
Issue
129021
Summary
clang++-21 crashed when using precompiled header
Labels
clang
Assignees
Reporter
sweihub
Hi
I have a cmake setup with precompiled headers
```cmake
# add the pch custom target as a dependency
add_dependencies(demo pch)
# add the flag
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -include-pch ${CMAKE_CURRENT_BINARY_DIR}/stdinc.h.pch")
# target
add_custom_target(pch COMMAND ${CMAKE_CXX_COMPILER} -std=c++26 -x c++-header ${CMAKE_CURRENT_SOURCE_DIR}/include/coin/stdinc.h -o ${CMAKE_CURRENT_BINARY_DIR}/stdinc.h.pch)
```
clang++-21 crashed when compiling
```log
➜ coin git:(develop) ✗ b
-- Configuring done (0.0s)
-- Generating done (0.0s)
-- Build files have been written to: /root/quant/algo/coin/build
[2/4] Building CXX object CMakeFiles/demo.dir/src/binance.cppm.o
FAILED: CMakeFiles/demo.dir/src/binance.cppm.o CMakeFiles/demo.dir/binance.pcm
/usr/bin/clang++-21 -I/root/quant/algo/coin/include -include-pch /root/quant/algo/coin/build/stdinc.h.pch -g -std=c++26 -MD -MT CMakeFiles/demo.dir/src/binance.cppm.o -MF CMakeFiles/demo.dir/src/binance.cppm.o.d @CMakeFiles/demo.dir/src/binance.cppm.o.modmap -o CMakeFiles/demo.dir/src/binance.cppm.o -c /root/quant/algo/coin/src/binance.cppm
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: /usr/lib/llvm-21/bin/clang -cc1 -triple x86_64-pc-linux-gnu -emit-obj -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name binance.cppm -mrelocation-model pic -pic-level 2 -pic-is-pie -mframe-pointer=all -fmath-errno -ffp-contract=on -fno-rounding-math -mconstructor-aliases -funwind-tables=2 -target-cpu x86-64 -tune-cpu generic -debug-info-kind=constructor -dwarf-version=5 -debugger-tuning=gdb -fdebug-compilation-dir=/root/quant/algo/coin/build -fcoverage-compilation-dir=/root/quant/algo/coin/build -resource-dir /usr/lib/llvm-21/lib/clang/21 -std=c++26 -fdeprecated-macro -ferror-limit 19 -fgnuc-version=4.2.1 -fno-implicit-modules -fmodule-file=websocket=CMakeFiles/demo.dir/websocket.pcm -fmodule-file=json=CMakeFiles/demo.dir/json.pcm -fmodule-file=web=CMakeFiles/demo.dir/web.pcm -fmodule-file=semaphore=CMakeFiles/demo.dir/semaphore.pcm -fmodule-file=ws=CMakeFiles/demo.dir/ws.pcm -fmodule-file=wss=CMakeFiles/demo.dir/wss.pcm -fskip-odr-check-in-gmf -fcxx-exceptions -fexceptions -faddrsig -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o CMakeFiles/demo.dir/src/binance.cppm.o -x pcm CMakeFiles/demo.dir/binance.pcm
#0 0x7f53018cbfef llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/usr/lib/llvm-21/bin/../lib/libLLVM.so.21.0+0x102efef)
#1 0x7f53018c9cf9 llvm::sys::RunSignalHandlers() (/usr/lib/llvm-21/bin/../lib/libLLVM.so.21.0+0x102ccf9)
#2 0x7f53018cc70d (/usr/lib/llvm-21/bin/../lib/libLLVM.so.21.0+0x102f70d)
#3 0x7f5300330330 (/lib/x86_64-linux-gnu/libc.so.6+0x45330)
#4 0x7f530b73506a clang::ASTReader::getLocalModuleFile(clang::serialization::ModuleFile&, unsigned int) const (/usr/lib/llvm-21/bin/../lib/libclang-cpp.so.21.0+0x253406a)
#5 0x7f530b7bbebb (/usr/lib/llvm-21/bin/../lib/libclang-cpp.so.21.0+0x25baebb)
#6 0x7f530b7ba2c9 clang::ASTReader::loadDeclUpdateRecords(clang::ASTReader::PendingUpdateRecord&) (/usr/lib/llvm-21/bin/../lib/libclang-cpp.so.21.0+0x25b92c9)
#7 0x7f530b769056 clang::ASTReader::finishPendingActions() (/usr/lib/llvm-21/bin/../lib/libclang-cpp.so.21.0+0x2568056)
#8 0x7f530b76c91b clang::ASTReader::FinishedDeserializing() (/usr/lib/llvm-21/bin/../lib/libclang-cpp.so.21.0+0x256b91b)
#9 0x7f530b75050a clang::ASTReader::ReadAST(llvm::StringRef, clang::serialization::ModuleKind, clang::SourceLocation, unsigned int, clang::serialization::ModuleFile**) (/usr/lib/llvm-21/bin/../lib/libclang-cpp.so.21.0+0x254f50a)
#10 0x7f530b8b1b22 clang::ASTUnit::LoadFromASTFile(llvm::StringRef, clang::PCHContainerReader const&, clang::ASTUnit::WhatToLoad, llvm::IntrusiveRefCntPtr, clang::FileSystemOptions const&, std::shared_ptr, std::shared_ptr, bool, clang::CaptureDiagsKind, bool, bool, llvm::IntrusiveRefCntPtr) (/usr/lib/llvm-21/bin/../lib/libclang-cpp.so.21.0+0x26b0b22)
#11 0x7f530b94dedd clang::FrontendAction::BeginSourceFile(clang::CompilerInstance&, clang::FrontendInputFile const&) (/usr/lib/llvm-21/bin/../lib/libclang-cpp.so.21.0+0x274cedd)
#12 0x7f530b8cafd5 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/usr/lib/llvm-21/bin/../lib/libclang-cpp.so.21.0+0x26c9fd5)
#13 0x7f530b9d522c clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/usr/lib/llvm-21/bin/../lib/libclang-cpp.so.21.0+0x27d422c)
#14 0x5583f62bd72f cc1_main(llvm::ArrayRef, char const*, void*) (/usr/lib/llvm-21/bi
[llvm-bugs] [Bug 129023] OpenMP Test Failures on Windows
Issue 129023 Summary OpenMP Test Failures on Windows Labels new issue Assignees Reporter omjavaid While testing LLVM 20 release several OpenMP runtime tests fail on Windows. These failures involve loop transformations and worksharing constructs, primarily affecting collapse scheduling and iterator transformations. The issue is not limited to release versions but persists in the latest development branch. Failing on both x64 and Arm64 Windows. **worksharing/for/omp_for_collapse_UpperTriangular.c** Error: Inefficient collapse scheduling, thread 0 assigned 2 iterations (should be 0-1). **worksharing/for/omp_for_collapse_LowerTriangularLessEqual.c** Error: Inefficient collapse scheduling, thread 3 assigned 2 iterations. **transform/interchange/iterfor.cpp** Error: CHECK-NEXT mismatch in expected iterator transformation output. **transform/tile/iterfor.cpp** Error: CHECK-NEXT mismatch in tile transformation output. **worksharing/for/omp_for_collapse_LowerTriangularLess.c** Error: Inefficient collapse scheduling, thread 5 assigned 2 iterations. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129034] [DAG] Convert MatchFunnelPosNeg to use SDPatternMatch matchers
Issue 129034 Summary [DAG] Convert MatchFunnelPosNeg to use SDPatternMatch matchers Labels good first issue, llvm:SelectionDAG Assignees Reporter RKSimon The IsBinOpImm lambda can be replaced with equivalent m_Srl / m_Shl / m_Xor etc. - along with m_Value / m_Specific / m_SpecificInt ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129043] [MLIR]`--pass-pipeline="builtin.module(func.func(test-match-reduction))"` triggers Assertion `Index < this->size() && "Invalid index!"' failed.
Issue
129043
Summary
[MLIR]`--pass-pipeline="builtin.module(func.func(test-match-reduction))"` triggers Assertion `Index < this->size() && "Invalid index!"' failed.
Labels
mlir
Assignees
Reporter
xisang0
Test on commit: https://github.com/llvm/llvm-project/commit/01cc1d13cd0c54bd4c29185b052fa5c16285dca7
steps to reproduce:
```
./mlir-opt test.mlir --pass-pipeline="builtin.module(func.func(test-match-reduction))"
```
test case:
```
func.func @pooling_ncw_sum_tensor(%input: tensor<1x3x10xf32>,
%kernel: tensor<3xf32>,
%output: tensor<1x3x8xf32>) {
%result = linalg.pooling_ncw_sum
{strides = dense<[1]> : tensor<1xi64>,
dilations = dense<[1]> : tensor<1xi64>}
ins(%input, %kernel : tensor<1x3x10xf32>, tensor<3xf32>)
outs(%output : tensor<1x3x8xf32>) -> tensor<1x3x8xf32>
return
}
```
crash trace:
```
mlir-opt: /home/llvm-project/llvm/include/llvm/ADT/ArrayRef.h:446: T &llvm::MutableArrayRef::operator[](size_t) const [T = mlir::OpOperand]: Assertion `Index < this->size() && "Invalid index!"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0. Program arguments: build/bin/mlir-opt test.mlir --pass-pipeline=builtin.module(func.func(test-match-reduction))
#0 0x5648b7c8bdd8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (build/bin/mlir-opt+0x10c8dd8)
#1 0x5648b7c898fe llvm::sys::RunSignalHandlers() (build/bin/mlir-opt+0x10c68fe)
#2 0x5648b7c8c7e1 SignalHandler(int, siginfo_t*, void*) Signals.cpp:0:0
#3 0x7fcbbaac0520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#4 0x7fcbbab149fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
#5 0x7fcbbaac0476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
#6 0x7fcbbaaa67f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
#7 0x7fcbbaaa671b (/lib/x86_64-linux-gnu/libc.so.6+0x2871b)
#8 0x7fcbbaab7e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96)
#9 0x5648b80add1b (build/bin/mlir-opt+0x14ead1b)
#10 0x5648bac9e4da mlir::matchReduction(llvm::ArrayRef, unsigned int, llvm::SmallVectorImpl&) (build/bin/mlir-opt+0x40db4da)
#11 0x5648baec2ff5 void llvm::function_ref::callback_fn<(anonymous namespace)::TestMatchReductionPass::runOnOperation()::'lambda'(mlir::Operation*)>(long, mlir::Operation*) TestMatchReduction.cpp:0:0
#12 0x5648b7d9de86 void mlir::detail::walk(mlir::Operation*, llvm::function_ref, mlir::WalkOrder) (build/bin/mlir-opt+0x11dae86)
#13 0x5648b7d9df1e void mlir::detail::walk(mlir::Operation*, llvm::function_ref, mlir::WalkOrder) (build/bin/mlir-opt+0x11daf1e)
#14 0x5648baec2de9 (anonymous namespace)::TestMatchReductionPass::runOnOperation() TestMatchReduction.cpp:0:0
#15 0x5648bacc1373 mlir::detail::OpToOpPassAdaptor::run(mlir::Pass*, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int) (build/bin/mlir-opt+0x40fe373)
#16 0x5648bacc1c12 mlir::detail::OpToOpPassAdaptor::runPipeline(mlir::OpPassManager&, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int, mlir::PassInstrumentor*, mlir::PassInstrumentation::PipelineParentInfo const*) (build/bin/mlir-opt+0x40fec12)
#17 0x5648bacc718e 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
#18 0x5648bacc346b mlir::detail::OpToOpPassAdaptor::runOnOperationAsyncImpl(bool) (build/bin/mlir-opt+0x410046b)
#19 0x5648bacc14cc mlir::detail::OpToOpPassAdaptor::run(mlir::Pass*, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int) (build/bin/mlir-opt+0x40fe4cc)
#20 0x5648bacc1c12 mlir::detail::OpToOpPassAdaptor::runPipeline(mlir::OpPassManager&, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int, mlir::PassInstrumentor*, mlir::PassInstrumentation::PipelineParentInfo const*) (build/bin/mlir-opt+0x40fec12)
#21 0x5648bacc43ee mlir::PassManager::run(mlir::Operation*) (build/bin/mlir-opt+0x41013ee)
#22 0x5648bacbc9ab performActions(llvm::raw_ostream&, std::shared_ptr const&, mlir::MLIRContext*, mlir::MlirOptMainConfig const&) MlirOptMain.cpp:0:0
#23 0x5648bacbc603 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
#24 0x5648bad66415 mlir::splitAndProcessBuffer(std::unique_ptr>, llvm::function_ref>, llvm::raw_ostream&)>, llvm::raw_ostream&, llvm::StringRef, llvm::StringRef) (build/bin/m
[llvm-bugs] [Bug 129039] The value range analysis results of Scalar Evolution Analysis seem to be incorrect
Issue
129039
Summary
The value range analysis results of Scalar Evolution Analysis seem to be incorrect
Labels
Assignees
Reporter
GINN-Imp
Hello, for the following IR, the value range analysis results of Scalar Evolution Analysis seem to be incorrect.
```llvm
define i1 @f() {
BB:
%B = sdiv i1 true, true
ret i1 %B
}
```
Output of `opt -passes="print"`:
```
Printing analysis 'Scalar Evolution Analysis' for function 'f':
Classifying expressions for: @f
%B = sdiv i1 true, true
--> %B U: [0,-1) S: [0,-1)
```
**According to https://llvm.org/doxygen/ConstantRange_8h_source.html, Scalar Evolution Analysis seems to think `%B`'s range is {False}, but in fact it has a value of True.**
testcase: https://godbolt.org/z/eWEM6nPqv
In addition, opt-16 considers it to be full-set:
```
Printing analysis 'Scalar Evolution Analysis' for function 'f':
Classifying expressions for: @f
%B = sdiv i1 true, true
--> %B U: full-set S: full-set
```
bisect to https://github.com/llvm/llvm-project/commit/124547eae
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129046] [MLIR][Crash]`--convert-vector-to-llvm="enable-x86vector" --dump-pass-pipeline --test-vector-scan-lowering` triggers crash.
Issue
129046
Summary
[MLIR][Crash]`--convert-vector-to-llvm="enable-x86vector" --dump-pass-pipeline --test-vector-scan-lowering` triggers crash.
Labels
mlir
Assignees
Reporter
xisang0
Test on commit: https://github.com/llvm/llvm-project/commit/01cc1d13cd0c54bd4c29185b052fa5c16285dca7
steps to reproduce:
```
build/mlir-opt test.mlir --convert-vector-to-llvm="enable-x86vector" --dump-pass-pipeline --test-vector-scan-lowering
```
test case:
```
func.func @main() {
return
}
```
crash trace:
```
UNREACHABLE executed at /home/llvm-project/mlir/include/mlir/Pass/PassOptions.h:168!
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0. Program arguments: build/bin/mlir-opt test.mlir --convert-vector-to-llvm=enable-x86vector --dump-pass-pipeline --test-vector-scan-lowering
#0 0x5576dc658dd8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (build/bin/mlir-opt+0x10c8dd8)
#1 0x5576dc6568fe llvm::sys::RunSignalHandlers() (build/bin/mlir-opt+0x10c68fe)
#2 0x5576dc6597e1 SignalHandler(int, siginfo_t*, void*) Signals.cpp:0:0
#3 0x7f00d0ac7520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#4 0x7f00d0b1b9fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
#5 0x7f00d0ac7476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
#6 0x7f00d0aad7f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
#7 0x5576dc6405e0 llvm::install_out_of_memory_new_handler() (build/bin/mlir-opt+0x10b05e0)
#8 0x5576df5fd0af (build/bin/mlir-opt+0x406d0af)
#9 0x5576df69e5c5 mlir::detail::PassOptions::print(llvm::raw_ostream&) const (build/bin/mlir-opt+0x410e5c5)
#10 0x5576df68dad7 mlir::OpPassManager::printAsTextualPipeline(llvm::raw_ostream&) const (build/bin/mlir-opt+0x40fdad7)
#11 0x5576df68dc59 mlir::OpPassManager::dump() (build/bin/mlir-opt+0x40fdc59)
#12 0x5576df689181 std::_Function_handler::_M_invoke(std::_Any_data const&, mlir::PassManager&) MlirOptMain.cpp:0:0
#13 0x5576df689991 performActions(llvm::raw_ostream&, std::shared_ptr const&, mlir::MLIRContext*, mlir::MlirOptMainConfig const&) MlirOptMain.cpp:0:0
#14 0x5576df689603 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 0x5576df733415 mlir::splitAndProcessBuffer(std::unique_ptr>, llvm::function_ref>, llvm::raw_ostream&)>, llvm::raw_ostream&, llvm::StringRef, llvm::StringRef) (build/bin/mlir-opt+0x41a3415)
#16 0x5576df683262 mlir::MlirOptMain(llvm::raw_ostream&, std::unique_ptr>, mlir::DialectRegistry&, mlir::MlirOptMainConfig const&) (build/bin/mlir-opt+0x40f3262)
#17 0x5576df683513 mlir::MlirOptMain(int, char**, llvm::StringRef, llvm::StringRef, mlir::DialectRegistry&) (build/bin/mlir-opt+0x40f3513)
#18 0x5576df683722 mlir::MlirOptMain(int, char**, llvm::StringRef, mlir::DialectRegistry&) (build/bin/mlir-opt+0x40f3722)
#19 0x5576dc6364f7 main (build/bin/mlir-opt+0x10a64f7)
#20 0x7f00d0aaed90 (/lib/x86_64-linux-gnu/libc.so.6+0x29d90)
#21 0x7f00d0aaee40 __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x29e40)
#22 0x5576dc636055 _start (build/bin/mlir-opt+0x10a6055)
Aborted (core dumped)
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129044] [MLIR][Crash] Assertion `mayBeGraphRegion(*op->getParentRegion()) && "expected that op has no uses"' failed.
Issue
129044
Summary
[MLIR][Crash] Assertion `mayBeGraphRegion(*op->getParentRegion()) && "expected that op has no uses"' failed.
Labels
mlir
Assignees
Reporter
xisang0
Test on commit: https://github.com/llvm/llvm-project/commit/01cc1d13cd0c54bd4c29185b052fa5c16285dca7
steps to reproduce:
```
build/bin/mlir-opt test.mlir --test-options-pass --test-loop-permutation="permutation-map=1,0,2" --affine-super-vectorizer-test=compose-maps --verify-each=false --test-extract-fixed-outer-loops='test-outer-loop-sizes=7,4' --test-tensor-transform-patterns=test-reassociative-reshape-folding
```
test case:
```
func.func @reduce_sum(%buffer: memref<1024xf32>, %lb: index,
%ub: index, %step: index) {
%initial_sum = arith.constant 0.0 : f32
%final_sum = scf.for %iv = %lb to %ub step %step
iter_args(%sum_iter = %initial_sum) -> (f32) {
%element = memref.load %buffer[%iv] : memref<1024xf32>
%updated_sum = arith.addf %sum_iter, %element : f32
scf.yield %updated_sum : f32
}
return
}
```
crash trace:
```
mlir-opt: /home/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: build/bin/mlir-opt test.mlir --test-options-pass --test-loop-permutation=permutation-map=1,0,2 --affine-super-vectorizer-test=compose-maps --verify-each=false --test-extract-fixed-outer-loops=test-outer-loop-sizes=7,4 --test-tensor-transform-patterns=test-reassociative-reshape-folding
#0 0x557a791aadd8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (build/bin/mlir-opt+0x10c8dd8)
#1 0x557a791a88fe llvm::sys::RunSignalHandlers() (build/bin/mlir-opt+0x10c68fe)
#2 0x557a791ab7e1 SignalHandler(int, siginfo_t*, void*) Signals.cpp:0:0
#3 0x7fd0d73f2520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#4 0x7fd0d74469fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
#5 0x7fd0d73f2476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
#6 0x7fd0d73d87f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
#7 0x7fd0d73d871b (/lib/x86_64-linux-gnu/libc.so.6+0x2871b)
#8 0x7fd0d73e9e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96)
#9 0x557a7c38fd26 (build/bin/mlir-opt+0x42add26)
#10 0x557a7c38f6ff std::_Function_handler::_M_invoke(std::_Any_data const&, mlir::Operation*&&) PatternMatch.cpp:0:0
#11 0x557a7c38e1b9 mlir::RewriterBase::eraseOp(mlir::Operation*) (build/bin/mlir-opt+0x42ac1b9)
#12 0x557a7c25c141 (anonymous namespace)::GreedyPatternRewriteDriver::processWorklist() GreedyPatternRewriteDriver.cpp:0:0
#13 0x557a7c259403 mlir::applyPatternsGreedily(mlir::Region&, mlir::FrozenRewritePatternSet const&, mlir::GreedyRewriteConfig, bool*) (build/bin/mlir-opt+0x4177403)
#14 0x557a7c3d94cb (anonymous namespace)::TestTensorTransforms::runOnOperation() TestTensorTransforms.cpp:0:0
#15 0x557a7c1e0373 mlir::detail::OpToOpPassAdaptor::run(mlir::Pass*, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int) (build/bin/mlir-opt+0x40fe373)
#16 0x557a7c1e0c12 mlir::detail::OpToOpPassAdaptor::runPipeline(mlir::OpPassManager&, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int, mlir::PassInstrumentor*, mlir::PassInstrumentation::PipelineParentInfo const*) (build/bin/mlir-opt+0x40fec12)
#17 0x557a7c1e33ee mlir::PassManager::run(mlir::Operation*) (build/bin/mlir-opt+0x41013ee)
#18 0x557a7c1db9ab performActions(llvm::raw_ostream&, std::shared_ptr const&, mlir::MLIRContext*, mlir::MlirOptMainConfig const&) MlirOptMain.cpp:0:0
#19 0x557a7c1db603 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 0x557a7c285415 mlir::splitAndProcessBuffer(std::unique_ptr>, llvm::function_ref>, llvm::raw_ostream&)>, llvm::raw_ostream&, llvm::StringRef, llvm::StringRef) (build/bin/mlir-opt+0x41a3415)
#21 0x557a7c1d5262 mlir::MlirOptMain(llvm::raw_ostream&, std::unique_ptr>, mlir::DialectRegistry&, mlir::MlirOptMainConfig const&) (build/bin/mlir-opt+0x40f3262)
#22 0x557a7c1d5513 mlir::MlirOptMain(int, char**, llvm::StringRef, llvm::StringRef, mlir::DialectRegistry&) (build/bin/mlir-opt+0x40f3513)
#23 0x557a7c1d5722 mlir::MlirOptMain(int, char**, llvm::StringRef, mlir::DialectRegistry&) (build/bin/mlir-opt+0x40f3722)
#24 0x557a791884f7 main (build/bin/mlir-opt+0x10a64f7)
#25 0x7fd0d73d9d90 (/lib/x86_64-linux-gnu/libc.so.6+0x29d90)
#26 0x7fd0d73d9
[llvm-bugs] [Bug 129049] [libc++] P2255R2: Implement type traits
Issue 129049 Summary [libc++] P2255R2: Implement type traits Labels libc++ Assignees Reporter Zingam - [x] `reference_constructs_from_temporary` - [x] `reference_converts_from_temporary` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129051] [libc++] P2255R2: `pair`, `tuple`, `INVOKE`
Issue 129051 Summary [libc++] P2255R2: `pair`, `tuple`, `INVOKE` Labels libc++ Assignees Reporter Zingam - `pair` - 20.4.2 [[pairs.pair]](https://wg21.link/pairs.pair) - `tuple` - 20.5.3.1 [[tuple.cnstr]](https://wg21.link/tuple.cnstr) - 20.5.5 [[tuple.apply]](https://wg21.link/tuple.apply) - `INVOKE` - 20.14.4 [[func.require]](https://wg21.link/func.require) ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129056] [X86] Failure to merge PINSRW insertions
Issue
129056
Summary
[X86] Failure to merge PINSRW insertions
Labels
backend:X86,
missed-optimization
Assignees
Reporter
RKSimon
```ll
define <16 x i16> @ff(<16 x i16> %x, i16 %s) {
%i0 = insertelement <16 x i16> %x, i16 %s, i32 0
%i1 = insertelement <16 x i16> %i0, i16 %s, i32 8
ret <16 x i16> %i1
}
```
llc -mcpu=x86-64-v3
```asm
ff: # @ff
vpinsrw $0, %edi, %xmm0, %xmm1
vpblendd $15, %ymm1, %ymm0, %ymm0 # ymm0 = ymm1[0,1,2,3],ymm0[4,5,6,7]
vmovd %edi, %xmm1
vpbroadcastw %xmm1, %ymm1
vpblendw $1, %ymm1, %ymm0, %ymm1 # ymm1 = ymm1[0],ymm0[1,2,3,4,5,6,7],ymm1[8],ymm0[9,10,11,12,13,14,15]
vpblendd $240, %ymm1, %ymm0, %ymm0 # ymm0 = ymm0[0,1,2,3],ymm1[4,5,6,7]
retq
```
This should just perform the vmovd+vpbroadcastw to transfer %edi once
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129057] [SLPVectorizer] Miscompilation at O3
Issue
129057
Summary
[SLPVectorizer] Miscompilation at O3
Labels
miscompilation,
llvm:SLPVectorizer
Assignees
Reporter
dtcxzyw
Reproducer:
```
; bin/opt -passes=slp-vectorizer reduced.ll -S
target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
@f = global i32 zeroinitializer
@.str = constant [4 x i8] c"%d\0A\00"
define i32 @main() {
entry:
store i32 152, ptr @f, align 4
%agg.tmp.sroa.0.0.copyload.i = load i32, ptr @f, align 4
%add.i.i = shl i32 %agg.tmp.sroa.0.0.copyload.i, 24
%sext.i = add i32 %add.i.i, 83886080
%conv2.i = ashr i32 %sext.i, 24
%and.i = and i32 %conv2.i, 66440127
%cmp3.i.i = icmp ugt i32 %and.i, 33554431
%shl.i.i = select i1 %cmp3.i.i, i32 0, i32 6
%cond.i.i = shl i32 %and.i, %shl.i.i
%0 = trunc i32 %cond.i.i to i8
%sext.1.i = add i32 0, 83886080
%conv2.1.i = ashr i32 %sext.1.i, 24
%and.1.i = and i32 %conv2.1.i, 1
%cmp3.i.1.i = icmp ugt i32 0, 0
%shl.i.1.i = select i1 %cmp3.i.1.i, i32 0, i32 0
%cond.i.1.i = shl i32 %and.1.i, %shl.i.1.i
%1 = trunc i32 %cond.i.1.i to i8
%conv17.1.i = and i8 %0, %1
%sext.2.i = add i32 0, 83886080
%conv2.2.i = ashr i32 %sext.2.i, 24
%and.2.i = and i32 %conv2.2.i, 1
%shl.i.2.i = select i1 false, i32 0, i32 0
%cond.i.2.i = shl i32 %and.2.i, %shl.i.2.i
%2 = trunc i32 %cond.i.2.i to i8
%conv17.2.i = and i8 %conv17.1.i, %2
%sext.3.i = add i32 0, 83886080
%conv2.3.i = ashr i32 %sext.3.i, 24
%and.3.i = and i32 %conv2.3.i, 1
%shl.i.3.i = select i1 false, i32 0, i32 0
%cond.i.3.i = shl i32 %and.3.i, %shl.i.3.i
%3 = trunc i32 %cond.i.3.i to i8
%conv17.3.i = and i8 %conv17.2.i, %3
%sext.4.i = add i32 0, 83886080
%conv2.4.i = ashr i32 %sext.4.i, 24
%and.4.i = and i32 %conv2.4.i, 1
%shl.i.4.i = select i1 false, i32 0, i32 0
%cond.i.4.i = shl i32 %and.4.i, %shl.i.4.i
%4 = trunc i32 %cond.i.4.i to i8
%conv17.4.i = and i8 %conv17.3.i, %4
%sext.5.i = add i32 0, 83886080
%conv2.5.i = ashr i32 %sext.5.i, 24
%and.5.i = and i32 %conv2.5.i, 1
%shl.i.5.i = select i1 false, i32 0, i32 0
%cond.i.5.i = shl i32 %and.5.i, %shl.i.5.i
%5 = trunc i32 %cond.i.5.i to i8
%conv17.5.i = and i8 %conv17.4.i, %5
%sext.6.i = add i32 0, 83886080
%conv2.6.i = ashr i32 %sext.6.i, 24
%and.6.i = and i32 %conv2.6.i, 1
%shl.i.6.i = select i1 false, i32 0, i32 0
%cond.i.6.i = shl i32 %and.6.i, %shl.i.6.i
%6 = trunc i32 %cond.i.6.i to i8
%conv17.6.i = and i8 %conv17.5.i, %6
%sext.7.i = add i32 0, 83886080
%conv2.7.i = ashr i32 %sext.7.i, 24
%and.7.i = and i32 %conv2.7.i, 1
%shl.i.7.i = select i1 false, i32 0, i32 0
%cond.i.7.i = shl i32 %and.7.i, %shl.i.7.i
%7 = trunc i32 %cond.i.7.i to i8
%conv17.7.i = and i8 %conv17.6.i, %7
%conv = zext i8 %conv17.7.i to i32
%call1 = call i32 (ptr, ...) @printf(ptr @.str, i32 %conv)
ret i32 0
}
declare i32 @printf(ptr, ...)
```
```
target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
@f = global i32 0
@.str = constant [4 x i8] c"%d\0A\00"
define i32 @main() {
entry:
store i32 152, ptr @f, align 4
%agg.tmp.sroa.0.0.copyload.i = load i32, ptr @f, align 4
%add.i.i = shl i32 %agg.tmp.sroa.0.0.copyload.i, 24
%0 = insertelement <8 x i32> , i32 %add.i.i, i32 0
%1 = add <8 x i32> , %0
%2 = ashr <8 x i32> %1, splat (i32 24)
%3 = trunc <8 x i32> %2 to <8 x i8>
%4 = and <8 x i8> %3,
%5 = zext <8 x i8> %4 to <8 x i32>
%6 = shufflevector <8 x i32> %5, <8 x i32> poison, <2 x i32>
%7 = shufflevector <2 x i32> %6, <2 x i32> , <2 x i32>
%8 = icmp ugt <2 x i32> %7,
%9 = call <8 x i1> @llvm.vector.insert.v8i1.v2i1(<8 x i1> , <2 x i1> %8, i64 0)
%10 = select <8 x i1> %9, <8 x i8> zeroinitializer, <8 x i8>
%11 = shl <8 x i8> %4, %10
%12 = call i8 @llvm.vector.reduce.and.v8i8(<8 x i8> %11)
%conv = zext i8 %12 to i32
%call1 = call i32 (ptr, ...) @printf(ptr @.str, i32 %conv)
ret i32 0
}
declare i32 @printf(ptr, ...)
; Function Attrs: nocallback nofree nosync nounwind speculatable willreturn memory(none)
declare <8 x i1> @llvm.vector.insert.v8i1.v2i1(<8 x i1>, <2 x i1>, i64 immarg) #0
; Function Attrs: nocallback nofree nosync nounwind speculatable willreturn memory(none)
declare i8 @llvm.vector.reduce.and.v8i8(<8 x i8>) #0
attributes #0 = { nocallback nofree nosync nounwind speculatable willreturn memory(none) }
```
llubi output:
Before SLP:
```
Entering function main
store i32 152, ptr @f, align 4
%agg.tmp.sroa.0.0.copyload.i = load i32, ptr @f, align 4 -> i32 152
%add.i.i = shl i32 %agg.tmp.sroa.0.0.copyload.i, 24 -> i32 -1744830464
%sext.i = add i32 %add.i.i, 83886080 -> i32 -1660944384
%conv2.i = ashr i32 %sext.i,
[llvm-bugs] [Bug 129053] s390x: support `.machine push` and `.machine pop` assembler directives
Issue 129053 Summary s390x: support `.machine push` and `.machine pop` assembler directives Labels new issue Assignees Reporter folkertdev The [documentation](https://sourceware.org/binutils/docs/as/s390-Directives.html) mentions that these directives should work (exactly like they do for powerpc): > .machine STRING[+EXTENSION]… This directive allows changing the machine for which code is generated. string may be any of the -march= selection options, or push, or pop. .machine push saves the currently selected cpu, which may be restored with .machine pop. But LLVM does not currently accept them [in the ASM parser](https://github.com/llvm/llvm-project/blob/74306afe87b85cb9b5734044eb6c74b8290098b3/llvm/lib/Target/SystemZ/AsmParser/SystemZAsmParser.cpp#L1362) This came up here https://github.com/rust-lang/rust/pull/137720#discussion_r1973375073 ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129060] [Clang][diagnostics] The location marking that structured binding shadows template parameter is not clear
Issue
129060
Summary
[Clang][diagnostics] The location marking that structured binding shadows template parameter is not clear
Labels
clang
Assignees
Reporter
zwuis
```cpp
template void test1() {
using arr = int[1];
auto [T] = arr{};
}
```
Current diagnostics:
```txt
:3:8: error: declaration of 'T' shadows template parameter
3 | auto [T] = arr{};
|^
:1:20: note: template parameter is declared here
1 | template void test1() {
| ^
```
Expected diagnostics:
```txt
:3:9: error: declaration of 'T' shadows template parameter
3 | auto [T] = arr{};
| ^
:1:20: note: template parameter is declared here
1 | template void test1() {
|^
```
It becomes more obvious if we add new line characters between '[' and ']':
```cpp
template void test2() {
using arr = int[1];
auto [
T
] = arr{};
}
```
Current diagnostics:
```txt
:8:8: error: declaration of 'T' shadows template parameter
8 | auto [
|^
:6:20: note: template parameter is declared here
6 | template void test2() {
|^
```
Expected diagnostics:
```txt
:9:5: error: declaration of 'T' shadows template parameter
9 | T
| ^
:6:20: note: template parameter is declared here
6 | template void test2() {
|^
```
Compiler Explorer:
I believe this can be a good-first-issue.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129061] [clang][crash] compiler crashes when building modules with a mingw sysroot
Issue 129061 Summary [clang][crash] compiler crashes when building modules with a mingw sysroot Labels clang Assignees Reporter qis This crash was observed on: * LLVM Version: 20.1.0-rc3 * Host platform: Windows, Linux * Target platform: MinGW-w64 Targeting Linux x86_64 with the same toolchain, but a different sysroot works just fine and does not crash. Unless instructed otherwise, I'll build clang in debug mode and reduce the code during the next few days, so that the error is easier to recreate and track down. In the meantime, here is the cmake build output of the crash and the accompanying generated files: ``` [build] /opt/ace/bin/clang++ --target=x86_64-w64-mingw32 --sysroot=/opt/ace/sys/mingw -DICE_EXPORT -DNOMINMAX -DWIN32_LEAN_AND_MEAN -Dice_EXPORTS -I/mnt/c/Workspace/ice/build/mingw-debug/src -I/mnt/c/Workspace/ice/src -march=x86-64-v2 -fasm -fms-compatibility-version=19.40 -fno-rtti -fexperimental-library -g -std=c++26 -fvisibility=hidden -Winvalid-pch -Xclang -include-pch -Xclang /mnt/c/Workspace/ice/build/mingw-debug/CMakeFiles/ice.dir/cmake_pch.hxx.pch -Xclang -include -Xclang /mnt/c/Workspace/ice/build/mingw-debug/CMakeFiles/ice.dir/cmake_pch.hxx -MD -MT CMakeFiles/ice.dir/src/ice.ccm.obj -MF CMakeFiles/ice.dir/src/ice.ccm.obj.d @CMakeFiles/ice.dir/src/ice.ccm.obj.modmap -o CMakeFiles/ice.dir/src/ice.ccm.obj -c /mnt/c/Workspace/ice/src/ice.ccm [build] PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script. [build] Stack dump: [build] 0. Program arguments: /opt/ace/bin/clang-20 -cc1 -triple x86_64-w64-windows-gnu -emit-obj -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name ice.ccm -mrelocation-model pic -pic-level 2 -mframe-pointer=none -fmath-errno -ffp-contract=on -fno-rounding-math -mconstructor-aliases -mms-bitfields -funwind-tables=2 -fno-sized-deallocation -fno-use-init-array -target-cpu x86-64-v2 -debug-info-kind=constructor -dwarf-version=4 -debugger-tuning=gdb -fdebug-compilation-dir=/mnt/c/Workspace/ice/build/mingw-debug -fcoverage-compilation-dir=/mnt/c/Workspace/ice/build/mingw-debug -resource-dir /opt/ace/lib/clang/20 -Winvalid-pch -std=c++26 -fdeprecated-macro -fgnu-keywords -fexperimental-library -ferror-limit 19 -fvisibility=hidden -fno-rtti -fno-use-cxa-atexit -fgnuc-version=4.2.1 -fms-compatibility-version=19.40 -fno-implicit-modules -fmodule-file=ice:application=CMakeFiles/ice.dir/ice-application.pcm -fmodule-file=ice:window=CMakeFiles/ice.dir/ice-window.pcm -fmodule-file=ice:log=CMakeFiles/ice.dir/ice-log.pcm -fmodule-file=ice:ct=CMakeFiles/ice.dir/ice-ct.pcm -fmodule-file=ice:memory=CMakeFiles/ice.dir/ice-memory.pcm -fmodule-file=ice:system.window=CMakeFiles/ice.dir/ice-system.window.pcm -fmodule-file=std=CMakeFiles/__cmake_cxx26.dir/std.pcm -fskip-odr-check-in-gmf -fcxx-exceptions -fexceptions -exception-model=seh -include-pch /mnt/c/Workspace/ice/build/mingw-debug/CMakeFiles/ice.dir/cmake_pch.hxx.pch -include /mnt/c/Workspace/ice/build/mingw-debug/CMakeFiles/ice.dir/cmake_pch.hxx -faddrsig -o CMakeFiles/ice.dir/src/ice.ccm.obj -x pcm CMakeFiles/ice.dir/ice.pcm [build] #0 0x56478a7fcb15 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/ace/bin/clang-20+0x318bb15) [build] #1 0x56478a7f9e8e llvm::sys::RunSignalHandlers() (/opt/ace/bin/clang-20+0x3188e8e) [build] #2 0x56478a7fd59f (/opt/ace/bin/clang-20+0x318c59f) [build] #3 0x7ff0905b9050 (/lib/x86_64-linux-gnu/libc.so.6+0x3c050) [build] #4 0x56478b780cc1 clang::ASTReader::getLocalModuleFile(clang::serialization::ModuleFile&, unsigned int) const (/opt/ace/bin/clang-20+0x410fcc1) [build] #5 0x56478b834b8d (/opt/ace/bin/clang-20+0x41c3b8d) [build] #6 0x56478b832391 clang::ASTReader::loadDeclUpdateRecords(clang::ASTReader::PendingUpdateRecord&) (/opt/ace/bin/clang-20+0x41c1391) [build] #7 0x56478b7cb350 clang::ASTReader::finishPendingActions() (/opt/ace/bin/clang-20+0x415a350) [build] #8 0x56478b7d4cc7 clang::ASTReader::FinishedDeserializing() (/opt/ace/bin/clang-20+0x4163cc7) [build] #9 0x56478b79e8df clang::ASTReader::ReadAST(llvm::StringRef, clang::serialization::ModuleKind, clang::SourceLocation, unsigned int, clang::serialization::ModuleFile**) (/opt/ace/bin/clang-20+0x412d8df) [build] #10 0x56478b6423dc clang::ASTUnit::LoadFromASTFile(llvm::StringRef, clang::PCHContainerReader const&, clang::ASTUnit::WhatToLoad, llvm::IntrusiveRefCntPtr, clang::FileSystemOptions const&, std::__2::shared_ptr, std::__2::shared_ptr, bool, clang::CaptureDiagsKind, bool, bool, llvm::IntrusiveRefCntPtr) (/opt/ace/bin/clang-20+0x3fd13dc) [build] #11 0x56478b633679 clang::FrontendAction::BeginSourceFile(clang::Compi
[llvm-bugs] [Bug 129181] [clang] Miscompile at -O2/3
Issue
129181
Summary
[clang] Miscompile at -O2/3
Labels
clang
Assignees
Reporter
cardigan1008
This code prints random value at `-O2/3` and 92 at `-O0/1`:
```c
int printf(const char *, ...);
int b[0];
int c;
int d;
int e;
int f() {
d = 7;
for (; 4 + d; d--)
e += 92 & 1 << d;
return e;
}
int main() {
int g = f();
printf("%d\n", g);
c = b[g];
return 0;
}
```
Compiler Explorer: https://godbolt.org/z/1KdhfczMW
It starts from clang-13.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129184] llvm.amdgcn.is.shared and llvm.is.private should be captures(address) to reinstate promote alloca optimization on addrspacecast
Issue 129184 Summary llvm.amdgcn.is.shared and llvm.is.private should be captures(address) to reinstate promote alloca optimization on addrspacecast Labels backend:AMDGPU Assignees Reporter arsenm These were previously marked as nocapture, and have upgraded to using captures(none). This is too aggressive, since it observes the address space of the value. We need this to be captured(address) so we can restore the optimizations removed in 21cea3f3be51d5c3856b87fed301b5fc3dddade4 We should be able to replace allocas in kernels which are addrspacecasted to generic and then passed to another function. We are replacing the underlying object with another valid address space cast source so it should be valid in most cases. This is hazardous if the use code is querying the address space, which should be considered as an address capture. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129203] [register] clang use redundant mov to avoid clobber return register w0
Issue
129203
Summary
[register] clang use redundant mov to avoid clobber return register w0
Labels
clang
Assignees
Reporter
vfdff
* test: https://godbolt.org/z/PG9GoMnqo
```
typedef struct {
int a;
int b;
} S;
extern S g_info;
__attribute__((noinline))
int foo1(S * s)
{
int start = g_info.a;
s->b = 0;
return g_info.a;
}
```
* Now gcc store the s->b first and then can load g_info.a into return regiser w0 without redundant mov
While clang need the redundant mov as it load g_info.a first, and the register w0 is not released.
- I already use -Wall to report all warning, but the **dangling pointer** is not identified by clang
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129083] std::source_location::function_name is ambiguous with function local types
Issue
129083
Summary
std::source_location::function_name is ambiguous with function local types
Labels
new issue
Assignees
Reporter
bebuch
https://godbolt.org/z/4jx1dxE3E
```cpp
#include
#include
template
auto PrettyName() -> char const* {
return std::source_location::current().function_name();
}
void normal() {
struct A{};
std::cout << "normal: " << PrettyName() << '\n';
}
struct A;
int main() {
auto lambda = []{
struct A{};
std::cout << "lambda: " << PrettyName() << '\n';
};
std::cout << "global: " << PrettyName() << '\n';
normal();
lambda();
}
```
clang output:
none
global: const char *PrettyName() [T = A]
normal: const char *PrettyName() [T = A]
lambda: const char *PrettyName() [T = A]
```
The GCC output is not ambiguous:
```none
global: const char* PrettyName() [with T = A]
normal: const char* PrettyName() [with T = normal()::A]
lambda: const char* PrettyName() [with T = main()A]
```
I think it might be an good idea to change `__PRETTY_FUNCTION__` output for function local types to something similar of what GCC does. Its annoying to look into a log file and see a type that exists globally while another function locale type was used. Thats pretty hard to debug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129185] [mlir][linalg] Crash parsing `linalg.elemwise_unary`
Issue
129185
Summary
[mlir][linalg] Crash parsing `linalg.elemwise_unary`
Labels
mlir
Assignees
Reporter
IanWood1
`mlir-opt` crashes when trying to parse/build ` linalg.elemwise_unary`, the unreachable is being hit in `ElemwiseUnaryOp::regionBuilder`
Reproducer:
```mlir
func.func @main(%arg0 : tensor) -> tensor {
%0 = linalg.elemwise_unary ins(%arg0 : tensor) outs(%arg0 : tensor) -> tensor
return %0 : tensor
}
```
Truncated stack-trace:
```
unsupported non numeric type
UNREACHABLE executed at /home/nod/llvm-project/mlir/lib/Dialect/Linalg/IR/LinalgOps.cpp:421!
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
#11 0x5bd2e86a9532 (anonymous namespace)::RegionBuilderHelper::buildUnaryFn(mlir::linalg::UnaryFn, mlir::Value) /home/nod/llvm-project/mlir/lib/Dialect/Linalg/IR/LinalgOps.cpp:0:7
#12 0x5bd2e86a93f3 mlir::linalg::ElemwiseUnaryOp::regionBuilder(mlir::ImplicitLocOpBuilder&, mlir::Block&, llvm::ArrayRef) /home/nod/llvm-project/build/Debug/tools/mlir/include/mlir/Dialect/Linalg/IR/LinalgNamedStructuredOps.yamlgen.cpp.inc:123:25
#13 0x5bd2e8865694 void std::__invoke_impl), mlir::ImplicitLocOpBuilder&, mlir::Block&, llvm::ArrayRef>(std::__invoke_other, void (*&)(mlir::ImplicitLocOpBuilder&, mlir::Block&, llvm::ArrayRef), mlir::ImplicitLocOpBuilder&, mlir::Block&, llvm::ArrayRef&&) /usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/bits/invoke.h:61:7
#14 0x5bd2e886560d std::enable_if), mlir::ImplicitLocOpBuilder&, mlir::Block&, llvm::ArrayRef>, void>::type std::__invoke_r), mlir::ImplicitLocOpBuilder&, mlir::Block&, llvm::ArrayRef>(void (*&)(mlir::ImplicitLocOpBuilder&, mlir::Block&, llvm::ArrayRef), mlir::ImplicitLocOpBuilder&, mlir::Block&, llvm::ArrayRef&&) /usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/bits/invoke.h:117:5
#15 0x5bd2e8865535 std::_Function_handler), void (*)(mlir::ImplicitLocOpBuilder&, mlir::Block&, llvm::ArrayRef)>::_M_invoke(std::_Any_data const&, mlir::ImplicitLocOpBuilder&, mlir::Block&, llvm::ArrayRef&&) /usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/bits/std_function.h:290:2
#16 0x5bd2e8896661 std::function)>::operator()(mlir::ImplicitLocOpBuilder&, mlir::Block&, llvm::ArrayRef) const /usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/bits/std_function.h:591:2
#17 0x5bd2e8896605 void llvm::function_ref)>::callback_fn)>>(long, mlir::ImplicitLocOpBuilder&, mlir::Block&, llvm::ArrayRef) /home/nod/llvm-project/llvm/include/llvm/ADT/STLFunctionalExtras.h:46:5
#18 0x5bd2e88653b9 llvm::function_ref)>::operator()(mlir::ImplicitLocOpBuilder&, mlir::Block&, llvm::ArrayRef) const /home/nod/llvm-project/llvm/include/llvm/ADT/STLFunctionalExtras.h:69:5
```
Full stacktrace here: https://gist.github.com/IanWood1/8f4d9c3d613c81b7490cac37872e8fe4
Commit: 746d8b0740095ea3939fef0112a51953ca22cd29
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129199] AMDGPU's getLargestLegalSuperClass should ignore register alignment requirements
Issue 129199 Summary AMDGPU's getLargestLegalSuperClass should ignore register alignment requirements Labels backend:AMDGPU Assignees Reporter arsenm On gfx90a+ VGPRs and AGPRs have a requirement to be even aligned, but this only applies to operations operating on tuple registers. We can still insert copies to and from the unaligned classes, as long as the ultimate use sees a copy back to an aligned use. In theory this should avoid some spills since there's more freedom in finding a free register in the wider class ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129124] Implement fixed point divifx functions in llvm-libc
Issue 129124 Summary Implement fixed point divifx functions in llvm-libc Labels good first issue, libc Assignees Reporter PiJoules ISO 18037 describes various fixed point `divifx` functions which divide an integer by a fixed point type and returns an integer rather than a fixed point type. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129122] Mislink with ICF and multi-instruction GOT entry references
Issue 129122 Summary Mislink with ICF and multi-instruction GOT entry references Labels new issue Assignees Reporter pcc With the attached reproducer, the `f2_*` functions containing the second half of a two-instruction GOT entry reference are ICF'd, but the `f1_*` functions containing the first half of the reference are not. Because the two functions refer to different GOT entries, about half of the `f1_*` functions end up loading from the wrong GOT entry (or potentially from an address outside the GOT entirely). ``` clang --target=aarch64-linux -c icf-bug.s ld.lld icf-bug.o --icf=all objdump -d ``` [...] ``` 002128e4 : 2128e4: d080 adrpx0, 224000 2128e8: d2803f01mov x1, #0x1f8 // #504 2128ec: 17fffa17b 211148 002128f0 : 2128f0: d080 adrpx0, 224000 2128f4: d2803f21mov x1, #0x1f9 // #505 2128f8: 17fffa14b 211148 002128fc : 2128fc: f080 adrpx0, 225000 212900: d2803f41 mov x1, #0x1fa // #506 212904: 17fffa11 b 211148 00212908 : 212908: f080adrpx0, 225000 21290c: d2803f61mov x1, #0x1fb // #507 212910: 17fffa0eb 211148 ``` [icf-bug.s.txt](https://github.com/user-attachments/files/19016403/icf-bug.s.txt) ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129125] Implement fixed point idivfx functions in llvm-libc
Issue 129125 Summary Implement fixed point idivfx functions in llvm-libc Labels good first issue, libc Assignees Reporter PiJoules ISO 18037 describes various fixed point `idivfx` functions which divide a fixed point type by a fixed point type and returns an integer rather than a fixed point type. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129126] Implement fixed point fxdivi functions in llvm-libc
Issue 129126 Summary Implement fixed point fxdivi functions in llvm-libc Labels good first issue, libc Assignees Reporter PiJoules ISO 18037 describes various fixed point `fxdivi` functions which divide an integer by an integer and returns a fixed point type. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129121] [mlir][LLVMIR] Support new debug records format
Issue 129121 Summary [mlir][LLVMIR] Support new debug records format Labels mlir:llvm Assignees Reporter smeenai Per https://discourse.llvm.org/t/psa-ir-output-changing-from-debug-intrinsics-to-debug-records/79578/3, debug intrinsics support is being removed after the LLVM 20 branch cut. The LLVM IR translator [relies on debug intrinsics](https://github.com/llvm/llvm-project/blob/10a9dcab0a5904ce6c12efb3555a2e31017bce92/mlir/lib/Target/LLVMIR/ConvertFromLLVMIR.cpp#L59). The comment says that "Debug records are not currently supported in the LLVM IR translator"; I'm not sure if it's just a translator issue or a broader lack of support in the LLVM IR dialect. Either way, it'll need to be fixed once LLVM no longer supports debug intrinsics. https://llvm.org/docs/RemoveDIsDebugInfo.html has an LLVM migration guide, for reference. CCing some people I've seen working on the LLVM dialect recently: @bcardosolopes @gysit @xlauko @Dinistro ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129141] Miscompile with GVN load PRE
Issue 129141 Summary Miscompile with GVN load PRE Labels new issue Assignees Reporter annamthomas Given this example: https://godbolt.org/z/Mrd6jn344, we see that GVN miscompiles by PRE'ing the load out of the loop. However, the load address is rewritten after some iterations in the loop by the store following it, so PRE'ing the load is incorrect. If we use MemorySSA with GVN, the load is not PRE'd. Also, with LICM, we do not hoist the load since we state that the store invalidates the loaded pointer. IMO, it looks like https://github.com/llvm/llvm-project/blob/63ecb0135d1c6457f82fc0e717d4fa8cdf0ee8e0/llvm/lib/Analysis/MemoryDependenceAnalysis.cpp#L339 is the issue.`canSkipClobberingStore` does not consider the fact that the store maybe overlapping with the Load's pointer (i.e. the MemLoc passed into `canSkipClobberingStore`). Circumventing this function also avoids the miscompile. This is the source code (I've simplified the IR to just the 1st loop within that function): https://github.com/andikleen/snappy-c/blob/master/snappy.c#L421 ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129098] [clang-tidy] Check request: improve greater equals or less equals operators
Issue
129098
Summary
[clang-tidy] Check request: improve greater equals or less equals operators
Labels
clang-tidy
Assignees
Reporter
denzor200
Needs a check that will find a definition of `operator>=` or `operator<=` which performs more than 1 invocations of another compare operators. The check will suggest to change the logic using only 1 invocation, and the observable behavior will remains unchanged.
BEFORE
```
bool operator>=(const A& lhs, const A& rhs) { return (rhs < lhs) || (lhs == rhs); }
bool operator<=(const A& lhs, const A& rhs) { return (lhs < rhs) || (lhs == rhs); }
bool operator>=(const B& lhs, const B& rhs) { return (lhs > rhs) || (lhs == rhs); }
bool operator<=(const B& lhs, const B& rhs) { return (rhs > lhs) || (lhs == rhs); }
```
AFTER
```
bool operator>=(const A& lhs, const A& rhs) { return !(lhs < rhs); }
bool operator<=(const A& lhs, const A& rhs) { return !(rhs < lhs); }
bool operator>=(const B& lhs, const B& rhs) { return !(rhs > lhs); }
bool operator<=(const B& lhs, const B& rhs) { return !(lhs > rhs); }
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129090] Incorrectly inferred captures(none) when a pointer is captured by a call to readonly nonunwind function without return value
Issue
129090
Summary
Incorrectly inferred captures(none) when a pointer is captured by a call to readonly nonunwind function without return value
Labels
new issue
Assignees
Reporter
tmiasko
FunctionAttrs assumes that readonly (or readnone) and nounwind function that
don't return a value can't capture arguments. That is incorrect, since such a
function can vary its behavior by terminating or not terminating.
An example demonstrating the issue:
```console
$ cat a.ll
define void @f(ptr %a, ptr %b) {
start:
call void @g(ptr %a, ptr %b)
ret void
}
define void @g(ptr %a, ptr %b) {
start:
%0 = icmp eq ptr %a, %b
br i1 %0, label %bb2, label %bb1
bb1:
br label %bb1
bb2:
ret void
}
$ opt-21 -S --passes=function-attrs a.ll
; ModuleID = 'a.ll'
source_filename = "a.ll"
; Function Attrs: nofree norecurse nosync nounwind memory(none)
define void @f(ptr readnone captures(none) %a, ptr readnone captures(none) %b) #0 {
start:
call void @g(ptr %a, ptr %b)
ret void
}
; Function Attrs: nofree norecurse nosync nounwind memory(none)
define void @g(ptr readnone %a, ptr readnone %b) #0 {
start:
%0 = icmp eq ptr %a, %b
br i1 %0, label %bb2, label %bb1
bb1: ; preds = %bb1, %start
br label %bb1
bb2: ; preds = %start
ret void
}
attributes #0 = { nofree norecurse nosync nounwind memory(none) }
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129091] [-Wunsafe-buffer-usage] Do not warn of unsafe buffers in consteval functions
Issue 129091 Summary [-Wunsafe-buffer-usage] Do not warn of unsafe buffers in consteval functions Labels new issue Assignees Reporter tsepez Since such a function is guaranteed to be evaluated at compile time, there should not be a possibility of a run-time buffer overflow. Adding annotations to these functions would thus not improve security. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129106] [HLSL] Report error when only some elements in `cbuffer` have `packoffset` annotation
Issue
129106
Summary
[HLSL] Report error when only some elements in `cbuffer` have `packoffset` annotation
Labels
HLSL
Assignees
Reporter
hekota
DXC has been reporting a warning on the code below for a while. The layout it produces is inconsistent between DXIL and SPIRV. We should make this an error in Clang.
```
cbuffer CB {
float f;
float g : packoffset(c0.z);
}
```
`warning: cannot mix packoffset elements with nonpackoffset elements in a cbuffer`
DXC places the elements without `packoffset` after the elements with explicit layout:
```
; struct CB
; {
;
; float f; ; Offset: 12
; float g; ; Offset:8
;
; } CB; ; Offset:0 Size: 16
```
SPIR-V does it differently - the offset of the first element is 0:
```
OpMemberDecorate %type_CB 0 Offset 0
OpMemberDecorate %type_CB 1 Offset 8
```
https://godbolt.org/z/Wq7EhKxEE
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129111] Implement type-generic fixed-point functions in libc
Issue 129111 Summary Implement type-generic fixed-point functions in libc Labels good first issue, libc Assignees Reporter PiJoules 4.1.7.6 in ISO 18037 specifies the following type-generic macros for fixed point functions: `absfx`, `roundfx`, `countlsfx`. For each macro, use of the macro invokes the function whose corresponding type and type domain is the fixed-point type of the first generic argument. If the type of the first generic argument is not a fixed-point type, the behavior is undefined. All of these functions are already included in llvm libc so we should be good to add these macros. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129123] Implement fixed point mulifx functions in llvm-libc
Issue 129123 Summary Implement fixed point mulifx functions in llvm-libc Labels good first issue, libc Assignees Reporter PiJoules ISO 18037 describes various fixed point `mulifx` functions which multiply a fixed point number by an integer and returns an integer rather than a fixed point type. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129019] opt: ../include/llvm/Support/GenericDomTree.h:403: [...] Assertion `(!BB || Parent == NodeTrait::getParent(const_cast(BB))) && "cannot get DomTreeNode of block with d
Issue 129019 Summary opt: ../include/llvm/Support/GenericDomTree.h:403: [...] Assertion `(!BB || Parent == NodeTrait::getParent(const_cast(BB))) && "cannot get DomTreeNode of block with different parent"' failed. Labels new issue Assignees Reporter mikaelholmen llvm commit: 7521207e415b Reproduce with: ``` opt -verify-scev -passes="loop-unroll-full" bbi-104544.ll -o /dev/null ``` Result: ``` opt: ../include/llvm/Support/GenericDomTree.h:403: DomTreeNodeBase *llvm::DominatorTreeBase::getNode(const NodeT *) const [NodeT = llvm::BasicBlock, IsPostDom = false]: Assertion `(!BB || Parent == NodeTrait::getParent(const_cast(BB))) && "cannot get DomTreeNode of block with different parent"' failed. PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. Stack dump: 0. Program arguments: build-all/bin/opt -verify-scev -passes=loop-unroll-full bbi-104544.ll -o /dev/null 1. Running pass "function(loop(loop-unroll-full))" on module "bbi-104544.ll" 2. Running pass "loop(loop-unroll-full)" on function "main" #0 0x564dfe0db856 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (build-all/bin/opt+0x4631856) #1 0x564dfe0d929e llvm::sys::RunSignalHandlers() (build-all/bin/opt+0x462f29e) #2 0x564dfe0dc0d9 SignalHandler(int, siginfo_t*, void*) Signals.cpp:0:0 #3 0x7f6d7e62ad10 __restore_rt (/lib64/libpthread.so.0+0x12d10) #4 0x7f6d7bfca52f raise (/lib64/libc.so.6+0x4e52f) #5 0x7f6d7bf9de65 abort (/lib64/libc.so.6+0x21e65) #6 0x7f6d7bf9dd39 _nl_load_domain.cold.0 (/lib64/libc.so.6+0x21d39) #7 0x7f6d7bfc2e86 (/lib64/libc.so.6+0x46e86) #8 0x564dfe70cc01 llvm::DominatorTreeBase::properlyDominates(llvm::BasicBlock const*, llvm::BasicBlock const*) const (build-all/bin/opt+0x4c62c01) #9 0x564dfe88ef13 llvm::ScalarEvolution::computeBlockDisposition(llvm::SCEV const*, llvm::BasicBlock const*) (build-all/bin/opt+0x4de4f13) #10 0x564dfe892b84 llvm::ScalarEvolution::verify() const (build-all/bin/opt+0x4de8b84) #11 0x564dff7c00ff llvm::FunctionToLoopPassAdaptor::run(llvm::Function&, llvm::AnalysisManager&) (build-all/bin/opt+0x5d160ff) #12 0x564dff5511cd llvm::detail::PassModel>::run(llvm::Function&, llvm::AnalysisManager&) PassBuilderPipelines.cpp:0:0 #13 0x564dfe3002a7 llvm::PassManager>::run(llvm::Function&, llvm::AnalysisManager&) (build-all/bin/opt+0x48562a7) #14 0x564dff55366d llvm::detail::PassModel>, llvm::AnalysisManager>::run(llvm::Function&, llvm::AnalysisManager&) PassBuilderPipelines.cpp:0:0 #15 0x564dfe304e7e llvm::ModuleToFunctionPassAdaptor::run(llvm::Module&, llvm::AnalysisManager&) (build-all/bin/opt+0x485ae7e) #16 0x564dff54f6ad llvm::detail::PassModel>::run(llvm::Module&, llvm::AnalysisManager&) PassBuilderPipelines.cpp:0:0 #17 0x564dfe2fef97 llvm::PassManager>::run(llvm::Module&, llvm::AnalysisManager&) (build-all/bin/opt+0x4854f97) #18 0x564dff4dc32c llvm::runPassPipeline(llvm::StringRef, llvm::Module&, llvm::TargetMachine*, llvm::TargetLibraryInfoImpl*, llvm::ToolOutputFile*, llvm::ToolOutputFile*, llvm::ToolOutputFile*, llvm::StringRef, llvm::ArrayRef, llvm::ArrayRef>, llvm::opt_tool::OutputKind, llvm::opt_tool::VerifierKind, bool, bool, bool, bool, bool, bool, bool) (build-all/bin/opt+0x5a3232c) #19 0x564dfe09e412 optMain (build-all/bin/opt+0x45f4412) #20 0x7f6d7bfb67e5 __libc_start_main (/lib64/libc.so.6+0x3a7e5) #21 0x564dfe09c02e _start (build-all/bin/opt+0x45f202e) Abort (core dumped) ``` [bbi-104544.ll.gz](https://github.com/user-attachments/files/19004737/bbi-104544.ll.gz) ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129027] [Backend][X86] Fatal error: Cannot emit physreg copy instruction (Clang 18.1.8, i9-13900K, Ubuntu 22)
Issue 129027 Summary [Backend][X86] Fatal error: Cannot emit physreg copy instruction (Clang 18.1.8, i9-13900K, Ubuntu 22) Labels clang Assignees Reporter yshekel When compiling my code with Clang 18.1.8 on Ubuntu 22.04 targeting Intel i9-13900K (x86_64), the compiler crashes with the following fatal error: `fatal error: error in backend: Cannot emit physreg copy instruction` I attached (archived) the source and associated run script. Here is the stack trace: Stack dump: 0. Program arguments: /usr/bin/clang++ -O3 -std=gnu++17 -fPIE -DRING=greyhound -DRING_ID=2002 -I/home/administrator/users/yuvals/icicle/icicle/include -I/home/administrator/users/yuvals/icicle/build/_deps/taskflow-src -isystem /home/administrator/users/yuvals/icicle/build/_deps/googletest-src/googletest/include -isystem /home/administrator/users/yuvals/icicle/build/_deps/googletest-src/googletest -DNDEBUG -c -MD -MT tests/CMakeFiles/test_ring_api.dir/test_ring_api.cpp.o -MF CMakeFiles/test_ring_api.dir/test_ring_api.cpp.o.d -fcolor-diagnostics -o CMakeFiles/test_ring_api.dir/test_ring_api.cpp.o /home/administrator/users/yuvals/icicle/icicle/tests/test_ring_api.cpp 1. parser at end of file 2. Code generation 3. Running pass 'Function Pass Manager' on module '/home/administrator/users/yuvals/icicle/icicle/tests/test_ring_api.cpp'. 4. Running pass 'Post-RA pseudo instruction expansion pass' on function '@_ZN28RingTest_RingSanityTest_TestI11IntegerRingIN9greyhound9zq_configEEE8TestBodyEv' #0 0x7815e2394716 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/lib/x86_64-linux-gnu/libLLVM-18.so.18.1+0xd94716) #1 0x7815e23926d0 llvm::sys::RunSignalHandlers() (/lib/x86_64-linux-gnu/libLLVM-18.so.18.1+0xd926d0) #2 0x7815e22e3fee (/lib/x86_64-linux-gnu/libLLVM-18.so.18.1+0xce3fee) #3 0x7815e22e3fab (/lib/x86_64-linux-gnu/libLLVM-18.so.18.1+0xce3fab) #4 0x7815e238ef87 llvm::sys::Process::Exit(int, bool) (/lib/x86_64-linux-gnu/libLLVM-18.so.18.1+0xd8ef87) #5 0x64999feb6133 (/usr/bin/clang+++0x13133) #6 0x7815e22f1832 llvm::report_fatal_error(llvm::Twine const&, bool) (/lib/x86_64-linux-gnu/libLLVM-18.so.18.1+0xcf1832) #7 0x7815e22f1716 (/lib/x86_64-linux-gnu/libLLVM-18.so.18.1+0xcf1716) #8 0x7815e51e9f60 (/lib/x86_64-linux-gnu/libLLVM-18.so.18.1+0x3be9f60) #9 0x7815e2951d29 llvm::TargetInstrInfo::lowerCopy(llvm::MachineInstr*, llvm::TargetRegisterInfo const*) const (/lib/x86_64-linux-gnu/libLLVM-18.so.18.1+0x1351d29) #10 0x7815e2661189 (/lib/x86_64-linux-gnu/libLLVM-18.so.18.1+0x1061189) #11 0x7815e2755024 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (/lib/x86_64-linux-gnu/libLLVM-18.so.18.1+0x1155024) #12 0x7815e24db04f llvm::FPPassManager::runOnFunction(llvm::Function&) (/lib/x86_64-linux-gnu/libLLVM-18.so.18.1+0xedb04f) #13 0x7815e24e0943 llvm::FPPassManager::runOnModule(llvm::Module&) (/lib/x86_64-linux-gnu/libLLVM-18.so.18.1+0xee0943) #14 0x7815e24db744 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/lib/x86_64-linux-gnu/libLLVM-18.so.18.1+0xedb744) #15 0x7815ea9c045e clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::IntrusiveRefCntPtr, std::unique_ptr >, clang::BackendConsumer*) (/usr/lib/llvm-18/bin/../lib/libclang-cpp.so.18.1+0x1bc045e) #16 0x7815ead4f602 clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) (/usr/lib/llvm-18/bin/../lib/libclang-cpp.so.18.1+0x1f4f602) #17 0x7815e997ffc6 clang::ParseAST(clang::Sema&, bool, bool) (/usr/lib/llvm-18/bin/../lib/libclang-cpp.so.18.1+0xb7ffc6) #18 0x7815eb7b0d25 clang::FrontendAction::Execute() (/usr/lib/llvm-18/bin/../lib/libclang-cpp.so.18.1+0x29b0d25) #19 0x7815eb72a2f4 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/usr/lib/llvm-18/bin/../lib/libclang-cpp.so.18.1+0x292a2f4) #20 0x7815eb82b4ce clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/usr/lib/llvm-18/bin/../lib/libclang-cpp.so.18.1+0x2a2b4ce) #21 0x64999feb5d55 cc1_main(llvm::ArrayRef, char const*, void*) (/usr/bin/clang+++0x12d55) #22 0x64999feb3155 (/usr/bin/clang+++0x10155) #23 0x7815eb3e2659 (/usr/lib/llvm-18/bin/../lib/libclang-cpp.so.18.1+0x25e2659) #24 0x7815e22e3f8c llvm::CrashRecoveryContext::RunSafely(llvm::function_ref) (/lib/x86_64-linux-gnu/libLLVM-18.so.18.1+0xce3f8c) #25 0x7815eb3e1fee clang::driver::CC1Command::Execute(llvm::ArrayRef >, std::__cxx11::basic_string, std::allocator >*, bool*) const (/usr/lib/llvm-18/bin/../lib/libclang-cpp.so.18.1+0x25e1fee) #26 0x7815eb3aa561 clang::driver::Compilation::ExecuteCommand(clang::driver::Comm
[llvm-bugs] [Bug 129028] "Bad machine code: No live segment at use" after scheduling
Issue 129028 Summary "Bad machine code: No live segment at use" after scheduling Labels backend:AMDGPU, llvm:codegen, crash-on-valid Assignees Reporter arsenm ``` RUN: at line 1: /Users/matt/src/llvm-project/build_rel_with_debinfo/bin/llc -mtriple=amdgcn-amd-amdhsa -mcpu=gfx908 -verify-machineinstrs -o - /Users/matt/src/llvm-project/llvm/test/CodeGen/AMDGPU/scheduler-no-live-segment-at-use.ll + /Users/matt/src/llvm-project/build_rel_with_debinfo/bin/llc -mtriple=amdgcn-amd-amdhsa -mcpu=gfx908 -verify-machineinstrs -o - /Users/matt/src/llvm-project/llvm/test/CodeGen/AMDGPU/scheduler-no-live-segment-at-use.ll # After Machine Instruction Scheduler ** INTERVALS ** AGPR0_LO16 [48r,56r:0) 0@48r AGPR0_HI16 [48r,56r:0) 0@48r SGPR8_LO16 [0B,16r:0) 0@0B-phi SGPR8_HI16 [0B,16r:0) 0@0B-phi SGPR9_LO16 [0B,16r:0) 0@0B-phi SGPR9_HI16 [0B,16r:0) 0@0B-phi %6 [16r,32r:0) 0@16r weight:0.00e+00 %12 [80r,80d:0) 0@80r weight:0.00e+00 %13 [96r,336r:0) 0@96r weight:0.00e+00 %14 [112r,352r:0) 0@112r weight:0.00e+00 %15 [128r,368r:0) 0@128r weight:0.00e+00 %16 [144r,384r:0) 0@144r weight:0.00e+00 %17 [160r,400r:0) 0@160r weight:0.00e+00 %18 [176r,416r:0) 0@176r weight:0.00e+00 %19 [192r,432r:0) 0@192r weight:0.00e+00 %20 [208r,448r:0) 0@208r weight:0.00e+00 %21 [224r,464r:0) 0@224r weight:0.00e+00 %22 [240r,480r:0) 0@240r weight:0.00e+00 %23 [256r,496r:0) 0@256r weight:0.00e+00 %24 [272r,512r:0) 0@272r weight:0.00e+00 %25 [288r,528r:0) 0@288r weight:0.00e+00 %26 [304r,544r:0) 0@304r weight:0.00e+00 %27 [320r,836r:0) 0@320r weight:0.00e+00 %28 [32r,872r:0) 0@32r L0003 [32r,832r:0) 0@32r L000C [32r,872r:0) 0@32r weight:0.00e+00 %33 [864r,896r:0)[896r,912r:1) 0@864r 1@896r weight:0.00e+00 %34 [832r,976r:0) 0@832r weight:0.00e+00 %35 [872r,976r:0) 0@872r weight:0.00e+00 %37 [912r,928r:0)[928r,944r:1) 0@912r 1@928r L0003 [912r,912d:0)[928r,944r:1) 0@912r 1@928r LFFFC [912r,944r:0) 0@912r weight:0.00e+00 %38 [944r,976r:0)[976r,992r:1) 0@944r 1@976r L00C0 [944r,976r:0)[976r,992r:1) 0@944r 1@976r LFF3F [944r,976r:0)[976r,976d:1) 0@944r 1@976r weight:0.00e+00 %42 [992r,1008r:0) 0@992r weight:0.00e+00 %74 [56r,336r:0)[336r,352r:1)[352r,368r:2)[368r,384r:3)[384r,400r:4)[400r,416r:5)[416r,432r:6)[432r,448r:7)[448r,464r:8)[464r,480r:9)[480r,496r:10)[496r,512r:11)[512r,528r:12)[528r,544r:13)[544r,836r:14)[836r,928r:15) 0@56r 1@336r 2@352r 3@368r 4@384r 5@400r 6@416r 7@432r 8@448r 9@464r 10@480r 11@496r 12@512r 13@528r 14@544r 15@836r L0003 [56r,928r:0) 0@56r L000C [336r,864r:0) 0@336r L0030 [352r,864r:0) 0@352r L00C0 [368r,864r:0) 0@368r L0300 [384r,864r:0) 0@384r L0C00 [400r,864r:0) 0@400r L3000 [416r,864r:0) 0@416r LC000 [432r,864r:0) 0@432r L0003 [448r,864r:0) 0@448r L000C [464r,864r:0) 0@464r L0030 [480r,864r:0) 0@480r L00C0 [496r,864r:0) 0@496r L0300 [512r,864r:0) 0@512r L0C00 [528r,864r:0) 0@528r L3000 [544r,864r:0) 0@544r LC000 [836r,864r:0) 0@836r weight:0.00e+00 RegMasks: ** MACHINEINSTRS ** # Machine code for function alloc_failure_with_split_vregs: NoPHIs, TracksLiveness, TiedOpsRewritten Function Live Ins: $sgpr8_sgpr9 in %6 0B bb.0 (%ir-block.0): liveins: $sgpr8_sgpr9 16B %6:sgpr_64(p4) = COPY $sgpr8_sgpr9 32B %28:sreg_64_xexec = S_LOAD_DWORDX2_IMM %6:sgpr_64(p4), 0, 0 :: (dereferenceable invariant load (s64) from %ir.v0.kernarg.offset1, align 16, addrspace 4) 48B INLINEASM &"; def $0" [sideeffect] [attdialect], $0:[regdef], implicit-def $agpr0 56B %74.sub0:av_512 = COPY $agpr0 80B INLINEASM &"; def $0" [sideeffect] [attdialect], $0:[regdef:AGPR_32], def dead %12:agpr_32 96B INLINEASM &"; def $0" [sideeffect] [attdialect], $0:[regdef:AGPR_32], def %13:agpr_32 112B INLINEASM &"; def $0" [sideeffect] [attdialect], $0:[regdef:AGPR_32], def %14:agpr_32 128B INLINEASM &"; def $0" [sideeffect] [attdialect], $0:[regdef:AGPR_32], def %15:agpr_32 144B INLINEASM &"; def $0" [sideeffect] [attdialect], $0:[regdef:AGPR_32], def %16:agpr_32 160B INLINEASM &"; def $0" [sideeffect] [attdialect], $0:[regdef:AGPR_32], def %17:agpr_32 176B INLINEASM &"; def $0" [sideeffect] [attdialect], $0:[regdef:AGPR_32], def %18:agpr_32 192B INLINEASM &"; def $0" [sideeffect] [attdialect], $0:[regdef:AGPR_32], def %19:agpr_32 208B INLINEASM &"; def $0" [sideeffect] [attdialect], $0:[regdef:AGPR_32], def %20:agpr_32 224B INLINEASM &"; def $0" [sideeffect] [attdialect], $0:[reg
[llvm-bugs] [Bug 129062] [libc++] regex uncaught exception using libc++, but libstdc++ not
Issue 129062 Summary [libc++] regex uncaught exception using libc++, but libstdc++ not Labels libc++ Assignees Reporter Zhenhang1213 demo: https://godbolt.org/z/13afaY64a ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129068] Implement `-Wmismatched-dealloc`
Issue 129068 Summary Implement `-Wmismatched-dealloc` Labels clang:diagnostics Assignees Reporter erichkeane This PR (https://github.com/llvm/llvm-project/pull/68059) adds support for the malloc-attribute with arguments, which enables diagnostics in GCC for the `-Wmismatched-dealloc` diagnostic, which requires static analysis. We should probably investigate that functionality at one point and see if we can implement similar diagnostics. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129069] warn_consecutive_comparision produces confusing message.
Issue
129069
Summary
warn_consecutive_comparision produces confusing message.
Labels
new issue
Assignees
Reporter
earnol
The warning for line like:
```if (a >= b <= c) {}```
produces warning or error after https://github.com/llvm/llvm-project/pull/128145 like:
```
warning: comparisons like 'X<=Y<=Z' don't have their mathematical meaning [-Wparentheses]
```
I'm finding this warning/error quite confusing as user's code contains neither X nor Y. Operators also got messed up. I believe the message reported should be corrected.
Also lines like 11:
```
if (a < b == c) {}
```
are not reported either. Which looks like a bug.
Please see live code example: https://godbolt.org/z/TTxrb1WcG
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129071] AMDGPU inreg arguments for SGPRs use whole VGPRs after SGPR arguments run out
Issue
129071
Summary
AMDGPU inreg arguments for SGPRs use whole VGPRs after SGPR arguments run out
Labels
backend:AMDGPU
Assignees
Reporter
arsenm
When SGPR available for argument passing run out, they silently switch to using whole VGPRs to pass arguments.
```
; RUN: llc -mtriple=amdgcn-amd-amdhsa -mcpu=gfx950 -o - %s
target triple = "amdgcn-amd-amdhsa"
define i32 @test0(<8 x i32> inreg %arg0,
<8 x i32> inreg %arg1,
<2 x i32> inreg %arg2,
i32 inreg %arg3,
i32 inreg %arg4) {
%add = add i32 %arg3, %arg4 ; arg3 is v0, arg4 is in v1. These should be packed into a lane and extracted with readlane
ret i32 %add
}
```
Ideally we would start to pack inreg arguments into individual lanes of VGPRs, not directly into VGPRs.
In this example, we ran out of SGPRs after 18 arguments. %arg3 and %arg4 end up in v0 and v1. We could treat these as WWM values, and pass them in v0.lane0 and v0.lane1.
Either way, we should get a scalar value in downstream code rather than forced VALU usage
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129074] Request Commit Access For citymarina
Issue 129074 Summary Request Commit Access For citymarina Labels infra:commit-access-request Assignees Reporter citymarina ### Why Are you requesting commit access Recently I have been submitting patches as part of my work at Apple, and I will likely be sending more patches moving forward. Thanks! ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 129077] [rejects valid] CTAD failing for alias template
Issue
129077
Summary
[rejects valid] CTAD failing for alias template
Labels
new issue
Assignees
Reporter
ericniebler
i believe (and a few folks in CWG agree) that the following code should compile. GCC trunk accepts it.
```c++
using size_t = decltype(sizeof(0));
struct index_type
{
size_t value{~0ull};
index_type() = default;
constexpr index_type(size_t i) noexcept : value(i) {}
};
template
struct extents
{
constexpr extents(decltype(Extents)...) noexcept {}
};
template
extents(Extents...) -> extents<(requires { Extents::value; } ? Extents{} : ~0ull)...>;
template
using index = extents;
int main()
{
extents i{0,0};
auto j = extents<64,{}>({}, 42);
index k{0,0};
auto l = index<64,{}>({}, 42);
}
```
Diagnostic:
```
:27:9: error: no viable constructor or deduction guide for deduction of template arguments of 'index'
27 | index k{0,0};
| ^
:20:1: note: candidate template ignored: substitution failure: deduced incomplete pack <(no value), (no value)> for template parameter 'Extents'
10 | template
| ~~~
11 | struct extents
12 | {
13 | constexpr extents(decltype(Extents)...) noexcept {}
14 | };
15 |
16 | template
17 | extents(Extents...) -> extents<(requires { Extents::value; } ? Extents{} : ~0ull)...>;
18 |
19 | template
20 | using index = extents;
| ^
:20:1: note: implicit deduction guide declared as 'template requires __is_deducible(index, extents) index(decltype(Extents) ...) -> extents'
:20:1: note: candidate function template not viable: requires 1 argument, but 2 were provided
11 | struct extents
|~~~
12 | {
13 | constexpr extents(decltype(Extents)...) noexcept {}
14 | };
15 |
16 | template
17 | extents(Extents...) -> extents<(requires { Extents::value; } ? Extents{} : ~0ull)...>;
18 |
19 | template
20 | using index = extents;
| ^
:20:1: note: implicit deduction guide declared as 'template requires __is_deducible(index, extents) index(extents) -> extents'
:20:1: note: candidate template ignored: constraints not satisfied
:20:1: note: cannot deduce template arguments for 'index' from 'extents<(requires { Extents::value; } ? Extents{} : ~0ULL)...>'
:20:1: note: implicit deduction guide declared as 'template <> requires __is_deducible(index, extents<(requires { Extents::value; } ? Extents{} : ~0ULL)...>) index(Extents ...) -> extents<(requires { Extents::value; } ? Extents{} : ~0ULL)...>'
```
See https://godbolt.org/z/qxsTWGsdx
Christof Meerwald (@cmeerw) of CWG explains it thusly:
> You try to deduce `extents<(requires { Extents::value; } ? Extents{} : ~0ull)...>` from `extents` (but can't deduce anything). As you didn't deduce anything, substituting into the original deduction guide doesn't change anything. So your `f'` is the same as `f` (and as you haven't deduced anything, you only use the template parameters from the original deduction guide, but none from the alias template). After doing deduction for `f'`, the only thing left to do is the deducible check (which also succeeds).
this issue seems distinct from #111216.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
