Re: Detection of hadware feature => please do not use signal

On Mon, Nov 25, 2024 at 9:16 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Anyway, experimentation shows that this gcc version gives the same
> "selected processor lacks an FPU" failure with "-march=armv8-a+crc".
> It will not take "-march=armv8-a+crc+fp", but it will take
> "-march=armv8-a+crc -mfpu=vfpv3"; the same holds for NetBSD 10.0's
> gcc 10.5.0. Possibly other -mfpu settings will work (I recall having
> had success yesterday with -mfpu=neon on NetBSD), but I think this is
> a pretty generic setting: per the gcc docs it corresponds to typical
> armv7 hardware.

LGTM.

It might be slightly more logical to say vfpv4 if that also works,
since armv8 floats are based on vfpf4[1], but it hardly matters given
we're not actually using it... [1] is also where you can read that
software implementation is still technically permitted in armv8
aarch32 state (but not aarch64), even though A profile chips without
it are apparently like unicorns. Anyway, I can't find any evidence
that GCC knows that[2], or changed that deliberately any time
recently, or is out of sync with its own docs, or has local patches in
NetBSD's copy, so yeah, maybe it really is a bug. There was some
recent-ish churn affecting -mfpu and -march interactions[3], maybe
relevant, or not, it beats me.

[1] https://developer.arm.com/documentation/dui0801/l/Overview-of-the-Armv8-Architecture/Floating-point-hardware?lang=en
[2] https://github.com/gcc-mirror/gcc/blob/master/gcc/config/arm/arm-cpus.in#L583
[3] https://sourceware.org/bugzilla/show_bug.cgi?id=28078