Any idea what's going on here? (clang blow-up on Pi3 under 14.1)

From: Karl Denninger <karl_at_denninger.net>
Date: Wed, 26 Jun 2024 22:01:45 UTC
FreeBSD 14.1-STABLE stable/14-n267995-2472e352d80f GENERIC

Environment: Pi3; this code has built without issue for quite some time 
on 13.x.

But check this out on the /same/ physical Pi3 I use for development 
under 14.1:

$ make clean
rm -f *.o hd-mcp hd-mcp.freeware license-server hd-commit
$ make
cc  -g -Wstrict-prototypes -DVERSION=\"8.0.0-LocalAuth\" -c config.c -o 
config.o
cc  -g -Wstrict-prototypes -DVERSION=\"8.0.0-LocalAuth\" -c funcs.c -o 
funcs.o
cc  -g -Wstrict-prototypes -DVERSION=\"8.0.0-LocalAuth\" -c hd-mcp.c -o 
hd-mcp.o
PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and 
include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0.      Program arguments: cc -g -Wstrict-prototypes 
-DVERSION=\"8.0.0-LocalAuth\" -c hd-mcp.c -o hd-mcp.o
1.      <eof> parser at end of file
2.      Code generation
3.      Running pass 'Function Pass Manager' on module 'hd-mcp.c'.
4.      Running pass 'AArch64O0PreLegalizerCombiner' on function 
'@process_unit_get_response'
#0 0x0000000004b17588 (/usr/bin/cc+0x4b17588)
#1 0x0000000004b15650 (/usr/bin/cc+0x4b15650)
#2 0x0000000004ae16a0 (/usr/bin/cc+0x4ae16a0)
#3 0x0000000089b92eb8 (/lib/libthr.so.3+0x2aeb8)
cc: error: clang frontend command failed with exit code 139 (use -v to 
see invocation)
FreeBSD clang version 18.1.6 (https://github.com/llvm/llvm-project.git 
llvmorg-18.1.6-0-g1118c2e05e67)
Target: aarch64-unknown-freebsd14.1
Thread model: posix
InstalledDir: /usr/bin
cc: note: diagnostic msg:
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
cc: note: diagnostic msg: /tmp/hd-mcp-a07b96.c
cc: note: diagnostic msg: /tmp/hd-mcp-a07b96.sh
cc: note: diagnostic msg:

********************
*** Error code 1

Stop.
make: stopped in /data/karl/HD-MCP
$ make
cc  -g -Wstrict-prototypes -DVERSION=\"8.0.0-LocalAuth\" -c hd-mcp.c -o 
hd-mcp.o
cc  -g -Wstrict-prototypes -DVERSION=\"8.0.0-LocalAuth\" -c www.c -o www.o
cc  -g -Wstrict-prototypes -DVERSION=\"8.0.0-LocalAuth\" -c slave.c -o 
slave.o
cc  -g -Wstrict-prototypes -DVERSION=\"8.0.0-LocalAuth\" -c amcrest.c -o 
amcrest.o
cc  -g -Wstrict-prototypes -DVERSION=\"8.0.0-LocalAuth\" -c license.c -o 
license.o
cc  -g -Wstrict-prototypes -DVERSION=\"8.0.0-LocalAuth\" -c z-wave.c -o 
z-wave.o
cc  -g -Wstrict-prototypes -DVERSION=\"8.0.0-LocalAuth\" -c malloc.c -o 
malloc.o
cc  -g -Wstrict-prototypes -DVERSION=\"8.0.0-LocalAuth\" -c 
S0-encryption.c -o S0-encryption.o
PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and 
include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0.      Program arguments: cc -g -Wstrict-prototypes 
-DVERSION=\"8.0.0-LocalAuth\" -c S0-encryption.c -o S0-encryption.o
1.      <eof> parser at end of file
2.      Code generation
3.      Running pass 'Function Pass Manager' on module 'S0-encryption.c'.
4.      Running pass 'AArch64O0PreLegalizerCombiner' on function 
'@decrypt_packet'
#0 0x0000000004b17588 (/usr/bin/cc+0x4b17588)
#1 0x0000000004b15650 (/usr/bin/cc+0x4b15650)
#2 0x0000000004ae16a0 (/usr/bin/cc+0x4ae16a0)
#3 0x0000000089887eb8 (/lib/libthr.so.3+0x2aeb8)
cc: error: clang frontend command failed with exit code 139 (use -v to 
see invocation)
FreeBSD clang version 18.1.6 (https://github.com/llvm/llvm-project.git 
llvmorg-18.1.6-0-g1118c2e05e67)
Target: aarch64-unknown-freebsd14.1
Thread model: posix
InstalledDir: /usr/bin
cc: note: diagnostic msg:
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
cc: note: diagnostic msg: /tmp/S0-encryption-30d26b.c
cc: note: diagnostic msg: /tmp/S0-encryption-30d26b.sh
cc: note: diagnostic msg:

********************
*** Error code 1

Stop.
make: stopped in /data/karl/HD-MCP


Note that the first time it stops in one of the files, hd-mcp.c in the 
function "process_unit_get_response."

But if I invoke "make" again having changed nothing /the same file 
compile succeeds!/

It then fails on a /different /file in the routine "decrypt_packet"; 
that particular source file has only a handful of functions in it and 
I've seen it fail on /different /entries -- it is not always in the same 
place.

Once in a /great /while the entire build will succeed. Note that on the 
/same /Pi3 running 13.1 (which is what I'm using right now in most 
cases, but looking to move to 14.x) the same code builds every time.

I've grabbed a brand-new in-box Pi3 that I have here as a spare - no 
difference - thus I conclude its not the specific hardware that decided 
to take a dump on me without warning.

Now I take the same SD card and stick it in a 4Gb Pi4 and boot that, 
clear the object files (so it has to do the entire thing) and....

root@rpi:~ # su - karl
$ ls
HD-MCP
$ cd HD-MCP
$ make clean
rm -f *.o hd-mcp hd-mcp.freeware license-server hd-commit
$ make
cc  -g -Wstrict-prototypes -DVERSION=\"8.0.0-LocalAuth\" -c config.c -o 
config.o
cc  -g -Wstrict-prototypes -DVERSION=\"8.0.0-LocalAuth\" -c funcs.c -o 
funcs.o
cc  -g -Wstrict-prototypes -DVERSION=\"8.0.0-LocalAuth\" -c hd-mcp.c -o 
hd-mcp.o
cc  -g -Wstrict-prototypes -DVERSION=\"8.0.0-LocalAuth\" -c www.c -o www.o
cc  -g -Wstrict-prototypes -DVERSION=\"8.0.0-LocalAuth\" -c slave.c -o 
slave.o
cc  -g -Wstrict-prototypes -DVERSION=\"8.0.0-LocalAuth\" -c amcrest.c -o 
amcrest.o
cc  -g -Wstrict-prototypes -DVERSION=\"8.0.0-LocalAuth\" -c license.c -o 
license.o
cc  -g -Wstrict-prototypes -DVERSION=\"8.0.0-LocalAuth\" -c z-wave.c -o 
z-wave.o
cc  -g -Wstrict-prototypes -DVERSION=\"8.0.0-LocalAuth\" -c malloc.c -o 
malloc.o
cc  -g -Wstrict-prototypes -DVERSION=\"8.0.0-LocalAuth\" -c 
S0-encryption.c -o S0-encryption.o
cc  -g -Wstrict-prototypes -DVERSION=\"8.0.0-LocalAuth\" -c 
boot-include.c -o boot-include.o
cc  -g -Wstrict-prototypes -DVERSION=\"8.0.0-LocalAuth\" -c 
root-include.c -o root-include.o
cc -g -o hd-mcp hd-mcp.o www.o config.o slave.o amcrest.o license.o 
funcs.o z-wave.o malloc.o S0-encryption.o root-include.o boot-include.o 
-lm -lcrypt -lssl -lpthread -lcrypto -lgpio
cc  -g -Wstrict-prototypes -DVERSION=\"8.0.0-LocalAuth\" -c hd-commit.c 
-o hd-commit.o
cc -g -o hd-commit hd-commit.o
cc  -g -Wstrict-prototypes -DVERSION=\"8.0.0-LocalAuth\" -c 
license-server.c -o license-server.o
cc -g -o license-server license-server.o funcs.o malloc.o -lcrypto -lssl -lm
$

No problem.

Ehhhh.... that does not smell good.

Has anyone seen some sort of problem with 14.x and the Pi3 series CPUs?  
There ARE a LOT of complaints about "clk_fixed...." printed on /both 
/the 3 and 4 during boot (clk_fixed4: clock-fixed has no 
clock-frequency), probably 50 all-in, but other than the complaint 
during the boot it appears to have no other effect and doesn't show up 
again once the system has come up.

The only other complaint of note during the boot is several of these on 
the Pi4 during the boot process :

sdhci_bcm0-slot0: Got command interrupt 0x00030000, but there is no 
active command.
sdhci_bcm0-slot0: ============== REGISTER DUMP ==============
sdhci_bcm0-slot0: Sys addr: 0x00000000 | Version:  0x00009902
sdhci_bcm0-slot0: Blk size: 0x00000000 | Blk cnt:  0x00000000
sdhci_bcm0-slot0: Argument: 0x000001aa | Trn mode: 0x00000000
sdhci_bcm0-slot0: Present:  0x000f0000 | Host ctl: 0x00000001
sdhci_bcm0-slot0: Power:    0x0000000f | Blk gap:  0x00000000
sdhci_bcm0-slot0: Wake-up:  0x00000000 | Clock:    0x00003947
sdhci_bcm0-slot0: Timeout:  0x00000000 | Int stat: 0x00000000
sdhci_bcm0-slot0: Int enab: 0x01ff00bb | Sig enab: 0x01ff00bb
sdhci_bcm0-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000
sdhci_bcm0-slot0: Caps:     0x00000000 | Caps2:    0x00000000
sdhci_bcm0-slot0: Max curr: 0x00000001 | ADMA err: 0x00000000
sdhci_bcm0-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000
sdhci_bcm0-slot0: ===========================================

The complaint asks to submit a bug on the compiler but I suspect this 
isn't the compiler at all, but rather something odd going on related to 
the OS and the CPU instead since the exactly same SD card booted in a 
"4" completes every time and the same code also compiles cleanly without 
problems on the Pi3 under 13.1.

Thanks in advance!

-- 
Karl Denninger
karl@denninger.net
/The Market Ticker/
/[S/MIME encrypted email preferred]/