On Wed, 2019-03-06 at 18:04 -0600, Segher Boessenkool wrote: > Hi! > > On Wed, Mar 06, 2019 at 07:15:54PM +0100, Sébastien Michelland wrote: > > I'm having trouble building programs for a SuperH-4 target without > > FPU. > > > > My current setup uses an sh4eb-nofpu-elf target which usually > > behaves > > very well (much better than sh4eb-elf that uses a lot of fmov for > > optimization), but I discovered that using a va_list causes the > > dreaded, > > illegal fmov instruction to be generated. > > > > I've looked up available options and expected -m4-nofpu to be of > > help, > > however GCC does not agree with this estimation: > > > > sh4eb-nofpu-elf-gcc: error: command line option '-m4-nofpu' is > > not > > supported by this configuration > > > > When building I expected this target to support the option "by > > default". > > I've tried building again and I found no relevant flag, even in > > the > > recursive configure help. > > > > Here is what the compiler looks like in more detail: > > > > Using built-in specs. > > COLLECT_GCC=sh4eb-nofpu-elf-gcc > > > > COLLECT_LTO_WRAPPER=/home/el/opt/sh4eb-nofpu-elf-2.32- > > 8.3.0/libexec/gcc/sh4eb-nofpu-elf/8.3.0/lto-wrapper > > Target: sh4eb-nofpu-elf > > Configured with: ../gcc-8.3.0/configure > > --prefix=/home/el/opt/sh4eb-nofpu-elf-2.32-8.3.0 > > --target=sh4eb-nofpu-elf --enable-languages=c,c++ --without- > > headers > > --with-newlib --disable-nls --disable-werror --enable-libssp -- > > enable-lto > > Thread model: single > > gcc version 8.3.0 (GCC) > > > > How can I fix this setup to generate entirely FPU-free programs? > > There is https://gcc.gnu.org/PR64008 which probably is relevant. > > Configuring with --enable-targets=all will help. > > I use this patch for sh, that may help too: > > diff --git a/gcc/config/sh/sh.h b/gcc/config/sh/sh.h > index 0204872..7f126ce 100644 > --- a/gcc/config/sh/sh.h > +++ b/gcc/config/sh/sh.h > @@ -124,6 +124,9 @@ extern int code_for_indirect_jump_scratch; > #define SUPPORT_SH2A_NOFPU 1 > #endif > #if SUPPORT_SH3 > +#define SUPPORT_SH4 1 > +#endif > +#if SUPPORT_SH4 > #define SUPPORT_SH4_NOFPU 1 > #endif > #if SUPPORT_SH4_NOFPU > Other than that, is "sh4eb-nofpu-elf" actually a valid recognized triplet? Maybe it "works" but does effectively nothing? I don't remember.... In any case, the problem sounds more like a (default) multilib configuration. See also the PR link above and the configuration option --with-multilib-list Cheers, Oleg