Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>]

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