On Jun 12, 2019, Alexandre Oliva <ol...@adacore.com> wrote: > I'm looking into a regression between gcc-7 and gcc-8 that causes > compilation with -mfloat-abi=hard to fail on arm-eabi with:
> $ arm-eabi-gcc -c -mfloat-abi=hard t.c > cc1: error: -mfloat-abi=hard: selected processor lacks an FPU > Per the documentation, -mfpu=auto was supposed to be the default, but > the implicit -mcpu=armv7tdmi option from configure_default_options, or > the -march=armv4t derived from it, seems to be taken as choosing to > disable the fpu. Or rather they don't have any fpu-related options, so none of the fpu bits are set, and -mfpu=auto thus necessarily resolves to nofp. What's confusing to me is that specifying -mfpu=vfp is accepted, even though -mcpu=arm7tdmi+vfp isn't, and with that, -mfloat-abi=hard goes through as before. Would it make sense, for backward-compatibility purposes, to implicitly enable vfpv2 for -mfpu=auto, even for CPUs not configured as having an FP option, when given -mfloat-abi=hard? Or is this error introduced in GCC 8.* actually desirable, and requiring an explicit override of -mfpu, say =vfpv2 along for -mfloat-abi=hard, when the default CPU, e.g. arv7tdmi, doesn't have an FP, something that users are expected to do? Thanks in advance, -- Alexandre Oliva, freedom fighter he/him https://FSFLA.org/blogs/lxo Be the change, be Free! FSF Latin America board member GNU Toolchain Engineer Free Software Evangelist Hay que enGNUrecerse, pero sin perder la terGNUra jamás - Che GNUevara
