[llvm-bugs] [Bug 126051] [flang] linker_flags.f90 fails with -DCLANG_DEFAULT_UNWINDLIB=libgcc
Issue 126051 Summary [flang] linker_flags.f90 fails with -DCLANG_DEFAULT_UNWINDLIB=libgcc Labels flang:driver Assignees Reporter nikic ``` RUN: at line 14: /builddir/build/BUILD/flang-20.1.0_rc1-build/llvm-project-20.1.0-rc1.src/flang/redhat-linux-build/bin/flang -### -rtlib=compiler-rt --target=aarch64-linux-gnu /builddir/build/BUILD/flang-20.1.0_rc1-build/llvm-project-20.1.0-rc1.src/flang/test/Driver/Inputs/hello.f90 2>&1 | /usr/lib64/llvm20/bin/FileCheck /builddir/build/BUILD/flang-20.1.0_rc1-build/llvm-project-20.1.0-rc1.src/flang/test/Driver/linker-flags.f90 --check-prefixes=CHECK,UNIX,COMPILER-RT + /builddir/build/BUILD/flang-20.1.0_rc1-build/llvm-project-20.1.0-rc1.src/flang/redhat-linux-build/bin/flang -### -rtlib=compiler-rt --target=aarch64-linux-gnu /builddir/build/BUILD/flang-20.1.0_rc1-build/llvm-project-20.1.0-rc1.src/flang/test/Driver/Inputs/hello.f90 + /usr/lib64/llvm20/bin/FileCheck /builddir/build/BUILD/flang-20.1.0_rc1-build/llvm-project-20.1.0-rc1.src/flang/test/Driver/linker-flags.f90 --check-prefixes=CHECK,UNIX,COMPILER-RT /builddir/build/BUILD/flang-20.1.0_rc1-build/llvm-project-20.1.0-rc1.src/flang/test/Driver/linker-flags.f90:68:20: error: COMPILER-RT-NOT: excluded string found in input ! COMPILER-RT-NOT: "-lgcc_s" ^ :6:880: note: found here "/usr/bin/ld" "-EL" "--hash-style=gnu" "--build-id" "--eh-frame-hdr" "-m" "aarch64linux" "-dynamic-linker" "/lib/ld-linux-aarch64.so.1" "-o" "a.out" "/lib/../lib64/crt1.o" "/lib/../lib64/crti.o" "crtbegin.o" "-L/lib/../lib64" "-L/usr/lib/../lib64" "-L/lib" "-L/usr/lib" "/tmp/lit-tmp-5pv3rp85/hello-e5d40e.o" "-L/builddir/build/BUILD/flang-20.1.0_rc1-build/llvm-project-20.1.0-rc1.src/flang/redhat-linux-build/lib" "-lFortranRuntime" "-lFortranDecimal" "-lm" "/builddir/build/BUILD/flang-20.1.0_rc1-build/llvm-project-20.1.0-rc1.src/flang/redhat-linux-build/bin/../../../lib/clang/20/lib/aarch64-unknown-linux-gnu/libclang_rt.builtins.a" "--as-needed" "-lgcc_s" "--no-as-needed" "-lc" "/builddir/build/BUILD/flang-20.1.0_rc1-build/llvm-project-20.1.0-rc1.src/flang/redhat-linux-build/bin/../../../lib/clang/20/lib/aarch64-unknown-linux-gnu/libclang_rt.builtins.a" "--as-needed" "-lgcc_s" "--no-as-needed" "crtend.o" "/lib/../lib64/crtn.o" ^ Input file: Check file: /builddir/build/BUILD/flang-20.1.0_rc1-build/llvm-project-20.1.0-rc1.src/flang/test/Driver/linker-flags.f90 -dump-input=help explains the following input dump. Input was: << 1: flang version 20.1.0 (Fedora 20.1.0~rc1-3.fc42) 2: Target: aarch64-unknown-linux-gnu 3: Thread model: posix 4: InstalledDir: /builddir/build/BUILD/flang-20.1.0_rc1-build/llvm-project-20.1.0-rc1.src/flang/redhat-linux-build/bin 5: "/builddir/build/BUILD/flang-20.1.0_rc1-build/llvm-project-20.1.0-rc1.src/flang/redhat-linux-build/bin/flang" "-fc1" "-triple" "aarch64-unknown-linux-gnu" "-emit-obj" "-mrelocation-model" "static" "-target-cpu" "generic" "-target-feature" "+outline-atomics" "-target-feature" "+v8a" "-target-feature" "+fp-armv8" "-target-feature" "+neon" "-resource-dir" "/builddir/build/BUILD/flang-20.1.0_rc1-build/llvm-project-20.1.0-rc1.src/flang/redhat-linux-build/bin/../../../lib/clang/20" "-mframe-pointer=non-leaf" "-o" "/tmp/lit-tmp-5pv3rp85/hello-e5d40e.o" "-x" "f95-cpp-input" "/builddir/build/BUILD/flang-20.1.0_rc1-build/llvm-project-20.1.0-rc1.src/flang/test/Driver/Inputs/hello.f90" 6: "/usr/bin/ld" "-EL" "--hash-style=gnu" "--build-id" "--eh-frame-hdr" "-m" "aarch64linux" "-dynamic-linker" "/lib/ld-linux-aarch64.so.1" "-o" "a.out" "/lib/../lib64/crt1.o" "/lib/../lib64/crti.o" "crtbegin.o" "-L/lib/../lib64" "-L/usr/lib/../lib64" "-L/lib" "-L/usr/lib" "/tmp/lit-tmp-5pv3rp85/hello-e5d40e.o" "-L/builddir/build/BUILD/flang-20.1.0_rc1-build/llvm-project-20.1.0-rc1.src/flang/redhat-linux-build/lib" "-lFortranRuntime" "-lFortranDecimal" "-lm" "/builddir/build/BUILD/flang-20.1.0_rc1-build/llvm-project-20.1.0-rc1.src/flang/redhat-linux-build/bin/../../../lib/clang/20/lib/aarch64-unknown-linux-gnu/libclang_rt.builtins.a" "--as-needed" "-lgcc_s" "--no-as-needed" "-lc" "/builddir/build/BUILD/flang-20.1.0_rc1-build/llvm-project-20.1.0-rc1.src/flang/redhat-linux-build/bin/../../../lib/clang/20/lib/aarch64-unknown-linux-gnu/libclang_rt.builtins.a" "--as-needed" "-lgcc_s" "--no-as-needed" "crtend.o" "/lib/../lib64/crtn.o" not:68 ! error: no match expected >> ``` -lgcc_s gets pulled in via the unwind library here. I'm not really sure what do do about this one. It looks like flang doesn't expose the `--unwindlib` flag from the driver. If I understand correctly, fortran doesn't have exceptions, so possibly it doesn't need to link an unwind library at all? I think it should be either that, or flang should ex
[llvm-bugs] [Bug 126035] [flang][Driver] When linking with the Fortran runtime also link with libexecinfo
Issue 126035 Summary [flang][Driver] When linking with the Fortran runtime also link with libexecinfo Labels flang Assignees Reporter brad0 /cherry-pick d1de75acea0da55316cd7827563e064105868f0f ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 126032] [clang-tidy] Rename google-explicit-constructor to cppcoreguidelines-explicit-constructor
Issue 126032 Summary [clang-tidy] Rename google-explicit-constructor to cppcoreguidelines-explicit-constructor Labels clang-tidy Assignees Reporter Febbe The `google-explicit-constructor` check is not only a check resulting from the google coding standards, it is also part of the [cppcoreguidelines](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rc-explicit). Since google-* checks are rather domain specific, users will often turn all google warnings off. This leads to cases, where such an important check is also omitted. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 126043] [Clang] [OpenMP] OMP_TRAIT_PROPERTY macro redefined error
Issue 126043 Summary [Clang] [OpenMP] OMP_TRAIT_PROPERTY macro redefined error Labels clang Assignees Ritanya-B-Bharadwaj Reporter Ritanya-B-Bharadwaj Build failure due to OMP_TRAIT_PROPERTY macro redefinition - https://lab.llvm.org/buildbot/#/builders/145/builds/4939/steps/5/logs/stdio This was caused due to this commit - https://github.com/llvm/llvm-project/commit/8c3666526794e011046fd3a837b623265afa471b ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 126046] [MLIR][LLVM Dialect][DTLI] Missing DLTI entries
Issue 126046 Summary [MLIR][LLVM Dialect][DTLI] Missing DLTI entries Labels mlir Assignees Reporter ghehg when we do mlir-translate --import-llvm for the simple LLVM IR line like following `target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128-Fn32"` to parse datalayout string from LLVM IR, we got following warnings ``` test.c:0:0: warning: unhandled data layout token: m:e test.c:0:0: warning: unhandled data layout token: n32:64 test.c:0:0: warning: unhandled data layout token: Fn32 ``` Thats because MLIR DLIT doesn't have representation of Mangling, native int width, as well as function pointer alignment, and thus LLVM dialect cannot import them. We should add those things to preserve info. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 126042] ASTImporter going into an infinite loop and consuming increasing amount of memory, when Importing a CallExpr, CompoundStmt
Issue
126042
Summary
ASTImporter going into an infinite loop and consuming increasing amount of memory, when Importing a CallExpr, CompoundStmt
Labels
new issue
Assignees
Reporter
YuvrajTalukdar
I was trying to import a CallExpr using clang::ASTImporter, and realized the program was going into an infinite loop while consuming more and more memory. I had to forcefully kill the program since the memory consumption was continuously increasing.
On performing some further test, I realized the problem also occurs when importing a CompoundStmt, . Here is a few example where the problem occurs.
Example1
```
void foo1()
{
printf("hello");
}
void foo2()
{
foo1();// s1
}
```
Example2
```
void foo1()
{
{// s2
printf("hello");
printf("world");
}
}
```
In example 1 the problem occurs when importing statement s1 and in example 2 the problem occurs when importing CompoundStmt s2.
Can any one else confirm this issue, and is there any solution to this.
I tested this on clang version 19.1.7 and ASTImporter was initialized like this:-
`ASTImporter Importer(astContext1, astContext1.getSourceManager().getFileManager(),astContext2, astContext2.getSourceManager().getFileManager(),false,nullptr);`
On running the same inside gdb the infinite loop looks like this
```
#22 0x74da869c in clang::ASTImporter::ImportImpl(clang::Decl*) () from /usr/lib/libclang-cpp.so.19.1
#23 0x74d7ab93 in clang::ASTImporter::Import(clang::Decl*) () from /usr/lib/libclang-cpp.so.19.1
#24 0x773f1316 in ?? () from /usr/lib/libclang-cpp.so.19.1
#25 0x74da8245 in clang::ASTNodeImporter::VisitFunctionDecl(clang::FunctionDecl*) ()
from /usr/lib/libclang-cpp.so.19.1
#26 0x74da869c in clang::ASTImporter::ImportImpl(clang::Decl*) () from /usr/lib/libclang-cpp.so.19.1
#27 0x74d7ab93 in clang::ASTImporter::Import(clang::Decl*) () from /usr/lib/libclang-cpp.so.19.1
#28 0x773f1316 in ?? () from /usr/lib/libclang-cpp.so.19.1
#29 0x74da8245 in clang::ASTNodeImporter::VisitFunctionDecl(clang::FunctionDecl*) ()
from /usr/lib/libclang-cpp.so.19.1
#30 0x74da869c in clang::ASTImporter::ImportImpl(clang::Decl*) () from /usr/lib/libclang-cpp.so.19.1
#31 0x74d7ab93 in clang::ASTImporter::Import(clang::Decl*) () from /usr/lib/libclang-cpp.so.19.1
#32 0x773f1316 in ?? () from /usr/lib/libclang-cpp.so.19.1
#33 0x74da8245 in clang::ASTNodeImporter::VisitFunctionDecl(clang::FunctionDecl*) ()
from /usr/lib/libclang-cpp.so.19.1
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 126041] [clang-tidy] performance-noexcept-move-constructor False Positive on =default'ed move SMFs
Issue
126041
Summary
[clang-tidy] performance-noexcept-move-constructor False Positive on =default'ed move SMFs
Labels
clang-tidy
Assignees
Reporter
marcmutz
performance-noexcept-move-constructor incorrectly warns about code employs https://eel.is/c++draft/except.spec#6 `noexcept(auto)` behaviour for `=default`ed special member functions (SMFs):
```
class Base {
protected:
~Base() = default; // want this
// need these because of recent Clang -Wdeprecated:
Base(const Base &) = default;
Base(Base &&) = default; // warning: move ctors should be noexcept
Base &operator=(const Base &) = default;
Base &operator=(Base &&) = default;
Base() = default;
~~~
};
```
In our case (https://codereview.qt-project.org/c/qt/qtbase/+/616627/comment/e32ef87f_2d0bf46b/), these `=default`s are coming from a macro, so we actively rely on [expect.spec]/6.
Expected behaviour: Clang-tidy either excludes `=default`ed SMFs from the analysis or (harder) actively calculates the noexcept specification for defaulted SMFs and only warns if the result is `false`.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 126025] Clang should provide intrinsic that lowers directly to `llvm.fma.*` intrinsic
Issue 126025 Summary Clang should provide intrinsic that lowers directly to `llvm.fma.*` intrinsic Labels clang Assignees Reporter petrhosek Clang already provides the `__builtin_fma` builtin intrinsic which is lowered either to `fma` call or `llvm.fma.*` Intrinsic depending on whether math `errno` is used or not (i.e. `-f[no-]math-errno`). This behavior makes [`__builtin_fma` unsuitable for implementing libc `fma` because unless libc is compiled with `-fno-math-errno`, on targets where math `errno` is used, this would result in an infinite recursion. We encountered this issue in LLVM libc: https://github.com/llvm/llvm-project/blob/5eed019080a53af5a5be915a5cf411466b77bf4b/libc/src/__support/FPUtil/FMA.h#L27-L33 On baremetal targets where math `errno` is used, the `__builtin_fma` call is lowered to `fma` call resulting a function trivially calling itself. The current workaround is to compile LLVM libc with `-fno-math-errno`, but that is generally undesirable. Ideally, Clang would provide a separate builtin intrinsic that always lowers to `llvm.fma.*` Intrinsic regardless of math `errno` behavior. We could then use this intrinsic to implement `fma`. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 126056] [InstCombine] Failure to recognise a split i128 extension
Issue
126056
Summary
[InstCombine] Failure to recognise a split i128 extension
Labels
llvm:instcombine,
missed-optimization
Assignees
Reporter
RKSimon
Split off from #76524
https://alive2.llvm.org/ce/z/4SwMjF
```ll
define i128 @src(i32 noundef %x) {
%coerce.sroa.0.0.extract.trunc = sext i32 noundef %x to i64
%ashr = ashr i32 noundef %x, 31
%coerce.sroa.2.0.extract.trunc = sext i32 %ashr to i64
%x.sroa.2.0.insert.ext.i = zext i64 %coerce.sroa.2.0.extract.trunc to i128
%x.sroa.2.0.insert.shift.i = shl nuw i128 %x.sroa.2.0.insert.ext.i, 64
%x.sroa.0.0.insert.ext.i = zext i64 %coerce.sroa.0.0.extract.trunc to i128
%x.sroa.0.0.insert.insert.i = or disjoint i128 %x.sroa.2.0.insert.shift.i, %x.sroa.0.0.insert.ext.i
ret i128 %x.sroa.0.0.insert.insert.i
}
=>
define i128 @tgt(i32 noundef %x) {
%xx = sext i32 noundef %x to i128
ret i128 %xx
}
Transformation seems to be correct!
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 126107] [MachineCP] Assertion `Reg.isPhysical()' failed in MCRegUnitIterator
Issue 126107 Summary [MachineCP] Assertion `Reg.isPhysical()' failed in MCRegUnitIterator Labels bug, llvm:regalloc Assignees ostannard Reporter aleks-tmb During our local testing, we encountered the assertion failure `Reg.isPhysical()` in the `MachineCP` pass. Reduced reproducer: ``` --- name: main body: | bb.0.entry: liveins: $ymm7 renamable $ymm6 = COPY killed renamable $ymm7 CALL64r killed renamable $rax, csr_64_mostregs renamable $ymm6 = VPADDWZ256rr $ymm6, $ymm6 ``` Steps to reproduce: ``` $ bin/llc -run-pass machine-cp test.mir llc: /root/llvm-project/llvm/include/llvm/MC/MCRegisterInfo.h:649: llvm::MCRegUnitIterator::MCRegUnitIterator(llvm::MCRegister, const llvm::MCRegisterInfo*): Assertion `Reg.isPhysical()' failed ``` Proof: https://godbolt.org/z/PnqdcKbfe The problematic patch seems to be: https://github.com/llvm/llvm-project/commit/9e436c2daa446da05e9219f0e6a22f932ba8e3cb Based on my investigation, the issue arises when we remove `renamable $ymm6 = COPY killed renamable $ymm7` due to regmask clobbering. However, during this process, we skip dropping the corresponding RegUnit from the tracking copies, since it's preserved: ```c++ LLVM_DEBUG(dbgs() << "MCP: Removing copy due to regmask clobbering: "; MaybeDead->dump()); // Invalidate all entries in the copy map which are not preserved by // this register mask. for (unsigned RegUnit : TRI->regunits(Reg)) if (!PreservedRegUnits.test(RegUnit)) Tracker.clobberRegUnit(RegUnit, *TRI, *TII, UseCopyInstr); // erase() will return the next valid iterator pointing to the next // element after the erased one. DI = MaybeDeadCopies.erase(DI); MaybeDead->eraseFromParent(); ``` As a result, we retain a pointer to the erased instruction in tracking copies, which leads to a failure when accessing it while processing `renamable $ymm6 = VPADDWZ256rr $ymm6, $ymm6`, clobbering any previous copy definitions. @ostannard hi, could you please take a look? ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 126077] [asan][win] memcpy is not alias for memmove with dynamic setup on latest Windows
Issue 126077 Summary [asan][win] memcpy is not alias for memmove with dynamic setup on latest Windows Labels new issue Assignees Reporter yingcong-wu I have seen the following error on some of our internal test machines ``` Failed Tests (5): AddressSanitizer-Unit :: ./Asan-x86_64-calls-Dynamic-Test.exe/AddressSanitizer/MemCpyOOBTest AddressSanitizer-Unit :: ./Asan-x86_64-inline-Dynamic-Test.exe/AddressSanitizer/MemCpyOOBTest AddressSanitizer-x86_64-windows-dynamic :: TestCases/Windows/dll_intercept_memcpy_indirect.cpp AddressSanitizer-x86_64-windows-dynamic :: TestCases/Windows/intercept_memcpy.cpp AddressSanitizer-x86_64-windows-dynamic :: TestCases/memset_test.cpp ``` After some investigation, with the latest Windows setup(these failures only reproduced on those setup) and dynamic setup(the static test config does not have these failures), ``` #elif SANITIZER_WINDOWS64 #define PLATFORM_HAS_DIFFERENT_MEMCPY_AND_MEMMOVE 0 ``` is not true anymore. The `memcpy` is not the alias for `memmove`, and we will have to intercept them both. However, simply changing this to `1` for Windows, although it can fix the failures for latest Windows, would bring huge regression for not-so-update-to-date Windows. I have no further idea how to solve this problem, but I think this would affect more users with time after users update their OS and runtime. And I don't sure which part of the environment is causing this difference. System information: ``` OS: Microsoft Windows 11 Enterprise LTSC 24H2 10.0.26100 msvcrt.dll version: 7.0.26100.1882 vcruntime140.dll version: 14.42.34433.0 ``` I don't know if this information is enough, and I am happy to provide other information if needed. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 126113] [Clang FE] Possible logic issue in `TransformTypos::TransformDesignatedInitExpr`
Issue
126113
Summary
[Clang FE] Possible logic issue in `TransformTypos::TransformDesignatedInitExpr`
Labels
clang
Assignees
Reporter
d367wang
When running the tree-visitor `TransformTypos` on a `DesignatedInitExpr` node, it first tries to transform its initializer
```
// transform the initializer value
ExprResult Init = getDerived().TransformExpr(E->getInit());
```
and later on decides whether the AST changes by
```
ExprChanged = ExprChanged || Init.get() != E->getArrayIndex(D);
```
at https://github.com/llvm/llvm-project/blob/5492199a9aa4b5d31c38e36928ac153570091d6d/clang/lib/Sema/TreeTransform.h#L13659
The logic in `Init.get() != E->getArrayIndex(D)` seems not correct as the initializer and the index of the designator are being compared, which is likely to always be false.
Ran debugger on clang compiling a designator example
```
const char *str[] = {
[some_typo] = "0"
};
```
and stepped in to the line, `Init.get()` is a StringLiteral and `E->getArrayIndex(D)` is a TypoExpr.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 126114] [Flang] Incorrect diagnostic on valid private component name to be the same as parent component
Issue 126114 Summary [Flang] Incorrect diagnostic on valid private component name to be the same as parent component Labels flang:frontend Assignees Reporter DanielCChen Consider the following code ``` module m type base integer*4, private :: base = 1 !! Not accessible outside of the module end type end module program main use m type, extends(base) :: child character(20) :: name end type end ``` Flang currently issues an error as: ``` ./t2.f:9:19: error: Type cannot be extended as it has a component named 'base' type, extends(base) :: child ./t2.f:3:31: Previous declaration of 'base' integer*4, private :: base = 1 !! Not accessible outside of the module ``` The code is valid as the name collision is by the scoping rule. The private component `integer :: base` is not accessible from outside of the module. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 126125] [clang++] function call disappears when `__restrict__` is used.
Issue 126125 Summary [clang++] function call disappears when `__restrict__` is used. Labels clang Assignees Reporter greg7mdp Looks like a bug to me, but maybe it is a dangerous consequence of using `__restrict__`? https://godbolt.org/z/87c7Eb4G5 ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 126127] [clang] -Wsystem-headers doesn't show up in `diagtool tree` output
Issue 126127 Summary [clang] -Wsystem-headers doesn't show up in `diagtool tree` output Labels clang Assignees Reporter nickdesaulniers I was trying to recall exactly what the flag was for `-Wsystem-headers` so I reached for `diagtool tree | grep system` and it was not listed. I wonder if there's a reason why `-Wsystem-headers` isn't listed, and if due to that reason (or others) additional flags aren't being reported by `diagtool tree`. labeling this with the clang label, even though the bug might be elsewhere, for eyes from clang maintainers. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 126092] Request Commit Access For SusanTan
Issue 126092 Summary Request Commit Access For SusanTan Labels infra:commit-access-request Assignees Reporter SusanTan ### Why Are you requesting commit access ? Hi, I am requesting commit access to the LLVM project, specifically for MLIR and Flang. I am a developer at NVHPC and have been actively contributing to projects within these domains. thanks, Susan ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 126196] [mlir] Crash when using --canonicalize
Issue
126196
Summary
[mlir] Crash when using --canonicalize
Labels
mlir
Assignees
Reporter
wangyongj1a
I have the following MLIR program:
test.mlir:
```
module {
func.func @func1() {
%cst_5 = arith.constant 0x4DD16869 : f32
%58 = vector.broadcast %cst_5 : f32 to vector<22x22xf32>
%59 = vector.fma %58, %58, %58 : vector<22x22xf32>
%90 = vector.extract_strided_slice %59 {offsets = [16], sizes = [1], strides = [1]} : vector<22x22xf32> to vector<1x22xf32>
%171 = vector.transpose %90, [1, 0] : vector<1x22xf32> to vector<22x1xf32>
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/v0207/llvm-project/llvm/include/llvm/ADT/SmallVector.h:291: T& llvm::SmallVectorTemplateCommon >::operator[](llvm::SmallVectorTemplateCommon >::size_type) [with T = long int; = void; llvm::SmallVectorTemplateCommon >::reference = long int&; llvm::SmallVectorTemplateCommon >::size_type = long unsigned int]: Assertion `idx < 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: /data/tmp/v0207/llvm-project/build/bin/mlir-opt --canonicalize test.mlir
#0 0x55dcb5f1d1df llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/data/tmp/v0207/llvm-project/build/bin/mlir-opt+0x170a1df)
#1 0x55dcb5f1a234 SignalHandler(int) Signals.cpp:0:0
#2 0x7fd1afb51420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420)
#3 0x7fd1af61e00b raise (/lib/x86_64-linux-gnu/libc.so.6+0x4300b)
#4 0x7fd1af5fd859 abort (/lib/x86_64-linux-gnu/libc.so.6+0x22859)
#5 0x7fd1af5fd729 (/lib/x86_64-linux-gnu/libc.so.6+0x22729)
#6 0x7fd1af60efd6 (/lib/x86_64-linux-gnu/libc.so.6+0x33fd6)
#7 0x55dcb86e039e (anonymous namespace)::ContiguousExtractStridedSliceToExtract::matchAndRewrite(mlir::vector::ExtractStridedSliceOp, mlir::PatternRewriter&) const VectorOps.cpp:0:0
#8 0x55dcb86516cf mlir::detail::OpOrInterfaceRewritePatternBase::matchAndRewrite(mlir::Operation*, mlir::PatternRewriter&) const (/data/tmp/v0207/llvm-project/build/bin/mlir-opt+0x3e3e6cf)
#9 0x55dcbcb843d8 mlir::PatternApplicator::matchAndRewrite(mlir::Operation*, mlir::PatternRewriter&, llvm::function_ref, llvm::function_ref, llvm::function_ref) (/data/tmp/v0207/llvm-project/build/bin/mlir-opt+0x83713d8)
#10 0x55dcb9086120 (anonymous namespace)::GreedyPatternRewriteDriver::processWorklist() GreedyPatternRewriteDriver.cpp:0:0
#11 0x55dcb908923b mlir::applyPatternsGreedily(mlir::Region&, mlir::FrozenRewritePatternSet const&, mlir::GreedyRewriteConfig, bool*) (/data/tmp/v0207/llvm-project/build/bin/mlir-opt+0x487623b)
#12 0x55dcb8ff4a12 (anonymous namespace)::Canonicalizer::runOnOperation() Canonicalizer.cpp:0:0
#13 0x55dcb8fccfb1 mlir::detail::OpToOpPassAdaptor::run(mlir::Pass*, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int) (/data/tmp/v0207/llvm-project/build/bin/mlir-opt+0x47b9fb1)
#14 0x55dcb8fcd44a mlir::detail::OpToOpPassAdaptor::runPipeline(mlir::OpPassManager&, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int, mlir::PassInstrumentor*, mlir::PassInstrumentation::PipelineParentInfo const*) (/data/tmp/v0207/llvm-project/build/bin/mlir-opt+0x47ba44a)
#15 0x55dcb8fcdf84 mlir::PassManager::run(mlir::Operation*) (/data/tmp/v0207/llvm-project/build/bin/mlir-opt+0x47baf84)
#16 0x55dcb8fbf09b performActions(llvm::raw_ostream&, std::shared_ptr const&, mlir::MLIRContext*, mlir::MlirOptMainConfig const&) MlirOptMain.cpp:0:0
#17 0x55dcb8fbfb02 processBuffer(llvm::raw_ostream&, std::unique_ptr>, mlir::MlirOptMainConfig const&, mlir::DialectRegistry&, llvm::ThreadPoolInterface*) MlirOptMain.cpp:0:0
#18 0x55dcb8fbfd74 llvm::LogicalResult llvm::function_ref>, llvm::raw_ostream&)>::callback_fn>, mlir::DialectRegistry&, mlir::MlirOptMainConfig const&)::'lambda'(std::unique_ptr>, llvm::raw_ostream&)>(long, std::unique_ptr>, llvm::raw_ostream&) MlirOptMain.cpp:0:0
#19 0x55dcb90c876e mlir::splitAndProcessBuffer(std::unique_ptr>, llvm::function_ref>, llvm::raw_ostream&)>, llvm::raw_ostream&, llvm::StringRef, llvm::StringRef) (/data/tmp/v0207/llvm-project/build/bin/mlir-opt+0x48b576e)
#20 0x55dcb8fb6989 mlir::MlirOptMain(llvm::raw_ostream&, std::unique_ptr>, mlir::DialectRegistry&, mlir::MlirOptMainConfig const&) (/data/tmp/v0207/llvm-project/build/bin/mlir-opt+0x47a3989)
#21 0x55dcb8fbfee1 mlir::MlirOptMain(int, char**, llvm::StringRef, llvm::StringRef, mlir::DialectRegistry&) (/data/tmp/v0207/llvm-project/build/bin/mlir-opt+0x47acee1)
#22 0x55dcb8fc03a6 mlir::MlirOptMain(int, char**, llvm::StringRef, mlir::DialectRegis
[llvm-bugs] [Bug 126195] [mlir] Inconsistent results when using --int-range-optimizations
Issue
126195
Summary
[mlir] Inconsistent results when using --int-range-optimizations
Labels
mlir
Assignees
Reporter
wangyongj1a
I have the following MLIR program:
test.mlir:
```
module {
func.func @main() -> i64 {
%idx9 = index.constant 9
%idx11 = index.constant 11
%idx0 = index.constant 0
%0 = llvm.mlir.constant(true) : i1
%1 = llvm.mlir.constant(29 : index) : i64
%2 = builtin.unrealized_conversion_cast %1 : i64 to index
%false = index.bool.constant false
cf.cond_br %false, ^bb1, ^bb2
^bb1: // pred: ^bb0
cf.br ^bb3(%2 : index)
^bb2: // pred: ^bb0
cf.br ^bb3(%idx9 : index)
^bb3(%3: index): // 2 preds: ^bb1, ^bb2
cf.br ^bb4
^bb4: // pred: ^bb3
vector.print %3 : index
cf.cond_br %false, ^bb5, ^bb6
^bb5: // pred: ^bb4
cf.br ^bb7(%2 : index)
^bb6: // pred: ^bb4
cf.br ^bb7(%idx11 : index)
^bb7(%4: index): // 2 preds: ^bb5, ^bb6
cf.br ^bb8
^bb8: // pred: ^bb7
vector.print %4 : index
cf.cond_br %0, ^bb9, ^bb10
^bb9: // pred: ^bb8
cf.br ^bb11(%2 : index)
^bb10: // pred: ^bb8
cf.br ^bb11(%idx0 : index)
^bb11(%5: index): // 2 preds: ^bb9, ^bb10
cf.br ^bb12
^bb12: // pred: ^bb11
%6 = builtin.unrealized_conversion_cast %5 : index to i64
vector.print %5 : index
return %6 : i64
}
}
```
When I ran
```
/data/tmp/v0207/llvm-project/build/bin/mlir-opt \
--convert-arith-to-llvm --convert-vector-to-llvm --convert-index-to-llvm --convert-func-to-llvm --convert-cf-to-llvm --reconcile-unrealized-casts test.mlir | /data/tmp/v0207/llvm-project/build/bin/mlir-runner --entry-point-result=i64 --shared-libs=/data/tmp/v0207/llvm-project/build/lib/libmlir_runner_utils.so,/data/tmp/v0207/llvm-project/build/lib/libmlir_c_runner_utils.so
```
on the program, I got the result of:
```
9
11
29
29
```
However, when I ran
```
/data/tmp/v0207/llvm-project/build/bin/mlir-opt \
--int-range-optimizations \
--convert-arith-to-llvm --convert-vector-to-llvm --convert-index-to-llvm --convert-func-to-llvm --convert-cf-to-llvm --reconcile-unrealized-casts test.mlir | /data/tmp/v0207/llvm-project/build/bin/mlir-runner --entry-point-result=i64 --shared-libs=/data/tmp/v0207/llvm-project/build/lib/libmlir_runner_utils.so,/data/tmp/v0207/llvm-project/build/lib/libmlir_c_runner_utils.so
```
on the program, I sometimes got the result of:
```
9
11
9
9
```
The above two results seem to be inconsistent. I'm not sure if there is any bug in my program or if the wrong usage of the above passes caused these results.
My git version is 4d3148d92681c154de51379a0cf393f9af8e1d75.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 126197] [mlir] Crash when using --test-vector-unrolling-patterns
Issue
126197
Summary
[mlir] Crash when using --test-vector-unrolling-patterns
Labels
mlir
Assignees
Reporter
wangyongj1a
I have the following MLIR program:
test.mlir:
```
module {
func.func @func1() {
%cst_25 = arith.constant dense<3.718400e+04> : vector<4x2x2xf16>
%cst_26 = arith.constant dense<1.00e+00> : vector<24x2x2xf32>
%47 = vector.fma %cst_26, %cst_26, %cst_26 : vector<24x2x2xf32>
%818 = scf.execute_region -> vector<24x2x2xf32> {
scf.yield %47 : vector<24x2x2xf32>
}
%823 = vector.extract_strided_slice %cst_25 {offsets = [2], sizes = [1], strides = [1]} : vector<4x2x2xf16> to vector<1x2x2xf16>
return
}
}
```
The above MLIR program will cause a crash when using the following command:
```
mlir-opt --test-vector-unrolling-patterns test.mlir
```
And the crash backtrace is:
```
mlir-opt: /data/tmp/v0207/llvm-project/mlir/lib/Dialect/Vector/IR/VectorOps.cpp:3536: mlir::Type inferStridedSliceOpResultType(mlir::VectorType, mlir::ArrayAttr, mlir::ArrayAttr, mlir::ArrayAttr): Assertion `offsets.size() == sizes.size() && offsets.size() == strides.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: /data/tmp/v0207/llvm-project/build/bin/mlir-opt --test-vector-unrolling-patterns test.mlir
#0 0x562344a6b1df llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/data/tmp/v0207/llvm-project/build/bin/mlir-opt+0x170a1df)
#1 0x562344a68234 SignalHandler(int) Signals.cpp:0:0
#2 0x7f4eee883420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420)
#3 0x7f4eee35000b raise (/lib/x86_64-linux-gnu/libc.so.6+0x4300b)
#4 0x7f4eee32f859 abort (/lib/x86_64-linux-gnu/libc.so.6+0x22859)
#5 0x7f4eee32f729 (/lib/x86_64-linux-gnu/libc.so.6+0x22729)
#6 0x7f4eee340fd6 (/lib/x86_64-linux-gnu/libc.so.6+0x33fd6)
#7 0x56234719ac01 inferStridedSliceOpResultType(mlir::VectorType, mlir::ArrayAttr, mlir::ArrayAttr, mlir::ArrayAttr) VectorOps.cpp:0:0
#8 0x5623471bed6d mlir::vector::ExtractStridedSliceOp::build(mlir::OpBuilder&, mlir::OperationState&, mlir::Value, llvm::ArrayRef, llvm::ArrayRef, llvm::ArrayRef) (/data/tmp/v0207/llvm-project/build/bin/mlir-opt+0x3e5dd6d)
#9 0x5623472bba44 (anonymous namespace)::UnrollElementwisePattern::matchAndRewrite(mlir::Operation*, mlir::PatternRewriter&) const (.part.0) VectorUnroll.cpp:0:0
#10 0x56234b6d23d8 mlir::PatternApplicator::matchAndRewrite(mlir::Operation*, mlir::PatternRewriter&, llvm::function_ref, llvm::function_ref, llvm::function_ref) (/data/tmp/v0207/llvm-project/build/bin/mlir-opt+0x83713d8)
#11 0x562347bd4120 (anonymous namespace)::GreedyPatternRewriteDriver::processWorklist() GreedyPatternRewriteDriver.cpp:0:0
#12 0x562347bd723b mlir::applyPatternsGreedily(mlir::Region&, mlir::FrozenRewritePatternSet const&, mlir::GreedyRewriteConfig, bool*) (/data/tmp/v0207/llvm-project/build/bin/mlir-opt+0x487623b)
#13 0x5623483454f2 mlir::applyPatternsGreedily(mlir::Operation*, mlir::FrozenRewritePatternSet const&, mlir::GreedyRewriteConfig, bool*) (.constprop.0) TestVectorTransforms.cpp:0:0
#14 0x5623483509df (anonymous namespace)::TestVectorUnrollingPatterns::runOnOperation() TestVectorTransforms.cpp:0:0
#15 0x562347b1afb1 mlir::detail::OpToOpPassAdaptor::run(mlir::Pass*, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int) (/data/tmp/v0207/llvm-project/build/bin/mlir-opt+0x47b9fb1)
#16 0x562347b1b44a mlir::detail::OpToOpPassAdaptor::runPipeline(mlir::OpPassManager&, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int, mlir::PassInstrumentor*, mlir::PassInstrumentation::PipelineParentInfo const*) (/data/tmp/v0207/llvm-project/build/bin/mlir-opt+0x47ba44a)
#17 0x562347b1b7ce 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 0x562347b1a4b5 mlir::detail::OpToOpPassAdaptor::runOnOperationAsyncImpl(bool) (/data/tmp/v0207/llvm-project/build/bin/mlir-opt+0x47b94b5)
#19 0x562347b1acdb mlir::detail::OpToOpPassAdaptor::run(mlir::Pass*, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int) (/data/tmp/v0207/llvm-project/build/bin/mlir-opt+0x47b9cdb)
#20 0x562347b1b44a mlir::detail::OpToOpPassAdaptor::runPipeline(mlir::OpPassManager&, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int, mlir::PassInstrumentor*, mlir::PassInstrumentation::PipelineParentInfo const*) (/data/tmp/v0207/llvm-project/build/bin/mlir-opt+0x47ba44a)
#21 0x562347b1bf84 mlir::PassManager::run(mlir::Operation*) (/data/tmp/v0207/llvm-project/b
[llvm-bugs] [Bug 126161] [NVPTX] Fix fence.py script to emit the right ptxas-verify checks.
Issue 126161 Summary [NVPTX] Fix fence.py script to emit the right ptxas-verify checks. Labels new issue Assignees akshayrdeodhar Reporter akshayrdeodhar https://github.com/llvm/llvm-project/pull/124865 + https://github.com/llvm/llvm-project/pull/125927 ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 126162] [mlir] Inconsistency when searching for Python3 and Python
Issue 126162 Summary [mlir] Inconsistency when searching for Python3 and Python Labels mlir Assignees Reporter dbabokin I've just stepped into a trap caused by these lines of CMake code: https://github.com/llvm/llvm-project/blob/b7279ed5b3ae3e7b0fd61e0f08c86fb1958f0b6f/mlir/cmake/modules/MLIRDetectPythonEnv.cmake#L25-L28 I was building [torch-mlir](https://github.com/llvm/torch-mlir) on my Macbook and I was following the official build guidelines. On my system I have Python3.13 and Python3.11, but I was running in VirtualEnv with Python3.11 enabled. And CMake behaved really weirdly. It looked for Python three times, every time it was looking for `Python3` twice and once for `Python` (that's expected). While it consistently found `Python3` with version `3.11`, the `Python` was found as `3.11` at first, but then as `3.13` (really unexpected). Then if I was rerunning `cmake` with exactly the same command line (which succeeded on the first pass), it crashed with the following message: ``` CMake Error at /Users/dbabokin/ox-workspaces/torch-mlir/.venv_torch_mlir2/lib/python3.11/site-packages/cmake/data/share/cmake-3.31/Modules/FindPackageHandleStandardArgs.cmake:233 (message): Could NOT find Python (missing: Development.Module) (found suitable version "3.11.11", minimum required is "3.8") Call Stack (most recent call first): /Users/dbabokin/ox-workspaces/torch-mlir/.venv_torch_mlir2/lib/python3.11/site-packages/cmake/data/share/cmake-3.31/Modules/FindPackageHandleStandardArgs.cmake:603 (_FPHSA_FAILURE_MESSAGE) /Users/dbabokin/ox-workspaces/torch-mlir/.venv_torch_mlir2/lib/python3.11/site-packages/cmake/data/share/cmake-3.31/Modules/FindPython/Support.cmake:4002 (find_package_handle_standard_args) /Users/dbabokin/ox-workspaces/torch-mlir/.venv_torch_mlir2/lib/python3.11/site-packages/cmake/data/share/cmake-3.31/Modules/FindPython.cmake:631 (include) /Users/dbabokin/ox-workspaces/torch-mlir/externals/llvm-project/mlir/cmake/modules/MLIRDetectPythonEnv.cmake:27 (find_package) /Users/dbabokin/ox-workspaces/torch-mlir/externals/llvm-project/mlir/CMakeLists.txt:196 (mlir_configure_python_dev_packages) ``` Running `cmake` again was successful, one more time - failing. Debugging the problem I found out that the root cause was that I passed `-DPython3_FIND_VIRTUALENV=ONLY` to CMake, but not `-DPython_FIND_VIRTUALENV=ONLY`!!! So that resolved my problem and in this sense it was a user error. But I think it really makes sense to check that `Python3_FIND_VIRTUALENV` and `Python_FIND_VIRTUALENV` are defined (or not defined) in the same way and warn user otherwise. Tagging @makslevental who is the last one who touched `find_package(Python ...)` code. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 126176] -fno-plt option does not suppress PLT generation in Clang 19 dev, while GCC works as expected
Issue
126176
Summary
-fno-plt option does not suppress PLT generation in Clang 19 dev, while GCC works as expected
Labels
clang
Assignees
Reporter
lfeng14
Environment
- Arch: aarch64
- Clang Version: Clang 19 dev (e.g., clang version 19.0.0git)
- GCC Version: (e.g., gcc version 10.3)
- Compiler Flags: -fno-plt
Description:
I encountered an issue with the -fno-plt option in Clang 19 dev (development version) on aarch64. When compiling code with -fno-plt, Clang still generates PLT (Procedure Linkage Table) entries for function calls, whereas GCC behaves correctly and does not generate PLT entries.
This issue affects scenarios where direct GOT-based access is expected, and the presence of PLT entries may lead to unnecessary indirection and performance overhead.
Compile the following code with Clang 19 dev and -fno-plt
```
// gcc 1.c -shared -fno-plt -O0 -o libnoplt-clang.so -fPIC
// clang 1.c -shared -fno-plt -O0 -o libnoplt-gcc.so -fPIC
int bar(int a) {
return 10;
}
int foo(int a) {
return bar(a);
}
```
The Clang-compiled version generates PLT functions, while the GCC version does not.
```
// libnoplt-clang.so
Disassembly of section .plt:
0440 <.plt>:
440: a9bf7bf0 stp x16, x30, [sp, #-16]!
444: f0f0 adrp x16, 1f000 <__FRAME_END__+0x1e934>
448: f947fe11 ldr x17, [x16, #4088]
44c: 913fe210 add x16, x16, #0xff8
450: d61f0220 br x17
454: d503201f nop
458: d503201f nop
45c: d503201f nop
0470 :
470: 9110 adrp x16, 2 <__cxa_finalize@GLIBC_2.17>
474: f9400611 ldr x17, [x16, #8]
478: 91002210 add x16, x16, #0x8
47c: d61f0220 br x17
0588 :
588: d10083ff sub sp, sp, #0x20
58c: a9017bfd stp x29, x30, [sp, #16]
590: 910043fd add x29, sp, #0x10
594: b81fc3a0 stur w0, [x29, #-4]
598: b85fc3a0 ldur w0, [x29, #-4]
59c: 97b5 bl 470
5a0: a9417bfd ldp x29, x30, [sp, #16]
5a4: 910083ff add sp, sp, #0x20
5a8: d65f03c0 ret
```
```
libnoplt-gcc.so
05c4 :
5c4: d10043ff sub sp, sp, #0x10
5c8: b9000fe0 str w0, [sp, #12]
5cc: 52800140 mov w0, #0xa // #10
5d0: 910043ff add sp, sp, #0x10
5d4: d65f03c0 ret
05d8 :
5d8: a9be7bfd stp x29, x30, [sp, #-32]!
5dc: 910003fd mov x29, sp
5e0: b9001fe0 str w0, [sp, #28]
5e4: b9401fe0 ldr w0, [sp, #28]
5e8: f0e1 adrp x1, 1f000 <__FRAME_END__+0x1e900>
5ec: f947e821 ldr x1, [x1, #4048]
5f0: d63f0020 blr x1
5f4: a8c27bfd ldp x29, x30, [sp], #32
5f8: d65f03c0 ret
```
relevant issue: (Support fno-plt like gcc)[https://github.com/llvm/llvm-project/issues/78275]
relevant pr: (Implement -fno-plt for SelectionDAG/GlobalISel)[https://github.com/llvm/llvm-project/pull/78890]
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 126181] Mismatched padding between `byval` and globals
Issue
126181
Summary
Mismatched padding between `byval` and globals
Labels
clang:codegen,
miscompilation
Assignees
Reporter
dtcxzyw
Reproducer: https://godbolt.org/z/PexPvPjf6
```
#include
#include
int8_t safe_mul_func_int8_t_s_s(int8_t si1, int8_t si2) {
return (((si1 > 0) && (si2 > 0) && (si1 > (INT8_MAX / si2))) ||
((si1 > 0) && (si2 <= 0) && (si2 < (INT8_MIN / si1))) ||
((si1 <= 0) && (si2 > 0) && (si1 < (INT8_MIN / si2))) ||
((si1 <= 0) && (si2 <= 0) && (si1 != 0) && (si2 < (INT8_MAX / si1
? 0
: si1 * si2;
}
uint64_t safe_div_func_uint64_t_u_u(uint64_t ui1, uint64_t ui2) {
return (ui2 == 0) ? 0 : (ui1 / ui2);
}
struct a {
uint32_t b;
uint64_t c;
int32_t d;
int32_t z;
} e = {5, 0, 1, 90986701};
int32_t *f;
int32_t h, r, p, q, s, m;
uint8_t g[3][3][4];
uint32_t o;
int64_t l;
struct a aa[1];
uint32_t n[1][1];
const int32_t *ab(int32_t *, struct a);
uint8_t ad(struct a);
int32_t *ac(int32_t *, struct a, uint32_t *, uint32_t *, int16_t);
int32_t *t(int16_t);
int64_t af(int16_t, struct a, uint16_t, int8_t);
int32_t u() {
struct a ag;
ab(f, ag);
return 0;
}
const int32_t *ab(int32_t *, struct a) {
ad(e);
return &r;
}
uint8_t ad(struct a ah) {
int8_t ae[3];
int i, j, k;
for (i = 0; i < 3; i++)
ae[i] = 1;
for (;;) {
uint32_t *v = &p;
if (ah.z) {
uint32_t *aj[2][4][4];
for (i = j = k = 0; k < 4; k++)
aj[i][j][k] = 0;
for (ah.b = 0;;) {
int32_t ak;
if (ae[ah.d]) {
ac(t(af(0, ah, ah.b, e.z)), ah, aj[0][0][0], v, ah.c);
return s;
}
}
}
}
}
int32_t *ac(int32_t *al, struct a y, uint32_t *, uint32_t *, int16_t ai) {
if (1 >= (aa[0] = y, ai))
return al;
}
int32_t *t(int16_t) { return &q; }
int64_t af(int16_t, struct a am, uint16_t, int8_t) {
int32_t w = 7;
am = e;
for (h = 0; h <= 2; h++)
for (o = 0; o <= 2; o++) {
int32_t *an = &w;
int64_t *ao = &l;
uint8_t *x = &g[1][2][3];
w ^= g[2][1][3];
if (safe_mul_func_int8_t_s_s(
am.c, m == (*x ^= 1 <= safe_mul_func_int8_t_s_s(
safe_div_func_uint64_t_u_u(*ao, am.z),
*an
++n[2][0];
}
return am.z;
}
int main() {
int i;
u();
i = 0;
printf("%d\n", aa[i].b);
}
```
```
> clang -O0 test.c && ./a.out
0
> clang -O3 test.c && ./a.out
5
```
```
%struct.a = type { i32, i64, i32, i32 }
@e = dso_local global { i32, [4 x i8], i64, i32, i32 } { i32 5, [4 x i8] zeroinitializer, i64 0, i32 1, i32 90986701 }, align 8
define dso_local zeroext i8 @ad(ptr noundef byval(%struct.a) align 8 %ah)
%call = call zeroext i8 @ad(ptr noundef byval(%struct.a) align 8 @e)
```
We should also emit the padding for `%struct.a`.
llvm version: d21fc58aeeaa7f0369a24dbe70a0360e0edbf76f
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 126153] [libc][setjmp] implement sigsetjmp/siglongjmp
Issue 126153 Summary [libc][setjmp] implement sigsetjmp/siglongjmp Labels libc Assignees Reporter nickdesaulniers When cross compiling the libc testsuite, I ran into: ``` llvm-project/libc/test/UnitTest/FPExceptMatcher.cpp:31:21: error: unknown type name 'sigjmp_buf' 31 | static thread_local sigjmp_buf jumpBuffer; | ^ ``` and @lntue points out the usage in https://github.com/llvm/llvm-project/blob/main/libc/test/UnitTest/FPExceptMatcher.cpp#L45 of the relevant functions. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 126174] [X86][compiler-rt][builtin] Static Link Failure Caused by the Builtins Function Dependence on libm
Issue
126174
Summary
[X86][compiler-rt][builtin] Static Link Failure Caused by the Builtins Function Dependence on libm
Labels
new issue
Assignees
Reporter
zhangtianhao6
case:
```
#include
int
test (long double _Complex x, long double _Complex ref)
{
long double re, im;
re = creall(ref);
im = cimagl(ref);
return x / ref;
}
int main (){
long double _Complex x;
long double _Complex ref;
test(x, ref);
}
```
**compiler-rt** options: -rtlib=compiler-rt -static -unwindlib=libunwind -lm
failed:
```
/opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/15.0.1/../../../../x86_64-linux-gnu/bin/ld: /opt/compiler-explorer/clang-trunk-20250206/lib/clang/21/lib/x86_64-unknown-linux-gnu/libclang_rt.builtins.a(divxc3.c.o): in function `__divxc3':
divxc3.c:(.text+0x47): undefined reference to `fmaxl'
/opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/15.0.1/../../../../x86_64-linux-gnu/bin/ld: divxc3.c:(.text+0x4f): undefined reference to `logbl'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Compiler returned: 1
```
https://godbolt.org/z/Ks61aGoqs
**libgcc** options: -static
link ok.
https://godbolt.org/z/qo1cPYo31
**Reason**:
The __divxc3 symbol of the builtin function in compiler-rt depends on the fmaxl and logbl symbols of libm. The ld linker fails to be statically linked.
But the __divxc3 symbol in libgcc doesn't depend on the fmaxl and logbl symbols of libm.
Is this a bug and is there a plan to fix it or a means to circumvent it?
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 126084] [flang] `NO WAIT` is also a `NOWAIT`
Issue 126084 Summary [flang] `NO WAIT` is also a `NOWAIT` Labels flang Assignees Reporter pawosm-arm In huge HPC projects like https://github.com/OpenRadioss/OpenRadioss some of the OpenMP directives use different spelling for `NOWAIT`, see: https://github.com/OpenRadioss/OpenRadioss/blob/d271d5b5f3e5f74a4fd8153f817c6a063a0e8d0e/engine/source/assembly/depla.F#L91 ...and many other places across the entire project. Flang cannot compile this until all the occurrences are replaced with `NOWAIT`, other compilers don't complain. It is important that Flang is being able to compile large HPC projects like this one out of the box. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 126085] [VectorCombine] Assertion `I >= 0 && I < (NumOpElts * 2) && "Out-of-bounds shuffle mask element"' failed.
Issue
126085
Summary
[VectorCombine] Assertion `I >= 0 && I < (NumOpElts * 2) && "Out-of-bounds shuffle mask element"' failed.
Labels
crash-on-valid,
llvm:transforms
Assignees
Reporter
dtcxzyw
Reproducer:
```
; bin/opt -passes=vector-combine 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"
define i32 @test(ptr readonly captures(none) dereferenceable(16) %0) {
%2 = load <16 x i8>, ptr %0, align 1
%.sroa.01.2.vec.insert = shufflevector <16 x i8> %2, <16 x i8> poison, <4 x i32>
%3 = extractelement <16 x i8> %2, i64 11
%.sroa.01.3.vec.insert = insertelement <4 x i8> %.sroa.01.2.vec.insert, i8 %3, i64 1
%4 = bitcast <4 x i8> %.sroa.01.3.vec.insert to i32
ret i32 %4
}
```
```
opt: /home/dtcxzyw/WorkSpace/Projects/compilers/llvm-project/llvm/lib/IR/Instructions.cpp:1890: bool isSingleSourceMaskImpl(llvm::ArrayRef, int): Assertion `I >= 0 && I < (NumOpElts * 2) && "Out-of-bounds shuffle mask element"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0. Program arguments: bin/opt -passes=vector-combine reduced.ll -S
1. Running pass "function(vector-combine)" on module "reduced.ll"
2. Running pass "vector-combine" on function "test"
#0 0x7f4379a17152 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/home/dtcxzyw/WorkSpace/Projects/compilers/LLVM/llvm-build/bin/../lib/libLLVMSupport.so.21.0git+0x217152)
#1 0x7f4379a1403f llvm::sys::RunSignalHandlers() (/home/dtcxzyw/WorkSpace/Projects/compilers/LLVM/llvm-build/bin/../lib/libLLVMSupport.so.21.0git+0x21403f)
#2 0x7f4379a1417c SignalHandler(int) Signals.cpp:0:0
#3 0x7f4379442520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#4 0x7f43794969fc __pthread_kill_implementation ./nptl/pthread_kill.c:44:76
#5 0x7f43794969fc __pthread_kill_internal ./nptl/pthread_kill.c:78:10
#6 0x7f43794969fc pthread_kill ./nptl/pthread_kill.c:89:10
#7 0x7f4379442476 gsignal ./signal/../sysdeps/posix/raise.c:27:6
#8 0x7f43794287f3 abort ./stdlib/abort.c:81:7
#9 0x7f437942871b _nl_load_domain ./intl/loadmsgcat.c:1177:9
#10 0x7f4379439e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96)
#11 0x7f4370e71a16 isSingleSourceMaskImpl(llvm::ArrayRef, int) Instructions.cpp:0:0
#12 0x7f4370e7c3dc llvm::ShuffleVectorInst::isReverseMask(llvm::ArrayRef, int) (/home/dtcxzyw/WorkSpace/Projects/compilers/LLVM/llvm-build/bin/../lib/../lib/libLLVMCore.so.21.0git+0x27c3dc)
#13 0x7f43788933f2 llvm::X86TTIImpl::getShuffleCost(llvm::TargetTransformInfo::ShuffleKind, llvm::VectorType*, llvm::ArrayRef, llvm::TargetTransformInfo::TargetCostKind, int, llvm::VectorType*, llvm::ArrayRef, llvm::Instruction const*) (/home/dtcxzyw/WorkSpace/Projects/compilers/LLVM/llvm-build/bin/../lib/../lib/libLLVMX86CodeGen.so.21.0git+0x4933f2)
#14 0x7f43716ddf0c llvm::TargetTransformInfo::getShuffleCost(llvm::TargetTransformInfo::ShuffleKind, llvm::VectorType*, llvm::ArrayRef, llvm::TargetTransformInfo::TargetCostKind, int, llvm::VectorType*, llvm::ArrayRef, llvm::Instruction const*) const (/home/dtcxzyw/WorkSpace/Projects/compilers/LLVM/llvm-build/bin/../lib/../lib/libLLVMAnalysis.so.21.0git+0x4ddf0c)
#15 0x7f437224f6e7 (anonymous namespace)::VectorCombine::foldInsExtVectorToShuffle(llvm::Instruction&) VectorCombine.cpp:0:0
#16 0x7f4372256116 (anonymous namespace)::VectorCombine::run()::'lambda'(llvm::Instruction&)::operator()(llvm::Instruction&) const VectorCombine.cpp:0:0
#17 0x7f437225787f llvm::VectorCombinePass::run(llvm::Function&, llvm::AnalysisManager&) (/home/dtcxzyw/WorkSpace/Projects/compilers/LLVM/llvm-build/bin/../lib/../lib/libLLVMVectorize.so.21.0git+0x25787f)
#18 0x7f4373f225c5 llvm::detail::PassModel>::run(llvm::Function&, llvm::AnalysisManager&) (/home/dtcxzyw/WorkSpace/Projects/compilers/LLVM/llvm-build/bin/../lib/../lib/libLLVMPasses.so.21.0git+0x1225c5)
#19 0x7f4370f10cad llvm::PassManager>::run(llvm::Function&, llvm::AnalysisManager&) (/home/dtcxzyw/WorkSpace/Projects/compilers/LLVM/llvm-build/bin/../lib/../lib/libLLVMCore.so.21.0git+0x310cad)
#20 0x7f43784dc235 llvm::detail::PassModel>, llvm::AnalysisManager>::run(llvm::Function&, llvm::AnalysisManager&) (/home/dtcxzyw/WorkSpace/Projects/compilers/LLVM/llvm-build/bin/../lib/../lib/libLLVMX86CodeGen.so.21.0git+0xdc235)
#21 0x7f4370f0ee75 llvm::ModuleToFunctionPassAdaptor::run(llvm::Module&, llvm::AnalysisManager&) (/home/dtcxzyw/WorkSpace/Projects/compilers/LLVM/llvm-build/bin/../lib/../lib/libLLVMCore.so.21.0git+0x30ee75)
#22 0x7f43784dcbf5 llvm::detail::PassModel>::run(llvm::Module&, llvm::AnalysisManager&) (/home/dtcxzyw/WorkSpa
[llvm-bugs] [Bug 126081] clang-diagnostic-error for boost include
Issue 126081 Summary clang-diagnostic-error for boost include Labels Assignees Reporter chrchr-github ~~~c++ #include ~~~ After upgrading from clang19 to clang20-rc1, the line above causes this error: ~~~ boost/boost_1_73_0\boost/mpl/aux_/integral_wrapper.hpp:73:31: error: non-type template argument is not a constant _expression_ [clang-diagnostic-error] 73 | typedef AUX_WRAPPER_INST( BOOST_MPL_AUX_STATIC_CAST(AUX_WRAPPER_VALUE_TYPE, (value - 1)) ) prior; | ^ boost/boost_1_73_0\boost/mpl/aux_/static_cast.hpp:24:47: note: expanded from macro 'BOOST_MPL_AUX_STATIC_CAST' 24 | # define BOOST_MPL_AUX_STATIC_CAST(T, expr) static_cast(expr) | ^ ~~~ This happens on Windows, but I don't see it here for some reason: https://godbolt.org/z/ooEnPzWqW ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 126106] Test LlvmLibcFILETest.SimpleFileOperations fails due to file descriptor assertion
Issue 126106 Summary Test LlvmLibcFILETest.SimpleFileOperations fails due to file descriptor assertion Labels bug, libc Assignees Reporter alanzhao1 Repro steps: ``` $ cmake ../runtimes -GNinja \ -DLLVM_ENABLE_RUNTIMES="libc;compiler-rt" \ -DCMAKE_BUILD_TYPE=Debug \ -DCMAKE_CXX_COMPILER=clang++ \ -DCMAKE_C_COMPILER=clang \ -DLLVM_LIBC_FULL_BUILD=ON \ -DLLVM_LIBC_INCLUDE_SCUDO=ON \ -DCOMPILER_RT_BUILD_SCUDO_STANDALONE_WITH_LLVM_LIBC=ON \ -DCOMPILER_RT_BUILD_GWP_ASAN=OFF \ -DCOMPILER_RT_SCUDO_STANDALONE_BUILD_SHARED=OFF $ ninja check-libc ``` Result: ``` [530/2361] Running unit test libc.test.src.stdio.fileop_test.__unit__ FAILED: libc/test/src/stdio/CMakeFiles/libc.test.src.stdio.fileop_test.__unit__ /usr/local/google/home/ayzhao/src/llvm-project/build-libc/libc/test/src/stdio/CMakeFiles/libc.test.src.stdio.fileop_test.__unit__ cd /usr/local/google/home/ayzhao/src/llvm-project/build-libc/libc/test/src/stdio && /usr/local/google/home/ayzhao/src/llvm-project/build-libc/libc/test/src/stdio/libc.test.src.stdio.fileop_test.__unit__.__build__ [==] Running 3 tests from 1 test suite. [ RUN ] LlvmLibcFILETest.SimpleFileOperations /usr/local/google/home/ayzhao/src/llvm-project/libc/test/src/stdio/fileop_test.cpp:34: FAILURE Expected: __llvm_libc_20_0_0_git::fileno(file) Which is: 5 To be equal to: 3 Which is: 3 [ FAILED ] LlvmLibcFILETest.SimpleFileOperations ``` Looking at the [code](https://github.com/llvm/llvm-project/blob/16f7e961c600986de7814822fd118f431e0bb433/libc/test/src/stdio/fileop_test.cpp#L32-L34) the test opens a file and assert that its file descriptor is equal to the hardcoded value 3. This seems to be a brittle assertion as it makes assumptions about the test's process environment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
