Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>]

Hi Adrian,

On 26/05/2025 17:05, John Paul Adrian Glaubitz 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 tried to patch gcc-13 with this BIGGEST_ALIGNMENT set to 64. I am 
using buildroot+uclibc-ng on a Coldfire (mcf54418).

Everything build fine, except the kernel:

In function ‘siginfo_build_tests’,
    inlined from ‘restore_sigcontext’ at arch/m68k/kernel/signal.c:684:2,
    inlined from ‘do_sigreturn’ at arch/m68k/kernel/signal.c:775:9:
././include/linux/compiler_types.h:542:45: error: call to 
‘__compiletime_assert_351’ declared with attribute error: BUILD_BUG_ON 
failed: offsetof(siginfo_t, si_lower) != 0x12
  542 |         _compiletime_assert(condition, msg, 
__compiletime_assert_, __COUNTER__)
      |                                             ^
././include/linux/compiler_types.h:523:25: note: in definition of macro 
‘__compiletime_assert’
  523 |                         prefix ## suffix(); 
        \
      |                         ^~~~~~
././include/linux/compiler_types.h:542:9: note: in expansion of macro 
‘_compiletime_assert’
  542 |         _compiletime_assert(condition, msg, 
__compiletime_assert_, __COUNTER__)
      |         ^~~~~~~~~~~~~~~~~~~
./include/linux/build_bug.h:39:37: note: in expansion of macro 
‘compiletime_assert’
   39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), 
msg)
      |                                     ^~~~~~~~~~~~~~~~~~
./include/linux/build_bug.h:50:9: note: in expansion of macro 
‘BUILD_BUG_ON_MSG’
   50 |         BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " 
#condition)
      |         ^~~~~~~~~~~~~~~~
arch/m68k/kernel/signal.c:621:9: note: in expansion of macro ‘BUILD_BUG_ON’
  621 |         BUILD_BUG_ON(offsetof(siginfo_t, si_lower) != 0x12);
      |         ^~~~~~~~~~~~
make[5]: *** [scripts/Makefile.build:207: arch/m68k/kernel/signal.o] Error 1
make[4]: *** [scripts/Makefile.build:465: arch/m68k/kernel] Error 2
make[4]: *** Waiting for unfinished jobs....

This is a 6.14.
Any idea about this ?

Thanks,
JM