GCC multilibs for ARM don't support FPU synonyms

[munster]

There are two issues with the ARM multilibs.

1. When a program is compiled with option -mfpu=neon-fp16, the default runtime (ARMv4T, no FP) is selected which results of course in linking errors.
2. When there are two object files compiled with different but compatible FPU options, the linker fails to understand this.

Both issues could be fixed with appropriate MULTILIB_MATCHES in file gcc/config/arm/t-rtems. I have attached the patch with fixes for ARMv7-A only. It was made by cutting and pasting from t-aprofile.

I understand that there are many ARM platforms for which this issue wouldn't matter, so maybe the better approach would be to have a command line argument for GCC's configure script along the lines of ​https://gcc.gnu.org/ml/gcc-patches/2015-11/msg03400.html
This would allow everybody to select the precise multilibs for the platform they have with a minimum hassle.

[Sebastian Huber]

The -mfpu=neon-fp16 is not supported by RTEMS as far as I know. If you want to add support for it, then please add a new multilib for this.

What do you mean with "different but compatible FPU options"?

[Sebastian Huber]

I should have had a look into the documentation:

​http://infocenter.arm.com/help/topic/com.arm.doc.dui0774f/DUI0774F_armclang_reference_guide.pdf

neon
    Enable the ARMv7 VFPv3 floating-point extension and the Advanced SIMD extension.

neon-fp16
    Enable the ARMv7 VFPv3 floating-point extension, including the optional half-precision extensions, and the Advanced SIMD extension.

I think we just have to teach GCC (in t-rtems) that it should use the

thumb/armv7-a/neon/hard;@mthumb@march=armv7-a@mfpu=neon@mfloat-abi=hard

multilib if your application uses -mfpu=neon-fp16. You can test this with:

arm-rtems5-gcc -print-multi-directory -mthumb -march=armv7-a -mfpu=neon-fp16 -mfloat-abi=hard

[munster]

Replying to Sebastian Huber:

The -mfpu=neon-fp16 is not supported by RTEMS as far as I know. If you want to add support for it, then please add a new multilib for this.

I did that, please see the attached file.

What do you mean with "different but compatible FPU options"?

For example, -mfpu=neon and -mfpu=neon-vfpv3 are the same. Also -march=armv7-a and -mcpu=cortex-a9 are very similar if not the same.

[Sebastian Huber]

Replying to munster:

Replying to Sebastian Huber:

The -mfpu=neon-fp16 is not supported by RTEMS as far as I know. If you want to add support for it, then please add a new multilib for this.

I did that, please see the attached file.

The patch is too extensive from my point of view. Please send patches to devel@….

What do you mean with "different but compatible FPU options"?

For example, -mfpu=neon and -mfpu=neon-vfpv3 are the same. Also -march=armv7-a and -mcpu=cortex-a9 are very similar if not the same.

I don't know the details of the cost models used by default on ARMv7-A and for Cortex-A9.

[munster]

Replying to Sebastian Huber:

I think we just have to teach GCC (in t-rtems) that it should use the
thumb/armv7-a/neon/hard;@mthumb@march=armv7-a@mfpu=neon@mfloat-abi=hard
multilib if your application uses -mfpu=neon-fp16.

I think it's not enough. Some people would like to use ARM (not Thumb mode), some people may need -mfloat-abi=softfp, and suddenly you're looking at 12 multilibs only for ARMv7-A.
Please also look at gcc-7.3.0/gcc/config/arm/t-rmprofile - it contains 20 multilibs.

To combat that rapid expansion, I suggest to create a GCC's configure option --with_multilib_list=<cpu1>,... and add sub-sections into t-rtems for each individual cpu. This way anybody could choose necessary platform without having to patch t-rtems.

[Sebastian Huber]

You can use ARM code in your application with the existing multilibs.

If you want to add a new GCC configure option, then please discuss this on the GCC mailing list.

With the current multilib support we cannot make everyone happy. Building 100 multilibs would be too much.