Opened on 05/28/18 at 17:22:38
Last modified on 05/29/18 at 11:39:52
#3438 new defect
GCC multilibs for ARM don't support FPU synonyms
Reported by: | munster | Owned by: | |
---|---|---|---|
Priority: | low | Milestone: | |
Component: | tool/gcc | Version: | |
Severity: | normal | Keywords: | multilibs, GCC, ARM |
Cc: | Blocked By: | ||
Blocking: |
Description
There are two issues with the ARM multilibs.
- 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.
- 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.
Attachments (1)
Change History (7)
Changed on 05/28/18 at 17:23:09 by munster
Attachment: | gcc-a9-multilib.patch added |
---|
comment:1 follow-up: 3 Changed on 05/29/18 at 08:23:09 by Sebastian Huber
comment:2 follow-up: 5 Changed on 05/29/18 at 08:33:08 by 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
comment:3 follow-up: 4 Changed on 05/29/18 at 11:04:11 by 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.
comment:4 Changed on 05/29/18 at 11:08:17 by 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.
comment:5 Changed on 05/29/18 at 11:29:16 by 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.
comment:6 Changed on 05/29/18 at 11:39:52 by 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.
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"?