[Bug 272806] aarch64's -m32 for system-clang uses -target armv4t-unknown-freebsd14.3 instead of -target armv7-unknown-freebsd14.3-gnueabihf (and main [so: 15] as well)
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sun, 17 May 2026 22:18:20 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272806
--- Comment #6 from Mark Millard <marklmi26-fbsd@yahoo.com> ---
(In reply to Mark Linimon from comment #5)
In my main [so: 16] context:
# cc -v -m32 basic_double_use.c
FreeBSD clang version 21.1.8 (https://github.com/llvm/llvm-project.git
llvmorg-21.1.8-0-g2078da43e25a)
Target: arm-unknown-freebsd16.0
Thread model: posix
InstalledDir: /usr/bin
Build config: +assertions
"/usr/bin/cc" -cc1 -triple armv4t-unknown-freebsd16.0 . . .
So: still armv4t-unknown-freebsd16.0 even on main, not
armv7-unknown-freebsd14.0-gnueabihf
However, no more "undefined symbol"s:
# ./a.out
#
But, the two type of builds have lots of differences,
comparing with:
# cc -v -m32 -target armv7-unknown-freebsd16.0-gnueabihf basic_double_use.c
FreeBSD clang version 21.1.8 (https://github.com/llvm/llvm-project.git
llvmorg-21.1.8-0-g2078da43e25a)
Target: armv7-unknown-freebsd16.0-gnueabihf
Thread model: posix
InstalledDir: /usr/bin
Build config: +assertions
"/usr/bin/cc" -cc1 -triple armv7-unknown-freebsd16.0-gnueabihf . . .
. . .
When I looked at the output a.out files via "objdump -x -d"
I found things like: arm4t had a:
.ARM.extab 00000018 000103dc DATA
section that the armv7 build did not. The arm4t one also had
(from a side by side objdunmp -a -d comparison):
00000000 l df *ABS* 00000000 divdf3.c <
000204f8 l .text 00000000 $a <
00020900 l .text 00000000 $d <
000204f8 l F .text 00000410 .hidden __divdf3 <
000204f8 l F .text 00000410 .hidden __aeabi_ddiv <
00000000 l df *ABS* 00000000 muldf3.c <
00020908 l .text 00000000 $a <
00020bf0 l .text 00000000 $d <
00020908 l F .text 000002f0 .hidden __muldf3 <
00020908 l F .text 000002f0 .hidden __aeabi_dmul <
00000000 l df *ABS* 00000000 comparedf2.c <
00020bf8 l .text 00000000 $a <
00020bf8 l F .text 00000090 .hidden __ltdf2 <
00020bf8 l F .text 00000090 .hidden __ledf2 <
00020c88 l F .text 00000088 .hidden __gedf2 <
00020d10 l F .text 00000040 .hidden __unorddf2 <
00020bf8 l F .text 00000090 .hidden __cmpdf2 <
00020bf8 l F .text 00000090 .hidden __eqdf2 <
00020bf8 l F .text 00000090 .hidden __nedf2 <
00020c88 l F .text 00000088 .hidden __gtdf2 <
00020d10 l F .text 00000040 .hidden __aeabi_dcmpun <
The main's were fairly different
(this may not display well here after the Save Changes?):
00020460 <main>: | 000203fc
<main>:
20460: e92d4800 push {r11, lr} | 203fc:
e92d4800 push {r11, lr}
20464: e1a0b00d mov r11, sp | 20400:
e1a0b00d mov r11, sp
20468: e24dd028 sub sp, sp, #40 | 20404:
e24dd018 sub sp, sp, #24
2046c: e3a00000 mov r0, #0 | 20408:
e3a00000 mov r0, #0
20470: e58d000c str r0, [sp, #0xc] | 2040c:
e50b0004 str r0, [r11, #-0x4]
20474: e50b0004 str r0, [r11, #-0x4] | 20410:
eef20b04 vmov.f64 d16, #1.000000e+01
20478: e3a01709 mov r1, #2359296 | 20414:
edcd0b02 vstr d16, [sp, #8]
2047c: e3811101 orr r1, r1, #1073741824 | 20418:
eef20b0a vmov.f64 d16, #1.300000e+01
20480: e50b100c str r1, [r11, #-0xc] | 2041c:
edcd0b00 vstr d16, [sp]
20484: e50b0010 str r0, [r11, #-0x10] | 20420:
eddd0b02 vldr d16, [sp, #8]
20488: e3a0182a mov r1, #2752512 | 20424:
eddd1b00 vldr d17, [sp]
2048c: e3811101 orr r1, r1, #1073741824 | 20428:
ee600ba1 vmul.f64 d16, d16, d17
20490: e58d1014 str r1, [sp, #0x14] | 2042c:
eddd1b00 vldr d17, [sp]
20494: e58d0010 str r0, [sp, #0x10] | 20430:
eddd2b02 vldr d18, [sp, #8]
20498: e51b0010 ldr r0, [r11, #-0x10] | 20434:
eec11ba2 vdiv.f64 d17, d17, d18
2049c: e51b100c ldr r1, [r11, #-0xc] | 20438:
eef40b61 vcmp.f64 d16, d17
204a0: e59d2010 ldr r2, [sp, #0x10] | 2043c:
eef1fa10 vmrs APSR_nzcv, fpscr
204a4: e59d3014 ldr r3, [sp, #0x14] | 20440:
53000001 movwpl r0, #0x1
204a8: eb000116 bl 0x20908 <__muldf3> @ imm | 20444:
e1a0d00b mov sp, r11
204ac: e58d0004 str r0, [sp, #0x4] | 20448:
e8bd8800 pop {r11, pc}
204b0: e58d1008 str r1, [sp, #0x8] <
204b4: e59d0010 ldr r0, [sp, #0x10] <
204b8: e59d1014 ldr r1, [sp, #0x14] <
204bc: e51b2010 ldr r2, [r11, #-0x10] <
204c0: e51b300c ldr r3, [r11, #-0xc] <
204c4: eb00000b bl 0x204f8 <__divdf3> @ imm <
204c8: e1a02000 mov r2, r0 <
204cc: e59d0004 ldr r0, [sp, #0x4] <
204d0: e1a03001 mov r3, r1 <
204d4: e59d1008 ldr r1, [sp, #0x8] <
204d8: eb0001c6 bl 0x20bf8 <__nedf2> @ imm <
204dc: e1a01000 mov r1, r0 <
204e0: e59d000c ldr r0, [sp, #0xc] <
204e4: e3710001 cmn r1, #1 <
204e8: c3a00001 movgt r0, #1 <
204ec: e1a0d00b mov sp, r11 <
204f0: e8bd4800 pop {r11, lr} <
204f4: e12fff1e bx lr <
and so on: The two -m32 target variants:
armv4t-unknown-freebsd16.0
vs.
armv7-unknown-freebsd16.0-gnueabihf
are far from equivalent.
--
You are receiving this mail because:
You are the assignee for the bug.