On Fri, 15 Nov 2024, Finn Thain wrote:
On NetBSD/m68k I get,
sizeof(struct baa) == 16
__alignof__(long long) == 8
__alignof__(struct baa) == 8
That makes sense.
Isn't the alignment of a struct the largest alignment of any of its members?
Sometimes...
I think I have a rough idea why i386 is weird here.
It famously can misalign, and it probably loads the
members as two separate dwords, being a 32-bit CPU,
and does not offer atomics for it, and so the initial
psABI decided to do that. Or something. If it helps,
it’s just as weird on MirBSD/i386, where this was no
deliberate decision.
tg@fish:~ $ ./a.out
int s=4 a=4
llong s=8 a=8
baa s=12 a=4
baa.a s=4 a=4 o=0
baa.b s=8 a=4 o=4
vs.
(pbuild22802-bookworm/i386)root@cafe:/tmp# ./a.out
int s=4 a=4
llong s=8 a=8
baa s=12 a=4
baa.a s=4 a=4 o=0
baa.b s=8 a=4 o=4
vs. (Linux/amd64)
tg@x61p:~ $ ./a.out
int s=4 a=4
llong s=8 a=8
baa s=16 a=8
baa.a s=4 a=4 o=0
baa.b s=8 a=8 o=8
But we certainly need to avoid following the other special
case and rather design the post-switch ABI so that it is
as easily handled as any other new ILP32 ABI for another
architecture, when we change it already anyway.
Two questions:
ⓐ if Clang+LLVM doesn’t know -malign-int anyway, and if its
capability to output code for m68k is experimental to
nōnexistent right now, do we even need to take it into
account? Perhaps changing it to always use the new one is good.
ⓑ what does NetBSD do to get the result (considering that
-malign-int supposedly only changes int to 4), patch GCC?
Of particular interest are a couple definitions in…
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/m68k/netbsd-elf.h;h=3d2043bbe7087ac58f0d2c4336734f7a37bba02f;hb=HEAD#l269
… versus the arch defaults in:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/m68k/m68k.h;h=0d57199714361ff9ed7f92ef28e36f71aee326b3;hb=HEAD#l290
With a bit of luck this means that raising BIGGEST_ALIGNMENT
is sufficient to give us 8-octet-aligned doubles and long doubles.
Then we “just” need to raise the other definitions that indicate
16-bit alignment to 32. (TARGET_SHORT is -mshort is I16LP32 and
so doesn’t need consideration for Linux/m68k.)
I’m not sure anything needs to have 128-bit alignment that won’t
explicitly specify that via attributes.
bye,
//mirabilos
--
Yay for having to rewrite other people's Bash scripts because bash
suddenly stopped supporting the bash extensions they make use of
-- Tonnerre Lombard in #nosec
