[llvm-bugs] [Bug 91925] vector-transpose-lowering.mlir
Issue 91925 Summary vector-transpose-lowering.mlir Labels mlir Assignees Reporter banach-space ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 91926] [Flang][OpenMP] Incorrect execution result when an if clause is specified for a dependent task in a sibling task that has a task dependency
Issue 91926 Summary [Flang][OpenMP] Incorrect execution result when an if clause is specified for a dependent task in a sibling task that has a task dependency Labels openmp, flang Assignees Reporter ohno-fj ``` Version of flang-new : 19.0.0(1a498103ee5c4d101e70dc49db11938d8b87b518)/AArch64 ``` In `sibling tasks` that have `task dependence`, when an `if` clause (the result is .false.) is specified for a `dependent task`, the execution result is incorrect. The result is correct when line 27 of the program is changed as follows: - Change `scalar-logical-_expression_` result specified in `if` clause from .false. to .true. ``` !$omp task shared(x) depend(in: x) if(x .ne. 0) ! if(.true.) ``` - Delete the `if` clause ``` !$omp task shared(x) depend(in: x) ! no if clause ``` The following are the test program, Flang-new, Gfortran and ifort compilation/execution result. taskdepend_054_2231.f90: ```fortran module taskdepend_mod integer, parameter :: ans=1 contains subroutine init(x) integer :: x x = 2 end subroutine init subroutine test(x) integer :: x if (x .ne. ans) then print *, "NG" else print *, "OK" end if end subroutine test end module taskdepend_mod program main use taskdepend_mod integer :: x call init(x) !$omp parallel !$omp single !$omp task shared(x) depend(out: x) x = x - 1 !$omp end task !$omp task shared(x) depend(in: x) if(x .eq. 0) ! if(.false.) call test(x) !$omp end task !$omp end single !$omp end parallel end program main ``` ``` $ export OMP_NUM_THREADS=2; flang-new -fopenmp taskdepend_054_2231.f90; ./a.out NG $ ``` ``` $ export OMP_NUM_THREADS=2; gfortran -fopenmp taskdepend_054_2231.f90; ./a.out OK $ ``` ``` $ export OMP_NUM_THREADS=2; ifort -qopenmp -diag-disable=10448 taskdepend_054_2231.f90; ./a.out OK $ ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 91928] [Flang][OpenMP] Compilation error when lastprivate clause specified in do construct has a derived type with an allocatable variable
Issue 91928 Summary [Flang][OpenMP] Compilation error when lastprivate clause specified in do construct has a derived type with an allocatable variable Labels openmp, flang Assignees Reporter ohno-fj ``` Version of flang-new : 19.0.0(1a498103ee5c4d101e70dc49db11938d8b87b518)/AArch64 ``` When `lastprivate` clause specified in `do` construct has a `derived type` with an allocatable variable, a compilation terminates abnormally. When `lastprivate` clause in `do` construct is removed, a compilation terminates normally. The following are the test program, Flang-new, Gfortran and ifort compilation/execution result. lp10_32.f90: ```fortran subroutine s4 type y3 integer,allocatable::x end type y3 type(y3)::v allocate(v%x) v%x=0 !$omp parallel if (.not. allocated(v%x)) print *,'101' !$omp do lastprivate(v) do i=1,10 v%x=i end do !$omp end do !$omp end parallel end subroutine s4 program main call s4 print *,'pass' end program main ``` ``` $ export OMP_NUM_THREADS=2; flang-new -fopenmp lp10_32.f90; ./a.out fatal Fortran runtime error(/work/home/ohno/CT/test/fort/tp/reproducerJ/fomp_omp40/lp10_32.f90:12): Assign: mismatching types (to code 64 != from code 9) fatal Fortran runtime error(/work/home/ohno/CT/test/fort/tp/reproducerJ/fomp_omp40/lp10_32.f90:12): Assign: mismatching types (to code 64 != from code 9) Aborted (core dumped) $ ``` ``` $ export OMP_NUM_THREADS=2; gfortran -fopenmp lp10_32.f90; ./a.out pass $ ``` ``` $ export OMP_NUM_THREADS=2; ifort -qopenmp -diag-disable=10448 lp10_32.f90; ./a.out pass $ ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 91927] [Flang][OpenMP] Incorrect execution result of an assignment statement in task construct in taskgroup construct
Issue 91927 Summary [Flang][OpenMP] Incorrect execution result of an assignment statement in task construct in taskgroup construct Labels openmp, flang Assignees Reporter ohno-fj ``` Version of flang-new : 19.0.0(1a498103ee5c4d101e70dc49db11938d8b87b518)/AArch64 ``` The attached program (An assignment statement in `task shared` construct in `taskgroup` construct) has incorrect results. When `task shared` construct is removed, the results are correct. The following are the test program, Flang-new, Gfortran and ifort compilation/execution result. taskgroup_003_22.f90: ```fortran program main integer, dimension(10) :: a a = 0 write(6,*) "1 : a = ", a !$omp parallel private(i) !$omp sections !$omp section !$omp taskgroup do i=1,10 !$omp task shared(a) !$omp atomic write a(i) = 1 !$omp end task end do !$omp end taskgroup write(6,*) "2 : a = ", a !$omp end sections !$omp end parallel end program main ``` ``` $ flang-new -fopenmp taskgroup_003_22.f90; ./a.out 1 : a = 0 0 0 0 0 0 0 0 0 0 2 : a = 0 0 0 0 0 0 0 0 0 0 $ ``` ``` $ gfortran -fopenmp taskgroup_003_22.f90; ./a.out 1 : a =0 0 0 0 0 0 0 0 0 0 2 : a = 1 1 1 1 1 1 1 1 1 1 $ ``` ``` $ ifort -qopenmp -diag-disable=10448 taskgroup_003_22.f90; ./a.out 1 : a = 0 0 0 0 0 0 0 0 0 0 2 : a =1 1 1 1 1 1 1 1 1 1 $ ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 91929] [Flang][OpenMP] Compilation error when the variables used in an `update-statement` in `atomic` construct are declared with different types
Issue 91929 Summary [Flang][OpenMP] Compilation error when the variables used in an `update-statement` in `atomic` construct are declared with different types Labels openmp, flang Assignees Reporter ohno-fj ``` Version of flang-new : 19.0.0(1a498103ee5c4d101e70dc49db11938d8b87b518)/AArch64 ``` When the variables (`x` and `expr`) used in an `update-statement` in `atomic` construct are declared with different types, a compilation terminates abnormally. When both variables are declared of the same type, a compilation terminates normally. The following are the test program, Flang-new, Gfortran and ifort compilation/execution result. OMP_3_O_007_4_atm_expr_027_up_323.f90: ```fortran program main integer(kind=4) :: s_x, i ! integer(kind=4) :: s_expr real(kind=4):: s_expr s_x= 3 s_expr = 3.0 !$omp atomic ! update s_x = s_x + s_expr !$omp end atomic write(6,*) 's_x = ', s_x, ', s_expr = ', s_expr end program main ``` ``` $ flang-new -fopenmp -L${LLVM_DIR}/lib OMP_3_O_007_4_atm_expr_027_up_323.f90; ./a.out error: loc("/work/home/ohno/CT/test/fort/tp/reproducerJ/fomp_omp40/OMP_3_O_007_4_atm_expr_027_up_323.f90":6:3): no atomic update operation with region argument as operand found inside atomic.update region error: loc("/work/home/ohno/CT/test/fort/tp/reproducerJ/fomp_omp40/OMP_3_O_007_4_atm_expr_027_up_323.f90":6:3): LLVM Translation failed for operation: omp.atomic.update error: failed to create the LLVM module $ ``` ``` $ export OMP_NUM_THREADS=2; gfortran -fopenmp OMP_3_O_007_4_atm_expr_027_up_323.f90; ./a.out s_x = 6 , s_expr =3. $ ``` ``` $ export OMP_NUM_THREADS=2; ifort -qopenmp OMP_3_O_007_4_atm_expr_027_up_323.f90; ./a.out s_x =6 , s_expr =3.00 $ ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 91934] [libc][docs] Outdated Code Review section in 'libc/src/math/docs/add_math_function.md'
Issue 91934 Summary [libc][docs] Outdated Code Review section in 'libc/src/math/docs/add_math_function.md' Labels libc Assignees Reporter cyuria Found this outdated section in the developer docs. https://github.com/llvm/llvm-project/blob/ae2a18d6cbc3328410bdb7e629fdc59766b73e4b/libc/src/math/docs/add_math_function.md?plain=1#L197-L202 The section mentions and links to phabricator. Possible Solutions: - Remove entirely, using github should be implicit I think - Change to mention github's PR review system - Do nothing, it doesn't pose any problems, although the link is outdated ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 91937] [GlobalISel] CSEMIRBuilder Performance
Issue 91937 Summary [GlobalISel] CSEMIRBuilder Performance Labels llvm:globalisel Assignees Reporter Pierre-vh Opening this issue to track performance improvement ideas for CSEMIRBuilder in GlobalISel. I did some profiling and I found that CSEMIRBuilder takes a non-negligible amount of time, about 2%. 0.8% of that is MachineIRBuilder::buildInstr, so that means CSEMIRBuilder adds a 150% overhead to a normal MIR builder.  ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 91948] MIPS: P5600 should use nan2008, fp64, msa
Issue 91948 Summary MIPS: P5600 should use nan2008, fp64, msa Labels new issue Assignees Reporter wzssyqa ``` $ ./bin/clang --target=mips -march=p5600 -mmsa -S pp.c -v clang version 19.0.0git (g...@github.com:wzssyqa/llvm-project.git 5ca368501ae81ca364f66ee6053aa4f8104fdbdd) Target: mips Thread model: posix InstalledDir: /data/syq/git-push/llvm-project.github/build-amd64/bin Build config: +unoptimized, +assertions (in-process) "/data/syq/git-push/llvm-project.github/build-amd64/bin/clang-19" -cc1 -triple mips -S -disable-free -clear-ast-before-backend -main-file-name pp.c -mrelocation-model static -mframe-pointer=all -fmath-errno -ffp-contract=on -fno-rounding-math -mconstructor-aliases -target-cpu p5600 -target-feature -noabicalls -target-feature +msa -target-feature +fp64 -target-abi o32 -mfloat-abi hard -debugger-tuning=gdb -fdebug-compilation-dir=/data/syq/git-push/llvm-project.github/build-amd64 -v -fcoverage-compilation-dir=/data/syq/git-push/llvm-project.github/build-amd64 -resource-dir /data/syq/git-push/llvm-project.github/build-amd64/lib/clang/19 -ferror-limit 19 -fgnuc-version=4.2.1 -fskip-odr-check-in-gmf -fno-relaxed-template-template-args -fcolor-diagnostics -faddrsig -o pp.s -x c pp.c error: '-mfp64' can only be used if the target supports the mfhc1 and mthc1 instructions $ ./bin/clang --target=mips -march=p5600 -S pp.c -v clang version 19.0.0git (g...@github.com:wzssyqa/llvm-project.git 5ca368501ae81ca364f66ee6053aa4f8104fdbdd) Target: mips Thread model: posix InstalledDir: /data/syq/git-push/llvm-project.github/build-amd64/bin Build config: +unoptimized, +assertions (in-process) "/data/syq/git-push/llvm-project.github/build-amd64/bin/clang-19" -cc1 -triple mips -S -disable-free -clear-ast-before-backend -main-file-name pp.c -mrelocation-model static -mframe-pointer=all -fmath-errno -ffp-contract=on -fno-rounding-math -mconstructor-aliases -target-cpu p5600 -target-feature -noabicalls -target-abi o32 -mfloat-abi hard -debugger-tuning=gdb -fdebug-compilation-dir=/data/syq/git-push/llvm-project.github/build-amd64 -v -fcoverage-compilation-dir=/data/syq/git-push/llvm-project.github/build-amd64 -resource-dir /data/syq/git-push/llvm-project.github/build-amd64/lib/clang/19 -ferror-limit 19 -fgnuc-version=4.2.1 -fskip-odr-check-in-gmf -fno-relaxed-template-template-args -fcolor-diagnostics -faddrsig -o pp.s -x c pp.c clang -cc1 version 19.0.0git based upon LLVM 19.0.0git default target x86_64-unknown-linux-gnu #include "..." search starts here: #include <...> search starts here: /usr/local/include /data/syq/git-push/llvm-project.github/build-amd64/lib/clang/19/include /usr/include End of search list. ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 68141 in oss-fuzz: llvm: Coverage build failure
Comment #4 on issue 68141 by ClusterFuzz-External: llvm: Coverage build failure https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=68141#c4 Friendly reminder that the build is still failing. Please try to fix this failure to ensure that fuzzing remains productive. Latest build log: https://oss-fuzz-build-logs.storage.googleapis.com/log-fa9511e1-c91e-466a-95b4-4cf17cabe584.txt -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 91952] ``: `ranges::ends_with`'s constraint check for bidirectional case is not quite right
Issue 91952 Summary ``: `ranges::ends_with`'s constraint check for bidirectional case is not quite right Labels new issue Assignees Reporter hewillk `ranges::ends_with` only checks whether the two sentinel types satisfy `bidirectional_iterator` then unconditionally warps all iterators and sentinels into `reverse_iterator`s. https://github.com/llvm/llvm-project/blob/19a62fbe00930d7eaa9f948c8dd26d58f5422c00/libcxx/include/__algorithm/ranges_ends_with.h#L67-L69 There are two implicit issues here. First, theoretically, the iterator can still not satisfy `bidirectional_iterator` in such case, which makes the construction of `reverse_iterator` ill-formed. Second, the reference of sentinels and iterators may not be the same, which makes the predicate and projection functions not necessarily applicable to the `reverse_iterator`. The following demos the issue: ```cpp #include #include struct Proj { int operator()(auto&); int operator()(const auto&) = delete; }; int main() { std::list l; std::ranges::subrange s{l.begin(), l.cend()}; return std::ranges::ends_with(s, s, {}, Proj{}, Proj{}); // hard error in libc++ } ``` https://godbolt.org/z/xrMdreWEv ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 91957] Miscompile with opt -passes="loop-unroll, loop-mssa(licm, indvars)" -unroll-count=4
Issue 91957 Summary Miscompile with opt -passes="loop-unroll,loop-mssa(licm,indvars)" -unroll-count=4 Labels new issue Assignees Reporter mikaelholmen llvm commit: e76b257483e6c Reproduce with: ```opt -passes="loop-unroll,loop-mssa(licm,indvars)" -unroll-count=4 bbi-95405.ll -S -o -``` The input function returns 32768, but after running the passes as above we get ``` define i16 @foo() { entry: br label %loop loop: ; preds = %loop, %entry br i1 false, label %loop, label %end, !llvm.loop !0 end: ; preds = %loop ret i16 8192 } !0 = distinct !{!0, !1} !1 = !{!"llvm.loop.unroll.disable"} ``` So now the function returns 8192 instead. If I extract the IR after loop-unroll or licm and run the rest of the passes instead I get the correct result. [bbi-95405.ll.gz](https://github.com/llvm/llvm-project/files/15294896/bbi-95405.ll.gz) ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 91959] Poor diagnostic quality for operators that cannot be used as fold-operator
Issue 91959 Summary Poor diagnostic quality for operators that cannot be used as fold-operator Labels new issue Assignees Reporter Eisenwave ```cpp template void awoo(Ts... args) { (args <=> ...); } ``` For this code, clang outputs (https://godbolt.org/z/xozTW66rY): ``` :3:15: error: expected _expression_ 3 | (args <=> ...); | ^ ``` There are also less than ideal diagnostics for `->` (and I assume, some other operators that cannot be folded over). Presumably, this happens because `(args <=> ...)` is not parsed as a fold-_expression_ at all, so you get some syntax error. It may be better to parse it as a fold-_expression_ but immediately reject it with an error such as > `<=>` is not a fold operator. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 91973] Do you still need commit access?
Issue 91973 Summary Do you still need commit access? Labels infrastructure:commit-access Assignees Reporter tstellar ### TLDR: If you want to retain your commit access, please comment on this issue. Otherwise, you can unsubscribe from this issue and ignore it. Commit access is not required to contribute to the project. You can still create Pull Requests without commit access. @AdamMagierFOSS @DylanFleming-arm @PeixinQiao @piggynl @kavitha-natarajan @ipriyanshi1708 @MarsPLR @Yunzezhu94 @hau-hsu @nirvedhmeshram @mohammed-nurulhoque @realqhc @v1nh1shungry @komalon1 @nhuhuan @tyb-arm @Sophia957 @wjschmidt @el-sc @dpenry LLVM has a policy of downgrading write access to its repositories for accounts with long term inactivity. This is done because inactive accounts with high levels of access tend to be at increased risk of compromise and this is one tactic that the project employs to guard itself from malicious actors. Note that write access is not required to contribute to the project. You can still submit pull requests and have someone else merge them. Our project policy is to ping anyone with less than five 'interactions' with the repositories over a 12 month period to see if they still need commit access. An 'interaction' and be any one of: * Pushing a commit. * Merging a pull request (either their own or someone else’s). * Commenting on a PR. If you want to retain your commit access, please post a comment on this issue. If you do not want to keep your commit access, you can just ignore this issue. If you have not responded in 6 weeks, then you will move moved from the 'write' role within the project to the 'triage' role. The 'triage' role is still a privileged role and will allow you to do the following: * Review Pull Requests. * Comment on issues. * Apply/dismiss labels. * Close, reopen, and assign all issues and pull requests. * Apply milestones. * Mark duplicate issues and pull requests. * Request pull request reviews. * Hide anyone’s comments. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 91975] Assertion `Elt->getBitWidth() == EltVT.getSizeInBits() && "APInt size does not match type size!"' failed.
Issue 91975 Summary Assertion `Elt->getBitWidth() == EltVT.getSizeInBits() && "APInt size does not match type size!"' failed. Labels new issue Assignees Reporter DigOrDog # Description The following code crashes aarch64 backend with "Assertion `Elt->getBitWidth() == EltVT.getSizeInBits() && "APInt size does not match type size!"' failed." # Minimal Reproduction https://godbolt.org/z/6Kvh5oeT8 ## Code ``` ; ModuleID = 'Fuzzer input' source_filename = "M" @G = global ppc_fp128 0xM7FF0 define i1 @f(i1 %0, i8 %1, i64 %2) { BB: %CastFPTrunc1 = fpext float 4.20e+01 to x86_fp80 %CastExt = sext i16 0 to i32 %CastFPTrunc = fpext float 0x47EFE000 to ppc_fp128 %RP = alloca i1, i32 %CastExt, align 1 %3 = load i1, ptr %RP, align 1 store ppc_fp128 %CastFPTrunc, ptr @G, align 16 store x86_fp80 %CastFPTrunc1, ptr %RP, align 16 ret i1 %3 } ``` ## Stack Trace ``` llc: /root/llvm-project/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp:1703: llvm::SDValue llvm::SelectionDAG::getConstant(const llvm::ConstantInt&, const llvm::SDLoc&, llvm::EVT, bool, bool): Assertion `Elt->getBitWidth() == EltVT.getSizeInBits() && "APInt size does not match type size!"' failed. PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. Stack dump: 0. Program arguments: /opt/compiler-explorer/clang-assertions-trunk/bin/llc -o /app/output.s -x86-asm-syntax=intel -mtriple aarch64 -global-isel -O0 1. Running pass 'Function Pass Manager' on module ''. 2. Running pass 'AArch64 Instruction Selection' on function '@f' #0 0x0399e058 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x399e058) #1 0x0399b7ac SignalHandler(int) Signals.cpp:0:0 #2 0x7a02eb242520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520) #3 0x7a02eb2969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc) #4 0x7a02eb242476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476) #5 0x7a02eb2287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3) #6 0x7a02eb22871b (/lib/x86_64-linux-gnu/libc.so.6+0x2871b) #7 0x7a02eb239e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96) #8 0x0372fa81 llvm::SelectionDAG::getConstant(llvm::ConstantInt const&, llvm::SDLoc const&, llvm::EVT, bool, bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x372fa81) #9 0x0384f5aa llvm::DAGTypeLegalizer::SoftenFloatRes_ConstantFP(llvm::SDNode*) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x384f5aa) #10 0x03862fa2 llvm::DAGTypeLegalizer::SoftenFloatResult(llvm::SDNode*, unsigned int) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x3862fa2) #11 0x037f2ed3 llvm::DAGTypeLegalizer::run() (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x37f2ed3) #12 0x037f3d59 llvm::SelectionDAG::LegalizeTypes() (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x37f3d59) #13 0x037664b4 llvm::SelectionDAGISel::CodeGenAndEmitDAG() (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x37664b4) #14 0x03769f45 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x3769f45) #15 0x0376b9b7 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) (.part.0) SelectionDAGISel.cpp:0:0 #16 0x029af0d1 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (.part.0) MachineFunctionPass.cpp:0:0 #17 0x02f70f83 llvm::FPPassManager::runOnFunction(llvm::Function&) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x2f70f83) #18 0x02f711c1 llvm::FPPassManager::runOnModule(llvm::Module&) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x2f711c1) #19 0x02f71a25 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x2f71a25) #20 0x0082dfcc compileModule(char**, llvm::LLVMContext&) llc.cpp:0:0 #21 0x0072b486 main (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x72b486) #22 0x7a02eb229d90 (/lib/x86_64-linux-gnu/libc.so.6+0x29d90) #23 0x7a02eb229e40 __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x29e40) #24 0x00824aee _start (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x824aee) Program terminated with signal: SIGSEGV Compiler returned: 139 ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 91978] [mlir][spirv] Add vulkan runner integration tests for `vector.shuffle` / `vector.interleave`
Issue 91978 Summary [mlir][spirv] Add vulkan runner integration tests for `vector.shuffle` / `vector.interleave` Labels help wanted, good first issue, mlir:spirv Assignees Reporter kuhar These go through several layers of decomposition / unrolling / emulation when targeting SPIR-V and it would be good to have e2e coverage there. The new tests should be added under: https://github.com/llvm/llvm-project/tree/main/mlir/test/mlir-vulkan-runner ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 91979] LLVM ERROR: Unsupported library call operation!
Issue 91979 Summary LLVM ERROR: Unsupported library call operation! Labels new issue Assignees Reporter DigOrDog # Description The following code crashes aarch64 backend with "LLVM ERROR: Unsupported library call operation!" # Minimal Reproduction https://godbolt.org/z/h3zvfE69b ## Code ``` ; ModuleID = 'Fuzzer input' source_filename = "M" @G = global float 0x36A0 @G.1 = global <32 x i2> define i32 @f() { BB: %A2 = alloca x86_fp80, align 16 store x86_fp80 undef, ptr %A2, align 16 %A = alloca <32 x i2>, align 8 %L1 = load float, ptr %A, align 4 store <32 x i2> undef, ptr %A, align 8 %CastIToFP = sitofp i64 -1 to float %RP = alloca i32, align 4 %CastFPTrunc = fpext float %L1 to x86_fp80 %L = load i64, ptr %RP, align 4 %Castbitcast = bitcast i64 %L to <32 x i2> %0 = load i32, ptr %RP, align 4 store float %CastIToFP, ptr @G, align 4 %Castbitcast1 = bitcast i64 %L to <32 x i2> store <32 x i2> %Castbitcast, ptr %A, align 8 store <32 x i2> %Castbitcast1, ptr @G.1, align 8 store x86_fp80 %CastFPTrunc, ptr %A2, align 16 ret i32 %0 } ``` ## Stack Trace ``` LLVM ERROR: Unsupported library call operation! PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. Stack dump: 0. Program arguments: /opt/compiler-explorer/clang-trunk/bin/llc -o /app/output.s -x86-asm-syntax=intel -mtriple=aarch64 -O=0 1. Running pass 'Function Pass Manager' on module ''. 2. Running pass 'AArch64 Instruction Selection' on function '@f' #0 0x0369cd38 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-trunk/bin/llc+0x369cd38) #1 0x0369a6ac SignalHandler(int) Signals.cpp:0:0 #2 0x781980a42520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520) #3 0x781980a969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc) #4 0x781980a42476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476) #5 0x781980a287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3) #6 0x00729d2e llvm::UniqueStringSaver::save(llvm::StringRef) (.cold) StringSaver.cpp:0:0 #7 0x035f53f8 (/opt/compiler-explorer/clang-trunk/bin/llc+0x35f53f8) #8 0x034dc187 llvm::TargetLowering::makeLibCall(llvm::SelectionDAG&, llvm::RTLIB::Libcall, llvm::EVT, llvm::ArrayRef, llvm::TargetLowering::MakeLibCallOptions, llvm::SDLoc const&, llvm::SDValue) const (/opt/compiler-explorer/clang-trunk/bin/llc+0x34dc187) #9 0x0356e08f llvm::DAGTypeLegalizer::SoftenFloatRes_FP_EXTEND(llvm::SDNode*) (/opt/compiler-explorer/clang-trunk/bin/llc+0x356e08f) #10 0x0356e44b llvm::DAGTypeLegalizer::SoftenFloatResult(llvm::SDNode*, unsigned int) (/opt/compiler-explorer/clang-trunk/bin/llc+0x356e44b) #11 0x03501aa2 llvm::DAGTypeLegalizer::run() (/opt/compiler-explorer/clang-trunk/bin/llc+0x3501aa2) #12 0x035020f1 llvm::SelectionDAG::LegalizeTypes() (/opt/compiler-explorer/clang-trunk/bin/llc+0x35020f1) #13 0x03478a21 llvm::SelectionDAGISel::CodeGenAndEmitDAG() (/opt/compiler-explorer/clang-trunk/bin/llc+0x3478a21) #14 0x0347b868 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) (/opt/compiler-explorer/clang-trunk/bin/llc+0x347b868) #15 0x0347e049 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) (.part.0) SelectionDAGISel.cpp:0:0 #16 0x027d3810 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (.part.0) MachineFunctionPass.cpp:0:0 #17 0x02cf7af2 llvm::FPPassManager::runOnFunction(llvm::Function&) (/opt/compiler-explorer/clang-trunk/bin/llc+0x2cf7af2) #18 0x02cf7c71 llvm::FPPassManager::runOnModule(llvm::Module&) (/opt/compiler-explorer/clang-trunk/bin/llc+0x2cf7c71) #19 0x02cf9920 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/opt/compiler-explorer/clang-trunk/bin/llc+0x2cf9920) #20 0x0083e4f4 compileModule(char**, llvm::LLVMContext&) llc.cpp:0:0 #21 0x0073befe main (/opt/compiler-explorer/clang-trunk/bin/llc+0x73befe) #22 0x781980a29d90 (/lib/x86_64-linux-gnu/libc.so.6+0x29d90) #23 0x781980a29e40 __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x29e40) #24 0x0083613e _start (/opt/compiler-explorer/clang-trunk/bin/llc+0x83613e) Program terminated with signal: SIGSEGV Compiler returned: 139 ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 91982] [clang-tidy] modernize-min-max-use-initializer-list
Issue 91982 Summary [clang-tidy] modernize-min-max-use-initializer-list Labels clang-tidy Assignees Reporter VReichelt Running the recently intoroduced clang-tidy check `modernize-min-max-use-initializer-list` on the following valid code snippet triggers an assertion: ``` clang-tidy: /LLVM/llvm-project/llvm/include/llvm/Support/Casting.h:706: auto llvm::cast_if_present(Y*) [with X = clang::Expr; Y = const clang::Stmt]: Assertion `isa(Val) && "cast_if_present() argument of incompatible type!"' failed. ``` ``` #include int x() const; int y() const; int z() const; int foo() { return std::max(x(), std::max(y(), z())); } ``` Stacktrace attached [Crash.txt](https://github.com/llvm/llvm-project/files/15296684/Crash.txt) ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 91983] Incorrect promise constructor used with lambda coroutines
Issue 91983 Summary Incorrect promise constructor used with lambda coroutines Labels new issue Assignees Reporter landelare In the C++20 program below, the lambda has a non-static member operator(), but its object parameter is skipped when looking for a promise constructor overload. This results in the first overload being called, and an output of `Wrong`. Tested on 18.1.5 and 19.0.0git (b5af667b01458e9083256f2614df175916c73e5a). When compiled with GCC or MSVC, the output is `Correct`, as expected. Additionally, removing the second constructor should make the resulting program no longer compile, which is the case with MSVC and GCC, but not Clang. ```c++ #include #include struct coro {}; struct promise { promise(int) {std::cout << "Wrong\n";} promise(auto, int){std::cout << "Correct\n";} // Remove me for an additional test case! coro get_return_object() {return {};} std::suspend_never initial_suspend() {return {};} std::suspend_never final_suspend() noexcept {return {};} void return_value(int) {} void unhandled_exception() {} }; template struct std::coroutine_traits { using promise_type = promise; }; int main() { int x = 0; [x](int y) -> coro { co_return x + y; }(1); } ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 91996] lldb on windows: The debugger crashes when trying to print a `shared_ptr`
Issue 91996 Summary lldb on windows: The debugger crashes when trying to print a `shared_ptr` Labels new issue Assignees Reporter sigasigasiga ```cpp #include #include int main() { std::shared_ptr p; std::cout << p << std::endl; } ``` Given the code above which was compiled with `clang++ -g3 cpp.cpp` I'm unable to print the contents of `p`: ```gdb $ lldb a.exe (lldb) target create "a.exe" (lldb) Current executable set to 'C:\dev\toy\a.exe' (x86_64). (lldb) process launch -m (lldb) Process 24372 launched: 'C:\dev\toy\a.exe' (x86_64) Process 24372 stopped * thread #1, stop reason = one-shot breakpoint 1 frame #0: 0x7ff71ba4bd60 a.exe`main at cpp.cpp:4 1#include 2#include 3 -> 4int main() { 5std::shared_ptr p; 6std::cout << p << std::endl; 7} (lldb) n Process 24372 stopped * thread #1, stop reason = step over frame #0: 0x7ff71ba4bd7a a.exe`main at cpp.cpp:5 2#include 3 4int main() { -> 5std::shared_ptr p; 6std::cout << p << std::endl; 7} (lldb) p p error: a.exe :: Class 'std::strong_ordering' has a member 'less' of type 'std::strong_ordering' which does not have a complete definition. error: a.exe :: Class 'std::partial_ordering' has a member 'less' of type 'std::partial_ordering' which does not have a complete definition. error: a.exe :: Class 'std::weak_ordering' has a member 'less' of type 'std::weak_ordering' which does not have a complete definition. (lldb) LLDB diagnostics will be written to C:\Users\EGORBY~1\AppData\Local\Temp\diagnostics-dbd91a Please include the directory content when filing a bug report Exception Code: 0xC005 #0 0x7ffcc890e457 (C:\Program Files\LLVM\bin\liblldb.dll+0x12de457) #1 0x7ffcc86a27dd (C:\Program Files\LLVM\bin\liblldb.dll+0x10727dd) #2 0x7ffcc86a72d8 (C:\Program Files\LLVM\bin\liblldb.dll+0x10772d8) #3 0x7ffcc86a6136 (C:\Program Files\LLVM\bin\liblldb.dll+0x1076136) #4 0x7ffcc86a4d80 (C:\Program Files\LLVM\bin\liblldb.dll+0x1074d80) #5 0x7ffcc7fdbc18 (C:\Program Files\LLVM\bin\liblldb.dll+0x9abc18) #6 0x7ffcc86de283 (C:\Program Files\LLVM\bin\liblldb.dll+0x10ae283) #7 0x7ffcc802756f (C:\Program Files\LLVM\bin\liblldb.dll+0x9f756f) #8 0x7ffcc803b824 (C:\Program Files\LLVM\bin\liblldb.dll+0xa0b824) #9 0x7ffcc803fc46 (C:\Program Files\LLVM\bin\liblldb.dll+0xa0fc46) #10 0x7ffcc8681c52 (C:\Program Files\LLVM\bin\liblldb.dll+0x1051c52) #11 0x7ffcc7fba997 (C:\Program Files\LLVM\bin\liblldb.dll+0x98a997) #12 0x7ffcc8041600 (C:\Program Files\LLVM\bin\liblldb.dll+0xa11600) #13 0x7ffcc7de0a32 (C:\Program Files\LLVM\bin\liblldb.dll+0x7b0a32) #14 0x7ff723dfe925 (C:\Program Files\LLVM\bin\lldb.exe+0xe925) #15 0x7ff723dff328 (C:\Program Files\LLVM\bin\lldb.exe+0xf328) #16 0x7ff723e0c790 (C:\Program Files\LLVM\bin\lldb.exe+0x1c790) #17 0x7ffdccc2257d (C:\Windows\System32\KERNEL32.DLL+0x1257d) #18 0x7ffdce94aa48 (C:\Windows\SYSTEM32\ntdll.dll+0x5aa48) Segmentation fault ``` The diagnostics file is not very interesting, as it duplicates the information in the error output ``` a.exe :: Class 'std::strong_ordering' has a member 'less' of type 'std::strong_ordering' which does not have a complete definition.a.exe :: Class 'std::partial_ordering' has a member 'less' of type 'std::partial_ordering' which does not have a complete definition.a.exe :: Class 'std::weak_ordering' has a member 'less' of type 'std::weak_ordering' which does not have a complete definition. ``` --- Versions ``` > cl Microsoft (R) C/C++ Optimizing Compiler Version 19.39.33519 for x64 Copyright (C) Microsoft Corporation. All rights reserved. usage: cl [ option... ] filename... [ /link linkoption... ] > clang++ --version clang version 18.1.4 Target: x86_64-pc-windows-msvc Thread model: posix InstalledDir: C:\Program Files\LLVM\bin > lldb --version lldb version 18.1.4 ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 91997] [SPIR-V] Inconsistent representation of SPIR-V builtins types as either simple types or pointers to types
Issue 91997 Summary [SPIR-V] Inconsistent representation of SPIR-V builtins types as either simple types or pointers to types Labels backend:SPIR-V Assignees michalpaszkowski Reporter michalpaszkowski SPIRVEmitIntrinsics pass inconsistently assigns types to values representing SPIR-V or OpenCL builtin using either `spv_assign_type` or `spv_assign_ptr_type`. This leads to issues in compilation e.g. when casting the types between address spaces or during runtime e.g. when passing to builtin functions. Example of a kernel with the issue: ``` define spir_kernel void @foo() { %event = alloca ptr, align 8 %call = call spir_func ptr @_Z29async_work_group_strided_copyPU3AS3hPU3AS1Khmm9ocl_event(ptr null, ptr null, i64 1, i64 1, ptr null) store ptr %call, ptr %event, align 8 %event.ascast = addrspacecast ptr %event to ptr addrspace(4) call spir_func void @_Z17wait_group_eventsiPU3AS49ocl_event(i32 2, ptr addrspace(4) %event.ascast) ret void } declare spir_func ptr @_Z29async_work_group_strided_copyPU3AS3hPU3AS1Khmm9ocl_event(ptr, ptr, i64, i64, ptr) declare spir_func void @_Z17wait_group_eventsiPU3AS49ocl_event(i32, ptr addrspace(4)) ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 91998] [SPIR-V] The order of instructions leads to errors in pointer element type deduction or crashes compilation
Issue 91998 Summary [SPIR-V] The order of instructions leads to errors in pointer element type deduction or crashes compilation Labels backend:SPIR-V Assignees michalpaszkowski Reporter michalpaszkowski The current implementation of SPIRVEmitIntrinsics sometimes allows generating duplicate `spv_assign_ptr_type` and `spv_assign_type` intrinsics. In these cases the order of instructions (and which intrinsic is selected first) plays a role in correct type deduction. In other words, the order of instructions or operands sometimes leads to incorrect type deduction or compilation crashes. TODO: Add a simple test case ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 92000] Missed coalescing of adjacent writes to stack variables
Issue 92000 Summary Missed coalescing of adjacent writes to stack variables Labels new issue Assignees Reporter Bryce-MW Here's a simple reproduction: https://godbolt.org/z/5dza4c787 (should be `mov qword ptr[rsp], 0`). I know that LLVM can coalesce known adjacent writes. The problem here is that these variables are not known to be adjacent until stack slot allocation which I know happens during target code generation so this isn't solvable at the IR level. I suspect that means that the solution would have to be per-target (currently, I can reproduce this on every arch that compiler explorer has though I am not proficient in non-x86_64 asm so I could be wrong). ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 92015] [clang] -Wmissing-include-dirs not implemented
Issue 92015 Summary [clang] -Wmissing-include-dirs not implemented Labels clang Assignees Reporter aeubanks Clang accepts but does not implement gcc's -Wmissing-include-dirs, which warns if a non-existent path is specified to `-I` (or any of the other similar arguments). https://gcc.gnu.org/pipermail/gcc-patches/2004-May/139462.html ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 92023] Wdocumentation false postive warning for a
Issue 92023 Summary Wdocumentation false postive warning for a Labels new issue Assignees Reporter andrei-sandor Here is a bug regarding a Doxygen annotation for a struct. Given the file structDoxygenFinal.cxx: ```c++ /** * \struct BooleanDispatch * \brief A comment here */ template struct BooleanDispatch {}; int main () { return 0; } ``` Run this command: ``` clang++ -Wdocumentation -std=c++14 -fsyntax-only structDoxygenFinal.cxx ``` The following warning will be generated ``` structDoxygenFinal.cxx:3:5: warning: '@struct' command should not be used in a comment attached to a non-struct declaration [-Wdocumentation] * \struct BooleanDispatch ~^~ 1 warning generated. ``` To fix this warning, the comment could be placed between Template and struct BooleanDispatch in structDoxygenFinal.cxx Is it fine, if in general, a Doxygen comment with \struct is placed between a template statement and a struct statement? ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 92033] [clang-cl] Using pointer to member as argument to template in the same class results in incorrect layout
Issue 92033 Summary [clang-cl] Using pointer to member as argument to template in the same class results in incorrect layout Labels new issue Assignees Reporter erikolofsson https://godbolt.org/z/ddhddo9zP ### Reproduction `-target x86_64-windows -std=c++23` ``` struct TestStruct { }; template struct TestTemplate { constexpr static int constexprStaticValue = 0; template struct InnerStruct { }; using InnerType = InnerStruct; }; struct TestRecursive { TestStruct link; TestTemplate<&TestRecursive::link> tree; }; void TestFrame() { TestRecursive Test; } ``` ### Warning ``` :24:6: error: stack frame size (118115794992) exceeds limit (4294967295) in 'void __cdecl TestFrame(void)' [-Werror,-Wframe-larger-than ``` The same code works when targeting macOS or Linux. Cloud be related to: https://github.com/llvm/llvm-project/issues/80806 A workaround is to replace the `constexpr static` with an `enum`. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 92035] Clang 18.1.6 crashes in TestFind with SIMD tag with hwy::float16_t lane type on AVX512_FP16
Issue 92035 Summary Clang 18.1.6 crashes in TestFind with SIMD tag with hwy::float16_t lane type on AVX512_FP16 Labels clang Assignees Reporter johnplatts Here is the crash that occurs when compiling TestFind for vector types that have a SIMD tag with a lane type of hwy::float16_t for x86_64 with `-march=sapphirerapids` when compiled with Clang 18.1.6: ``` 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/bin/clang++-18 -DHWY_STATIC_DEFINE -DTOOLCHAIN_MISS_ASM_HWCAP_H -I/home/jplatts/jepprojects/hwy_avx3_dl_clang_f16_051324/jep_google_highway -isystem /home/jplatts/jepprojects/hwy_avx3_dl_clang_f16_051324/avx3_spr_build/googletest-src/googletest/include -isystem /home/jplatts/jepprojects/hwy_avx3_dl_clang_f16_051324/avx3_spr_build/googletest-src/googletest -march=sapphirerapids -DHWY_COMPILE_ONLY_STATIC=1 -ftrapv -O2 -g -DNDEBUG -fPIE -fvisibility=hidden -fvisibility-inlines-hidden -Wno-builtin-macro-redefined -D__DATE__=\"redacted\" -D__TIMESTAMP__=\"redacted\" -D__TIME__=\"redacted\" -fmerge-all-constants -Wall -Wextra -Wconversion -Wsign-conversion -Wvla -Wnon-virtual-dtor -Wcast-align -Wfloat-overflow-conversion -Wfloat-zero-conversion -Wfor-loop-analysis -Wgnu-redeclared-enum -Winfinite-recursion -Wself-assign -Wstring-conversion -Wtautological-overlap-compare -Wthread-safety-analysis -Wundefined-func-template -fno-cxx-exceptions -fno-slp-vectorize -fno-vectorize -fdiagnostics-show-option -fcolor-diagnostics -Wc++2a-extensions -fmath-errno -fno-exceptions -Wno-psabi -Werror -DHWY_IS_TEST=1 -std=c++14 -MD -MT CMakeFiles/find_test.dir/hwy/contrib/algo/find_test.cc.o -MF CMakeFiles/find_test.dir/hwy/contrib/algo/find_test.cc.o.d -o CMakeFiles/find_test.dir/hwy/contrib/algo/find_test.cc.o -c /home/jplatts/jepprojects/hwy_avx3_dl_clang_f16_051324/jep_google_highway/hwy/contrib/algo/find_test.cc 1. parser at end of file 2. Code generation 3. Running pass 'Function Pass Manager' on module '/home/jplatts/jepprojects/hwy_avx3_dl_clang_f16_051324/jep_google_highway/hwy/contrib/algo/find_test.cc'. 4. Running pass 'Early Machine Loop Invariant Code Motion' on function '@_ZN3hwy10N_AVX3_SPR8TestFindclINS0_4SimdINS_9float16_tELm32ELi0EvT_mmRNS_11RandomStateE' #0 0x7d32a19946d6 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/usr/lib/llvm-18/bin/../lib/libLLVM.so.18.1+0xd946d6) #1 0x7d32a1992690 llvm::sys::RunSignalHandlers() (/usr/lib/llvm-18/bin/../lib/libLLVM.so.18.1+0xd92690) #2 0x7d32a18e41b0 (/usr/lib/llvm-18/bin/../lib/libLLVM.so.18.1+0xce41b0) #3 0x7d32a0442520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520) #4 0x7d32a47f44f4 (/usr/lib/llvm-18/bin/../lib/libLLVM.so.18.1+0x3bf44f4) clang++-18: error: clang frontend command failed with exit code 139 (use -v to see invocation) Ubuntu clang version 18.1.6 (++20240513065742+09615ce869b0-1~exp1~20240513065903.119) Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/bin clang++-18: note: diagnostic msg: PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang++-18: note: diagnostic msg: /tmp/find_test-aae644.cpp clang++-18: note: diagnostic msg: /tmp/find_test-aae644.sh clang++-18: note: diagnostic msg: make[3]: *** [CMakeFiles/find_test.dir/build.make:76: CMakeFiles/find_test.dir/hwy/contrib/algo/find_test.cc.o] Error 1 make[2]: *** [CMakeFiles/Makefile2:1169: CMakeFiles/find_test.dir/all] Error 2 make[1]: *** [CMakeFiles/Makefile2:1176: CMakeFiles/find_test.dir/rule] Error 2 make: *** [Makefile:621: find_test] Error 2 ``` Attached are preprocessed soruces and run script: [avx3_spr_f16_find_test_051324_0418pm.zip](https://github.com/llvm/llvm-project/files/15300105/avx3_spr_f16_find_test_051324_0418pm.zip) The same code compiles successfully with GCC 12 or later. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 92054] Factor `Error` and `Expected` boilerplate return-macros
Issue 92054 Summary Factor `Error` and `Expected` boilerplate return-macros Labels new issue Assignees Reporter mtrofin Examples: [`RETURN_IF_ERROR` and `ASSIGN_OR_RETURN`](https://github.com/llvm/llvm-project/blob/c3028a230557405b0f10bdd7d450f7f92747bbe3/llvm/tools/llvm-rc/ResourceScriptParser.cpp#L20-L30) or [these](https://github.com/llvm/llvm-project/blob/c3028a230557405b0f10bdd7d450f7f92747bbe3/llvm/unittests/tools/llvm-profdata/OutputSizeLimitTest.cpp#L56-L70) with a slightly different name. The idea is to place them in Error.h ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 92056] Inconsistent results when using --buffer-deallocation
Issue 92056 Summary Inconsistent results when using --buffer-deallocation Labels new issue Assignees Reporter wangyongj1a I have the following MLIR program: test.mlir: ``` module { func.func @func0(%arg0: tensor<19xi32>) -> (){ %0 = arith.constant 2 : index %1 = tensor.extract %arg0[%0] : tensor<19xi32> vector.print %1 : i32 return } func.func private @func1() { %0 = arith.constant 10 : i32 %1 = tensor.from_elements %0 : tensor<1xi32> %2 = tensor.from_elements %0, %0, %0, %0, %0, %0, %0, %0, %0, %0, %0, %0, %0, %0, %0, %0, %0, %0, %0 : tensor<19xi32> call @func0(%2) : (tensor<19xi32>) -> () return } } ``` When I tried to lower the program with ```mlir-opt --tensor-bufferize --buffer-deallocation --convert-scf-to-cf --convert-cf-to-llvm --func-bufferize --convert-func-to-llvm --convert-index-to-llvm --convert-vector-to-llvm --finalize-memref-to-llvm --convert-arith-to-llvm --reconcile-unrealized-casts test.mlir```, and executed the executable file, I got inconsistent results over multiple runs. I noticed that after using the passes ```--tensor-bufferize --buffer-deallocation```, the program was lowered to: ``` module { func.func @func0(%arg0: tensor<19xi32>) { %0 = bufferization.to_memref %arg0 : memref<19xi32> %c2 = arith.constant 2 : index %1 = memref.load %0[%c2] : memref<19xi32> vector.print %1 : i32 return } func.func private @func1() { %c10_i32 = arith.constant 10 : i32 %alloc = memref.alloc() {alignment = 64 : i64} : memref<1xi32> %c0 = arith.constant 0 : index memref.store %c10_i32, %alloc[%c0] : memref<1xi32> memref.dealloc %alloc : memref<1xi32> %alloc_0 = memref.alloc() {alignment = 64 : i64} : memref<19xi32> %c0_1 = arith.constant 0 : index %c1 = arith.constant 1 : index %c2 = arith.constant 2 : index %c3 = arith.constant 3 : index %c4 = arith.constant 4 : index %c5 = arith.constant 5 : index %c6 = arith.constant 6 : index %c7 = arith.constant 7 : index %c8 = arith.constant 8 : index %c9 = arith.constant 9 : index %c10 = arith.constant 10 : index %c11 = arith.constant 11 : index %c12 = arith.constant 12 : index %c13 = arith.constant 13 : index %c14 = arith.constant 14 : index %c15 = arith.constant 15 : index %c16 = arith.constant 16 : index %c17 = arith.constant 17 : index %c18 = arith.constant 18 : index memref.store %c10_i32, %alloc_0[%c0_1] : memref<19xi32> memref.store %c10_i32, %alloc_0[%c1] : memref<19xi32> memref.store %c10_i32, %alloc_0[%c2] : memref<19xi32> memref.store %c10_i32, %alloc_0[%c3] : memref<19xi32> memref.store %c10_i32, %alloc_0[%c4] : memref<19xi32> memref.store %c10_i32, %alloc_0[%c5] : memref<19xi32> memref.store %c10_i32, %alloc_0[%c6] : memref<19xi32> memref.store %c10_i32, %alloc_0[%c7] : memref<19xi32> memref.store %c10_i32, %alloc_0[%c8] : memref<19xi32> memref.store %c10_i32, %alloc_0[%c9] : memref<19xi32> memref.store %c10_i32, %alloc_0[%c10] : memref<19xi32> memref.store %c10_i32, %alloc_0[%c11] : memref<19xi32> memref.store %c10_i32, %alloc_0[%c12] : memref<19xi32> memref.store %c10_i32, %alloc_0[%c13] : memref<19xi32> memref.store %c10_i32, %alloc_0[%c14] : memref<19xi32> memref.store %c10_i32, %alloc_0[%c15] : memref<19xi32> memref.store %c10_i32, %alloc_0[%c16] : memref<19xi32> memref.store %c10_i32, %alloc_0[%c17] : memref<19xi32> memref.store %c10_i32, %alloc_0[%c18] : memref<19xi32> %0 = bufferization.to_tensor %alloc_0 : memref<19xi32> memref.dealloc %alloc_0 : memref<19xi32> call @func0(%0) : (tensor<19xi32>) -> () return } } ``` The memory of ```%alloc_0``` seems to be deallocated before the related tensor ```%0``` was used as an attribute in the function call. I also tried to use the pass ```--buffer-deallocation-simplification``` after ```--buffer-deallocation```, but it seems couldn't help with this case. I'm not sure if there is any bug in my program or the wrong usage of ```--buffer-deallocation``` and ```--buffer-deallocation-simplification``` that caused this error. My git version is 4c79d38f82e1f6fe8575d88d8c74f2f1806b19ce. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 92057] Crash
Issue 92057 Summary Crash Labels new issue Assignees Reporter wangyongj1a I have the following MLIR program: test.mlir: ``` func.func @func1() { %1 = arith.constant 5 : i16 %i0 = arith.constant 0 : index %3 = tensor.from_elements %1, %1, %1, %1, %1, %1, %1, %1, %1, %1, %1, %1 : tensor<12xi16> %10 = arith.extsi %3 : tensor<12xi16> to tensor %7 = tensor.dim %10, %i0 : tensor return } ``` The above MLIR program will cause a crash when using the following command: ``` mlir-opt --canonicalize test.mlir ``` And the crash backtrace is: ``` mlir-opt: /data/tmp/v0514/llvm-project/mlir/lib/IR/BuiltinAttributes.cpp:1342: static mlir::DenseElementsAttr mlir::DenseIntOrFPElementsAttr::getRaw(mlir::ShapedType, llvm::ArrayRef): Assertion `type.hasStaticShape() && "type must have static shape"' failed. PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. Stack dump: 0. Program arguments: /data/tmp/v0514/llvm-project/build/bin/mlir-opt --canonicalize test.mlir #0 0x559cf13586ef llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/data/tmp/v0514/llvm-project/build/bin/mlir-opt+0x15946ef) #1 0x559cf1355744 SignalHandler(int) Signals.cpp:0:0 #2 0x7f5be1cbb420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420) #3 0x7f5be178800b raise (/lib/x86_64-linux-gnu/libc.so.6+0x4300b) #4 0x7f5be1767859 abort (/lib/x86_64-linux-gnu/libc.so.6+0x22859) #5 0x7f5be1767729 (/lib/x86_64-linux-gnu/libc.so.6+0x22729) #6 0x7f5be1778fd6 (/lib/x86_64-linux-gnu/libc.so.6+0x33fd6) #7 0x559cf4427f58 mlir::DenseIntOrFPElementsAttr::getRaw(mlir::ShapedType, llvm::ArrayRef) (/data/tmp/v0514/llvm-project/build/bin/mlir-opt+0x4663f58) #8 0x559cf442924a mlir::DenseIntOrFPElementsAttr::getRaw(mlir::ShapedType, unsigned long, llvm::ArrayRef) (/data/tmp/v0514/llvm-project/build/bin/mlir-opt+0x466524a) #9 0x559cf4429559 mlir::DenseElementsAttr::get(mlir::ShapedType, llvm::ArrayRef) (/data/tmp/v0514/llvm-project/build/bin/mlir-opt+0x4665559) #10 0x559cf15d5bd1 mlir::arith::ExtSIOp::fold(mlir::arith::ExtSIOpGenericAdaptor>) (/data/tmp/v0514/llvm-project/build/bin/mlir-opt+0x1811bd1) #11 0x559cf1631e07 mlir::LogicalResult llvm::detail::UniqueFunctionBase, llvm::SmallVectorImpl&>::CallImpl::Impl, mlir::OpTrait::ZeroSuccessors, mlir::OpTrait::OneOperand, mlir::OpTrait::OpInvariants, mlir::InferIntRangeInterface::Trait, mlir::ConditionallySpeculatable::Trait, mlir::OpTrait::AlwaysSpeculatableImplTrait, mlir::MemoryEffectOpInterface::Trait, mlir::OpTrait::SameOperandsAndResultShape, mlir::CastOpInterface::Trait, mlir::VectorUnrollOpInterface::Trait, mlir::OpTrait::Elementwise, mlir::OpTrait::Scalarizable, mlir::OpTrait::Vectorizable, mlir::OpTrait::Tensorizable>::getFoldHookFn()::'lambda'(mlir::Operation*, llvm::ArrayRef, llvm::SmallVectorImpl&) const>(void*, mlir::Operation*, llvm::ArrayRef, llvm::SmallVectorImpl&) (/data/tmp/v0514/llvm-project/build/bin/mlir-opt+0x186de07) #12 0x559cf1629376 mlir::RegisteredOperationName::Model::foldHook(mlir::Operation*, llvm::ArrayRef, llvm::SmallVectorImpl&) (/data/tmp/v0514/llvm-project/build/bin/mlir-opt+0x1865376) #13 0x559cf44dee34 mlir::Operation::fold(llvm::ArrayRef, llvm::SmallVectorImpl&) (/data/tmp/v0514/llvm-project/build/bin/mlir-opt+0x471ae34) #14 0x559cf44df1c8 mlir::Operation::fold(llvm::SmallVectorImpl&) (/data/tmp/v0514/llvm-project/build/bin/mlir-opt+0x471b1c8) #15 0x559cf437a72e (anonymous namespace)::GreedyPatternRewriteDriver::processWorklist() GreedyPatternRewriteDriver.cpp:0:0 #16 0x559cf437d81b mlir::applyPatternsAndFoldGreedily(mlir::Region&, mlir::FrozenRewritePatternSet const&, mlir::GreedyRewriteConfig, bool*) (/data/tmp/v0514/llvm-project/build/bin/mlir-opt+0x45b981b) #17 0x559cf42e900a (anonymous namespace)::Canonicalizer::runOnOperation() Canonicalizer.cpp:0:0 #18 0x559cf42c9881 mlir::detail::OpToOpPassAdaptor::run(mlir::Pass*, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int) (/data/tmp/v0514/llvm-project/build/bin/mlir-opt+0x4505881) #19 0x559cf42c9d6a mlir::detail::OpToOpPassAdaptor::runPipeline(mlir::OpPassManager&, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int, mlir::PassInstrumentor*, mlir::PassInstrumentation::PipelineParentInfo const*) (/data/tmp/v0514/llvm-project/build/bin/mlir-opt+0x4505d6a) #20 0x559cf42ca524 mlir::PassManager::run(mlir::Operation*) (/data/tmp/v0514/llvm-project/build/bin/mlir-opt+0x4506524) #21 0x559cf42bb9ab performActions(llvm::raw_ostream&, std::shared_ptr const&, mlir::MLIRContext*, mlir::MlirOptMainConfig const&) MlirOptMain.cpp:0:0 #22 0x559cf42bc364 processBuffer(llvm::raw_ostream&, std::unique_ptr>, mlir::MlirOptMainConfig const&, mlir::Dial
[llvm-bugs] [Bug 92059] What does this "%mlir_cuda_runtime" refer to?
Issue 92059 Summary What does this "%mlir_cuda_runtime" refer to? Labels new issue Assignees Reporter BruceDai003 https://github.com/llvm/llvm-project/blob/e20800c16f0570562fea31e9a02d65ba56e6858a/mlir/test/Integration/GPU/CUDA/all-reduce-and.mlir#L4 Hello, I'm new to these tests, don't know what these `"%mlir_cuda_runtime", "%mlir_runner_utils", cubin-format=%gpu_compilation_format"` refer to. Could anybody tell me what they are? Thanks. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 92060] fatal error: error in backend: unknown codeview register HSI
Issue 92060 Summary fatal error: error in backend: unknown codeview register HSI Labels new issue Assignees Reporter oocpp 11:32:37:733 1>fatal error: error in backend: unknown codeview register HSI 11:32:37:733 1>PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script. 11:32:37:733 1>Stack dump: 11:32:37:734 1>0. Program arguments: "C:\\Program Files\\Microsoft Visual Studio\\2022\\Preview\\VC\\Tools\\Llvm\\x64\\bin\\clang-cl.exe" @G:\\link\\Temp\\MSBuildTemp\\tmp281af428f5694b638d1d08c26d8b7191.rsp 11:32:37:734 1>1. parser at end of file 11:32:37:734 1>2. Code generation 11:32:37:734 1>3. Running pass 'Function Pass Manager' on module 'G:\code\CCCreator3\Effect\Business\Base\Framework\BEFEffect\Parser\ParserFactory.cpp'. 11:32:37:734 1>4. Running pass 'X86 Assembly Printer' on function '@"??1?$pair@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@V?$function@$$A6APEAVBaseParser@BEF@@XZ@2@@std@@QEAA@XZ"' 11:32:37:734 1>Exception Code: 0xE046 11:32:37:789 1> #0 0x7fff9045ab89 (C:\Windows\System32\KERNELBASE.dll+0x2ab89) 11:32:37:794 1> #1 0x7ff69b391b8a C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x501b8a C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x502049 11:32:37:794 1> #2 0x7ff69b391b8a C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x9021 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x520a8c 11:32:37:794 1> #3 0x7ff69b391b8a C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x68595d C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x1941974 11:32:37:794 1> #4 0x7ff69b391b8a C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x1941d9f C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x1948008 11:32:37:794 1> #5 0x7ff69b391b8a C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x1f69139 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x659e77 11:32:37:794 1> #6 0x7ff69b391b8a C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x2405e4 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x6d823d 11:32:37:794 1> #7 0x7ff69b391b8a C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x3824a8 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x3885b3 11:32:37:794 1> #8 0x7ff69b391b8a C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x382b37 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x14cb704 11:32:37:794 1> #9 0x7ff69b391b8a C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x189764e C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x314cf84 11:32:37:794 1>#10 0x7ff69b391b8a C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x1801582 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x5bd4cd 11:32:37:794 1>#11 0x7ff69b391b8a C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x64fdde C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x8bd6 11:32:37:794 1>#12 0x7ff69b391b8a C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x53a9 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x168e28d 11:32:37:794 1>#13 0x7ff69b391b8a C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x501aa5 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x168da5e 11:32:37:794 1>#14 0x7ff69b391b8a C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x5a82e5 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x5a862e 11:32:37:794 1>#15 0x7ff69b391b8a C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x58e66b C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x4c2a 11:32:37:794 1>#16 0x7ff69b391b8a C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\
[llvm-bugs] Issue 65424 in oss-fuzz: llvm:llvm-special-case-list-fuzzer: Stack-overflow in p_ere
Updates: Status: WontFix Comment #1 on issue 65424 by ClusterFuzz-External: llvm:llvm-special-case-list-fuzzer: Stack-overflow in p_ere https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=65424#c1 ClusterFuzz testcase 5593834478174208 is closed as invalid, so closing issue. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 92061] [clang-tidy] create a check that looks for constructing a string from a nullptr
Issue 92061 Summary [clang-tidy] create a check that looks for constructing a string from a nullptr Labels enhancement, good first issue, clang-tidy Assignees Reporter LegalizeAdulthood Consider the following code: ``` std::string foo() { return nullptr; } ``` See [compiler explorer example](https://godbolt.org/z/azW348cbd) This code compiles just fine with no warnings or errors, but crashes when you run it. We should be able to detect cases where a `nullptr` is used to construct a string, at least in the simple case above. I had a real-world bug that was exactly the above scenario, although I have simplified the example to remove irrelevant code. Obviously more sophisticated data flow analysis can propagate `nullptr` through usages until it hits a `std::basic_string` constructor, but even detecting the above simple case would be a useful start. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 92062] [RegBankSelect] Assertion `N < NumContainedTys && "Element number out of range!"'
Issue 92062 Summary [RegBankSelect] Assertion `N < NumContainedTys && "Element number out of range!"' Labels backend:ARM, llvm:codegen, crash-on-valid Assignees Reporter DianQK I tried the following code: ```llvm target triple = "arm64" @p = external global { {}, { ptr } } define void @foo() { bb: %i1 = load ptr, ptr @p, align 8 store ptr %i1, ptr null, align 8 ret void } ``` When using llc in LLVM 18, the following error occurs: ``` llc: /root/llvm-project/llvm/include/llvm/IR/DerivedTypes.h:343: llvm::Type* llvm::StructType::getElementType(unsigned int) const: Assertion `N < NumContainedTys && "Element number out of range!"' failed. PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. Stack dump: 0. Program arguments: /opt/compiler-explorer/clang-assertions-trunk/bin/llc -o /app/output.s -x86-asm-syntax=intel -O0 1. Running pass 'Function Pass Manager' on module ''. 2. Running pass 'RegBankSelect' on function '@foo' ... #8 0x00b27667 llvm::AArch64RegisterBankInfo::isLoadFromFPType(llvm::MachineInstr const&) const (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0xb27667) #9 0x00b2b155 llvm::AArch64RegisterBankInfo::getInstrMapping(llvm::MachineInstr const&) const (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0xb2b155) #10 0x04203f47 llvm::RegBankSelect::assignInstr(llvm::MachineInstr&) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x4203f47) #11 0x042044d3 llvm::RegBankSelect::assignRegisterBanks(llvm::MachineFunction&) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x42044d3) ... Compiler returned: 139 ``` https://llvm.godbolt.org/z/a4h1abfKc ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 92064] Crash when using --pass-pipeline="builtin.module(func.func(tosa-to-linalg))"
Issue 92064 Summary Crash when using --pass-pipeline="builtin.module(func.func(tosa-to-linalg))" Labels new issue Assignees Reporter wangyongj1a I have the following MLIR program: test.mlir: ``` module { func.func nested @func1() { %33 = tensor.empty() : tensor<1x1x1xi1> %output_real, %output_imag = "tosa.rfft2d"(%33) : (tensor<1x1x1xi1>) -> (tensor<1x1x1xi1>, tensor<1x1x1xi1>) return } } ``` The above MLIR program will cause a crash when using the following command: ``` mlir-opt --pass-pipeline="builtin.module(func.func(tosa-to-linalg))" test.mlir ``` And the crash backtrace is: ``` mlir-opt: /data/tmp/v0514/llvm-project/llvm/include/llvm/Support/Casting.h:566: decltype(auto) llvm::cast(const From&) [with To = mlir::FloatType; From = mlir::Type]: Assertion `isa(Val) && "cast() argument of incompatible type!"' failed. PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. Stack dump: 0. Program arguments: /data/tmp/v0514/llvm-project/build/bin/mlir-opt --pass-pipeline=builtin.module(func.func(tosa-to-linalg)) test.mlir #0 0x556fdf39c6ef llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/data/tmp/v0514/llvm-project/build/bin/mlir-opt+0x15946ef) #1 0x556fdf399744 SignalHandler(int) Signals.cpp:0:0 #2 0x7fa27c8c7420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420) #3 0x7fa27c39400b raise (/lib/x86_64-linux-gnu/libc.so.6+0x4300b) #4 0x7fa27c373859 abort (/lib/x86_64-linux-gnu/libc.so.6+0x22859) #5 0x7fa27c373729 (/lib/x86_64-linux-gnu/libc.so.6+0x22729) #6 0x7fa27c384fd6 (/lib/x86_64-linux-gnu/libc.so.6+0x33fd6) #7 0x556fe1bf7a2e (anonymous namespace)::RFFT2dConverter::matchAndRewrite(mlir::tosa::RFFT2dOp, mlir::PatternRewriter&) const TosaToLinalg.cpp:0:0 #8 0x556fe1bc552f mlir::detail::OpOrInterfaceRewritePatternBase::matchAndRewrite(mlir::Operation*, mlir::PatternRewriter&) const (/data/tmp/v0514/llvm-project/build/bin/mlir-opt+0x3dbd52f) #9 0x556fe52d41a8 mlir::PatternApplicator::matchAndRewrite(mlir::Operation*, mlir::PatternRewriter&, llvm::function_ref, llvm::function_ref, llvm::function_ref) (/data/tmp/v0514/llvm-project/build/bin/mlir-opt+0x74cc1a8) #10 0x556fe23ab396 (anonymous namespace)::OperationLegalizer::legalize(mlir::Operation*, mlir::ConversionPatternRewriter&) DialectConversion.cpp:0:0 #11 0x556fe23acb9e mlir::OperationConverter::convert(mlir::ConversionPatternRewriter&, mlir::Operation*) (/data/tmp/v0514/llvm-project/build/bin/mlir-opt+0x45a4b9e) #12 0x556fe23b289b mlir::OperationConverter::convertOperations(llvm::ArrayRef) (/data/tmp/v0514/llvm-project/build/bin/mlir-opt+0x45aa89b) #13 0x556fe23b2eed mlir::applyFullConversion(mlir::Operation*, mlir::ConversionTarget const&, mlir::FrozenRewritePatternSet const&, mlir::ConversionConfig) (/data/tmp/v0514/llvm-project/build/bin/mlir-opt+0x45aaeed) #14 0x556fe1bba34d (anonymous namespace)::TosaToLinalg::runOnOperation() TosaToLinalgPass.cpp:0:0 #15 0x556fe230d881 mlir::detail::OpToOpPassAdaptor::run(mlir::Pass*, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int) (/data/tmp/v0514/llvm-project/build/bin/mlir-opt+0x4505881) #16 0x556fe230dd6a mlir::detail::OpToOpPassAdaptor::runPipeline(mlir::OpPassManager&, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int, mlir::PassInstrumentor*, mlir::PassInstrumentation::PipelineParentInfo const*) (/data/tmp/v0514/llvm-project/build/bin/mlir-opt+0x4505d6a) #17 0x556fe230e6fc mlir::detail::OpToOpPassAdaptor::runOnOperationAsyncImpl(bool)::'lambda'(mlir::detail::OpToOpPassAdaptor::runOnOperationAsyncImpl(bool)::OpPMInfo&)::operator()(mlir::detail::OpToOpPassAdaptor::runOnOperationAsyncImpl(bool)::OpPMInfo&) const Pass.cpp:0:0 #18 0x556fe230cdd5 mlir::detail::OpToOpPassAdaptor::runOnOperationAsyncImpl(bool) (/data/tmp/v0514/llvm-project/build/bin/mlir-opt+0x4504dd5) #19 0x556fe230d606 mlir::detail::OpToOpPassAdaptor::run(mlir::Pass*, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int) (/data/tmp/v0514/llvm-project/build/bin/mlir-opt+0x4505606) #20 0x556fe230dd6a mlir::detail::OpToOpPassAdaptor::runPipeline(mlir::OpPassManager&, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int, mlir::PassInstrumentor*, mlir::PassInstrumentation::PipelineParentInfo const*) (/data/tmp/v0514/llvm-project/build/bin/mlir-opt+0x4505d6a) #21 0x556fe230e524 mlir::PassManager::run(mlir::Operation*) (/data/tmp/v0514/llvm-project/build/bin/mlir-opt+0x4506524) #22 0x556fe22ff9ab performActions(llvm::raw_ostream&, std::shared_ptr const&, mlir::MLIRContext*, mlir::MlirOptMainConfig const&) MlirOptMain.cpp:0:0 #23 0x556fe2300364 processBuffer(llvm::raw_ostream&, std::unique_ptr>, mlir::MlirOptMainC
[llvm-bugs] [Bug 92069] Inconsistent result with --sparsification-and-bufferization and tensor.empty
Issue 92069 Summary Inconsistent result with --sparsification-and-bufferization and tensor.empty Labels new issue Assignees Reporter Anonymous15592 Consider the following MLIR program: a.mlir: ``` module { func.func @tensor_i32(%arg0: tensor<1xi32>) -> i32 { %idx0 = index.constant 0 %0 = tensor.extract %arg0[%idx0] : tensor<1xi32> return %0 : i32 } func.func @func1() { %c1_i32 = arith.constant 1 : i32 %c0_i32 = arith.constant 0 : i32 %c0 = arith.constant 0 : index %5 = tensor.empty() : tensor<1xi32> // using empty // %5 = tensor.from_elements %c0_i32 : tensor<1xi32> %inserted_28 = tensor.insert %c1_i32 into %5[%c0] : tensor<1xi32> %31 = call @tensor_i32(%inserted_28) : (tensor<1xi32>) -> i32 %308 = tensor.extract %5[%c0] : tensor<1xi32> // vector.print %31 : i32 vector.print %308 : i32 return } } ``` It will output two different results when applying two different optimization pass sequences: ```pass sequence1```: ```--sparsification-and-bufferization --tensor-bufferize --func-bufferize --convert-func-to-llvm --convert-index-to-llvm --convert-vector-to-llvm --finalize-memref-to-llvm --convert-arith-to-llvm --reconcile-unrealized-casts``` ```pass sequence2```: ```--tensor-bufferize --func-bufferize --convert-func-to-llvm --convert-index-to-llvm --convert-vector-to-llvm --finalize-memref-to-llvm --convert-arith-to-llvm --reconcile-unrealized-casts``` The ```pass sequence1``` outputs the executable that outputs 1, while the latter outputs 0. The difference between ```pass sequence1``` and ```pass sequence2``` is that there is an additional ```--sparsification-and-bufferization``` at the begining of the ```pass sequence1```. I futher analyze the output of these two sequences: pass1: ```--sparsification-and-bufferization --tensor-bufferize``` pass2: ```--tensor-bufferize``` The result of ```pass1``` is: ``` module { func.func @tensor_i32(%arg0: memref<1xi32>) -> i32 { %idx0 = index.constant 0 %0 = memref.load %arg0[%idx0] : memref<1xi32> return %0 : i32 } func.func @func1() { %c1_i32 = arith.constant 1 : i32 %c0 = arith.constant 0 : index %alloc = memref.alloc() {alignment = 64 : i64} : memref<1xi32> memref.store %c1_i32, %alloc[%c0] : memref<1xi32> %0 = call @tensor_i32(%alloc) : (memref<1xi32>) -> i32 %1 = memref.load %alloc[%c0] : memref<1xi32> vector.print %1 : i32 return } } ``` The result of ```pass2``` is: ``` module { func.func @tensor_i32(%arg0: tensor<1xi32>) -> i32 { %0 = bufferization.to_memref %arg0 : memref<1xi32> %idx0 = index.constant 0 %1 = memref.load %0[%idx0] : memref<1xi32> return %1 : i32 } func.func @func1() { %c1_i32 = arith.constant 1 : i32 %c0_i32 = arith.constant 0 : i32 %c0 = arith.constant 0 : index %alloc = memref.alloc() {alignment = 64 : i64} : memref<1xi32> %alloc_0 = memref.alloc() {alignment = 64 : i64} : memref<1xi32> memref.copy %alloc, %alloc_0 : memref<1xi32> to memref<1xi32> memref.store %c1_i32, %alloc_0[%c0] : memref<1xi32> %0 = bufferization.to_tensor %alloc_0 : memref<1xi32> %1 = call @tensor_i32(%0) : (tensor<1xi32>) -> i32 %2 = memref.load %alloc[%c0] : memref<1xi32> vector.print %2 : i32 return } } ``` It seems that ```--sparsification-and-bufferization --tensor-bufferize``` treats the operand and the result of ```tensor.insert``` as same tensor(memref), when the operand of ```tensor.insert``` is created by ```tensor.empty```. If I replace the ```tensor.empty``` with ```tensor.from_element```, or just wrap the ```tensor.empty``` with a function. The modified MLIR program will output the same result. The modified program: ``` module { func.func @gen_tensor_i32() -> tensor<1xi32> { %c0_i32 = arith.constant 0 : i32 %5 = tensor.empty() : tensor<1xi32> return %5 : tensor<1xi32> } func.func @tensor_i32(%arg0: tensor<1xi32>) -> i32 { %idx0 = index.constant 0 %0 = tensor.extract %arg0[%idx0] : tensor<1xi32> return %0 : i32 } func.func @func1() { %c1_i32 = arith.constant 1 : i32 %c0_i32 = arith.constant 0 : i32 %c0 = arith.constant 0 : index %5 = call @gen_tensor_i32() : () -> tensor<1xi32> // %5 = tensor.empty() : tensor<1xi32> // using empty // %5 = tensor.from_elements %c0_i32 : tensor<1xi32> %inserted_28 = tensor.insert %c1_i32 into %5[%c0] : tensor<1xi32> %31 = call @tensor_i32(%inserted_28) : (tensor<1xi32>) -> i32 %308 = tensor.extract %5[%c0] : tensor<1xi32> // vector.print %31 : i32 vector.print %308 : i32 return } } ``` I wonder if there is some thing wrong with ```--sparsification-and-bufferization``` and ```tensor.empty```. This result inconsistency may not be a problem because ```tensor.e
[llvm-bugs] [Bug 92071] [HLSL] Default linkage of HLSL functions should be internal
Issue 92071 Summary [HLSL] Default linkage of HLSL functions should be internal Labels Assignees Reporter hekota Currently the default linkage of HLSL function is set to external. This issue is blocking #90095. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 92073] Enable HLSL diagnostic on exported library functions and add tests
Issue 92073 Summary Enable HLSL diagnostic on exported library functions and add tests Labels new issue Assignees Reporter hekota ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 92074] [ValueTracking] Missed optimization of modulo power-of-two
Issue 92074 Summary [ValueTracking] Missed optimization of modulo power-of-two Labels new issue Assignees Reporter YanWQ-monad Recently I found a missed optimization related to modulo power-of-two. It's https://github.com/dtcxzyw/llvm-opt-benchmark/blob/b79d63cb8adea5949cc449d4186e342d3dbdd871/bench/wasmtime-rs/optimized/1ham0fg2czw77e66.ll#L235 and it's compiled from [something](https://github.com/bytecodealliance/wasmtime/blob/a6f27eeb7e9ada3f1e10d75630f733b204e2c1ba/cranelift/codegen/meta/src/constant_hash.rs#L12-L42) like ``` rust let modulo = if size.is_power_of_two() { // i.e. ctpop(size) == 1 size * 2 } else { size.next_power_of_two() }; let result = xxx % modulo; ``` where `urem xxx, modulo` could be optimized to `and xxx, (modulo - 1)`. To solve it, I have created a PR #91171 that enables the recognization of `.next_power_of_two()`, and I also have a draft patch that could recognize power-of-two from dom conditions. However, the key problem in this case is that LLVM currently only search 2 levels beyond `phi` nodes, so the resursion of `isKnownToBeAPowerOfTwo` stops at `size * 2`, and fails to know `size` is a power-of-two from the condition. https://github.com/llvm/llvm-project/blob/37ffbbb19576a884c5bb93b9ac0ae97f89523b6b/llvm/lib/Analysis/ValueTracking.cpp#L2197-L2199 Though changing `- 1` to `- 3` could make it work in this case, it's obviously not a proper way to solve the problem. I am not sure if there is a way to handle this complex context across multiple basic blocks, or should we instead patch `wasmtime` to use `let modulo = (size + 1).next_power_of_two()`? cc @nikic @dtcxzyw ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 92075] Running pass 'X86 DAG->DAG Instruction Selection' on function
Issue 92075 Summary Running pass 'X86 DAG->DAG Instruction Selection' on function Labels new issue Assignees Reporter oocpp 14:48:08:143 1>PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script. 14:48:08:143 1>Stack dump: 14:48:08:205 1>0. Program arguments: "C:\\Program Files\\Microsoft Visual Studio\\2022\\Preview\\VC\\Tools\\Llvm\\x64\\bin\\clang-cl.exe" @G:\\link\\Temp\\MSBuildTemp\\tmp4dcfa4a803b54680b871965b6596d9f6.rsp 14:48:08:205 1>1. parser at end of file 14:48:08:205 1>2. Code generation 14:48:08:205 1>3. Running pass 'Function Pass Manager' on module 'G:\code\CCCreator3\Effect\Business\Base\LuaSystem\LuaBindings.cpp'. 14:48:08:205 1>4. Running pass 'X86 DAG->DAG Instruction Selection' on function '@"??$_Destroy_range@V?$allocator@UMeshCookingVertex@BEF@@@std@@@std@@YAXPEAUMeshCookingVertex@BEF@@QEAU12@AEAV?$allocator@UMeshCookingVertex@BEF@@@0@@Z"' 14:48:08:205 1>Exception Code: 0xC005 14:48:08:205 1> #0 0x7ff60e3ca004 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x6aa004 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x1b04617 14:48:08:205 1> #1 0x7ff60e3ca004 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x1b023e5 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x1b00092 14:48:08:205 1> #2 0x7ff60e3ca004 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x10aabfc C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x6d823d 14:48:08:205 1> #3 0x7ff60e3ca004 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x3824a8 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x3885b3 14:48:08:205 1> #4 0x7ff60e3ca004 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x382b37 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x14cb704 14:48:08:205 1> #5 0x7ff60e3ca004 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x189764e C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x314cf84 14:48:08:205 1> #6 0x7ff60e3ca004 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x1801582 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x5bd4cd 14:48:08:205 1> #7 0x7ff60e3ca004 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x64fdde C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x8bd6 14:48:08:205 1> #8 0x7ff60e3ca004 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x53a9 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x168e28d 14:48:08:205 1> #9 0x7ff60e3ca004 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x501aa5 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x168da5e 14:48:08:205 1>#10 0x7ff60e3ca004 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x5a82e5 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x5a862e 14:48:08:205 1>#11 0x7ff60e3ca004 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x58e66b C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x4c2a 14:48:08:205 1>#12 0x7ff60e3ca004 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x16f14 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x459f320 14:48:08:205 1>#13 0x7ff60e3ca004 (C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe+0x6aa004) 14:48:08:205 1>#14 0x7ff60f824617 (C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe+0x1b04617) 14:48:08:205 1>0x7FF60E3CA004, C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe(0x7FF60DD2) + 0x6AA004 byte(s) 14:48:08:205 1>0x7FF60F824617, C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe(0x7FF60DD2) + 0x1B04617 byte(s) 14:48:08:205 1>0x7FF60F8223E5, C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\cl