[llvm-bugs] [Bug 117306] [x86][MC] Over-decode invalid instruction with mutual exclusive prefix and unmatch opcode
Issue
117306
Summary
[x86][MC] Over-decode invalid instruction with mutual exclusive prefix and unmatch opcode
Labels
new issue
Assignees
Reporter
Mar3yZhang
### Work environment
| Questions | Answers
|--|
| OS/arch/bits | x86_64 Ubuntu 20.04
| Architecture | x86_64
| Source of Capstone | `git clone`, default on `master` branch.
| Version/git commit | llvm-20git, [f08278](https://github.com/llvm/llvm-project/commit/f082782c1b3ec98f50237ddfc92e6776013bf62f)
### minimum disassembler PoC program
```c
int main(int argc, char *argv[]){
/*
some input sanity check of hex string from argv
*/
// Initialize LLVM after input validation
LLVMInitializeAllTargetInfos();
LLVMInitializeAllTargets();
LLVMInitializeAllTargetMCs();
LLVMInitializeAllDisassemblers();
LLVMDisasmContextRef disasm = LLVMCreateDisasm("x86_64", NULL, 0, NULL, NULL);
if (!disasm) {
errx(1, "Error: LLVMCreateDisasm() failed.");
}
// Set disassembler options: print immediates as hex, use Intel syntax
if (!LLVMSetDisasmOptions(disasm, LLVMDisassembler_Option_PrintImmHex |
LLVMDisassembler_Option_AsmPrinterVariant)) {
errx(1, "Error: LLVMSetDisasmOptions() failed.");
}
char output_string[MAX_OUTPUT_LENGTH];
uint64_t address = 0;
size_t instr_len = LLVMDisasmInstruction(disasm, raw_bytes, bytes_len, address,
output_string, sizeof(output_string));
if (instr_len > 0) {
printf("%s\n", output_string);
} else {
printf("Error: Unable to disassemble the input bytes.\n");
}
}
```
### Instruction bytes giving faulty results
```
f2 f0 41 0f b7 d6
```
### Expected results
It should be:
```
Error: Unable to disassemble the input bytes.
```
### Actually results
```sh
$./min_llvm_disassembler "f2f0410fb7d6"
xacquire
```
### Additional Logs, screenshots, source code, configuration dump, ...
This is similar to [a verified bug](https://github.com/capstone-engine/capstone/issues/2547) in the capstone engine. Bytes "f2f0410fb7d6" can not be translated into valid x86 instructions because of mutual exclusive prefixes `f2`, `f0` and LOCK prefix on register operation. But llvm MC accepts it into instruction `xacquire`. All the other instruction decoders like the Capstone, Zydis, and Xed reject the byte sequences. Not sure whether the workaround in this [pull request](https://github.com/llvm/llvm-project/pull/117299) can fix this.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 117304] [x86][MC] Fail to decode some long multi-byte NOPs
Issue
117304
Summary
[x86][MC] Fail to decode some long multi-byte NOPs
Labels
Assignees
Reporter
Mar3yZhang
### Work environment
| Questions| Answers
|--|
| OS/arch/bits | x86_64 Ubuntu 20.04
| Architecture | x86_64
| Source of Capstone | `git clone`, default on `master` branch.
| Version/git commit | llvm-20git, [f08278](https://github.com/llvm/llvm-project/commit/f082782c1b3ec98f50237ddfc92e6776013bf62f)
### minimum disassembler PoC program
```c
int main(int argc, char *argv[]){
/*
some input sanity check of hex string from argv
*/
// Initialize LLVM after input validation
LLVMInitializeAllTargetInfos();
LLVMInitializeAllTargets();
LLVMInitializeAllTargetMCs();
LLVMInitializeAllDisassemblers();
LLVMDisasmContextRef disasm = LLVMCreateDisasm("x86_64", NULL, 0, NULL, NULL);
if (!disasm) {
errx(1, "Error: LLVMCreateDisasm() failed.");
}
// Set disassembler options: print immediates as hex, use Intel syntax
if (!LLVMSetDisasmOptions(disasm, LLVMDisassembler_Option_PrintImmHex |
LLVMDisassembler_Option_AsmPrinterVariant)) {
errx(1, "Error: LLVMSetDisasmOptions() failed.");
}
char output_string[MAX_OUTPUT_LENGTH];
uint64_t address = 0;
size_t instr_len = LLVMDisasmInstruction(disasm, raw_bytes, bytes_len, address,
output_string, sizeof(output_string));
if (instr_len > 0) {
printf("%s\n", output_string);
} else {
printf("Error: Unable to disassemble the input bytes.\n");
}
}
```
### Instruction bytes giving faulty results
```
0f 1a de
```
### Expected results
It should be:
```
nop esi, ebx
```
### Actually results
```sh
$./min_llvm_disassembler "0f1ade"
Error: Unable to disassemble the input bytes.
```
### Other cases seem to work
```sh
$./min_llvm_disassembler "0f1f00"
nop dword ptr [rax]
```
### Additional Logs, screenshots, source code, configuration dump, ...
Instructions with opcodes ranging from `0f 18` to `0f 1f` are defined as multi-byte NOP (No Operation) instructions in x86 ISA. Please refer to the [StackOverflow post](https://stackoverflow.com/questions/25545470/long-multi-byte-nops-commonly-understood-macros-or-other-notation) for more details. It should be decoded in the following logic.
- "0x0f 0x1a" is extended opcode.
- The ModR/M byte DE translates to binary 1100 (0xde).
- Bits 7-6 (Mod): 11 (binary) = 3 (decimal)
Indicates register-direct addressing mode.
- Bits 5-3 (Reg): 011 (binary) = 3 (decimal)
Corresponds to the EBX (or RBX in 64-bit mode) register.
- Bits 2-0 (R/M): 110 (binary) = 6 (decimal)
Corresponds to the ESI (or RSI in 64-bit mode) register.
XED also translates "0f 1a de" into "nop esi, ebx".
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 117319] [libc++] libc++ doesn't compile with gcc 15
Issue 117319 Summary [libc++] libc++ doesn't compile with gcc 15 Labels libc++ Assignees Reporter killcerr libc++ doesn't compile with GCC 15 because it comes with new GCC ```__decay``` built-in which is incompatible with libc++. [similar issue](https://github.com/llvm/llvm-project/issues/91831) [the bug file](https://github.com/llvm/llvm-project/blob/main/libcxx/include/__type_traits/decay.h#L28) ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 117308] Crash on wasm-ld (failed Received SIGSEGV (-11))
Issue 117308 Summary Crash on wasm-ld (failed Received SIGSEGV (-11)) Labels Assignees Reporter yogisalomo I came across this error when trying to build wasm artifact of [this repository](https://github.com/daquexian/onnx-simplifier) ( branch `v0.4.36` ) using ninja. The `emsdk` version that I used was 3.1.72. ``` : && /home/yogisalomo/emsdk/upstream/emscripten/em++ -O3 -DNDEBUG -s ALLOW_MEMORY_GROWTH=1 -s EXIT_RUNTIME=1 -s FORCE_FILESYSTEM=1 -s MODULARIZE=1 -s 'EXPORT_NAME="create_onnxsim"' -s 'EXPORTED_RUNTIME_METHODS=[FS,ccall,cwrap,callMain]' -s EXPORTED_FUNCTIONS=[_main] CMakeFiles/onnxsim_bin.dir/onnxsim/bin/onnxsim_bin.cpp.o CMakeFiles/onnxsim_bin.dir/onnxsim/bin/onnxsim_option.cpp.o -o onnxsim.js libonnxsim.a third_party/onnx-optimizer/libonnx_optimizer.a libonnxruntime_webassembly.a && : PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. Stack dump: 0. Program arguments: /home/yogisalomo/emsdk/upstream/bin/wasm-ld -o onnxsim.wasm -L/home/yogisalomo/emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten CMakeFiles/onnxsim_bin.dir/onnxsim/bin/onnxsim_bin.cpp.o CMakeFiles/onnxsim_bin.dir/onnxsim/bin/onnxsim_option.cpp.o libonnxsim.a third_party/onnx-optimizer/libonnx_optimizer.a libonnxruntime_webassembly.a -lGL-getprocaddr -lal -lhtml5 -lstubs -lc -ldlmalloc -lcompiler_rt -lc++-noexcept -lc++abi-noexcept -lsockets -mllvm -combiner-global-alias-analysis=false -mllvm -enable-emscripten-sjlj -mllvm -disable-lsr /tmp/tmpuew4mr6alibemscripten_js_symbols.so --strip-debug --export=_emscripten_stack_alloc --export=__get_temp_ret --export=__set_temp_ret --export=__funcs_on_exit --export=__wasm_call_ctors --export=emscripten_stack_get_current --export=_emscripten_stack_restore --export-if-defined=__start_em_asm --export-if-defined=__stop_em_asm --export-if-defined=__start_em_lib_deps --export-if-defined=__stop_em_lib_deps --export-if-defined=__start_em_js --export-if-defined=__stop_em_js --export-if-defined=main --export-if-defined=__main_argc_argv --export-if-defined=fflush --export-table -z stack-size=65536 --max-memory=2147483648 --initial-heap=16777216 --no-entry --table-base=1 --global-base=1024 1. Running pass "cgscc(function-attrs)" on module "ld-temp.o" #0 0x5a6692b63088 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/home/yogisalomo/emsdk/upstream/bin/wasm-ld+0x1083088) #1 0x5a6692b603ee llvm::sys::RunSignalHandlers() (/home/yogisalomo/emsdk/upstream/bin/wasm-ld+0x10803ee) #2 0x5a6692b63c7f SignalHandler(int) Signals.cpp:0:0 #3 0x79f165242520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520) #4 0x5a66941e9d3c checkFunctionMemoryAccess(llvm::Function&, bool, llvm::AAResults&, llvm::SmallSetVector const&) (.llvm.13958950707188126733) FunctionAttrs.cpp:0:0 #5 0x5a66941eb09a llvm::SmallSet> deriveAttrsInPostOrder&, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&)::$_0&>(llvm::ArrayRef, llvm::PostOrderFunctionAttrsPass::run(llvm::LazyCallGraph::SCC&, llvm::AnalysisManager&, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&)::$_0&, bool) FunctionAttrs.cpp:0:0 #6 0x5a66941ea819 llvm::PostOrderFunctionAttrsPass::run(llvm::LazyCallGraph::SCC&, llvm::AnalysisManager&, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&) (/home/yogisalomo/emsdk/upstream/bin/wasm-ld+0x270a819) #7 0x5a6693a8370d llvm::detail::PassModel, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&>::run(llvm::LazyCallGraph::SCC&, llvm::AnalysisManager&, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&) PassBuilder.cpp:0:0 #8 0x5a6694de42f3 llvm::ModuleToPostOrderCGSCCPassAdaptor::run(llvm::Module&, llvm::AnalysisManager&) (/home/yogisalomo/emsdk/upstream/bin/wasm-ld+0x33042f3) #9 0x5a6693a605fd llvm::detail::PassModel>::run(llvm::Module&, llvm::AnalysisManager&) PassBuilder.cpp:0:0 #10 0x5a6695695c9a llvm::PassManager>::run(llvm::Module&, llvm::AnalysisManager&) (/home/yogisalomo/emsdk/upstream/bin/wasm-ld+0x3bb5c9a) #11 0x5a66939ba386 llvm::lto::opt(llvm::lto::Config const&, llvm::TargetMachine*, unsigned int, llvm::Module&, bool, llvm::ModuleSummaryIndex*, llvm::ModuleSummaryIndex const*, std::__2::vector> const&) (/home/yogisalomo/emsdk/upstream/bin/wasm-ld+0x1eda386) #12 0x5a66939bc7e3 llvm::lto::backend(llvm::lto::Config const&, std::__2::function>> (unsigned int, llvm::Twine const&)>, unsigned int, llvm::Module&, llvm::ModuleSummaryIndex&) (/home/yogisalomo/emsdk/upstream/bin/wasm-ld+0x1edc7e3) #13 0x5a66939a602f llvm::lto::LTO::runRegularLTO(std::__2::function>> (unsigned int, llvm::Twine const&)>) (/home/yogisalomo/emsdk/upstream/bin/wasm-ld+0x1ec602f) #14 0x5a66939a52ad llvm::lto::LTO::run(std::__2::function>> (unsigned int, llvm::Twine const&)>, llvm::FileCache) (/home/yogisalomo/emsdk/upstream/bin/wasm-
[llvm-bugs] [Bug 117317] Clang emits wrong (escaped) path in preprocessor+assembler output on Windows
Issue
117317
Summary
Clang emits wrong (escaped) path in preprocessor+assembler output on Windows
Labels
debuginfo,
platform:windows
Assignees
Reporter
aykevl
Take this very simple assembly file:
```asm
foobar:
nop
```
If I compile without the preprocessor, the `DW_AT_decl_file` under `DW_TAG_label` looks more or less correct:
```
$ clang -g --target=thumbv6m-unknown-unknown-eabi -c -o tmp/test.o "C:\Users\Ayke\src\tinygo\tinygo\tmp\test.s"
$ llvm-dwarfdump tmp/test.o
tmp/test.o: file format elf32-littlearm
.debug_info contents:
0x: Compile Unit: length = 0x006c, format = DWARF32, version = 0x0005, unit_type = DW_UT_compile, abbr_offset = 0x, addr_size = 0x04 (next unit at 0x0070)
0x000c: DW_TAG_compile_unit
DW_AT_stmt_list (0x)
DW_AT_low_pc (0x)
DW_AT_high_pc (0x0002)
DW_AT_name("tmp\\test.s")
DW_AT_comp_dir ("C:\\Users\\Ayke\\src\\tinygo\\tinygo")
DW_AT_producer("clang version 19.1.4")
DW_AT_language (DW_LANG_Mips_Assembler)
0x005b: DW_TAG_label
DW_AT_name ("foobar")
DW_AT_decl_file ("C:\Users\Ayke\src\tinygo\tinygo/tmp\test.s")
DW_AT_decl_line (1)
DW_AT_low_pc (0x)
0x006f: NULL
```
(There's a forward slash there for some reason, but that's not what this bug is about).
But when I compile with the preprocessor enabled (note `test.S` instead of `test.s`), the `DW_AT_decl_file` path seems to be escaped:
```
$ ~/scoop/apps/llvm/current/bin/clang -g --target=thumbv6m-unknown-unknown-eabi -c -o tmp/test.o "C:\Users\Ayke\src\tinygo\tinygo\tmp\test.S"
$ llvm-dwarfdump tmp/test.o
tmp/test.o: file format elf32-littlearm
.debug_info contents:
0x: Compile Unit: length = 0x0093, format = DWARF32, version = 0x0005, unit_type = DW_UT_compile, abbr_offset = 0x, addr_size = 0x04 (next unit at 0x0097)
0x000c: DW_TAG_compile_unit
DW_AT_stmt_list (0x)
DW_AT_low_pc (0x)
DW_AT_high_pc (0x0002)
DW_AT_name ("C:UsersAykesrctinygotinygotmptest.S")
DW_AT_comp_dir ("C:\\Users\\Ayke\\src\\tinygo\\tinygo")
DW_AT_producer("clang version 19.1.4")
DW_AT_language (DW_LANG_Mips_Assembler)
0x0082: DW_TAG_label
DW_AT_name ("foobar")
DW_AT_decl_file ("C:\\Users\\Ayke\\src\\tinygo\\tinygo\\tmp\\test.S")
DW_AT_decl_line (8)
DW_AT_low_pc (0x)
0x0096: NULL
```
Also, the `DW_AT_name` even looks double-escaped!
This is my Clang version:
```
$ clang --version
clang version 19.1.4
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Users\Ayke\scoop\apps\llvm\19.1.4\bin
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 117318] [LSR][SCEV] Increses register spilling in 503.bwaves_r (SPEC CPU 2017)
Issue
117318
Summary
[LSR][SCEV] Increses register spilling in 503.bwaves_r (SPEC CPU 2017)
Labels
loopoptim,
performance,
llvm:SCEV
Assignees
Reporter
yus3710-fj
This issue became apparent with #110063.
LSR increses register spilling, causing a performance regression on 503.bwaves_r in SPEC2017. The regression is eliminated when the option `-disable-lsr` is enabled. This looks similar to #60325, but the root cause may differ.
Minimal reproducer: https://godbolt.org/z/Y46xsvjK8
The code above shows the state before the patch, and the code below shows the state after the patch. (Please note that the patch is only related to the frontend.) Register spilling occurs only after the patch. The difference between the two IRs is as follows:
```diff
35,36c35,36
< %21 = srem i32 %20, %9
< %22 = add i32 %21, 1
---
> %21 = urem i32 %20, %9
> %22 = add nuw i32 %21, 1
61,62c61,62
< %40 = srem i32 %39, %8
< %41 = add i32 %40, 1
---
> %40 = urem i32 %39, %8
> %41 = add nuw i32 %40, 1
```
FYI: The original Fortran code of the reproducer is the following.
```fortran
function repro(x,nb,nx,ny)
implicit none
integer nb,nx,ny,i,j,m,l,im1,ip1,jm1,jp1
real(8) x(nb,nx,ny),repro
repro = 0.0
do j=1,ny
jm1 = mod(j-2,ny) + 1
jp1 = mod(j,ny) + 1
do i=1,nx
im1 = mod(i-2,nx) + 1
ip1 = mod(i,nx) + 1
do l=1,nb
! added "llvm.loop.unroll.disable" metadata manually
do m=1,nb
repro = repro &
+ x(m,ip1,j) + x(m,i,jp1) + x(m,i,j) + x(m,im1,j) + x(m,i,jm1)
end do
end do
end do
end do
end function
```
---
I think there are two possible causes for this issue. Perhaps, this issue would be resolved by either of them. (I'm not familiar with LSR pass, so any comments are welcome.)
One is about the baseline cost. The baseline cost seems to be calculated based on Formulae that consume more registers than original code. For example, Formula correspoing to the address of `x(m,i,j)` is `reg({{{%0,+,(8 * (zext i32 (0 smax %5) to i64) * (zext i32 (0 smax %8) to i64))}<%19>,+,(8 * (zext i32 (0 smax %5) to i64))}<%38>,+,8}<%57>)` in the beginning. However, Formula reflecting the original code strictly would be `reg(%0) + 8*reg({0,+,((zext i32 (0 smax %5) to i64) * (zext i32 (0 smax %8) to i64))}<%19>) + 8*reg({0,+,(zext i32 (0 smax %5) to i64)}<%38>) + 8*reg({0,+,1}<%57>)`. (If I make mistakes, please correct me.) The baseline cost is calculated using the former. This leads to optimizations that increase register spilling being preferentially selected.
The other is related to the analysis for `SCEVUDivExpr`. `urem %a, %b` is interpreted as `(add (mul -1, (mul (udiv %a, %b), %b), %a)` by SCEV. On the other hand, `srem` and `sdiv` are ignored by SCEV. SCEV which have `udiv` operations aren't optimized considering zero division. The following is the debug message.
```
After generating reuse formulae:
LSR is examining the following uses:
:
LSR Use: Kind=Address of double in addrspace(0), Offsets={0}, widest fixup type: ptr
reg({{((8 * (zext i32 (0 smax %5) to i64) * (zext i32 (0 smax %8) to i64) * (-1 + (sext i32 ((-1 * ({1,+,1}<%19> /u %9) * %9) + {2,+,1}<%19>) to i64))) + %0),+,(8 * (zext i32 (0 smax %5) to i64))}<%38>,+,8}<%57>)
LSR Use: Kind=Address of double in addrspace(0), Offsets={0}, widest fixup type: ptr
reg({((8 * (zext i32 (0 smax %5) to i64) * (-1 + (sext i32 ((-1 * ({1,+,1}<%38> /u %8) * %8) + {2,+,1}<%38>) to i64))) + {%0,+,(8 * (zext i32 (0 smax %5) to i64) * (zext i32 (0 smax %8) to i64))}<%19>),+,8}<%57>)
```
Translating Formulae is necessary to find other Formulae which can save the number of registers, but it doesn't work.
Actually, it is obvious that zero division never happens in this case. When I tried removing the check below experimentally, the problematic optimization was improved.
https://github.com/llvm/llvm-project/blob/dde9477d8c0b85d445f10b08b0120f3d361cb77f/llvm/lib/Transforms/Utils/ScalarEvolutionExpander.cpp#L2332-L2337
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 117316] False "GCC compatibility" warnings?
Issue 117316 Summary False "GCC compatibility" warnings? Labels new issue Assignees Reporter cmorve-te Not sure if there is a problem here. But I don't have time to look further, and probably better to get somebody to double check. In https://github.com/llvm/llvm-project/blob/063a6f70a6e86deb81fe6b1f24fecb7774d8cb44/clang/utils/TableGen/ClangDiagnosticsEmitter.cpp#L1972, it seems to default to use "This diagnostic flag exists for GCC compatibility, and has no effect in Clang." in some situations. I don't fully understand the details, but I have observed a few warnings with this message in the documentation that I don't think gcc ever had. So sure, [-Wabi](https://clang.llvm.org/docs/DiagnosticsReference.html#wabi) may be there for [gcc compatibility](https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wabi). It was there even in the [clang 4.0.0 documentation](https://releases.llvm.org/4.0.0/tools/clang/docs/DiagnosticsReference.html#wabi). But then you get things as [-Wexport-unnamed](http://clang.llvm.org/docs/DiagnosticsReference.html#wexport-unnamed). Which, - I can't find in any version of the gcc documentation. - Was documented as a normal, valid, warning in the clang [16.0.0 documentation](https://releases.llvm.org/16.0.0/tools/clang/docs/DiagnosticsReference.html#wexport-unnamed). -Wexport-unnamed was removed in https://github.com/llvm/llvm-project/commit/e5c7904fa0bfa5a24f192cfa7b9116560e1f5d43, which just says "This patch removes these diagnostics". It doesn't say anything about being kept as a flag for GCC compatibility. Is it possible some warnings have not been properly removed, and ended up marked as "for GCC compatibility" incorrectly? If so, I can list the following suspects (there may be more, specially if removed recently): - https://clang.llvm.org/docs/DiagnosticsReference.html#wauto-import was https://releases.llvm.org/14.0.0/tools/clang/docs/DiagnosticsReference.html#wauto-import - http://clang.llvm.org/docs/DiagnosticsReference.html#wexport-unnamed was https://releases.llvm.org/16.0.0/tools/clang/docs/DiagnosticsReference.html#wexport-unnamed - https://clang.llvm.org/docs/DiagnosticsReference.html#wgnu-empty-initializer was https://releases.llvm.org/16.0.0/tools/clang/docs/DiagnosticsReference.html#wgnu-empty-initializer - https://clang.llvm.org/docs/DiagnosticsReference.html#wignored-pragma-optimize was https://releases.llvm.org/14.0.0/tools/clang/docs/DiagnosticsReference.html#wignored-pragma-optimize - https://clang.llvm.org/docs/DiagnosticsReference.html#wreturn-std-move was https://releases.llvm.org/12.0.0/tools/clang/docs/DiagnosticsReference.html#wreturn-std-move - https://clang.llvm.org/docs/DiagnosticsReference.html#wgnu-binary-literal was https://releases.llvm.org/18.1.0/tools/clang/docs/DiagnosticsReference.html#wgnu-binary-literal - https://clang.llvm.org/docs/DiagnosticsReference.html#wgnu-offsetof-extensions was https://releases.llvm.org/18.1.0/tools/clang/docs/DiagnosticsReference.html#wgnu-offsetof-extensions ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 117301] Request Commit Access For ylzsx
Issue 117301 Summary Request Commit Access For ylzsx Labels infra:commit-access-request Assignees Reporter ylzsx ### Why Are you requesting commit access ? Hi, I am a compiler enthusiast and work on LoongArch target. Over the past period of time, I have submitted PRs ([Merged prs](https://github.com/llvm/llvm-project/pulls?q=is%3Apr+author%3Aylzsx+is%3Aclosed) and [Open prs](https://github.com/llvm/llvm-project/pulls/ylzsx)) for llvm and flang. May I request for commit access? Thanks. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 117337] [llvm][Hexagon] Crash in `llvm::DAGTypeLegalizer::PromoteFloatResult()` for `freeze half`
Issue
117337
Summary
[llvm][Hexagon] Crash in `llvm::DAGTypeLegalizer::PromoteFloatResult()` for `freeze half`
Labels
new issue
Assignees
Reporter
alexrp
This is very similar to #107791.
```llvm
define half @freeze_half_poison(half %maybe.poison) {
%y1 = freeze half %maybe.poison
%t1 = fadd half %y1, %y1
ret half %t1
}
```
```console
❯ llc --version | head -n2
LLVM (http://llvm.org/):
LLVM version 19.1.2
❯ llc test.ll -mtriple hexagon-linux
PromoteFloatResult #0: t5: f16 = freeze t4
LLVM ERROR: Do not know how to promote this operator's result!
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0. Program arguments: llc test.ll -mtriple hexagon-linux
1. Running pass 'Function Pass Manager' on module 'test.ll'.
2. Running pass 'Hexagon DAG->DAG Pattern Instruction Selection' on function '@freeze_half_poison'
#0 0x7c530544faa2 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /home/alexrp/Source/llvm-project/llvm/lib/Support/Unix/Signals.inc:727:3
#1 0x7c530544d40f llvm::sys::RunSignalHandlers() /home/alexrp/Source/llvm-project/llvm/lib/Support/Signals.cpp:105:20
#2 0x7c530544d7a6 SignalHandler(int) /home/alexrp/Source/llvm-project/llvm/lib/Support/Unix/Signals.inc:413:1
#3 0x7c5303e42990 (/lib/x86_64-linux-gnu/libc.so.6+0x42990)
#4 0x7c5303e99a1b __pthread_kill_implementation ./nptl/pthread_kill.c:44:76
#5 0x7c5303e99a1b __pthread_kill_internal ./nptl/pthread_kill.c:78:10
#6 0x7c5303e99a1b pthread_kill ./nptl/pthread_kill.c:89:10
#7 0x7c5303e428e6 gsignal ./signal/../sysdeps/posix/raise.c:27:6
#8 0x7c5303e268b7 abort ./stdlib/abort.c:81:7
#9 0x7c5305180c78 std::__cxx11::basic_string, std::allocator>::_M_replace(unsigned long, unsigned long, char const*, unsigned long) /usr/include/c++/13/bits/basic_string.tcc:540:21
#10 0x7c5305180c78 std::__cxx11::basic_string, std::allocator>::assign(char const*) (.isra.0.cold) /usr/include/c++/13/bits/basic_string.h:1672:19
#11 0x7c530536fa05 (/opt/llvm-19/bin/../lib/libLLVM.so.19.1+0xd6fa05)
#12 0x7c5305e7cd2e llvm::DAGTypeLegalizer::PromoteFloatResult(llvm::SDNode*, unsigned int) /home/alexrp/Source/llvm-project/llvm/lib/CodeGen/SelectionDAG/LegalizeFloatTypes.cpp:2588:25
#13 0x7c5305ebee8f llvm::DAGTypeLegalizer::run() /home/alexrp/Source/llvm-project/llvm/lib/CodeGen/SelectionDAG/LegalizeTypes.cpp:291:14
#14 0x7c5305ec00f4 llvm::SelectionDAG::LegalizeTypes() /home/alexrp/Source/llvm-project/llvm/lib/CodeGen/SelectionDAG/LegalizeTypes.cpp:1057:10
#15 0x7c5306031313 llvm::TimeRegion::~TimeRegion() /home/alexrp/Source/llvm-project/llvm/include/llvm/Support/Timer.h:155:9
#16 0x7c5306031313 llvm::NamedRegionTimer::~NamedRegionTimer() /home/alexrp/Source/llvm-project/llvm/include/llvm/Support/Timer.h:163:8
#17 0x7c5306031313 llvm::SelectionDAGISel::CodeGenAndEmitDAG() /home/alexrp/Source/llvm-project/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:954:3
#18 0x7c5306035d20 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) /home/alexrp/Source/llvm-project/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:1868:33
#19 0x7c53060375fc llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) /home/alexrp/Source/llvm-project/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:632:22
#20 0x7c5308bdca94 llvm::HexagonDAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&) /home/alexrp/Source/llvm-project/llvm/lib/Target/Hexagon/HexagonISelDAGToDAG.h:47:17
#21 0x7c5306022b77 llvm::OptLevelChanger::~OptLevelChanger() /home/alexrp/Source/llvm-project/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:268:11
#22 0x7c5306022b77 llvm::SelectionDAGISelLegacy::runOnMachineFunction(llvm::MachineFunction&) /home/alexrp/Source/llvm-project/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:375:1
#23 0x7c5306022b77 llvm::SelectionDAGISelLegacy::runOnMachineFunction(llvm::MachineFunction&) /home/alexrp/Source/llvm-project/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:346:6
#24 0x7c5305996e7f llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (.part.0) /home/alexrp/Source/llvm-project/llvm/lib/CodeGen/MachineFunctionPass.cpp:94:33
#25 0x7c530560d687 llvm::FPPassManager::runOnFunction(llvm::Function&) /home/alexrp/Source/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1450:7
#26 0x7c530560d8c1 llvm::ilist_detail::node_base_prevnext, true>::getNext() const /home/alexrp/Source/llvm-project/llvm/include/llvm/ADT/ilist_node_base.h:42:38
#27 0x7c530560d8c1 llvm::ilist_node_impl>::getNext() /home/alexrp/Source/llvm-project/llvm/include/llvm/ADT/ilist_node.h:117:66
#28 0x7c530560d8c1 llvm::ilist_iterator, false, false>::oper
[llvm-bugs] [Bug 117385] Assertion failure with `if consteval` + `-Wconsumed`
Issue
117385
Summary
Assertion failure with `if consteval` + `-Wconsumed`
Labels
new issue
Assignees
Reporter
davidstone
The following valid translation unit:
```c++
void f() {
if consteval {
}
}
```
when compiled with `-std=c++23 -Wconsumed` causes clang to fail with
```console
clang++: /root/llvm-project/llvm/include/llvm/Support/Casting.h:662: decltype(auto) llvm::dyn_cast(From*) [with To = clang::ExprWithCleanups; From = const clang::Expr]: Assertion `detail::isPresent(Val) && "dyn_cast on a non-existent value"' 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 -std=c++23 -Wconsumed
1. parser at end of file
2. :1:10: parsing function body 'f'
#0 0x03bfabd8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x3bfabd8)
#1 0x03bf88dc llvm::sys::CleanupOnSignal(unsigned long) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x3bf88dc)
#2 0x03b45fc8 CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0
#3 0x7e7b14e42520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#4 0x7e7b14e969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
#5 0x7e7b14e42476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
#6 0x7e7b14e287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
#7 0x7e7b14e2871b (/lib/x86_64-linux-gnu/libc.so.6+0x2871b)
#8 0x7e7b14e39e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96)
#9 0x071bfed4 clang::consumed::ConsumedStmtVisitor::getInfo(clang::Expr const*) const (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x71bfed4)
#10 0x071c5327 clang::consumed::ConsumedAnalyzer::splitState(clang::CFGBlock const*, clang::consumed::ConsumedStmtVisitor const&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x71c5327)
#11 0x071ca1be clang::consumed::ConsumedAnalyzer::run(clang::AnalysisDeclContext&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x71ca1be)
#12 0x07132088 clang::sema::AnalysisBasedWarnings::IssueWarnings(clang::sema::AnalysisBasedWarnings::Policy, clang::sema::FunctionScopeInfo*, clang::Decl const*, clang::QualType) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x7132088)
#13 0x0669a286 clang::Sema::PopFunctionScopeInfo(clang::sema::AnalysisBasedWarnings::Policy const*, clang::Decl const*, clang::QualType) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x669a286)
#14 0x068b72f0 clang::Sema::ActOnFinishFunctionBody(clang::Decl*, clang::Stmt*, bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x68b72f0)
#15 0x0661e68f clang::Parser::ParseFunctionStatementBody(clang::Decl*, clang::Parser::ParseScope&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x661e68f)
#16 0x06531f03 clang::Parser::ParseFunctionDefinition(clang::ParsingDeclarator&, clang::Parser::ParsedTemplateInfo const&, clang::Parser::LateParsedAttrList*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6531f03)
#17 0x065666bd clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, clang::DeclaratorContext, clang::ParsedAttributes&, clang::Parser::ParsedTemplateInfo&, clang::SourceLocation*, clang::Parser::ForRangeInit*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x65666bd)
#18 0x06525c4e clang::Parser::ParseDeclOrFunctionDefInternal(clang::ParsedAttributes&, clang::ParsedAttributes&, clang::ParsingDeclSpec&, clang::AccessSpecifier) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6525c4e)
#19 0x0652640e clang::Parser::ParseDeclarationOrFunctionDefinition(clang::ParsedAttributes&, clang::ParsedAttributes&, clang::ParsingDeclSpec*, clang::AccessSpecifier) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x652640e)
#20 0x0652dba3 clang::Parser::ParseExternalDeclaration(clang::ParsedAttributes&, clang::ParsedAttributes&, clang::ParsingDeclSpec*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x652dba3)
#21 0x0652ea8d clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&, clang::Sema::ModuleImportState&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x652ea8d)
#22 0x0652ef30 clang::Parser::ParseFirstTopLevelDecl(clang::OpaquePtr&, clang::Sema::ModuleImportState&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x652ef30)
#23 0x06520f72 c
[llvm-bugs] [Bug 117369] [Clang][OpenMP] Weak alias fails on OpenMP targets
Issue
117369
Summary
[Clang][OpenMP] Weak alias fails on OpenMP targets
Labels
Assignees
Reporter
Jason-VanBeusekom
Reproducer test file:
```
int __One(void) { return 1; }
int One(void) __attribute__ ((weak, alias("__One")));
int main(){
return One();
}
```
When compiling:
```
clang -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa test.c
test.c:3:37: error: alias must point to a defined variable or function
3 | int One(void) __attribute__ ((weak, alias("__One")));
| ^
test.c:3:37: note: the function or variable specified in an alias must refer to its mangled name
test.c:3:37: note: function by that name is mangled as "__One"
3 | int One(void) __attribute__ ((weak, alias("__One")));
| ^~
| alias("__One")
test.c:3:37: error: alias must point to a defined variable or function
3 | int One(void) __attribute__ ((weak, alias("__One")));
| ^
test.c:3:37: note: the function or variable specified in an alias must refer to its mangled name
test.c:3:37: note: function by that name is mangled as "__One"
3 | int One(void) __attribute__ ((weak, alias("__One")));
| ^~
| alias("__One")
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: /ptmp2/vanbeuse-ptmp2/clang_install/bin/clang-20 -cc1 -triple amdgcn-amd-amdhsa -aux-triple x86_64-unknown-linux-gnu -Werror=atomic-alignment -emit-llvm-bc -emit-llvm-uselists -dumpdir a- -disable-free -clear-ast-before-backend -main-file-name test.c -mrelocation-model pic -pic-level 2 -fhalf-no-semantic-interposition -mframe-pointer=all -ffp-contract=on -fno-rounding-math -mconstructor-aliases -mlink-builtin-bitcode /opt/rocm-6.2.0/amdgcn/bitcode/ocml.bc -mlink-builtin-bitcode /opt/rocm-6.2.0/amdgcn/bitcode/oclc_daz_opt_off.bc -mlink-builtin-bitcode /opt/rocm-6.2.0/amdgcn/bitcode/oclc_unsafe_math_off.bc -mlink-builtin-bitcode /opt/rocm-6.2.0/amdgcn/bitcode/oclc_finite_only_off.bc -mlink-builtin-bitcode /opt/rocm-6.2.0/amdgcn/bitcode/oclc_correctly_rounded_sqrt_on.bc -mlink-builtin-bitcode /opt/rocm-6.2.0/amdgcn/bitcode/oclc_wavefrontsize64_on.bc -mlink-builtin-bitcode /opt/rocm-6.2.0/amdgcn/bitcode/oclc_isa_version_908.bc -mlink-builtin-bitcode /opt/rocm-6.2.0/amdgcn/bitcode/oclc_abi_version_500.bc -target-cpu gfx908 -debugger-tuning=gdb -fdebug-compilation-dir=/ptmp2/vanbeuse-ptmp2/CAST-30331 -resource-dir /ptmp2/vanbeuse-ptmp2/clang_install/lib/clang/20 -internal-isystem /ptmp2/vanbeuse-ptmp2/clang_install/lib/clang/20/include/openmp_wrappers -include __clang_openmp_device_functions.h -internal-isystem /ptmp2/vanbeuse-ptmp2/clang_install/lib/clang/20/include/llvm_libc_wrappers -internal-isystem /ptmp2/vanbeuse-ptmp2/clang_install/lib/clang/20/include -internal-isystem /usr/local/include -internal-isystem /usr/lib64/gcc/x86_64-suse-linux/13/../../../../x86_64-suse-linux/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -internal-isystem /ptmp2/vanbeuse-ptmp2/clang_install/lib/clang/20/include -internal-isystem /usr/local/include -internal-isystem /usr/lib64/gcc/x86_64-suse-linux/13/../../../../x86_64-suse-linux/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -ferror-limit 19 -fvisibility=protected -fopenmp -fgnuc-version=4.2.1 -fskip-odr-check-in-gmf -fcolor-diagnostics -fopenmp-is-target-device -fopenmp-host-ir-file-path /tmp/test-3dcfd8.bc -faddrsig -o /tmp/test-223d72.bc -x c test.c
1. parser at end of file
2. Per-file LLVM IR generation
#0 0x7fe39a249c1d llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /ptmp2/vanbeuse-ptmp2/llvm-project/llvm/lib/Support/Unix/Signals.inc:723:11
#1 0x7fe39a24a0db PrintStackTraceSignalHandler(void*) /ptmp2/vanbeuse-ptmp2/llvm-project/llvm/lib/Support/Unix/Signals.inc:798:1
#2 0x7fe39a24827f llvm::sys::RunSignalHandlers() /ptmp2/vanbeuse-ptmp2/llvm-project/llvm/lib/Support/Signals.cpp:105:5
#3 0x7fe39a24a7ae SignalHandler(int) /ptmp2/vanbeuse-ptmp2/llvm-project/llvm/lib/Support/Unix/Signals.inc:413:1
#4 0x7fe397a3fdc0 __restore_rt (/lib64/libc.so.6+0x4adc0)
#5 0x7fe3a1efe2fc llvm::Value::getType() const /ptmp2/vanbeuse-ptmp2/llvm-project/llvm/include/llvm/IR/Value.h:255:34
#6 0x7fe3a1f8bff5 llvm::GlobalValue::getType() const /ptmp2/vanbeuse-ptmp2/llvm-project/llvm/include/llvm/IR/GlobalValue.h:294:65
#7 0x7fe3a287ddbc clang::CodeGen::CodeGenModule::checkAliases() /ptmp2/vanbeuse-ptmp2/llvm-project/clang/lib/CodeGen/CodeGenModule.cpp:736:61
#8 0x7fe3a287f0bc clang::CodeGen::CodeGenModule::Release() /ptmp2/vanbeuse-ptmp2/llvm-project/clang/lib/CodeGen/CodeGenModule.cpp:898:3
#9 0x7fe3a2a652dd (anonymous namespace)::Co
[llvm-bugs] [Bug 117372] [Flang] Failed to compile CHARACTER type declaration statement for array
Issue 117372 Summary [Flang] Failed to compile CHARACTER type declaration statement for array Labels bug, flang:frontend Assignees Reporter DanielCChen Flang failed to compile the following code ``` character cv3*(3)(3) end >flang-new -ffree-form ch1.f error: Could not parse ch1.f ./ch1.f:1:18: error: expected end of statement character cc*(3)(3) ^ ./ch1.f:1:1: in the context: specification construct character cc*(3)(3) ^ ./ch1.f:1:1: in the context: declaration construct character cc*(3)(3) ^ ./ch1.f:1:1: in the context: specification part character cc*(3)(3) ^ ./ch1.f:1:1: in the context: main program character cc*(3)(3) ^ ``` gfortran issues an error also. XLF and ifort both compile it successfully. The code seems standard conforming to me. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 117360] Swap ports 10 and 11 in Golden Cover Scheduler Models
Issue 117360 Summary Swap ports 10 and 11 in Golden Cover Scheduler Models Labels backend:X86 Scheduler Models Assignees boomanaiden154 Reporter boomanaiden154 The documentation is incorrect according to https://github.com/intel/perfmon/issues/149. We should update our scheduling models to be consistent with all the other tools. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 117327] ThreadElfCore.h: fails to build with `error: static assertion failed due to requirement`
Issue 117327 Summary ThreadElfCore.h: fails to build with `error: static assertion failed due to requirement` Labels lldb, build-problem Assignees Reporter sylvestre on linux i386: ``` FAILED: tools/lldb/source/Plugins/Process/elf-core/CMakeFiles/lldbPluginProcessElfCore.dir/ThreadElfCore.cpp.o /opt/sccache//sccache /build/source/build-llvm/./bin/clang++ -DHAVE_ROUND -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -D_LARGEFILE_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/Process/elf-core -I/build/source/lldb/source/Plugins/Process/elf-core -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.11 -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 -fstack-protector-strong -Wformat -Werror=format-security -Wno-unused-command-line-argument -Wdate-time -D_FORTIFY_SOURCE=2 -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 -fno-exceptions -funwind-tables -std=c++17 -MD -MT tools/lldb/source/Plugins/Process/elf-core/CMakeFiles/lldbPluginProcessElfCore.dir/ThreadElfCore.cpp.o -MF tools/lldb/source/Plugins/Process/elf-core/CMakeFiles/lldbPluginProcessElfCore.dir/ThreadElfCore.cpp.o.d -o tools/lldb/source/Plugins/Process/elf-core/CMakeFiles/lldbPluginProcessElfCore.dir/ThreadElfCore.cpp.o -c /build/source/lldb/source/Plugins/Process/elf-core/ThreadElfCore.cpp In file included from /build/source/lldb/source/Plugins/Process/elf-core/ThreadElfCore.cpp:44: /build/source/lldb/source/Plugins/Process/elf-core/ThreadElfCore.h:120:15: error: static assertion failed due to requirement 'sizeof(ELFLinuxSigInfo) == 56': sizeof ELFLinuxSigInfo is not correct! 120 | static_assert(sizeof(ELFLinuxSigInfo) == 56, | ^ /build/source/lldb/source/Plugins/Process/elf-core/ThreadElfCore.h:120:39: note: _expression_ evaluates to '44 == 56' 120 | static_assert(sizeof(ELFLinuxSigInfo) == 56, | ^ 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 117389] [MLIR] mlir-translate emits global struct init on address of
Issue
117389
Summary
[MLIR] mlir-translate emits global struct init on address of
Labels
mlir
Assignees
Reporter
Jezurko
I have tested this on llvm 18 and 19.
For each function where `addressof` is generated for a global variable of struct type, mlir-translate also generates the body of the init region of the struct.
Take this program:
```
struct MyStruct {
char f0[20];
int f1;
int* f2;
};
int x, y;
struct MyStruct global = {"abcdefg", 20, &x};
int foo(struct MyStruct *S) {
return &global == S;
}
int main() {
int x = foo(&global);
struct MyStruct *P = &global;
return 0;
}
```
emitting LLVM IR with clang produces following code:
```
; ModuleID = 'experiment.c'
source_filename = "experiment.c"
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-solus-linux"
%struct.MyStruct = type { [20 x i8], i32, ptr }
@x = dso_local global i32 0, align 4
@global = dso_local global %struct.MyStruct { [20 x i8] c"abcdefg\00\00\00\00\00\00\00\00\00\00\00\00\00", i32 20, ptr @x }, align 8
@y = dso_local global i32 0, align 4
; Function Attrs: noinline nounwind optnone sspstrong uwtable
define dso_local i32 @foo(ptr noundef %0) #0 {
%2 = alloca ptr, align 8
store ptr %0, ptr %2, align 8
%3 = load ptr, ptr %2, align 8
%4 = icmp eq ptr @global, %3
%5 = zext i1 %4 to i32
ret i32 %5
}
; Function Attrs: noinline nounwind optnone sspstrong uwtable
define dso_local i32 @main() #0 {
%1 = alloca i32, align 4
%2 = alloca i32, align 4
%3 = alloca ptr, align 8
store i32 0, ptr %1, align 4
%4 = call i32 @foo(ptr noundef @global)
store i32 %4, ptr %2, align 4
store ptr @global, ptr %3, align 8
ret i32 0
}
attributes #0 = { noinline nounwind optnone sspstrong uwtable "frame-pointer"="all" "min-legal-vector-width"="0" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+cmov,+cx8,+fxsr,+mmx,+sse,+sse2,+x87" "tune-cpu"="generic" }
!llvm.module.flags = !{!0, !1, !2, !3, !4}
!llvm.ident = !{!5}
!0 = !{i32 1, !"wchar_size", i32 4}
!1 = !{i32 8, !"PIC Level", i32 2}
!2 = !{i32 7, !"PIE Level", i32 2}
!3 = !{i32 7, !"uwtable", i32 2}
!4 = !{i32 7, !"frame-pointer", i32 2}
!5 = !{!"clang version 18.1.8"}
```
Which is okay.
Loading this into mlir using `mlir-translate -import-llvm` produces following code:
```
module attributes {dlti.dl_spec = #dlti.dl_spec<#dlti.dl_entry : vector<2xi64>>, #dlti.dl_entry : vector<2xi64>>, #dlti.dl_entry : vector<4xi64>>, #dlti.dl_entry : vector<2xi64>>, #dlti.dl_entry : vector<2xi64>>, #dlti.dl_entry : vector<2xi64>>, #dlti.dl_entry : vector<2xi64>>, #dlti.dl_entry : vector<2xi64>>, #dlti.dl_entry, dense<64> : vector<4xi64>>, #dlti.dl_entry : vector<2xi64>>, #dlti.dl_entry, dense<32> : vector<4xi64>>, #dlti.dl_entry : vector<2xi64>>, #dlti.dl_entry, dense<32> : vector<4xi64>>, #dlti.dl_entry : vector<2xi64>>, #dlti.dl_entry<"dlti.endianness", "little">, #dlti.dl_entry<"dlti.stack_alignment", 128 : i64>>} {
llvm.mlir.global external @x(0 : i32) {addr_space = 0 : i32, alignment = 4 : i64, dso_local} : i32
llvm.mlir.global external @global() {addr_space = 0 : i32, alignment = 8 : i64, dso_local} : !llvm.struct<"struct.MyStruct", (array<20 x i8>, i32, ptr)> {
%0 = llvm.mlir.constant(0 : i32) : i32
%1 = llvm.mlir.addressof @x : !llvm.ptr
%2 = llvm.mlir.constant(20 : i32) : i32
%3 = llvm.mlir.constant("abcdefg\00\00\00\00\00\00\00\00\00\00\00\00\00") : !llvm.array<20 x i8>
%4 = llvm.mlir.undef : !llvm.struct<"struct.MyStruct", (array<20 x i8>, i32, ptr)>
%5 = llvm.insertvalue %3, %4[0] : !llvm.struct<"struct.MyStruct", (array<20 x i8>, i32, ptr)>
%6 = llvm.insertvalue %2, %5[1] : !llvm.struct<"struct.MyStruct", (array<20 x i8>, i32, ptr)>
%7 = llvm.insertvalue %1, %6[2] : !llvm.struct<"struct.MyStruct", (array<20 x i8>, i32, ptr)>
llvm.return %7 : !llvm.struct<"struct.MyStruct", (array<20 x i8>, i32, ptr)>
}
llvm.mlir.global external @y(0 : i32) {addr_space = 0 : i32, alignment = 4 : i64, dso_local} : i32
llvm.func @foo(%arg0: !llvm.ptr {llvm.noundef}) -> i32 attributes {frame_pointer = #llvm.framePointerKind, passthrough = ["noinline", "nounwind", "optnone", "sspstrong", ["uwtable", "2"], ["min-legal-vector-width", "0"], ["no-trapping-math", "true"], ["stack-protector-buffer-size", "8"], ["target-cpu", "x86-64"], ["tune-cpu", "generic"]], target_cpu = "x86-64", target_features = #llvm.target_features<["+cmov", "+cx8", "+fxsr", "+mmx", "+sse", "+sse2", "+x87"]>} {
%0 = llvm.mlir.constant(1 : i32) : i32
%1 = llvm.mlir.constant(0 : i32) : i32
%2 = llvm.mlir.addressof @x : !llvm.ptr
%3 = llvm.mlir.constant(20 : i32) : i32
%4 = llvm.mlir.constant("abcdefg\00\00\00\00\0
[llvm-bugs] [Bug 117406] [HLSL] Add concepts to validate raw buffer element types
Issue 117406 Summary [HLSL] Add concepts to validate raw buffer element types Labels new issue Assignees bob80905 Reporter bob80905 Raw buffer resources, like StructuredBuffer, need concept decls so that their element types can be validated. The concepts need to use the negation of the is_intangible builtin, that should be a sufficient condition to impose on element types. Tests need to be added. This issue is resolved when there are tests that show that raw buffers with invalid element types fail at compile time. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 117420] basic SEH test fails
Issue
117420
Summary
basic SEH test fails
Labels
new issue
Assignees
Reporter
jaykrell
```
C:\s>clang --version
swift.org clang version 16.0.0
Target: x86_64-unknown-windows-msvc
Thread model: posix
InstalledDir: C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin
C:\s>type 1.c
int main()
{
__try { *(volatile char*) 0; } __except(1) { return 2; }
}
C:\s>clang-cl 1.c
C:\s>1.exe
C:\s>echo %errorlevel%
-1073741819
```
That is 0xc005 access violation.
This program returns 2 with Visual C++.
Hm not sure about this toolchain, I'll try another later.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 117409] [clang] Function call without comparisons reported as non-constant expression after CWG2765 implementation
Issue
117409
Summary
[clang] Function call without comparisons reported as non-constant _expression_ after CWG2765 implementation
Labels
c++20,
clang:diagnostics,
clang:analysis
Assignees
Reporter
ormris
We're seeing a new diagnostic trigger in an internal test. The diagnostic is implemented in...
```
commit d8a281590311010955c323806fb24fa484376f4d
Author: Richard Smith
Date: Thu Sep 26 15:56:33 2024 -0700
[clang] implement current direction of CWG2765 for string literal comparisons in constant evaluation (#109208)
Track the identity of each string literal object produced by evaluation
with a global version number. Accept comparisons between literals of the
same version, and between literals of different versions that cannot
possibly be placed in overlapping storage. Treat the remaining
comparisons as non-constant.
-
Co-authored-by: Timm Baeder
Co-authored-by: Aaron Ballman
```
Reduced test case below. The test case and CWG document seem to indicate that comparison is the expected use case, but I don't see any comparison operations in the code below. The values returned by the function indicated in the diagnostic are constant as well.
```
template struct g;
template struct g { using e = b; };
template struct l;
template struct l { using e = b; };
template struct ab {
const aa *ac;
ab();
constexpr ab(const aa *k, long) : ac(k) {}
constexpr auto af() { return ac; }
};
constexpr void al(const char *am, ab aj) {
am - aj.af();
}
struct L {
ab bp;
template consteval L(o k) : bp(k) {
al(bp.af(), k);
}
};
template void q(br, L);
template constexpr auto t(const aa (&k)[s]) -> ab {
return {k, s};
}
void e() {
q(0, [] {
struct bx {
constexpr operator ab::e>::e>() { return t(""); }
};
return bx();
}());
}
```
To reproduce:
```
$ clang -std=c++20 test.cpp
test.cpp:12:6: warning: _expression_ result unused [-Wunused-value]
12 | am - aj.af();
| ~~ ^ ~~~
test.cpp:25:8: error: call to consteval function 'L::L' is not a constant _expression_
25 | q(0, [] {
|^
test.cpp:12:6: note: subexpression not valid in a constant _expression_
12 | am - aj.af();
| ~~~^
test.cpp:17:5: note: in call to 'al(&""[0], {&""[0]})'
17 | al(bp.af(), k);
| ^~
test.cpp:25:8: note: in call to 'L({})'
25 | q(0, [] {
|^~~~
26 | struct bx {
| ~~~
27 | constexpr operator ab::e>::e>() { return t(""); }
| ~~
28 | };
| ~~
29 | return bx();
|
30 | }());
| ~~~
1 warning and 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 117393] [SLP, -slp-revec] Assertion `DemandedElts.getBitWidth() == Ty->getNumElements() && "Vector size mismatch"' failed.
Issue 117393 Summary [SLP, -slp-revec] Assertion `DemandedElts.getBitWidth() == Ty->getNumElements() && "Vector size mismatch"' failed. Labels new issue Assignees Reporter JonPsson1 opt -mtriple=systemz-unknown -O3 -o /dev/null -mcpu=z15 ./tc_slp_revec.bc -force-vector-width=4 -slp-revec -disable-licm-promotion ... #10 0x02aa01f3e642 llvm::slpvectorizer::BoUpSLP::reorderGatherNode [tc_slp_revec.tar.gz](https://github.com/user-attachments/files/17877127/tc_slp_revec.tar.gz) @HanKuanChen ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 117425] [warning] Don't report function returns address of local variable
Issue
117425
Summary
[warning] Don't report function returns address of local variable
Labels
new issue
Assignees
Reporter
vfdff
* test: https://gcc.godbolt.org/z/Yz1dTvbhn
```
int *foo() {
int *p = 0;
{
int x = 0;
p = &x;
*p = 42;
}
*p = 42;
return p;
}
```
- I already use -Wall to report all warning, but the **dangling pointer** is not identified by clang
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 117348] wrong value for BOOL_WIDTH
Issue 117348 Summary wrong value for BOOL_WIDTH Labels new issue Assignees Reporter gustedt C23 has a new feature test macro BOOL_WIDTH which is fixed by the standard to the value 1. Clang has it as 8 in v. 14 to 20, gcc has the correct value. Test this by compiling with `-std=c2x` ``` #include static_assert(BOOL_WIDTH == 1); ``` Thanks Jens ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 117323] Allow to pause / resume clangd indexing
Issue 117323 Summary Allow to pause / resume clangd indexing Labels enhancement, clangd Assignees Reporter dnsampaio Hi, frequently while using vscode I get to a point where clangd indexing is running aside a full llvm compilation (such as a 3k files changed after a merge with upstream). Would it be possible to add a pause / resume indexing feature to clangd's vscode plugin? ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 117321] [clang] Immediate invocations in constexpr initailizers are evaluated twice
Issue
117321
Summary
[clang] Immediate invocations in constexpr initailizers are evaluated twice
Labels
clang
Assignees
Reporter
groundswellaudio
It seems that immediate invocations in constexpr initailizers are evaluated twice, once on evaluating the decl, and again on Sema::HandleImmediateInvocations (this doesn't happen if the var is within a consteval function). Strictly speaking, not a defect, but it's kinda wasteful?
```cpp
consteval int foo(int* b) {
return *b; // Evaluation errors are emitted twice
}
constexpr int a = foo(nullptr);
```
https://godbolt.org/z/7ec5bsK9e
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 117333] No clang-scan-deps-19 on ubuntu23.04 after install with llvm.sh
Issue 117333 Summary No clang-scan-deps-19 on ubuntu23.04 after install with llvm.sh Labels new issue Assignees Reporter vrecluse did I miss something? ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 117334] [clang] Static analyzer crash with just core checkers
Issue
117334
Summary
[clang] Static analyzer crash with just core checkers
Labels
clang:static analyzer,
crash
Assignees
Reporter
omern1
https://gcc.godbolt.org/z/aMnzcs6Eb
``` C++
// > clang -O0 -Xclang -analyzer-checker=core -Xclang -analyze ./input.cpp
enum class a { b };
char c[sizeof(a)];
struct {
operator a() { return __builtin_bit_cast(a, c); }
} d;
void e() {
switch (d)
case a::b:
}
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 117332] Possible missed optimization when calling memcpy or memmove in a loop
Issue
117332
Summary
Possible missed optimization when calling memcpy or memmove in a loop
Labels
missed-optimization
Assignees
Reporter
ldionne
I noticed that the following code did not optimize to a single memcpy, unlike I would expect:
```c++
template
void relocate_1(T *first, T *last, T *dest) {
for ( ; first != last; ++first, ++dest) {
std::memcpy((void*)dest, first, sizeof(T));
}
}
```
I would expect this to be equivalent to roughly:
```c++
template
void relocate_2(T *first, T *last, T *dest) {
auto n = last - first;
std::memcpy((void*)dest, first, n);
}
```
Is this a problem with e.g. the lack of knowledge that the `[first, last)` range is all valid? Note that both GCC and Clang fail to perform this optimization.
Godbolt: https://godbolt.org/z/zzdhcKPh4
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 117349] [RISC-V] Assertion `(TLI.getTypeAction(*DAG.getContext(), Op.getValueType()) == TargetLowering::TypeLegal || Op.getOpcode() == ISD::TargetConstant || Op.getOpcode() == ISD::Re
Issue
117349
Summary
[RISC-V] Assertion `(TLI.getTypeAction(*DAG.getContext(), Op.getValueType()) == TargetLowering::TypeLegal || Op.getOpcode() == ISD::TargetConstant || Op.getOpcode() == ISD::Register) && "Unexpected illegal type!"' failed.
Labels
bug,
backend:RISC-V,
rejects-valid
Assignees
Reporter
hvdijk
Please consider this automatically reduced (courtesy of `llvm-reduce`) `tmp.ll`:
```llvm
; ModuleID = 'tmp.bc'
target datalayout = "e-m:e-p:64:64-i64:64-i128:128-n32:64-S128"
target triple = "riscv64-unknown-linux-gnu"
; Function Attrs: nocallback nofree nosync nounwind speculatable willreturn memory(none)
declare half @llvm.ldexp.f16.i32(half, i32) #0
define spir_kernel void @_ZTS6kernelILi4330275EE() #1 {
entry:
call void @_Z17__spirv_ocl_ldexpDv16_DF16_Dv16_i()
ret void
}
; Function Attrs: alwaysinline
define void @_Z17__spirv_ocl_ldexpDv16_DF16_Dv16_i() #2 {
entry:
%args_1 = load <16 x i32>, ptr null, align 64
%0 = extractelement <16 x i32> %args_1, i64 0
%1 = tail call half @llvm.ldexp.f16.i32(half 0xH3C00, i32 %0)
%vecinit4.i21.i24.i.i = insertelement <2 x half> zeroinitializer, half %1, i64 0
%vecinit11.i36.i.i = shufflevector <2 x half> %vecinit4.i21.i24.i.i, <2 x half> zeroinitializer, <4 x i32>
%vecinit9.i.i = shufflevector <4 x half> %vecinit11.i36.i.i, <4 x half> zeroinitializer, <8 x i32>
%vecinit7.i = shufflevector <8 x half> zeroinitializer, <8 x half> %vecinit9.i.i, <16 x i32>
store <16 x half> %vecinit7.i, ptr null, align 32
ret void
}
attributes #0 = { nocallback nofree nosync nounwind speculatable willreturn memory(none) }
attributes #1 = { "target-features"="+64bit,+a,+c,+d,+f,+m,+relax,+zfh,+zfhmin,+zicsr,+zmmul,-b,-e,-h,-shcounterenw,-shgatpa,-shtvala,-shvsatpa,-shvstvala,-shvstvecd,-smaia,-smcdeleg,-smcsrind,-smepmp,-smstateen,-ssaia,-ssccfg,-ssccptr,-sscofpmf,-sscounterenw,-sscsrind,-ssqosid,-ssstateen,-ssstrict,-sstc,-sstvala,-sstvecd,-ssu64xl,-svade,-svadu,-svbare,-svinval,-svnapot,-svpbmt,-v,-xcvalu,-xcvbi,-xcvbitmanip,-xcvelw,-xcvmac,-xcvmem,-xcvsimd,-xsfcease,-xsfvcp,-xsfvfnrclipxfqf,-xsfvfwmaccqqq,-xsfvqmaccdod,-xsfvqmaccqoq,-xsifivecdiscarddlone,-xsifivecflushdlone,-xtheadba,-xtheadbb,-xtheadbs,-xtheadcmo,-xtheadcondmov,-xtheadfmemidx,-xtheadmac,-xtheadmemidx,-xtheadmempair,-xtheadsync,-xtheadvdot,-xventanacondops,-xwchc,-za128rs,-za64rs,-zaamo,-zabha,-zacas,-zalrsc,-zama16b,-zawrs,-zba,-zbb,-zbc,-zbkb,-zbkc,-zbkx,-zbs,-zca,-zcb,-zcd,-zce,-zcf,-zcmop,-zcmp,-zcmt,-zdinx,-zfa,-zfbfmin,-zfinx,-zhinx,-zhinxmin,-zic64b,-zicbom,-zicbop,-zicboz,-ziccamoa,-ziccif,-zicclsm,-ziccrse,-zicntr,-zicond,-zifencei,-zihintntl,-zihintpause,-zihpm,-zimop,-zk,-zkn,-zknd,-zkne,-zknh,-zkr,-zks,-zksed,-zksh,-zkt,-ztso,-zvbb,-zvbc,-zve32f,-zve32x,-zve64d,-zve64f,-zve64x,-zvfbfmin,-zvfbfwma,-zvfh,-zvfhmin,-zvkb,-zvkg,-zvkn,-zvknc,-zvkned,-zvkng,-zvknha,-zvknhb,-zvks,-zvksc,-zvksed,-zvksg,-zvksh,-zvkt,-zvl1024b,-zvl128b,-zvl16384b,-zvl2048b,-zvl256b,-zvl32768b,-zvl32b,-zvl4096b,-zvl512b,-zvl64b,-zvl65536b,-zvl8192b" }
attributes #2 = { alwaysinline }
```
Compiling this with `clang --target=riscv64-linux-gnu -c tmp.ll` results in:
```
clang: /home/harald/llvm-project/main/llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp:969: void {anonymous}::SelectionDAGLegalize::LegalizeOp(llvm::SDNode*): Assertion `(TLI.getTypeAction(*DAG.getContext(), Op.getValueType()) == TargetLowering::TypeLegal || Op.getOpcode() == ISD::TargetConstant || Op.getOpcode() == ISD::Register) && "Unexpected illegal type!"' 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: /home/harald/llvm-project/main/build/aarch64-linux/bin/clang --target=riscv64-linux-gnu -c tmp.ll
1. Code generation
2. Running pass 'Function Pass Manager' on module 'tmp.ll'.
3. Running pass 'RISC-V DAG->DAG Pattern Instruction Selection' on function '@_ZTS6kernelILi4330275EE'
#0 0xe41bf4a86748 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/home/harald/llvm-project/main/build/aarch64-linux/bin/../lib/libLLVM.so.20.0git+0xe86748)
#1 0xe41bf4a84288 llvm::sys::CleanupOnSignal(unsigned long) (/home/harald/llvm-project/main/build/aarch64-linux/bin/../lib/libLLVM.so.20.0git+0xe84288)
#2 0xe41bf4983e3c CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0
#3 0xe41c02d3a8f8 (linux-vdso.so.1+0x8f8)
#4 0xe41bf36c7628 (/lib/aarch64-linux-gnu/libc.so.6+0x87628)
#5 0xe41bf367cb3c raise (/lib/aarch64-linux-gnu/libc.so.6+0x3cb3c)
#6 0xe41bf3667e00 abort (/lib/aarch64-linux-gnu/libc.so.6+0x27e00)
#7 0xe41bf3675cbc (/lib/aarch64-linux-gnu/libc.so.6+0x35cbc)
#8 0xe41bf3675d2c (/lib/aarch64-linux-gnu/libc.so.6+0
