Bug#1001314: mozjs78: FTBFS on armhf: '-mfloat-abi=hard': selected architecture lacks an FPU

[Simon McVittie]

The default -march value on Debian armhf is "armv7-a+fp". You should
*NOT* use "armv7-a+vfpv3" as that specifies the version of vfpv3
with 32 double precision registers which is above the Debian baseline.

https://github.com/alexcrichton/cc-rs/commit/b2f6b146b75299c444e05bbde50d03705c7c4b6e
(which I have now applied to the copy of cc-rs in mozjs78) uses
"-march=armv7-a -mfpu=vfpv3-d16", which seems like a plausible encoding of
the minimum spec given in https://wiki.debian.org/ArmHardFloatPort and
https://wiki.debian.org/ArchitectureSpecificsMemo#Architecture_baselines
(ARMv7 with Thumb-2 and VFPv3-D16).

If I understand correctly, VFPv3-D16 refers to the version of vfpv3 with
only 16 registers, which is exactly what our armhf baseline guarantees
(and as you point out, some ARM CPUs with VFPv3 have more registers, but we
require our binaries to assume those extra registers are not available).
Am I getting this right?

(And yes, in answer to the obvious question, it's not ideal that mozjs78
vendors lots of Rust modules, but I'm not aware of a way to un-vendor them
in Mozilla's rather unique build system. Someone who knows Rust and/or mozjs
better is welcome to step in any time.)

smcv

[Wookey]

The result of this change is if you manually set "-march" then it
overrides the built-in defaults for both the CPU and FPU rather than
only overriding the CPU.

OK. That explains some things I've been noticing recently.

The default -march value on Debian armhf is "armv7-a+fp". You should

Shouldn't it be "armv7-a+nosimd+fp", because neon is not assumed to be present on armhf?
All neon code has to be gated on a HWCAP check, so the default should exclude it.

I recently found a case where gcc11 helpfully put a neon optimisation
into the init code of a complilation unit (zeroing variables), which
of course means the program crashes on started on non-neon hardware.
To be fair it only did that with -mfpu=neon set, but I'm not sure that it can't happen with a
default march=armv7-a+fp

OK. I just checked and in fact it doesn't do this optimisation if
built with -march=armv7-a+fp so I guess there is an implicit assumption that everything not listed is disabled?
Do we actually know for sure or shall I try and find out from some compiler engineers?

Wookey