On ARM an option to -mfpu is auto, this is given when you do: /usr/local/gcc/bin/gcc -mcpu=native -Q --help=target ... Known ARM FPUs (for use with the -mfpu= option): auto crypto-neon-fp-armv8 fp-armv8 fpv4-sp-d16 fpv5-d16 fpv5-sp-d16 neon neon-fp-armv8 neon-fp16 neon-vfpv3 neon-vfpv4 vfp vfp3 vfpv2 vfpv3 vfpv3-d16 vfpv3-d16-fp16 vfpv3-fp16 vfpv3xd vfpv3xd-fp16 vfpv4 vfpv4-d16 If you try: /usr/local/gcc/bin/gcc -mcpu=native -mfpu=auto -Q --help=target You get: -mfpu= auto But if you try to use it: gcc -march=native -mcpu=native -mtune=native -mfpu=auto -Ofast -o matrix matrix.c You get: cc1: error: -mfloat-abi=hard: selected processor lacks an FPU which isn't true as: gcc -march=native -mcpu=native -mtune=native -mfpu=neon -Ofast -o matrix matrix.c works as does -mfpu=vfpv3-d16 etc This is true on: armv7l and armv6l at least, tested on: ODROID-XU3: (ARM big/little Cortex-A15/A7) Raspbery Pi B: (ARM ARM1176) Raspberry Pi 2B v1: (ARM Cortex-A7) Raspberry Pi 3B: (ARM Cortex-A53)
This was tested using: /usr/local/gcc/bin/gcc -v Using built-in specs. COLLECT_GCC=/usr/local/gcc/bin/gcc COLLECT_LTO_WRAPPER=/usr/local/gcc-8.0.0/libexec/gcc/armv7l-unknown-linux-gnueabihf/8.0.0/lto-wrapper Target: armv7l-unknown-linux-gnueabihf Configured with: ../gcc-8.0.0/configure --prefix=/usr/local/gcc-8.0.0 --program-suffix= --disable-werror --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-plugin --enable-gnu-indirect-function --enable-lto --with-isl --enable-languages=c,c++,fortran,lto --disable-libgcj --enable-clocale=gnu --disable-libstdcxx-pch --enable-install-libiberty --disable-multilib --disable-libssp --enable-default-pie --enable-default-ssp --host=armv7l-unknown-linux-gnueabihf --build=armv7l-unknown-linux-gnueabihf --with-arch=armv7-a --with-float=hard --with-fpu=vfpv3-d16 --disable-bootstrap Thread model: posix gcc version 8.0.0 20171126 (experimental) (GCC) and its wasn't a ODROID-XU3 it was a Hardkernel Odroid XU4
Correction: 1) This works on gcc 8 snapshot, it doesn't work on gcc-7.2.0 /usr/local/gcc-7.2.0/bin/gcc -march=native -mcpu=cortex-a53 -mfpu=auto -Ofast -o matrix matrix.c cc1: error: -mfloat-abi=hard: selected processor lacks an FPU 2) The current message when you do not select a cpu explicitly, could do with improving to prompt you to do so. /usr/local/gcc/bin/gcc -march=native -mfpu=auto -o matrix matrix.c cc1: error: -mfloat-abi=hard: selected processor lacks an FPU Should really prompt user to use -mcpu= to select a cpu 3) This is the gcc version it doesn't work against, I'll check latest gcc-7 snapshot to check if the gcc-8 fix has been backported. /usr/local/gcc-7.2.0/bin/gcc -v Using built-in specs. COLLECT_GCC=/usr/local/gcc-7.2.0/bin/gcc COLLECT_LTO_WRAPPER=/usr/local/gcc-7.2.0/libexec/gcc/armv7l-unknown-linux-gnueabihf/7.2.0/lto-wrapper Target: armv7l-unknown-linux-gnueabihf Configured with: ../gcc-7.2.0/configure --prefix=/usr/local/gcc-7.2.0 --program-suffix= --disable-werror --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-plugin --enable-gnu-indirect-function --enable-lto --with-isl --enable-languages=c,c++,fortran,lto --disable-libgcj --enable-clocale=gnu --disable-libstdcxx-pch --enable-install-libiberty --disable-multilib --disable-libssp --enable-default-pie --enable-default-ssp --host=armv7l-unknown-linux-gnueabihf --build=armv7l-unknown-linux-gnueabihf --with-arch=armv7-a --with-float=hard --with-fpu=vfpv3-d16 --disable-bootstrap Thread model: posix gcc version 7.2.0 (GCC)
ok confirmed, this bug is still present on the gcc-7 branch, with the current snapshot: /usr/local/gcc-7.2.1/bin/gcc -v Using built-in specs. COLLECT_GCC=/usr/local/gcc-7.2.1/bin/gcc COLLECT_LTO_WRAPPER=/usr/local/gcc-7.2.1/bin/../libexec/gcc/armv7l-unknown-linux-gnueabihf/7.2.1/lto-wrapper Target: armv7l-unknown-linux-gnueabihf Configured with: ../gcc-7.3.0/configure --prefix=/usr/local/gcc-7.3.0 --program-suffix= --disable-werror --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-plugin --enable-gnu-indirect-function --enable-lto --with-isl --enable-languages=c,c++,fortran,lto --disable-libgcj --enable-clocale=gnu --disable-libstdcxx-pch --enable-install-libiberty --disable-multilib --disable-libssp --enable-default-pie --enable-default-ssp --host=armv7l-unknown-linux-gnueabihf --build=armv7l-unknown-linux-gnueabihf --with-arch=armv7-a --with-float=hard --with-fpu=vfpv3-d16 --disable-bootstrap Thread model: posix gcc version 7.2.1 20171123 (GCC) /usr/local/gcc-7.2.1/bin/gcc -march=native -mcpu=cortex-a53 -mfpu=auto -Ofast -o matrix matrix.c cc1: error: -mfloat-abi=hard: selected processor lacks an FPU Also the gcc man pages for 7.2.1 lack documentation for the -mfpu=auto option, although it is accepted as an argument (gcc 8 does document it) On 7.2.1 man page: -mfpu=name This specifies what floating-point hardware (or hardware emulation) is available on the target. Permissible names are: vfpv2, vfpv3, vfpv3-fp16, vfpv3-d16, vfpv3-d16-fp16, vfpv3xd, vfpv3xd-fp16, neon-vfpv3, neon-fp16, vfpv4, vfpv4-d16, fpv4-sp-d16, neon-vfpv4, fpv5-d16, fpv5-sp-d16, fp-armv8, neon-fp-armv8 and crypto-neon-fp-armv8. Note that neon is an alias for neon-vfpv3 and vfp is an alias for vfpv2. On 8.0.0 man page: -mfpu=name This specifies what floating-point hardware (or hardware emulation) is available on the target. Permissible names are: auto, vfpv2, vfpv3, vfpv3-fp16, vfpv3-d16, vfpv3-d16-fp16, vfpv3xd, vfpv3xd-fp16, neon-vfpv3, neon-fp16, vfpv4, vfpv4-d16, fpv4-sp-d16, neon-vfpv4, fpv5-d16, fpv5-sp-d16, fp-armv8, neon-fp-armv8 and crypto-neon-fp-armv8. Note that neon is an alias for neon-vfpv3 and vfp is an alias for vfpv2.
Implementation of -mfpu=auto wasn't complete in GCC-7, which is why it isn't in the main documentation. Some of the implementation was there though, which is why it leaks into the --help information. As you've noted it's fixed in gcc-8. It's unlikely that this will be fixed on the release branch.
It looks like I was right about this all along, its just that armv6l isn't working. armv7l seems ok: On RaspberryPi B - ARM1176 rev 7 (0x4100b760) cat /proc/cpuinfo processor : 0 model name : ARMv6-compatible processor rev 7 (v6l) BogoMIPS : 697.95 Features : half thumb fastmult vfp edsp java tls CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xb76 CPU revision : 7 /usr/local/gcc/bin/gcc -v Using built-in specs. COLLECT_GCC=/usr/local/gcc/bin/gcc COLLECT_LTO_WRAPPER=/usr/local/gcc-8.0.0/libexec/gcc/armv6l-unknown-linux-gnueabihf/8.0.0/lto-wrapper Target: armv6l-unknown-linux-gnueabihf Configured with: ../gcc-8.0.0/configure --prefix=/usr/local/gcc-8.0.0 --program-suffix= --disable-werror --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-plugin --enable-gnu-indirect-function --enable-lto --with-isl --enable-languages=c,c++,fortran,lto --disable-libgcj --enable-clocale=gnu --disable-libstdcxx-pch --enable-install-libiberty --disable-multilib --disable-libssp --enable-default-pie --enable-default-ssp --host=armv6l-unknown-linux-gnueabihf --build=armv6l-unknown-linux-gnueabihf --with-arch=armv6 --with-float=hard --with-fpu=vfp --disable-bootstrap Thread model: posix gcc version 8.0.0 20171126 (experimental) (GCC) /usr/local/gcc/bin/gcc -march=native -mcpu=native -mtune=native -Q --target-help | grep "march=\|mtune=\|mcpu=\|mfpu=" -march= armv6zk+fp -mcpu= arm1176jz-s -mfpu= vfp -mtune= arm1176jz-s /usr/local/gcc/bin/gcc -o matrix-v6 -march=native -mcpu=native -mtune=native -mfpu=auto -O3 matrix.c cc1: error: -mfloat-abi=hard: selected processor lacks an FPU whereas: /usr/local/gcc/bin/gcc -o matrix-v6 -march=native -mcpu=native -mtune=native -mfpu=vfp -O3 matrix.c is fine. -mfpu=auto works on Raspberry Pi 3B - 4 x Cortex-A53 rev 4 (0x4100d030) and ODROID-XU4 - 4 x Cortex-A15 rev 3 (0x4100c0f0)/4 x Cortex-A7 rev 3 (0x4100c070) On aarch64 -mfpu=auto gives: gcc: error: unrecognized command line option ‘-mfpu=auto’ which is correct, but would it be better to silently accept it for compatibility with ARM 32 bit
> /usr/local/gcc/bin/gcc -o matrix-v6 -march=native -mcpu=native -mtune=native -mfpu=auto -O3 matrix.c > cc1: error: -mfloat-abi=hard: selected processor lacks an FPU -mcpu=... is an alias that sets both architecture and tuning, you should never need to specify all three. What happens if you just use: /usr/local/gcc/bin/gcc -o matrix-v6 -mcpu=native -mfpu=auto -O3 matrix.c > On aarch64 -mfpu=auto gives: > gcc: error: unrecognized command line option ‘-mfpu=auto’ The AArch64 compiler does not have a -mfpu option of any format, it's all part of the architecture (-march) option. I'll have another look at the native stuff, but I don't have an ARMv6 board to test with and it might not be in the next few days.
I get the same thing if I just use -mcpu=native: /usr/local/gcc/bin/gcc -o matrix-v6 -mcpu=native -mfpu=auto -O3 matrix.c cc1: error: -mfloat-abi=hard: selected processor lacks an FPU I realize the aarch64 compiler does not need -mfpu=auto, but I was wondering if it was worth at least not rejecting it so makefiles can be portable between arm and aarch64. At present you get: gcc: error: unrecognized command line option ‘-mfpu=auto’ and the compile fails A Rasbperry PI Zero is the cheapest and easiest armv6 option, although it does take 24hrs to build the compiler
(In reply to Andrew Roberts from comment #7) > I get the same thing if I just use -mcpu=native: > > /usr/local/gcc/bin/gcc -o matrix-v6 -mcpu=native -mfpu=auto -O3 matrix.c > cc1: error: -mfloat-abi=hard: selected processor lacks an FPU > Ok, I'll look a bit further. > I realize the aarch64 compiler does not need -mfpu=auto, but I was wondering > if it was worth at least not rejecting it so makefiles can be portable > between arm and aarch64. At present you get: > > gcc: error: unrecognized command line option ‘-mfpu=auto’ > No, that would be a bad idea. -mfpu=auto is supposed to be a transition path to making the -mfpu option obsolete (ie doing the way we do things on AArch64). Adding that to the aarch64 compiler would be a backwards step. > and the compile fails > > A Rasbperry PI Zero is the cheapest and easiest armv6 option, although it > does take 24hrs to build the compiler
Created attachment 42787 [details] /proc/cpuinfo from cortex-a7 Raspberry Pi 2b v1.1 /proc/cpuinfo from cortex-a7 Raspberry Pi 2b v1.1
Created attachment 42788 [details] /proc/cpuinfo from odroid-xu4 big/little cortex-a15/cortex-a7 /proc/cpuinfo from odroid-xu4 big/little cortex-a15/cortex-a7
Created attachment 42789 [details] /proc/cpuinfo from rpi b (arm1176jzf-s) /proc/cpuinfo from rpi b (arm1176jzf-s)
Created attachment 42790 [details] /proc/cpuinfo from Raspberry Pi 3 (cortex-A53) arm mode /proc/cpuinfo from Raspberry Pi 3 (cortex-A53) arm mode
Created attachment 42791 [details] /proc/cpuinfo from odroid-c2 (cortex-A53) aarch64 mode /proc/cpuinfo from odroid-c2 (cortex-A53) aarch64 mode
Richard, I have checked with latest snapshot (20171203) and problem persists. I think the issue is that the CPU on the original Raspberry Pi and Pi Zero is not detected properly by gcc. /usr/local/gcc/bin/gcc -mcpu=native -Q --help=target | grep mcpu= -mcpu= arm1176jz-s But the processor is actually an arm1176jzf-s Using: /usr/local/gcc/bin/gcc -o matrix-v6 -mcpu=arm1176jzf-s -mfpu=auto -O3 matrix.c works whereas using -mcpu=native or -mcpu=arm1176jz-s fails (no FPU). gcc seems to parse /proc/cpuinfo to get the MIDR details and this is correct (as far as it goes). But it doesn't parse the Features line to get the FPU details. Which is the only way of telling the arm1176jz-s from arm1176jzf-s (as Linux doesn't give access to control registers). On Raspberry Pi B/Zero: Features : half thumb fastmult vfp edsp java tls I've attached /proc/cpuinfo for all arm processors I have. While looking at this it might be worth also looking at bug 83207 (big/little cpu detection) as that is just a case of parsing out both processors from the /proc/cpuinfo file (see odroid-xu4 file) It might be worth soliciting additional /proc/cpuinfo files from the mailing list, if anybody has them.
Created attachment 42792 [details] /proc/cpuinfo fro rpi3 (cortex a-53) on aarch64 /proc/cpuinfo fro rpi3 (cortex a-53) on aarch64 while this is the same cpu as odroid-c2 running aarch64, it has much newer kernel. rpi: 4.14.3-1-ARCH odroid-c2: 3.14.79-28-ARCH Newer aarch64 kernels expose MIDR directly at: /sys/devices/system/cpu/cpu0/regs/identification/midr_el1 but not the other control regs needed for FPU detection
reopening
Author: rearnsha Date: Fri Dec 8 11:19:20 2017 New Revision: 255504 URL: https://gcc.gnu.org/viewcvs?rev=255504&root=gcc&view=rev Log: [arm] PR target/83206: Make native driver select fp-capable armv6 cores A quirk in the historical naming of some ARMv6 products means that the main CPU name implies the presence or otherwise of the floating point unit. This causes problems when using -mfpu=auto with -mcpu=native: the driver is picking a CPU that does not support a floating-point unit, even though one may well exist. This patch addresses this by selecting the FP-capable names so that FP instructions will be generated if the other options suggest this is permitted. Note that a more complete fix is really needed here to look up the FP/simd capabilities and append the appropriate capability extensions. This will be the subject of some follow-up patches. * config/arm/driver-arm.c (arm_cpu_table): Use fp-capable product names for armv6 ARM CPU IDs. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/driver-arm.c
Richard, I'm giving the latest snapshot a test, the armv6 version will be ready in 16 hrs or so... Meanwhile a question about consistency with gcc -Q --help=target, and also what happens if you don't specify -mcpu= with =mfpu=auto tested with gcc version 8.0.0 20171210 (experimental) (GCC) /usr/local/gcc/bin/gcc -Q --help=target | grep "mcpu\|mfpu\|march" -march= armv7-a+fp -mcpu= -mfpu= vfpv3-d16 /usr/local/gcc/bin/gcc -march=native -Q --help=target | grep "mcpu\|mfpu\|march" -march= armv7ve+vfpv3-d16 -mcpu= -mfpu= vfpv3-d16 /usr/local/gcc/bin/gcc -march=native -mcpu=native -Q --help=target | grep "mcpu\|mfpu\|march" -march= armv7ve+vfpv3-d16 -mcpu= cortex-a7 -mfpu= vfpv3-d16 /usr/local/gcc/bin/gcc -march=native -mcpu=native -mfpu=auto -Q --help=target | grep "mcpu\|mfpu\|march" -march= armv7ve -mcpu= cortex-a7 -mfpu= auto So without anything specified generic arch is given and also a fpu. -march=native fills in the arch with the correct one whereas -mfpu=auto just says auto rather than what was selected march=native gives different results depending on if -mfpu=auto is set How does mfpu=auto impact cross compuilers? Will it just not be available? What will happen in the future when its the default? This was all on the Big/Little ODROID XU4, so it should really have been: -mcpu= cortex-a15.cortex-a7 When the patches for that issue land.
-m{cpu,tune,arch}=native are hosted-only flags that mean look-up the architecture on the machine I'm running on now. They are not supported at all on cross compilers. This is translated by the driver into the real -m{cpu,tune,arch} flag that gets passed to the compiler proper, which is why you see it changed by the help information. -mfpu=auto means use the floating-point unit implied by -mcpu/-march flags. This works even if on a cross compiler. -mfpu=auto != -mfpu=native. There never has been a -mfpu=native option and now we have -mfpu=auto we don't need one. -mfpu=auto is not translated by the driver; it's used in the compiler proper to control where the selected FPU information is looked up (directly or from the architecture specification).
The patch in in latest snapshot is working ok on Raspberry Pi Zero. And -help=target now returns: /usr/local/gcc/bin/gcc -march=native -mcpu=native -mfpu=auto -Q --help=target | grep "march\|mcpu\|mfpu" -march= armv6zk -mcpu= arm1176jzf-s -mfpu= auto gcc version 8.0.0 20171210 (experimental) (GCC)
Since the bug seems to be fixed, anything keeping this ticket open?
The RPI Zero bug was fixed, I'm retesting with the latest snapshot (8.0.1 20180304) just to be sure it is ok. There are still a number of inconsistencies and things which could be improved. On Odroid-Xu4 (Cortex A15/A7 Big/little, Aarch32) ------------------------------------------------- /usr/local/gcc/bin/gcc -mfpu=auto -O3 -o matrix matrix.c cc1: error: -mfloat-abi=hard: selected processor lacks an FPU It would be better if this error could let the user know they need to select a CPU manually, rather than incorrectly state it lacks an FPU. This is going to be confusing to people. /usr/local/gcc/bin/gcc -mcpu=native -mfpu=auto -O3 -o matrix matrix.c Is fine. /usr/local/gcc/bin/gcc -march=native -Q --help=target | grep "mcpu\|mfpu\|march" -march= armv7ve+vfpv3-d16 -mcpu= -mfpu= vfpv3-d16 /usr/local/gcc/bin/gcc -march=native -mcpu=native -Q --help=target | grep "mcpu\|mfpu\|march" -march= armv7ve+vfpv3-d16 -mcpu= cortex-a7 -mfpu= vfpv3-d16 This is still not detecting BIG/little CPU combinations (I had a separate PR about this [83207]). On ODROID-C2 (Cortex A53,AARCH64) ---------------------- /usr/local/gcc/bin/gcc -march=native -mcpu=native -Q --help=target | grep "mcpu\|mfpu\|march" -march=ARCH armv8-a+crc -mcpu=CPU cortex-a53 The output is inconsistent with aarch32 output (=ARCH, =CPU), I had also raised a PR about this [83193]. On RPI 3 (Cortex A53,AArch32) ----------------------------- No issues here that I can see. I'll update again tomorrow when the RPI Zero build has completed
RPI Zero still looks ok with latest snapshot. /usr/local/gcc/bin/gcc -mfpu=auto -O3 -o matrix matrix.c cc1: error: -mfloat-abi=hard: selected processor lacks an FPU /usr/local/gcc/bin/gcc -mcpu=native -mfpu=auto -O3 -o matrix matrix.c Is ok. /usr/local/gcc/bin/gcc -march=native -mcpu=native -Q --help=target | grep "mcpu\|mfpu\|march" -march= armv6zk+fp -mcpu= arm1176jzf-s -mfpu= vfp /usr/local/gcc/bin/gcc -v Using built-in specs. COLLECT_GCC=/usr/local/gcc/bin/gcc COLLECT_LTO_WRAPPER=/usr/local/gcc-8.0.0/libexec/gcc/armv6l-unknown-linux-gnueabihf/8.0.1/lto-wrapper Target: armv6l-unknown-linux-gnueabihf Configured with: ../gcc-8.0.0/configure --prefix=/usr/local/gcc-8.0.0 --program-suffix= --disable-werror --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-plugin --enable-gnu-indirect-function --enable-lto --with-isl --enable-languages=c,c++,fortran,lto --disable-libgcj --enable-clocale=gnu --disable-libstdcxx-pch --enable-install-libiberty --disable-multilib --disable-libssp --enable-default-pie --enable-default-ssp --host=armv6l-unknown-linux-gnueabihf --build=armv6l-unknown-linux-gnueabihf --with-arch=armv6 --with-float=hard --with-fpu=vfp --disable-bootstrap Thread model: posix gcc version 8.0.1 20180304 (experimental) (GCC)
GCC 8.1 has been released.
GCC 8.2 has been released.
GCC 8.3 has been released.
GCC 8.4.0 has been released, adjusting target milestone.