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

Thomas Munro <thomas.munro@gmail.com> writes:
> The GCC docs give only +nofp, not +fp as an option for 32 bit armv8-a
> (that is, under "ARM options", as opposed to "aarch64 options").  But
> I guess GCC is pretty configurable and NetBSD targets some weird
> hardware... as for why it could be like that (if not a mistake), it
> looks like it might be technically possible for armv8 (including -a)
> to lack FP in aarch32 state (unlike aarch64 state), but I went looking
> for real existing 32-bit only armv8 chips lacking FP and found only
> stuff like Cortex M23, and they're using armv8-m (embedded profile,
> lots of other stuff missing or optional).  The weakest 32 bit-only
> armv8-a chip I could find in a quick search was the Cortex A32 but it
> looks like it has FP.  I don't know enough about any of this stuff to
> guess what's going on here.

I'm confused too, because the gcc documentation is quite definite
that -march=armv8-a assumes FP support by default.  It seems like
somebody broke that for no very good reason and didn't bother to
update the docs either.  Maybe it's actually a bug?

Mainline Linux distros like Fedora and Debian seem to have dropped
32-bit ARM altogether, but there's still a build available from
https://www.raspberrypi.com/software/operating-systems/
that says it is based on Debian bookworm.  I installed that on
my RPi4 and found that it has

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/12/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ... --with-arch=armv6+fp --with-float=hard ...
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (Raspbian 12.2.0-14+rpi1) 

So, just like NetBSD's "generic" ARM32 build, they are firmly in
the hard-float camp.  There may be builds out there that will
still work on soft-float ARM, but they've got to be scarce ...
and you'd have to wonder why anybody would be trying to run PG
on such hardware anyway.

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.

I've checked the attached patch on both the raspberrypi system and
NetBSD 10.0.

			regards, tom lane