On Mon, May 26, 2025 at 11:05 AM John Paul Adrian Glaubitz <[email protected]> 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
