Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Jeffrey Walton <noloader%gmail.com@localhost>]

On Mon, May 26, 2025 at 11:05 AM John Paul Adrian Glaubitz
<glaubitz%physik.fu-berlin.de@localhost> wrote:
>
> 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?

I don't know about the 64 byte alignment on NetBSD. Maybe it was
copied/pasted/modified from amd64? amd64 has a BIGGEST_ALIGNMENT of 64
due to AVX512. Prior to that, I believe amd64 had a BIGGEST_ALIGNMENT
of 32 due to AVX. (These were due to the aligned loads, like
_mm256_load_epi32 (32-byte requirement) or _mm512_load_epi32 (64-byte
requirement)).

For PowerPC with Altivec, I believe BIGGEST_ALIGNMENT should be 16.

I don't know if __ALTIVEC__ plays a part in BIGGEST_ALIGNMENT. That
is, should BIGGEST_ALIGNMENT be 4 (for int) or 8 (for doubles) unless
__ALTIVEC__ is defined; and if __ALTIVEC__ is defined, then
BIGGEST_ALIGNMENT should be 16.

Jeff