From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Bastien Roucariès <rouca@debian.org>
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: Detection of hadware feature => please do not use signal
Date: Sun, 24 Nov 2024 18:34:28 -0500
Message-ID: <1216860.1732491268@sss.pgh.pa.us> (raw)
In-Reply-To: <CA+hUKG+CghJfzhsqTwxxfZoMTA0uKtG8ka02Ydba+qbxOCV5nA@mail.gmail.com>
References: <4496616.iHFcN1HehY@portable-bastien>
<af84e934-4e9c-4380-95ee-8921dab1254b@iki.fi>
<1156374.1730396928@sss.pgh.pa.us>
<7ec1c65c-1a28-49a7-af43-f77c260a3df6@iki.fi>
<1292593.1730399134@sss.pgh.pa.us>
<CA+hUKGLRXq0-s0n2=dy_A5iY-Omg628osyJEJMjPQ=6m566UgA@mail.gmail.com>
<707008.1732325995@sss.pgh.pa.us>
<CA+hUKGJPrRow2aiUSK=aep5nyXUaB0gBoDJQKfyCsP=-ivfapg@mail.gmail.com>
<736756.1732341046@sss.pgh.pa.us>
<865773.1732399354@sss.pgh.pa.us>
<CA+hUKGLOh5kr4fvGFnpOq+_QuXErsYRL4kcSpBYqKdQLa3keBw@mail.gmail.com>
<885805.1732406935@sss.pgh.pa.us>
<CA+hUKGKucCptPdnuQtMGpAD3zYTFN0DMpO3D8fDhmuS1c-yBUA@mail.gmail.com>
<1074317.1732479406@sss.pgh.pa.us>
<CA+hUKG+CghJfzhsqTwxxfZoMTA0uKtG8ka02Ydba+qbxOCV5nA@mail.gmail.com>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, thomas.munro@gmail.com, hlinnaka@iki.fi, rouca@debian.org, pgsql-bugs@lists.postgresql.org
Subject: Re: Detection of hadware feature => please do not use signal
In-Reply-To: <1216860.1732491268@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox