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

Thomas Munro <thomas.munro@gmail.com> writes:
> On Mon, Nov 25, 2024 at 9:16 AM Tom Lane <tgl@sss.pgh.pa.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...

Yeah, with no FP operations in the files that get compiled with these
flags, it probably doesn't matter.  But gcc 10.5.0 seems happy with
-mfpu=vfpv4, so I'll use that.

> [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.

It's very confusing, especially given this:

$ gcc -march=armv8-a+crc+fp testarm32.c
gcc: error: 'armv8-a' does not support feature 'fp'
gcc: note: valid feature names are: crc simd crypto nocrypto nofp sb predres; did you mean 'nofp'?

If they think that base armv8-a doesn't include FP, why is there a
+nofp option?  But whether it's a bug or somehow intentional, there's
an awful lot of copies of gcc with this behavior, so we need to cope.

I wonder whether "armv8-a" includes FP on aarch64 but not arm32, and
we only did the original testing of f044d71e3 on aarch64.  If so,
it might've been like this all along and we didn't notice.

> There was some
> recent-ish churn affecting -mfpu and -march interactions[3], maybe
> relevant, or not, it beats me.

That looks like incorrect assembly code being emitted.  Our
problem here is much further upstream, ie what compiler flags
are accepted.

			regards, tom lane