rorth wrote:
This is certainly a case of unaligned access. In a local build, I've run the
first failing `clang` invocation under `truss` (the Solaris syscall tracer).
For
```
/var/llvm/dist-sparcv9-release-stage2-A-flang-clang18/tools/clang/stage2-bins/bin/clang
-cc1 -internal-isystem
/var/llvm/dist-sparcv9-release-stage2-A-flang-clang18/tools/clang/stage2-bins/lib/clang/19/include
-nostdsysteminc -fmodules -Wno-private-module -fimplicit-module-maps
-fmodules-cache-path=/var/llvm/dist-sparcv9-release-stage2-A-flang-clang18/tools/clang/stage2-bins/tools/clang/test/APINotes/Output/availability.m.tmp/ModulesCache
-fapinotes-modules -fsyntax-only -I
/vol/llvm/src/llvm-project/dist/clang/test/APINotes/Inputs/Headers -F
/vol/llvm/src/llvm-project/dist/clang/test/APINotes/Inputs/Frameworks
/vol/llvm/src/llvm-project/dist/clang/test/APINotes/availability.m -verify
```
this reveals
```
14552: Incurred fault #5, FLTACCESS %pc = 0x1083824E0
14552: siginfo: SIGBUS BUS_ADRALN addr=0xFFFFFFFF7F5E7B6C
14552: Received signal #10, SIGBUS [caught]
14552: siginfo: SIGBUS BUS_ADRALN addr=0xFFFFFFFF7F5E7B6C
```
`gdb` shows exactly that:
```
Thread 2 received signal SIGBUS, Bus error.
[Switching to Thread 1 (LWP 1)]
0x00000001083824e0 in clang::ASTReader::DeclCursorForID(clang::GlobalDeclID,
clang::SourceLocation&) ()
1: x/i $pc
=> 0x1083824e0
<_ZN5clang9ASTReader15DeclCursorForIDENS_12GlobalDeclIDERNS_14SourceLocationE+168>:
ldx [ %i5 + %i1 ], %o2
(gdb) p/x $i5
$1 = 0xffffffff7f5e7b4c
(gdb) p/x $i1
$2 = 0x20
```
The `ldx` insn (Load Extended Word) takes a doubleword address with natural
(64-bit) alignment.
https://github.com/llvm/llvm-project/pull/86912
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
