Hi,
I'm currently testing enabling 4 bytes alignment and first started looking into
what NetBSD does (gcc/config/m68k/linux.h in the GCC source). Surprisingly, this
is set to 64 and not 32 bits for the largest possible alignment.
The explanation is as follows:
/* No data type wants to be aligned rounder than this.
For m68k/SVR4, some types (doubles for example) are aligned on 8 byte
boundaries */
#undef BIGGEST_ALIGNMENT
#define BIGGEST_ALIGNMENT 64
BIGGEST_ALIGNMENT is what's being toggled with the -malign-int option
in gcc/config/m68k/m68k.h:
/* No data type wants to be aligned rounder than this.
Most published ABIs say that ints should be aligned on 16-bit
boundaries, but CPUs with 32-bit busses get better performance
aligned on 32-bit boundaries. */
#define BIGGEST_ALIGNMENT (TARGET_ALIGN_INT ? 32 : 16)
In order to test GCC on Linux/m68k with 32-bit alignment, I just copied
the definitions from netbsd-elf.h into linux.h above which eventually
failed with:
free(): invalid pointer
during GIMPLE pass: slp
../../../../../src/libstdc++-v3/src/c++17/floating_from_chars.cc: In function
'std::from_chars_result std::from_chars(const char*, const char*, double&,
chars_format)':
../../../../../src/libstdc++-v3/src/c++17/floating_from_chars.cc:1243:1:
internal compiler error: Aborted
Now I'm wondering whether why some types on NetBSD such as double have 8 bytes
alignment on a 32-bit system. Does anyone know the reasoning for that?
And does libstdc++ have an additional codepath on NetBSD to deal with the
largest possible alignment to be 8 bytes so that the error above does not
occur?
Or could it just be a result of the ABI mismatch because glibc needs to be
patched as well?
Thanks,
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
