[llvm-bugs] [Bug 117157] [clang] Crash at O1: Assertion `MSSA->dominates(NewDef, FirstDef) && "Should have dominated the new access"' failed
Issue
117157
Summary
[clang] Crash at O1: Assertion `MSSA->dominates(NewDef, FirstDef) && "Should have dominated the new access"' failed
Labels
clang
Assignees
Reporter
cardigan1008
When I compiled this code with -O3, it crashed:
```c
int a, b, c, d;
long e, f;
long *g;
char h;
static long i[];
void j() {
while (1) {
if (a == 0)
break;
if (a == 1) {
if (b == 0)
break;
} else if (a == 2)
if (c)
break;
else
a;
}
}
void k() {
for (; d; e++) {
h = 2;
for (; h; h++) {
*g || (i[1] &= 0);
--f;
}
j();
}
}
```
Compiler Explorer: https://godbolt.org/z/fGf7hjTxe
Crash is
```
clang: /root/llvm-project/llvm/lib/Analysis/MemorySSAUpdater.cpp:504: void llvm::MemorySSAUpdater::fixupDefs(const llvm::SmallVectorImpl&): Assertion `MSSA->dominates(NewDef, FirstDef) && "Should have dominated the new access"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments: /opt/compiler-explorer/clang-assertions-trunk/bin/clang -gdwarf-4 -g -o /app/output.s -mllvm --x86-asm-syntax=intel -fno-verbose-asm -S --gcc-toolchain=/opt/compiler-explorer/gcc-snapshot -fcolor-diagnostics -fno-crash-diagnostics -O1 -Wall -Wextra
1. parser at end of file
2. Optimizer
3. Running pass "function(float2int,lower-constant-intrinsics,loop(loop-rotate,loop-deletion),loop-distribute,inject-tli-mappings,loop-vectorize,infer-alignment,loop-load-elim,instcombine,simplifycfg,vector-combine,instcombine,loop-unroll,transform-warning,sroa,infer-alignment,instcombine,loop-mssa(licm),alignment-from-assumptions,loop-sink,instsimplify,div-rem-pairs,tailcallelim,simplifycfg)" on module ""
4. Running pass "loop-mssa(licm)" on function "k"
#0 0x03bf59c8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x3bf59c8)
#1 0x03bf36cc llvm::sys::CleanupOnSignal(unsigned long) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x3bf36cc)
#2 0x03b40db8 CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0
#3 0x751620442520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#4 0x7516204969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
#5 0x751620442476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
#6 0x7516204287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
#7 0x75162042871b (/lib/x86_64-linux-gnu/libc.so.6+0x2871b)
#8 0x751620439e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96)
#9 0x02bf1b11 llvm::MemorySSAUpdater::fixupDefs(llvm::SmallVectorImpl const&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x2bf1b11)
#10 0x02bf205b llvm::MemorySSAUpdater::insertDef(llvm::MemoryDef*, bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x2bf205b)
#11 0x039fa897 (anonymous namespace)::LoopPromoter::doExtraRewritesBeforeFinalDeletion() LICM.cpp:0:0
#12 0x03d8281e llvm::LoadAndStorePromoter::run(llvm::SmallVectorImpl const&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x3d8281e)
#13 0x039f8dae llvm::promoteLoopAccessesToScalars(llvm::SmallSetVector const&, llvm::SmallVectorImpl&, llvm::SmallVectorImpl, false, false>>&, llvm::SmallVectorImpl&, llvm::PredIteratorCache&, llvm::LoopInfo*, llvm::DominatorTree*, llvm::AssumptionCache*, llvm::TargetLibraryInfo const*, llvm::TargetTransformInfo*, llvm::Loop*, llvm::MemorySSAUpdater&, llvm::ICFLoopSafetyInfo*, llvm::OptimizationRemarkEmitter*, bool, bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x39f8dae)
#14 0x03a06a36 (anonymous namespace)::LoopInvariantCodeMotion::runOnLoop(llvm::Loop*, llvm::AAResults*, llvm::LoopInfo*, llvm::DominatorTree*, llvm::AssumptionCache*, llvm::TargetLibraryInfo*, llvm::TargetTransformInfo*, llvm::ScalarEvolution*, llvm::MemorySSA*, llvm::OptimizationRemarkEmitter*, bool) (.part.0) LICM.cpp:0:0
#15 0x03a075f8 llvm::LICMPass::run(llvm::Loop&, llvm::AnalysisManager&, llvm::LoopStandardAnalysisResults&, llvm::LPMUpdater&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x3a075f8)
#16 0x052606ee llvm::detail::PassModel, llvm::LoopStandardAnalysisResults&, llvm::LPMUpdater&>::run(llvm::Loop&, llvm::AnalysisManager&, llvm::LoopStandardAnalysisResults&, llvm::LPMUpdater&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x52606ee)
#17 0x03a0fd93 llvm::FunctionToLoopPassAdaptor::run(llvm::Function&, llvm::AnalysisManager&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x3a0fd93)
#18 0x010ee88e llvm::detail::PassModel>::run(llvm::Function&, llvm::AnalysisManager&) (/opt/compiler-explorer/clang-as
[llvm-bugs] [Bug 117290] [clang-format] Assertion failed in FormatToken.cpp
Issue 117290 Summary [clang-format] Assertion failed in FormatToken.cpp Labels clang-format Assignees Reporter rmarker I encountered a crash with clang-format 19.1.4 (well, initially with 19.1.0 before I tried the newer version). I built a debug version and got the following output. (Including the debug output as it seemed to have more information than the regular version that I initially encountered. E.g. it mentioned the assertion) ``` Assertion failed: i < MustBreakBeforeItem.size(), file \clang\lib\Format\FormatToken.cpp, line 271 PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. Stack dump: 0. Program arguments: clang-format.exe ./temp.C Exception Code: 0x8003 0x7FF67CF7EF7C, clang-format.exe(0x7FF67CDD) + 0x1AEF7C byte(s), HandleAbort() + 0xC byte(s), \llvm\lib\Support\Windows\Signals.inc, line 429 + 0x0 byte(s) 0x7FF8E7B090ED, C:\WINDOWS\SYSTEM32\ucrtbased.dll(0x7FF8E7A6) + 0xA90ED byte(s), raise() + 0x46D byte(s) 0x7FF8E7B0AE49, C:\WINDOWS\SYSTEM32\ucrtbased.dll(0x7FF8E7A6) + 0xAAE49 byte(s), abort() + 0x39 byte(s) 0x7FF8E7B11345, C:\WINDOWS\SYSTEM32\ucrtbased.dll(0x7FF8E7A6) + 0xB1345 byte(s), _get_wide_winmain_command_line() + 0x2895 byte(s) 0x7FF8E7B10BD7, C:\WINDOWS\SYSTEM32\ucrtbased.dll(0x7FF8E7A6) + 0xB0BD7 byte(s), _get_wide_winmain_command_line() + 0x2127 byte(s) 0x7FF8E7B0EBA1, C:\WINDOWS\SYSTEM32\ucrtbased.dll(0x7FF8E7A6) + 0xAEBA1 byte(s), _get_wide_winmain_command_line() + 0xF1 byte(s) 0x7FF8E7B118AF, C:\WINDOWS\SYSTEM32\ucrtbased.dll(0x7FF8E7A6) + 0xB18AF byte(s), _wassert() + 0x2F byte(s) 0x7FF67D11B13E, clang-format.exe(0x7FF67CDD) + 0x34B13E byte(s), clang::format::CommaSeparatedList::precomputeFormattingInfos() + 0x75E byte(s), \clang\lib\Format\FormatToken.cpp, line 271 + 0x40 byte(s) 0x7FF67D120B18, clang-format.exe(0x7FF67CDD) + 0x350B18 byte(s), clang::format::TokenAnnotator::calculateFormattingInformation() + 0xF08 byte(s), \clang\lib\Format\TokenAnnotator.cpp, line 4071 + 0x44 byte(s) 0x7FF67D11FCA5, clang-format.exe(0x7FF67CDD) + 0x34FCA5 byte(s), clang::format::TokenAnnotator::calculateFormattingInformation() + 0x95 byte(s), \clang\lib\Format\TokenAnnotator.cpp, line 3866 + 0x12 byte(s) 0x7FF67D0B5D8E, clang-format.exe(0x7FF67CDD) + 0x2E5D8E byte(s), clang::format::`anonymous namespace'::SemiRemover::removeSemi() + 0x10E byte(s), \clang\lib\Format\Format.cpp, line 2305 + 0x0 byte(s) 0x7FF67D0B5C31, clang-format.exe(0x7FF67CDD) + 0x2E5C31 byte(s), clang::format::`anonymous namespace'::SemiRemover::analyze() + 0x71 byte(s), \clang\lib\Format\Format.cpp, line 2282 + 0x19 byte(s) 0x7FF67D1553D1, clang-format.exe(0x7FF67CDD) + 0x3853D1 byte(s), clang::format::TokenAnalyzer::process() + 0x621 byte(s), \clang\lib\Format\TokenAnalyzer.cpp, line 129 + 0x4B byte(s) 0x7FF67D0C142C, clang-format.exe(0x7FF67CDD) + 0x2F142C byte(s), `clang::format::internal::reformat'::`36'operator()() + 0x6C byte(s), \clang\lib\Format\Format.cpp, line 3716 + 0x3D byte(s) 0x7FF67D0E5D18, clang-format.exe(0x7FF67CDD) + 0x315D18 byte(s), std::invoke<`clang::format::internal::reformat'::`36':: &,clang::format::Environment const &>() + 0x28 byte(s), C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.42.34433\include\type_traits, line 1705 + 0x14 byte(s) 0x7FF67D0C35CF, clang-format.exe(0x7FF67CDD) + 0x2F35CF byte(s), std::_Func_impl_no_alloc<`clang::format::internal::reformat'::`36'::,std::pair,clang::format::Environment const &>::_Do_call() + 0x2F byte(s), C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.42.34433\include\functional, line 876 + 0x1B byte(s) 0x7FF67D10883E, clang-format.exe(0x7FF67CDD) + 0x33883E byte(s), std::_Func_class,clang::format::Environment const &>::operator()() + 0x5E byte(s), C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.42.34433\include\functional, line 920 + 0x24 byte(s) 0x7FF67D0C070D, clang-format.exe(0x7FF67CDD) + 0x2F070D byte(s), clang::format::internal::reformat() + 0xD2D byte(s), \clang\lib\Format\Format.cpp, line 3768 + 0x4F byte(s) 0x7FF67D0B1DC9, clang-format.exe(0x7FF67CDD) + 0x2E1DC9 byte(s), clang::format::reformat() + 0xB9 byte(s), \clang\lib\Format\Format.cpp, line 3812 + 0x9C byte(s) 0x7FF67CE22679, clang-format.exe(0x7FF67CDD) + 0x52679 byte(s), clang::format::format() + 0x1789 byte(s), \clang\tools\clang-format\ClangFormat.cpp, line 510 + 0x1F2 byte(s) 0x7FF67CE249DA, clang-format.exe(0x7FF67CDD) + 0x549DA byte(s), main() + 0x81A byte(s), \clang\
[llvm-bugs] [Bug 117300] [LLVM] SIGSEGV with clang-trunk at -Os; Unexpected Behavior at -O1 vs Expected Infinite Loop at -O0 and gcc -O2
Issue
117300
Summary
[LLVM] SIGSEGV with clang-trunk at -Os; Unexpected Behavior at -O1 vs Expected Infinite Loop at -O0 and gcc -O2
Labels
new issue
Assignees
Reporter
wangbo15
The following code triggers a `SIGSEGV` when compiled with `clang-trunk` and `clang 19.1.0` using the `-Os` optimization level.
With `-O1`, the program exits with a return value of `64`. However, when compiled with `clang` `-O0` or `gcc` `-O2`, the program behaves as expected and enters an infinite loop.
Additionally, the behavior cases are also different on the `arm` backends.
```
#include
unsigned long long a;
void b(unsigned long long *, int) {}
class {
public:
short c[10];
} e;
int main() {
for (size_t d;;)
b(&a, e.c[d]);
}
```
Please see: https://godbolt.org/z/79fzqePEv
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 117131] [RISC-V] How to use C types to represent the mask type in inline asm?
Issue 117131 Summary [RISC-V] How to use C types to represent the mask type in inline asm? Labels new issue Assignees Reporter cocacola-wing Hi, there I wrote some rvv inline assembly code. [Compiler Explorer](https://godbolt.org/z/9vY4jca8T) If I modify the mask operand with vbool8_t and constraint 'vm', the vlm.v instruction generates a vsetvli instruction, which changes the SEW of the subsequent instructions. Do I need to insert a vsetvl instruction before each asm? ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 117133] [indvars] Miscompile when loop body has an operation with Undefined Behaviour
Issue
117133
Summary
[indvars] Miscompile when loop body has an operation with Undefined Behaviour
Labels
new issue
Assignees
Reporter
Nirhar
Here is the problematic IR:
```
define i32 @widget() {
bb:
br label %bb1
bb1: ; preds = %bb5, %bb
%phi = phi i32 [ 0, %bb ], [ %udiv6, %bb5 ]
%phi2 = phi i32 [ 1, %bb ], [ %add, %bb5 ]
%icmp = icmp eq i32 %phi, 0
br i1 %icmp, label %bb3, label %bb8
bb3: ; preds = %bb1
%udiv = udiv i32 10, %phi2
%urem = urem i32 %udiv, 10
%icmp4 = icmp eq i32 %urem, 0
br i1 %icmp4, label %bb7, label %bb5
bb5: ; preds = %bb3
%udiv6 = udiv i32 %phi2, 0
%add = add i32 %phi2, 1
br label %bb1
bb7: ; preds = %bb3
ret i32 5
bb8: ; preds = %bb1
ret i32 7
}
```
produces incorrect IR when `indvars` pass is run. I suspect this is because of the `%udiv6 = udiv i32 %phi2, 0` divide by zero operation.
Look at the indvars transformation here: https://godbolt.org/z/cz1r5178h
The original IR must return 5, while the transformed IR returns 7
Proof of wrong transformation: https://alive2.llvm.org/ce/z/vPFhzg
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 117141] [X86] Incorrect shuffle comment decoding for `vinsertps`
Issue 117141 Summary [X86] Incorrect shuffle comment decoding for `vinsertps` Labels backend:X86 Assignees Reporter omern1 ### Reproducer ``` ; input.s .intel_syntax vinsertps xmm2,xmm2,dword ptr [r14+rdi*8+0x4C],0x0B0 ``` ### Current behaviour ``` > llvm-mc -triple x86_64-unknown-unknown input.s .text vinsertps $176, 76(%r14,%rdi,8), %xmm2, %xmm2 # xmm2 = xmm2[0,1,2],mem[2] ``` Note that shuffle comment says `mem[2]`. The part describing vinsertps operation in the Intel SDM says the following: ``` IF (SRC = "" THEN COUNT_S := imm8[7:6] ELSE COUNT_S := 0 ``` In input.s the source for the vinsertps is not a register therefore the source index in the comment should be 0 (`mem[0]`). ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 117170] SLP vectorizer produces bad shuffles
Issue 117170 Summary SLP vectorizer produces bad shuffles Labels miscompilation, llvm:SLPVectorizer Assignees Reporter wjschmidt [slp-shuffle-bug.ll.txt](https://github.com/user-attachments/files/17847373/slp-shuffle-bug.ll.txt) [slp-shuffle-output.ll.txt](https://github.com/user-attachments/files/17847374/slp-shuffle-output.ll.txt) opt -passes=slp-vectorizer slp-shuffle-bug.ll -o slp-shuffle-output.ll The attached reduced test case slp-shuffle-bug.ll.txt contains a number of scalar load-multiply-store chains that SLP vectorizes. However, something goes wrong with generating two of the shuffles in the vectorized sequence, shown in slp-shuffle-output.ll. The shuffle ` %14 = shufflevector <16 x float> %13, <16 x float> %12, <16 x i32> ` produces wrong code, as all of the 0 indices should have referenced indices from the second operand %12 instead. Also, the shuffle ` %12 = shufflevector <2 x float> %11, <2 x float> %8, <16 x i32> ` is suspect, as the first four indices are never used and the fifth entry is incorrect (0 instead of 2). The test case loads from two areas of array GLOB, performs multiplications, and stores the result in a third area of GLOB. The expected behavior is: [2928:2956] = [1612] * [1208:1236] [2960:2996] = [1616] * [1240:1276] [3000:3036] = [1620] * [1280:1316] [3040:3052] = [1624] * [1320:1332] where [X] references dereference of the location at offset X of GLOB, and [X:Y] references a sequence of such dereferences. The vectorized code produces correct values for locations [2928:2996], but due to the bad shuffles the rest of the values are: [3000:3004] = [1612] * [1280:1284] [3008] = [1612] * [1620] [3012:3052] = [1612] * [1292:1332] ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 117145] lldb `ClangExpressionParser.cpp:783:15: error: no matching member function for call to 'createDiagnostics'`
Issue 117145 Summary lldb `ClangExpressionParser.cpp:783:15: error: no matching member function for call to 'createDiagnostics'` Labels lldb, build-problem Assignees Reporter sylvestre On linux: ``` /build/source/build-llvm/bin/clang++ -DHAVE_ROUND -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/build/source/build-llvm/tools/clang/stage2-bins/tools/lldb/source/Plugins/ExpressionParser/Clang -I/build/source/lldb/source/Plugins/ExpressionParser/Clang -I/build/source/lldb/include -I/build/source/build-llvm/tools/clang/stage2-bins/tools/lldb/include -I/build/source/build-llvm/tools/clang/stage2-bins/include -I/build/source/llvm/include -I/usr/include/python3.12 -I/build/source/clang/include -I/build/source/build-llvm/tools/clang/stage2-bins/tools/lldb/../clang/include -I/build/source/lldb/source -I/build/source/build-llvm/tools/clang/stage2-bins/tools/lldb/source -isystem /usr/include/libxml2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -mbranch-protection=standard -Wno-unused-command-line-argument -Wdate-time -D_FORTIFY_SOURCE=3 -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wmisleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color -ffunction-sections -fdata-sections -ffile-prefix-map=/build/source/build-llvm/tools/clang/stage2-bins=../../../../ -ffile-prefix-map=/build/source/= -no-canonical-prefixes -Wno-unknown-pragmas -Wno-strict-aliasing -Wno-vla-extension -O2 -DNDEBUG -g1 -std=c++17 -fno-exceptions -funwind-tables -MD -MT tools/lldb/source/Plugins/ExpressionParser/Clang/CMakeFiles/lldbPluginExpressionParserClang.dir/ClangExpressionParser.cpp.o -MF tools/lldb/source/Plugins/ExpressionParser/Clang/CMakeFiles/lldbPluginExpressionParserClang.dir/ClangExpressionParser.cpp.o.d -o tools/lldb/source/Plugins/ExpressionParser/Clang/CMakeFiles/lldbPluginExpressionParserClang.dir/ClangExpressionParser.cpp.o -c /build/source/lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp /build/source/lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp:783:15: error: no matching member function for call to 'createDiagnostics' 783 | m_compiler->createDiagnostics(); | ^ /build/source/clang/include/clang/Frontend/CompilerInstance.h:687:8: note: candidate function not viable: requires at least argument 'VFS', but no arguments were provided 687 | void createDiagnostics(llvm::vfs::FileSystem &VFS, |^ ~~~ 688 | DiagnosticConsumer *Client = nullptr, | ~ 689 | bool ShouldOwnClient = true); | ~~~ /build/source/clang/include/clang/Frontend/CompilerInstance.h:710:3: note: candidate function not viable: requires at least 2 arguments, but 0 were provided 710 | createDiagnostics(llvm::vfs::FileSystem &VFS, DiagnosticOptions *Opts, | ^ 711 | DiagnosticConsumer *Client = nullptr, | ~ 712 | bool ShouldOwnClient = true, | 713 | const CodeGenOptions *CodeGenOpts = nullptr); | ~~~ 1 error generated. ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 117166] __builtin_bit_cast does not allow bitcasting from nullptr_t
Issue 117166 Summary __builtin_bit_cast does not allow bitcasting from nullptr_t Labels clang:frontend, constexpr Assignees Reporter tbaederr `nullptr_t` is not a pointer type, see the `static_assert` in https://godbolt.org/z/vjq1Tse7W In this example, the second bitcast works, but the first one does not: ```c++ typedef __UINTPTR_TYPE__ uintptr_t; constexpr uintptr_t A = __builtin_bit_cast(uintptr_t, nullptr); typedef decltype(nullptr) nullptr_t; constexpr decltype(nullptr) N = __builtin_bit_cast(nullptr_t, (uintptr_t)12); static_assert(N == nullptr); ``` The output suggests some bogus reason though: ```console ./array.cpp:26:21: error: constexpr variable 'A' must be initialized by a constant _expression_ 26 | constexpr uintptr_t A = __builtin_bit_cast(uintptr_t, nullptr); | ^ ~~ ./array.cpp:26:25: note: indeterminate value can only initialize an object of type 'unsigned char' or 'std::byte'; 'unsigned long' is invalid 26 | constexpr uintptr_t A = __builtin_bit_cast(uintptr_t, nullptr); | ^ ``` GCC accepts the first one, but not the second. I opened https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117727 for that. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 117180] Cannot build rust std with llvm-libc
Issue 117180 Summary Cannot build rust std with llvm-libc Labels libc Assignees Reporter SchrodingerZhu Tracking what is needed: ``` = note: /usr/bin/ld: warning: cannot find entry symbol _start; defaulting to 1000 /usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/libgcc_eh.a(unwind-dw2-fde-dip.o): in function `version_lock_lock_exclusive': (.text+0x6d2): undefined reference to `pthread_cond_wait' /usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/libgcc_eh.a(unwind-dw2-fde-dip.o): in function `btree_allocate_node': (.text+0x1b1b): undefined reference to `pthread_cond_broadcast' /usr/bin/ld: (.text+0x1b47): undefined reference to `malloc' /usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/libgcc_eh.a(unwind-dw2-fde-dip.o): in function `btree_remove': (.text+0x295d): undefined reference to `pthread_cond_broadcast' /usr/bin/ld: (.text+0x2c56): undefined reference to `pthread_cond_broadcast' /usr/bin/ld: (.text+0x3a28): undefined reference to `pthread_cond_broadcast' /usr/bin/ld: (.text+0x42b2): undefined reference to `pthread_cond_broadcast' /usr/bin/ld: (.text+0x4327): undefined reference to `pthread_cond_broadcast' /usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/libgcc_eh.a(unwind-dw2-fde-dip.o):(.text+0x4356): more undefined references to `pthread_cond_broadcast' follow /usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/libgcc_eh.a(unwind-dw2-fde-dip.o): in function `__deregister_frame_info_bases.part.0': (.text+0x4938): undefined reference to `free' /usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/libgcc_eh.a(unwind-dw2-fde-dip.o): in function `btree_insert.isra.0': (.text+0x4f19): undefined reference to `pthread_cond_broadcast' /usr/bin/ld: (.text+0x58b6): undefined reference to `pthread_cond_broadcast' /usr/bin/ld: (.text+0x5900): undefined reference to `pthread_cond_broadcast' /usr/bin/ld: (.text+0x5937): undefined reference to `pthread_cond_broadcast' /usr/bin/ld: (.text+0x5999): undefined reference to `pthread_cond_broadcast' /usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/libgcc_eh.a(unwind-dw2-fde-dip.o):(.text+0x5aa9): more undefined references to `pthread_cond_broadcast' follow /usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/libgcc_eh.a(unwind-dw2-fde-dip.o): in function `btree_insert.isra.0': (.text+0x5b28): undefined reference to `malloc' /usr/bin/ld: (.text+0x5c7b): undefined reference to `pthread_cond_broadcast' /usr/bin/ld: (.text+0x5eb1): undefined reference to `pthread_cond_broadcast' /usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/libgcc_eh.a(unwind-dw2-fde-dip.o): in function `__register_frame': (.text+0x62db): undefined reference to `malloc' /usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/libgcc_eh.a(unwind-dw2-fde-dip.o): in function `__register_frame_table': (.text+0x637f): undefined reference to `malloc' /usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/libgcc_eh.a(unwind-dw2-fde-dip.o): in function `__deregister_frame': (.text+0x6412): undefined reference to `free' /usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/libgcc_eh.a(unwind-dw2-fde-dip.o): in function `_Unwind_Find_FDE': (.text+0x645d): undefined reference to `_dl_find_object' /usr/bin/ld: (.text+0x6650): undefined reference to `_dl_find_object' /usr/bin/ld: (.text+0x6c84): undefined reference to `malloc' /usr/bin/ld: (.text+0x6ca1): undefined reference to `malloc' /usr/bin/ld: (.text+0x6d69): undefined reference to `free' /usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/libgcc_eh.a(unwind-dw2-fde-dip.o): in function `btree_release_tree_recursively': (.text.exit+0x4fa): undefined reference to `pthread_cond_broadcast' /usr/bin/ld: (.text.exit+0x53a): undefined reference to `pthread_cond_broadcast' /usr/bin/ld: (.text.exit+0x57a): undefined reference to `pthread_cond_broadcast' /usr/bin/ld: (.text.exit+0x5ba): undefined reference to `pthread_cond_broadcast' /usr/bin/ld: (.text.exit+0x5f9): undefined reference to `pthread_cond_broadcast' /usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/libgcc_eh.a(unwind-dw2-fde-dip.o):(.text.exit+0x63a): more undefined references to `pthread_cond_broadcast' follow /usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/libgcc_eh.a(unwind-dw2-fde-dip.o): in function `btree_destroy': (.text.exit+0x739): undefined reference to `free' /usr/bin/ld: /home/schrodingerzy/Documents/rust-linux-llvm/target/x86_64-llvm-linux-gnu/release/build/l
[llvm-bugs] [Bug 117178] Reserved function pointers are broken on x86
Issue
117178
Summary
Reserved function pointers are broken on x86
Labels
new issue
Assignees
Reporter
brandtbucher
The `"frame-pointer"="reserved"` attribute is useful for compiling functions that don't want the overhead of saving, setting, and restoring frame pointers in their prologue and epilogue, but still want to guarantee that any existing chain of frame pointers is kept valid (by reserving the frame pointer register). Frame-pointer-based unwinders see these functions as if they are part of the previous frame, and can unwind through them.
On x86, however, this attribute is incorrectly ignored, and `rbp` is incorrectly used as a scratch register. After some digging, I found that the following change appears to fix the bug:
```diff
diff --git a/llvm/lib/Target/X86/X86RegisterInfo.cpp b/llvm/lib/Target/X86/X86RegisterInfo.cpp
index 50db211c99d8..9b8652b7e302 100644
--- a/llvm/lib/Target/X86/X86RegisterInfo.cpp
+++ b/llvm/lib/Target/X86/X86RegisterInfo.cpp
@@ -563,7 +563,7 @@ BitVector X86RegisterInfo::getReservedRegs(const MachineFunction &MF) const {
Reserved.set(SubReg);
// Set the frame-pointer register and its aliases as reserved if needed.
- if (TFI->hasFP(MF)) {
+ if (TFI->hasFP(MF) || MF.getTarget().Options.FramePointerIsReserved(MF)) {
if (MF.getInfo()->getFPClobberedByInvoke())
MF.getContext().reportError(
SMLoc(),
```
For context, in CPython's new JIT, we plan to use the feature to support unwinding through JIT frames while not introducing additional runtime overhead. Our JIT works by concatenating pre-compiled templates that tail-call into each other; because of this, the overhead of saving and restoring frame pointers is significant. However, this overhead drops to 0% if the frame pointer register is set once upon entry into JIT code, and then reserved in the templates themselves (for more info, see [this CPython issue](https://github.com/python/cpython/issues/126910), and [this comment](https://github.com/python/cpython/issues/126910#issuecomment-2488846508) in particular). We'd appreciate it if this were considered for backporting to LLVM 19 as a bugfix.
I'm not familiar enough with the x86 backend to know if additional changes are required or not to do this properly, but I can vouch that the above fix is sufficient for our purposes (unwinding support with 0% slowdown). `llc --frame-pointer=reserved`, `clang -Xclang -mframe-pointer=reserved`, and LLVM IR's `"frame-pointer"="reserved"` attribute all seem to work locally after the fix.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 117192] Clang ignores -femulated-tls on Darwin with LTO enabled
Issue
117192
Summary
Clang ignores -femulated-tls on Darwin with LTO enabled
Labels
clang
Assignees
Reporter
Un1q32
`tls.c`:
```c
#include
#include
__thread int var = 0;
void *func(void *arg) {
(void)arg;
if (var == 0)
var = 1;
else
puts("race");
return NULL;
}
int main(void) {
pthread_t ptid;
int i = 0;
while (i < 10) {
pthread_create(&ptid, NULL, func, NULL);
i++;
}
return 0;
}
```
Run on macOS:
```
$ clang -mmacos-version-min=14.0 tls.c -c
$ ld -arch x86_64 -platform_version macos 14.0 14.0 tls.o
Undefined symbols for architecture x86_64:
"__tlv_bootstrap", referenced from:
_var in tls.o
"_pthread_create", referenced from:
_main in tls.o
"_puts", referenced from:
_func in tls.o
ld: symbol(s) not found for architecture x86_64
$ # __tlv_bootstrap indicates normal TLS
$ clang -mmacos-version-min=14.0 tls.c -c -femulated-tls
$ ld -arch x86_64 -platform_version macos 14.0 14.0 tls.o
Undefined symbols for architecture x86_64:
"___emutls_get_address", referenced from:
_func in tls.o
_func in tls.o
"_pthread_create", referenced from:
_main in tls.o
"_puts", referenced from:
_func in tls.o
ld: symbol(s) not found for architecture x86_64
$ # ___emutls_get_address indicates emulated TLS
$ clang tls.c -c -femulated-tls -flto
$ ld -arch x86_64 -platform_version macos 14.0 14.0 tls.o
Undefined symbols for architecture x86_64:
"__tlv_bootstrap", referenced from:
_var in lto.o
"_pthread_create", referenced from:
_main in lto.o
"_puts", referenced from:
_func in lto.o
ld: symbol(s) not found for architecture x86_64
$ # __tlv_bootstrap is used dispite -femulated-tls being passed.
```
It happens when using -emit-llvm instead of -flto too. My guess is that the TLS model used is decided after LLVM IR generation, is there a workaround to use emulated TLS with LTO?
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 117139] [VPlan] Recipe fo splat operation
Issue 117139 Summary [VPlan] Recipe fo splat operation Labels vectorizers, vectorization Assignees Reporter Mel-Chen While trying to re-implement min/max with index, I discovered this potential bug. ``` middle.block: EMIT vp<%8> = compute-reduction-result ir<%max.09>, ir<%1> EMIT vp<%9> = icmp eq ir<%1>, vp<%8> ``` Currently, it seems there’s no check to ensure the vector preheader dominates the definition before hoisting the splat to the vector preheader. This could result in a use-before-definition issue. For now, I’ve temporarily reverted SafeToHoist to an earlier setting, but I think the best approach would likely be to introduce a dedicated VPInstruction::Splat. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 117279] Do you still need commit access?
Issue 117279 Summary Do you still need commit access? Labels new issue 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. @pmatos @vmiklos @gislan @ashay @tschwinge @Theodor @ianlevesque @steveire @nvoorhies @comex @whitequark @filcab @powderluv @aadsm @splhack @simonpcook @tJener @vedantk @vchuravy @rudkx @Lekensteyn @luismarques @waywardmonkeys @vmurali @werat @petar-jovanovic @luqmana @last5bits @pepsiman @DanAlbert @chisophugis @kaladron @awatry @stephenneuendorffer @yuanfang-chen @zatrazz @gottesmm @jackoalan @shawnl @aperez @chfast @vext01 @cchen15 @sheredom @sivachandra @DiamondLovesYou @bryant @bhamiltoncx @mantognini @chandlerc @rmaz @Teemperor @mgehre @jbcoe @jchlanda @speednoisemovement @faisalv @hyp @dstenb @xiangzhai @harlanhaskins @deadalnix @kaomoneus @kinu @k15tfu @isanbard @GeorgeLyon @asaadaldien @davezarzycki @vlad902 @ddcc @lnihlen @rkayaith @ezhulenev @kubamracek @Kariddi @samitolvanen @sqlbyme @arnamoy10 @jankratochvil @koparasy @gflegar @Keno @sommerlukas @ColdenCullen @rdwampler @ohmantics @jberdine @mhjacobson @tpopp @tamird @wanders @stephanemoore @lxfind @josemonsalve2 @mkurdej @SavchenkoValeriy @marco-c @davidtgoldblatt @porglezomp @FruitClover @spaceotter @kcc @zakk0610 @r4nt @orodley @VladimirMakaev @zhengyang92 @doac @christinaa @atrick @donhinton @ibookstein @spacemonkeydelivers @LittleFox94 @anton-afanasyev @llunak @marxin @wrengr @CareyJWilliams @smoofra @GleasonK @kpdev @atanasyan @hhb @kirillbobyrev @Dor1s @DaniilSuchkov @irishrover @trilorez @rsundahl @asavonic @LegalizeAdulthood @joelkevinjones @gpetters94 @pguo-cn @dendibakh @aardappel @miyuki @phisiart @ljmf00 @nuta @pendingchaos @markoshorro @andreybokhanko @greened @Bryce-MW @Izaron @movie-travel-code @abrachet @calixteman @jmciver @chichunchen @LYP951018 @jsetoain @yaoyua @trenouf @martong @scott-linder @jvesely @SForeKeeper @fodinabor @denizevrenci @gareevroman @itf @inouehrs @maflcko @JoeLoser @mumbleskates @aqjune @lukeg101 @erjin @ArcsinX @GBuella @krobelus @hexhexD @pasaulais @arpilipe @bryanpkc @kevinsala @EccoTheDolphin @erikdesjardins @ktras @ggeorgakoudis @tripleCC @brads55 @manueljacob @Snape3058 @oToToT @rgal @nadavrot @ilya-golovenko @edward-jones @dgg5503 @yurai007 @jcai19 @eopXD @cmd120 @JonasToth @andyly @amehsan @crtrott @ckissane @kda @imkiva @maekawatoshiki @AndreyChurbanov @emankov @vmrajas @Logikable @JosephTremoulet @hellobbn @JohanEngelen @cabreraam @ipazarbasi @abpostelnicu @zhyty @jmgorius @K-Wu @natgla @jubnzv @kawashima-fj @fjricci @NicolaLancellotti @simoll @ayushsahay1837 @gargaroff @PaulkaToast @GuilhermeValarini @aaronsm @fzhinkin @laszlokindrat @tom-anders @lhtin @peterbell10 @jaykang10 @gkmhub @CRobeck @ttyS0 @mcl0vinit @Xeonacid @cathyzhyi @jrose-apple @aschwaighofer @fredriss @wyzero @sapostolakis @Ralender @andydavis1 @anlunx @TocarIP @Discookie @Northbadge @aaronenyeshi @zhuhan0 @stephenhines @Ruturaj4 @ri-char @pestctrl @mscuttari @shenhanc78 @Qi-Hu @kuzkry @HLJ2009 @morehouse @yavtuk @cddouma @holland11 @mleair @higuoxing @Stoorx @tkrasnukha @zhangkangcool @kitbarton @schweitzpgi @AndrewLitteken @davidbolvansky @kitaisreal @NutshellySima @TH3CHARLie @CongzheUalberta @aturetsk @mzyKi @argentite @tentzen @HazemAbdelhafez @Arnaud-de-Grandmaison-ARM @ebahapo @Jerry-Ge @searlmc1 @An-DJ @ekatz @silvasean @yabinc @zhanghb97 @baziotis @harviniriawan @ken-matsui @huhu233 @StrongerXi @eric-xtang1008 @kpyzhov @ayzhuang @LuoYuanke @mkitzan @m-gupta @llongint @Narutoworld @zhizhouy @MaggieYingYi @gprateek93 @gpei-dev @akirchhoff-modular @sstamenova @kuterd @tylanphear @jackhong12 @ashermancinelli @alan-j-hu @jonathanmetzman @bmahjour @mariannems @khei4 @ivankelarev @sks75220 @SanitizedMemory @sidbav @nigelp-xmos @lhutton1 @reidtatge @bixia1 @rdhindsa14 @tarinduj @chandankds @Z572 @luxufan @shraiysh @jedilyn @psoni2628 @LWenH @gregbedwell @SharmaRithik @lewis-revill @aakanksha555 @weiyi-t @weirdsmiley @compinder @junlarsen @aleks-tmb @vangthao95 @RichBarton-Arm @jinge90 @pooja2299 @AntonRydahl @karimnosseir @kmitropoulou @Sockke @melonedo @dc03 @browneee @Kepontry @konstantinschwarz @MarkAHarley @georgemitenkov @jinlin-bayarea @jasonliudev @TamarChristinaArm @againull @gkousik @hazohelet @stevemerr @schittir @googlewalt @sihuan @yhgu2000 @MarkMurrayARM @bwyma @elizabethandrews @kiranktp @sndmitriev @dantrushin @whitneywhtsang @amccarth-google @futog @wuzish @RedDocMD @nextsilicon-itay-bookstein @aelovikov-intel @rkorsa @gbreynoo @pzhengqc @simpal01 @wolfy1961 @uabjean @rcraik @dcandler @mdtrent @romanova-ekaterina @dnuzman @henricka
[llvm-bugs] [Bug 117294] [Clang] Placement-new in constant evaluation can give indeterminate result
Issue
117294
Summary
[Clang] Placement-new in constant evaluation can give indeterminate result
Labels
c++20,
clang:frontend,
c++26,
constexpr
Assignees
Reporter
frederick-vs-ja
The following program shouldn't be accepted per [[expr.const]/5.18.2.1](https://eel.is/c++draft/expr.const#5.18.2.1) as corrected by [CWG2922](https://cplusplus.github.io/CWG/issues/2922.html) (since the constructed array type is unsuitable).
However, Clang currently accepts it and give different results in different compilation. [Godbolt link](https://godbolt.org/z/asjev19vj).
```C++
#include
#include
constexpr int N = []
{
struct S {
int a[1];
};
S s;
::new (s.a) int[1][2][3][4]();
return s.a[0];
}();
template
struct tag {};
void unknown(const std::type_info&) noexcept;
int main()
{
unknown(typeid(tag));
}
```
Moreover, the following seems valid because the array type is suitable, but there are still indeterminate results. [Godbolt link](https://godbolt.org/z/5bPfns185).
(The correct `N` is `0`.)
```C++
#include
#include
constexpr int N = []
{
struct S {
int a[1];
};
S s;
::new (s.a) int[1](); // s.a is converted to the poiner to s.a[0]
return s.a[0];
}();
template
struct tag {};
void unknown(const std::type_info&) noexcept;
int main()
{
unknown(typeid(tag));
}
```
This can be also trigged by the current resolution of [LWG3436](https://cplusplus.github.io/LWG/issue3436) (so labled `c++20`).
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 117254] [libc] rename newhdrgen to just hdrgen
Issue 117254 Summary [libc] rename newhdrgen to just hdrgen Labels libc Assignees Reporter nickdesaulniers Once old hdrgen is deleted (#117208), we should renamed newhdrgen to just hdrgen. This bug can also help us track other todo/related cleanups from the removal of old hdrgen. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 117255] Request Commit Access For @a-tarasyuk
Issue 117255 Summary Request Commit Access For @a-tarasyuk Labels infra:commit-access-request Assignees Reporter a-tarasyuk ### Why Are you requesting commit access? I'm an [open-source enthusiast](https://github.com/a-tarasyuk) with an interest in compilers. Over the past five months as a Clang contributor, I have resolved over [forty issues](https://github.com/llvm/llvm-project/pulls/a-tarasyuk), implementing various fixes and improvements. Gaining commit access would allow me ownership to manage my pull requests more efficiently. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 117273] [DirectX] DXIL Data Scalarization crash
Issue
117273
Summary
[DirectX] DXIL Data Scalarization crash
Labels
backend:DirectX
Assignees
Reporter
llvm-beanz
The following shader to compute a mandelbrot set crashes the DXIL Data Scalarizer:
```hlsl
RWBuffer Tex;
const static float3 Palette[8] = {float3(0.0, 0.0, 0.0), float3(0.5, 0.5, 0.5),
float3(1.0, 0.5, 0.5), float3(0.5, 1.0, 0.5),
float3(0.5, 0.5, 1.0), float3(0.5, 1.0, 1.0),
float3(1.0, 0.5, 1.0), float3(1.0, 1.0, 0.5)};
const static int Dimension = 4096;
[numthreads(1024, 1, 1)] void main(uint3 DID
: SV_DispatchThreadID) {
float scale = 1.5 / pow(2.0, 16.0 * abs(sin(0.25 / 16.0)));
float2 offset = float2(-1.0, 0.0);
uint2 Index =
uint2(DID.x % Dimension, DID.x / Dimension + (Dimension * DID.y));
uint2 DispatchSize = Dimension.xx;
float X0 =
scale * (2.0 * (float)Index.x / (float)DispatchSize.x - 1.5) + offset.x;
float Y0 =
scale * (2.0 * (float)Index.y / (float)DispatchSize.y - 1.0) + offset.y;
// Implement Mandelbrot set
float X = X0;
float Y = Y0;
uint Iteration = 0;
uint MaxIteration = 2000;
float XTmp = 0.0;
bool Diverged = false;
for (; Iteration < MaxIteration; ++Iteration) {
if (X * X + Y * Y > 2000 * 2000) {
Diverged = true;
break;
}
XTmp = X * X - Y * Y + X0;
Y = 2 * X * Y + Y0;
X = XTmp;
}
float3 Color = float3(0, 0, 0);
if (Diverged) {
float Gradient = 1.0;
float Smooth = log2(log2(X * X + Y * Y) / 2.0);
float ColorIdx = sqrt((float)Iteration + 10.0 - Smooth) * Gradient;
float LerpSize = frac(ColorIdx);
LerpSize = LerpSize * LerpSize * (3.0 - 2.0 * LerpSize);
int ColorIdx1 = (int)ColorIdx % 8;
int ColorIdx2 = (ColorIdx1 + 1) % 8;
Color = lerp(Palette[ColorIdx1], Palette[ColorIdx2], LerpSize.xxx);
}
Tex[DID.x] = float4(Color, 1.0);
}
```
Crash backtrace:
```
0. Program arguments: C:\\Users\\cbieneman\\dev\\llvm-project\\llvm\\out\\build\\x64-Clang-Debug\\bin\\clang-dxc.exe -cc1 -triple dxilv1.0-unknown-shadermodel6.0-compute -emit-obj -dumpdir a- -disable-free -clear-ast-before-backend -main-file-name Mandelbrot.hlsl -mrelocation-model static -mframe-pointer=all -fmath-errno -ffp-contract=on -fno-rounding-math -mconstructor-aliases -debugger-tuning=gdb -fdebug-compilation-dir=C:\\Users\\cbieneman\\dev\\llvm-project\\llvm\\out\\build\\x64-Clang-Debug -fcoverage-compilation-dir=C:\\Users\\cbieneman\\dev\\llvm-project\\llvm\\out\\build\\x64-Clang-Debug -resource-dir C:\\Users\\cbieneman\\dev\\llvm-project\\llvm\\out\\build\\x64-Clang-Debug\\lib\\clang\\20 -O3 -ferror-limit 19 -fmessage-length=350 -O3 -finclude-default-header -fgnuc-version=4.2.1 -fskip-odr-check-in-gmf -fcolor-diagnostics -vectorize-loops -vectorize-slp -o mandelbrot.yaml -x hlsl C:\\Users\\cbieneman\\dev\\hlsl-test-suite\\test\\Basic\\Inputs\\Mandelbrot.hlsl
1. parser at end of file
2. Code generation
3. Running pass 'DXIL Data Scalarization' on module 'C:\Users\cbieneman\dev\hlsl-test-suite\test\Basic\Inputs\Mandelbrot.hlsl'.
Exception Code: 0xC005
#0 0x7ff735544409 llvm::Value::getValueID(void) const C:\Users\cbieneman\dev\llvm-project\llvm\include\llvm\IR\Value.h:533:0
#1 0x7ff73556dc13 llvm::ConstantExpr::classof(class llvm::Value const *) C:\Users\cbieneman\dev\llvm-project\llvm\include\llvm\IR\Constants.h:1385:0
#2 0x7ff7365085d3 llvm::isa_impl::doit(class llvm::User const &) C:\Users\cbieneman\dev\llvm-project\llvm\include\llvm\Support\Casting.h:64:0
#3 0x7ff7367fd679 llvm::isa_impl_cl::doit(class llvm::User const *) C:\Users\cbieneman\dev\llvm-project\llvm\include\llvm\Support\Casting.h:110:0
#4 0x7ff7367fd636 llvm::isa_impl_wrap::doit(class llvm::User const *const &) C:\Users\cbieneman\dev\llvm-project\llvm\include\llvm\Support\Casting.h:137:0
#5 0x7ff7367fd601 llvm::isa_impl_wrap::doit(class llvm::User const *const &) C:\Users\cbieneman\dev\llvm-project\llvm\include\llvm\Support\Casting.h:127:0
#6 0x7ff7367fd5c3 llvm::CastIsPossible::isPossible(class llvm::User const *const &) C:\Users\cbieneman\dev\llvm-project\llvm\include\llvm\Support\Casting.h:255:0
#7 0x7ff7367fd591 llvm::CastInfo::isPossible(class llvm::User *const &) C:\Users\cbieneman\dev\llvm-project\llvm\include\llvm\Support\Casting.h:509:0
#8 0x7ff7367fc583 llvm::isa(class llvm::User *const &) C:\Users\cbieneman\dev\llvm-project\llvm\include\llvm\Support\Casting.h:549:0
#9 0x7ff7367fb947 findAndReplaceVectors C:\Users\cbieneman\dev\llvm-project\llvm\lib\Target\DirectX\DXILDataScalarization.cpp:248:0
#10 0x7ff7367fbb68 DXILDataScalarizationLegacy::runOnModule(class llvm::Module &) C:\Users\cbieneman\dev\llvm-project\llvm\lib\Target\DirectX\DXILDataScalarization.cpp:284:0
#11 0x7ff73594e646 `anonymous namesp
[llvm-bugs] [Bug 117281] [mlir] Transform dialect interpreter crashed on unregistered ops
Issue
117281
Summary
[mlir] Transform dialect interpreter crashed on unregistered ops
Labels
mlir,
mlir:transform_dialect
Assignees
Reporter
kuhar
Repro:
```mlir
// RUN: mlir-opt %s --transform-interpreter --allow-unregistered-dialect
module @named attributes { transform.with_named_sequence } {
transform.named_sequence @__transform_main(%arg0: !transform.any_op {transform.readonly}) -> () {
"test.op_a"() : () -> ()
transform.yield
}
}
```
Error message:
```
mlir-opt: /home/jakub/iree/iree/third_party/llvm-project/llvm/include/llvm/Support/Casting.h:572: decltype(auto) llvm::cast(From &) [To = mlir::transform
::TransformOpInterface, From = mlir::Operation]: Assertion `isa(Val) && "cast() argument of incompatible type!"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0. Program arguments: llvm-project/bin/mlir-opt /home/jakub/iree/iree/compiler/src/iree/compiler/Codegen/Common/test/link_transform_named_sequences.
mlir --transform-interpreter --allow-unregistered-dialect
#0 0x641bfd1562be llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /home/jakub/iree/iree/third_party/llvm-project/llvm/lib/Support/Unix/Signals.i
nc:723:13
#1 0x641bfd154595 llvm::sys::RunSignalHandlers() /home/jakub/iree/iree/third_party/llvm-project/llvm/lib/Support/Signals.cpp:106:18
#2 0x641bfd15699d SignalHandler(int) /home/jakub/iree/iree/third_party/llvm-project/llvm/lib/Support/Unix/Signals.inc:413:1
#3 0x7620e1442520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#4 0x7620e14969fc __pthread_kill_implementation ./nptl/pthread_kill.c:44:76
#5 0x7620e14969fc __pthread_kill_internal ./nptl/pthread_kill.c:78:10
#6 0x7620e14969fc pthread_kill ./nptl/pthread_kill.c:89:10
#7 0x7620e1442476 gsignal ./signal/../sysdeps/posix/raise.c:27:6
#8 0x7620e14287f3 abort ./stdlib/abort.c:81:7
#9 0x7620e142871b _nl_load_domain ./intl/loadmsgcat.c:1177:9
#10 0x7620e1439e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96)
#11 0x641bff2385ca mlir::detail::Interface, mlir::OpTrait::TraitBase>::Interface(mlir::Operation*) /home/jakub/iree/iree/third_party/ll
vm-project/mlir/include/mlir/Support/InterfaceSupport.h:97:5
#12 0x641bff2385ca mlir::OpInterface::OpInterfac
e(mlir::Operation*) /home/jakub/iree/iree/third_party/llvm-project/mlir/include/mlir/IR/OpDefinition.h:2086:24
#13 0x641bff2385ca mlir::transform::TransformOpInterface::TransformOpInterface(mlir::Operation*) /home/jakub/iree/build/relass/llvm-project/tools/mli
r/include/mlir/Dialect/Transform/Interfaces/TransformInterfaces.h.inc:50:97
#14 0x641bff2385ca llvm::CastInfo::doCast(mlir::Operation&) /home/jakub/iree/iree/third
_party/llvm-project/mlir/include/mlir/IR/Operation.h:1125:52
#15 0x641bff2385ca decltype(auto) llvm::cast(mlir::Operation&) /home/jakub/iree/iree/third_party/llvm-project/llvm/include/llvm/Support/Casting.h:573:10
#16 0x641bff2385ca applySequenceBlock(mlir::Block&, mlir::transform::FailurePropagationMode, mlir::transform::TransformState&, mlir::transform::TransformResults&) /home/jakub/iree/iree/third_party/llvm-project/mlir/lib/Dialect/Transform/IR/TransformOps.cpp:1786:30
#17 0x641bff23c06e mlir::transform::NamedSequenceOp::apply(mlir::transform::TransformRewriter&, mlir::transform::TransformResults&, mlir::transform::TransformState&) /home/jakub/iree/iree/third_party/llvm-project/mlir/lib/Dialect/Transform/IR/TransformOps.cpp:0:10
#18 0x641bff1ea512 mlir::transform::detail::TransformOpInterfaceInterfaceTraits::Model::apply(mlir::transform::detail::TransformOpInterfaceInterfaceTraits::Concept const*, mlir::Operation*, mlir::transform::TransformRewriter&, mlir::transform::TransformResults&, mlir::transform::TransformState&) /home/jakub/iree/build/relass/llvm-project/tools/mlir/include/mlir/Dialect/Transform/Interfaces/TransformInterfaces.h.inc:477:3
#19 0x641bff9d0303 mlir::transform::TransformState::applyTransform(mlir::transform::TransformOpInterface) /home/jakub/iree/iree/third_party/llvm-project/mlir/lib/Dialect/Transform/Interfaces/TransformInterfaces.cpp:952:3
#20 0x641bff9dad61 mlir::transform::applyTransforms(mlir::Operation*, mlir::transform::TransformOpInterface, mlir::RaggedArray> const&, mlir::transform::TransformOptions const&, bool, llvm::function_ref, llvm::function_ref) /home/jakub/iree/iree/third_party/llvm-project/mlir/lib/Dialect/Transform/Interfaces/TransformInterfaces.cpp:2018:39
#21 0x641bff26b828 mlir::transform::applyTransformNamedSequence(mlir::RaggedArray>, mlir::transform::TransformOpInterface, mlir::ModuleOp, mlir::transform::TransformOptions const&) /home/jakub/iree/iree/third_party/llvm-project/mlir/lib/Dialect/Transform/T
[llvm-bugs] [Bug 117297] [flang] Incorrect preprocesor output
Issue
117297
Summary
[flang] Incorrect preprocesor output
Labels
flang
Assignees
Reporter
shivaramaarao
for the following program:
#define NOCOMMENT
NOCOMMENTCALL myfunc( 'hello ' // &
NOCOMMENT'world' //
NOCOMMENT'again' )
The correct preprocessor output is
CALL myfunc( 'hello ' // &
'world' //
'again' )
flang is not able to scan this code and gives following error
flang -E -ffree-form x1.F
error: Could not scan x1.F
./x1.F:2:25: error: Unmatched '('
NOCOMMENTCALL myfunc( 'hello ' // &
^
./x1.F:4:22: error: Unmatched ')'
NOCOMMENT'again' )
^
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 117230] clang-analyzer-alpha.cplusplus.DeleteWithNonVirtualDtor does not handle indirection through base pointer
Issue
117230
Summary
clang-analyzer-alpha.cplusplus.DeleteWithNonVirtualDtor does not handle indirection through base pointer
Labels
new issue
Assignees
Reporter
tiagomacarios
The following code will trigger clang-analyzer-alpha.cplusplus.DeleteWithNonVirtualDtor
https://godbolt.org/z/7jPa8dr5W
```
#include
struct A {};
struct B : A {
virtual ~B() { std::puts("B dtor"); }
};
struct C : B {
~C() { std::puts("C dtor"); }
};
int main() {
C* c1 = new C{};
C* c2 = nullptr;
A** pp = (A**)&c2; // note: Casting from 'C' to 'A' here
*pp = c1;
delete c2; // warning: Destruction of a polymorphic object with no virtual destructor [clang-analyzer-alpha.cplusplus.DeleteWithNonVirtualDtor]
}
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 117251] [libc][llvm] allocate the LLVM environment type
Issue 117251 Summary [libc][llvm] allocate the LLVM environment type Labels libc Assignees Reporter SchrodingerZhu According to discussion in https://discourse.llvm.org/t/target-triple-of-llvm-libc-environment-component/82845, we should probably allocate the `-llvm` environment type for LLVM(-libc). ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 117264] [clang-tidy] some clang-diagnostic checks are not available.
Issue 117264 Summary [clang-tidy] some clang-diagnostic checks are not available. Labels clang-tidy Assignees Reporter hoyhoy Possibly anything not included by `-Wextra`... Enabling `clang-dianostic-strict-prototypes` can't be enabled in llvm 19.1.4. Even explicitly enabling it with `clang-dianostic-strict-prototypes` doesn't work. Is there some way to enable this manually? Seems like a bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 117206] [X86AsmPrinter] Assertion `!NodePtr->isKnownSentinel()' failed
Issue
117206
Summary
[X86AsmPrinter] Assertion `!NodePtr->isKnownSentinel()' failed
Labels
new issue
Assignees
Reporter
aeubanks
```
$ cat /tmp/a.ll
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-grtev4-linux-gnu"
; Function Attrs: noinline optnone
define void @f() #0 !dbg !3 {
entry:
%0 = call ptr @llvm.returnaddress(i32 0)
br label %do.body
do.body: ; preds = %entry
unreachable
}
; Function Attrs: nocallback nofree nosync nounwind willreturn memory(none)
declare ptr @llvm.returnaddress(i32 immarg) #1
attributes #0 = { noinline optnone "frame-pointer"="all" }
attributes #1 = { nocallback nofree nosync nounwind willreturn memory(none) }
!llvm.dbg.cu = !{!0}
!llvm.module.flags = !{!2}
!0 = distinct !DICompileUnit(language: DW_LANG_C_plus_plus_14, file: !1, producer: "clang", isOptimized: false, runtimeVersion: 0, emissionKind: LineTablesOnly, splitDebugInlining: false, nameTableKind: None)
!1 = !DIFile(filename: "a.c", directory: "/tmp", checksumkind: CSK_MD5, checksum: "e84fa2105300221d1aebb85a89a53960")
!2 = !{i32 2, !"Debug Info Version", i32 3}
!3 = distinct !DISubprogram(name: "f", scope: !1, file: !1, line: 37, type: !4, scopeLine: 37, flags: DIFlagPrototyped, spFlags: DISPFlagLocalToUnit | DISPFlagDefinition, unit: !0)
!4 = !DISubroutineType(types: !5)
!5 = !{}
$ llc -o /dev/null /tmp/a.ll
llc: ../../llvm/include/llvm/ADT/ilist_iterator.h:168: reference llvm::ilist_iterator, false, true>::operator*() const [OptionsT = llvm::ilist_detail::node_options, IsReverse = false, IsConst = true]: Assertion `!NodePtr->isKnownSentinel()' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0. Program arguments: build/rel/bin/llc -o /dev/null /tmp/b.ll
1. Running pass 'Function Pass Manager' on module '/tmp/b.ll'.
2. Running pass 'X86 Assembly Printer' on function '@"_ZZNK3cel11StructValue14GetRuntimeTypeEvENK3$_0clINSt6__tsan9monostateEEENS_10StructTypeERKT_"'
#0 0x56416e8a76a8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) llvm-project/build/rel/../../llvm/lib/Support/Unix/Signals.inc:723:13
#1 0x56416e8a52ee llvm::sys::RunSignalHandlers() llvm-project/build/rel/../../llvm/lib/Support/Signals.cpp:106:18
#2 0x56416e8a7d38 SignalHandler(int) llvm-project/build/rel/../../llvm/lib/Support/Unix/Signals.inc:413:1
#3 0x7fc90b82c1a0 (/lib/x86_64-linux-gnu/libc.so.6+0x3d1a0)
#4 0x7fc90b87a0ec __pthread_kill_implementation ./nptl/pthread_kill.c:44:76
#5 0x7fc90b82c102 gsignal ./signal/../sysdeps/posix/raise.c:27:6
#6 0x7fc90b8154f2 abort ./stdlib/abort.c:81:7
#7 0x7fc90b815415 _nl_load_domain ./intl/loadmsgcat.c:1177:9
#8 0x7fc90b824d32 (/lib/x86_64-linux-gnu/libc.so.6+0x35d32)
#9 0x56416df3bcd2 findPrologueEndLoc llvm-project/build/rel/../../llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp:0:0
#10 0x56416df3bcd2 llvm::DwarfDebug::emitInitialLocDirective(llvm::MachineFunction const&, unsigned int) llvm-project/build/rel/../../llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp:2284:53
#11 0x56416df3d70b llvm::DwarfDebug::beginFunctionImpl(llvm::MachineFunction const*) llvm-project/build/rel/../../llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp:2472:16
#12 0x56416df1493e llvm::AsmPrinter::emitFunctionHeader() llvm-project/build/rel/../../llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp:1057:37
#13 0x56416df1714d llvm::AsmPrinter::emitFunctionBody() llvm-project/build/rel/../../llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp:1768:3
#14 0x56416f98424b llvm::X86AsmPrinter::runOnMachineFunction(llvm::MachineFunction&) llvm-project/build/rel/../../llvm/lib/Target/X86/X86AsmPrinter.cpp:91:3
#15 0x56416dba4137 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) llvm-project/build/rel/../../llvm/lib/CodeGen/MachineFunctionPass.cpp:0:13
#16 0x56416e497e4a llvm::FPPassManager::runOnFunction(llvm::Function&) llvm-project/build/rel/../../llvm/lib/IR/LegacyPassManager.cpp:0:27
#17 0x56416e49f7e2 llvm::FPPassManager::runOnModule(llvm::Module&) llvm-project/build/rel/../../llvm/lib/IR/LegacyPassManager.cpp:1452:13
#18 0x56416e498946 runOnModule llvm-project/build/rel/../../llvm/lib/IR/LegacyPassManager.cpp:1521:27
#19 0x56416e498946 llvm::legacy::PassManagerImpl::run(llvm::Module&) llvm-project/build/rel/../../llvm/lib/IR/LegacyPassManager.cpp:539:44
#20 0x56416d6ddc7e compileModule llvm-project/build/rel/../../llvm/tools/llc/llc.cpp:753:17
#21 0x56416d6ddc7e main llvm-project/build/rel/../../llvm/tools/llc/llc.cpp:411:22
#22 0x7fc90b816b8a __libc_start_call_main ./csu/../sysdeps/nptl/libc_start_call_main.h:74:3
#23 0x7fc90b816c45 call_init ./csu/../csu/libc
[llvm-bugs] [Bug 117208] [libc] delete old hdrgen
Issue 117208 Summary [libc] delete old hdrgen Labels libc Assignees Reporter nickdesaulniers Now that we have newhdrgen, filing a bug to track the removal of the existing hdrgen (couldn't find an existing bug for this; feel free to dupe this to that if it exists). I've moved over the buildbots to use newhdrgen (required resetting buildbot's cmakecache). cc @petrhosek @RoseZhang03 @aaryanshukla ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 117200] fatal error: error in backend: Cannot select: t54: v4f32 = fexp10 t49, ../simde/x86/svml.h:4583:21 @[ ../test/x86/svml.c:15090:21 ]
Issue 117200 Summary fatal error: error in backend: Cannot select: t54: v4f32 = fexp10 t49, ../simde/x86/svml.h:4583:21 @[ ../test/x86/svml.c:15090:21 ] Labels new issue Assignees Reporter Dave-Lowndes The above error occurs building the simd-everywhere project. Hopefully the information you need is recorded here: https://github.com/simd-everywhere/simde/actions/runs/11917581735/job/33213028281?pr=1233#step:8:1067 ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 117209] [libc] ensure libc-riscv32-* are using newhdrgen
Issue 117209 Summary [libc] ensure libc-riscv32-* are using newhdrgen Labels libc Assignees Reporter nickdesaulniers @mikhailramalho Please ensure the following buildbots: 1. libc-riscv32-qemu-debian-dbg 2. libc-riscv32-qemu-yocto-fullbuild-dbg Have the following set in their build/CMakeCache.txt: `LIBC_USE_NEW_HEADER_GEN:BOOL=ON` If they do, no further work is necessary and this issue can be closed. If build/CMakeCache.txt instead has: `LIBC_USE_NEW_HEADER_GEN:BOOL=OFF` Then please `rm build/CMakeCache.txt`. All other buildbots are moved to newhdrgen at this time. I'd like to move them over before we delete the old hdrgen (#117208). --- libc-riscv32-qemu-debian-dbg seems offline; can that bot be deleted? ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 117267] [DirectX] Don't put entry name into string table for PSV0 before v3
Issue 117267 Summary [DirectX] Don't put entry name into string table for PSV0 before v3 Labels new issue, backend:DirectX, HLSL Assignees Reporter llvm-beanz Currently the entry name is added to the PSV0 string table regardless of whether or not we're targeting PSV0 v3 where it is needed. We should correct that to generate PSV matching DXC. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 117221] [MC] Assembly emission removes `.arch`/`.arch_extension` directives
Issue
117221
Summary
[MC] Assembly emission removes `.arch`/`.arch_extension` directives
Labels
new issue
Assignees
Reporter
zyedidia
Here is an example program that uses `.arch` in inline assembly to enable LSE instructions:
```c
int main() {
asm volatile (
".arch armv8-a+lse\n"
"casal x0, x1, [x2]\n"
);
return 0;
}
```
If compiled with `clang -c test.c` it works fine, but if I first emit to assembly and then attempt to compile, it no longer succeeds:
```
$ clang -S test.c
$ clang -c test.s
test.s:14:2: error: instruction requires: lse
casal x0, x1, [x2]
^
```
The generated assembly does not include the `.arch` directive, causing the instruction to be illegal.
```
//APP
casal x0, x1, [x2]
//NO_APP
```
A similar issue exists for `.arch_directive`
Example:
```c
asm volatile (
".arch_extension lse\n"
"casal x0, x1, [x2]\n"
);
```
Thanks!
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 117222] Documentation typo in DestinationStyleOpInterface
Issue
117222
Summary
Documentation typo in DestinationStyleOpInterface
Labels
new issue
Assignees
Reporter
PerMildner
https://github.com/llvm/llvm-project/blob/505e049aa078c8961f00cacefc3983398a46fb04/mlir/include/mlir/Interfaces/DestinationStyleOpInterface.td#L86
Says
```
/// Return the number of DPS inits.
int64_t getNumDpsInputs() {
return $_op->getNumOperands() - $_op.getNumDpsInits();
}
```
but it should say `... DPS inputs.`
It looks like a copy-paste bug from [getNumDpsInits()](https://github.com/llvm/llvm-project/blob/505e049aa078c8961f00cacefc3983398a46fb04/mlir/include/mlir/Interfaces/DestinationStyleOpInterface.td#L72)).
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 117249] ubsan: sub-overflow in gcd after #77747
Issue 117249 Summary ubsan: sub-overflow in gcd after #77747 Labels new issue Assignees Reporter hiraditya With #77747 one of the tests failed with ubsanitized binary. Original stack trace ``` Revision: 'MP1.0' ABI: 'arm64' Timestamp: 2024-11-21 18:06:46.362693790+ Process uptime: 4s Cmdline: system_server pid: 10110, tid: 10299, name: StorageManagerS >>> system_server <<< uid: 1000 tagged_addr_ctrl: 0001 (PR_TAGGED_ADDR_ENABLE) pac_enabled_keys: 000f (PR_PAC_APIAKEY, PR_PAC_APIBKEY, PR_PAC_APDAKEY, PR_PAC_APDBKEY) signal 6 (SIGABRT), code -1 (SI_QUEUE), fault addr Abort message: 'ubsan: sub-overflow by 0x0077deea71e8' x0 x1 283b x2 0006 x3 007384bc6e30 x4 362f2f2f2f2f2f77 x5 362f2f2f2f2f2f77 x6 362f2f2f2f2f2f77 x7 7f7f7f7f7f7f7f7f x8 00f0 x9 4c34f981a6e2fcab x10 0001 x11 0077cbb60390 x12 0001 x13 0012 x14 0010 x15 001e x16 0077cbbca068 x17 0077cbbb3ec0 x18 007379284000 x19 277e x20 283b x21 x22 2e68 x23 0016 x24 2e68 x25 b47596f395f0 x26 x27 001f4000 x28 0016 x29 007384bc6eb0 lr 0077cbb49358 sp 007384bc6e30 pc 0077cbb4937c pst 1000 37 total frames backtrace: #00 pc 0005e37c /apex/com.android.runtime/lib64/bionic/libc.so (abort+156) (BuildId: a0aadb8b9a435cba80682f8ec11369be) #01 pc c208 /system/lib64/libmedia_codeclist_capabilities.so (__ubsan_handle_sub_overflow_minimal_abort+112) (BuildId: 95fc54602b3701495fdf8d22ac7c0587) #02 pc 000271e4 /system/lib64/libmedia_codeclist_capabilities.so (android::VideoCapabilities::applyLevelLimits()+7668) (BuildId: 95fc54602b3701495fdf8d22ac7c0587) #03 pc 000253c0 /system/lib64/libmedia_codeclist_capabilities.so (android::VideoCapabilities::init(std::__1::basic_string, std::__1::allocator>, std::__1::vector>, android::sp const&)+272) (BuildId: 95fc54602b3701495fdf8d22ac7c0587) #04 pc 0002523c /system/lib64/libmedia_codeclist_capabilities.so (android::VideoCapabilities::Create(std::__1::basic_string, std::__1::allocator>, std::__1::vector>, android::sp const&) (.cfi)+268) (BuildId: 95fc54602b3701495fdf8d22ac7c0587) #05 pc 00020d5c /system/lib64/libmedia_codeclist_capabilities.so (android::CodecCapabilities::init(std::__1::vector>, std::__1::vector>, bool, android::sp&, android::sp&, int)+908) (BuildId: 95fc54602b3701495fdf8d22ac7c0587) #06 pc ee9c /system/lib64/libmedia_codeclist.so (android::MediaCodecInfoWriter::BuildCodecCapabilities(char const*, android::sp, bool, int) (.cfi)+1212) (BuildId: a0f243d4bccfcd7d288db72bc3e3500d) ``` Symbolicated trace ```trace Revision: 'MP1.0' ABI: 'arm64' pid: 10110, tid: 10299, name: StorageManagerS >>> system_server <<< signal 6 (SIGABRT), code -1 (SI_QUEUE), fault addr Abort message: 'ubsan: sub-overflow by 0x0077deea71e8' Stack Trace: RELADDR FUNCTION FILE:LINE 0005e37c abort (BuildId: a0aadb8b9a435cba80682f8ec11369be) bionic/libc/bionic/abort.cpp:52:3 (inlined) abort_with_message (BuildId: 95fc54602b3701495fdf8d22ac7c0587) out/lib/compiler-rt-aarch64/out/llvm-project/compiler-rt/lib/ubsan_minimal/ubsan_minimal_handlers.cpp:71:3 c208 __ubsan_handle_sub_overflow_minimal_abort (BuildId: 95fc54602b3701495fdf8d22ac7c0587) out/lib/compiler-rt-aarch64/out/llvm-project/compiler-rt/lib/ubsan_minimal/ubsan_minimal_handlers.cpp:123:1 (inlined) unsigned int std::__1::__gcd(unsigned int, unsigned int) (BuildId: 95fc54602b3701495fdf8d22ac7c0587) prebuilts/clang/host/linux-x86/clang-r536225/include/c++/v1/__numeric/gcd_lcm.h:85:22 (inlined) std::__1::common_type::type std::__1::gcd[abi:nn19](int, int) (BuildId: 95fc54602b3701495fdf8d22ac7c0587) prebuilts/clang/host/linux-x86/clang-r536225/include/c++/v1/__numeric/gcd_lcm.h:106:7 (inlined) android::Rational::Rational(int, int) (BuildId: 95fc54602b3701495fdf8d22ac7c0587) frameworks/av/media/libmedia/include/media/CodecCapabilitiesUtils.h:404:23 000271e4 android::VideoCapabilities::applyLevelLimits() (BuildId: 95fc54602b3701495fdf8d22ac7c0587) frameworks/av/media/libmedia/VideoCapabilities.cpp:1392:0 000253c0 android::VideoCapabilities::init(std::__1::basic_string, std::__1::allocator>, std::__1::vector>, android::sp const&) (BuildId: 95fc54602b3701495fdf8d22ac7c0587) frameworks/av/media/libmedia/VideoCapabilities.cpp:444:5 0002523c android::VideoCapa
