[Bug target/117766] Confusion over whether ARM32 -march=armv8-a implies floating point support

2024-11-24 Thread tgl at sss dot pgh.pa.us via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117766 --- Comment #13 from Tom Lane --- After further experimentation, it seems to me that: * There was a behavioral change between gcc 9.3.1 and the later releases I tested. Specifically, in 9.3.1 a -march switch does not override the platform-sele

[Bug target/117766] Confusion over whether ARM32 -march=armv8-a implies floating point support

2024-11-24 Thread tgl at sss dot pgh.pa.us via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117766 --- Comment #12 from Tom Lane --- This does seem like there is some confusion between arm32 and aarch64. Specifically, having +nofp and not +fp makes sense on the aarch64 side. It doesn't make sense for arm32, but nonetheless that's how it's a

[Bug target/117766] Confusion over whether ARM32 -march=armv8-a implies floating point support

2024-11-24 Thread tgl at sss dot pgh.pa.us via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117766 --- Comment #6 from Tom Lane --- Further info: I dug up an ancient Fedora 30 ARM32 system, and it does not exhibit this behavior: $ touch foo.c $ gcc -c -march=armv8-a foo.c [fine] $ gcc -c -march=armv8-a -mfloat-abi=hard foo.c [also fine] Thi

[Bug target/117766] Confusion over whether ARM32 -march=armv8-a implies floating point support

2024-11-24 Thread tgl at sss dot pgh.pa.us via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117766 --- Comment #5 from Tom Lane --- As far as that goes: I don't think there are any armv8-a machines without an FPU, either. The v8a spec technically allows it in 32-bit but not 64-bit mode; but desultory searching doesn't find any examples.

[Bug target/117766] Confusion over whether ARM32 -march=armv8-a implies floating point support

2024-11-24 Thread tgl at sss dot pgh.pa.us via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117766 --- Comment #10 from Tom Lane --- Well, I simplified the report a bit compared to the real use-case. What we actually want to use is "-march=armv8-a+crc" so as to compile hardware CRC instructions (that will be used only if a runtime check veri

[Bug target/117766] Confusion over whether ARM32 -march=armv8-a implies floating point support

2024-11-25 Thread tgl at sss dot pgh.pa.us via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117766 --- Comment #15 from Tom Lane --- (In reply to Richard Earnshaw from comment #14) > GCC implements the following extensions for the v7 architecture: > > +fp - add floating point (as defined by the base architecture) > +simd - add floating point

[Bug c/117766] New: Confusion over whether ARM32 -march=armv8-a implies floating point support

2024-11-24 Thread tgl at sss dot pgh.pa.us via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117766 Bug ID: 117766 Summary: Confusion over whether ARM32 -march=armv8-a implies floating point support Product: gcc Version: 10.5.0 Status: UNCONFIRMED Severity: n

[Bug target/117766] Confusion over whether ARM32 -march=armv8-a implies floating point support

2024-11-24 Thread tgl at sss dot pgh.pa.us via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117766 --- Comment #3 from Tom Lane --- No go on fpu=auto, at least on the NetBSD platform: $ gcc -c -march=armv8-a -mfpu=auto foo.c cc1: error: '-mfloat-abi=hard': selected processor lacks an FPU The simd method does work to stop the error: $ gcc -