Bug 45886 - [ARM] support for __ARM_PCS_VFP predefined symbol in gcc 4.5.x would be very nice
Summary: [ARM] support for __ARM_PCS_VFP predefined symbol in gcc 4.5.x would be very ...
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 4.5.1
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL: http://gcc.gnu.org/ml/gcc-patches/201...
Keywords:
Depends on:
Blocks:
 
Reported: 2010-10-04 22:04 UTC by Siarhei Siamashka
Modified: 2011-01-16 21:07 UTC (History)
5 users (show)

See Also:
Host: arm-unknown-linux-gnueabi
Target: arm-unknown-linux-gnueabi
Build: arm-unknown-linux-gnueabi
Known to work: 4.6.0
Known to fail: 4.5.0, 4.5.1
Last reconfirmed: 2010-10-07 08:15:57


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Siarhei Siamashka 2010-10-04 22:04:57 UTC
This is quite important for JIT code when we want so support all ABI variants properly. Because now gcc 4.5.x supports -mfloat-abi=hard, being able to identify its use is also needed.
Comment 1 Ramana Radhakrishnan 2010-10-07 08:15:57 UTC
Confirmed though I think this isn't an "enhancement" but more a bug because code can't identify whether -mfloat-abi=hard is chosen by use of a pre-processor directive.

Ramana
Comment 2 Siarhei Siamashka 2010-10-11 14:31:29 UTC
(In reply to comment #1)
> Confirmed though I think this isn't an "enhancement" but more a bug because
> code can't identify whether -mfloat-abi=hard is chosen by use of a
> pre-processor directive.

Thanks. Can we expect this problem to be fixed in gcc 4.5.2 (backported from trunk)?

For now I'm going to use the following guard code to make sure that using unpatched gcc will result in compilation problem instead of runtime failure:

#if defined(__GNUC__) && (__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 5)) \
    && defined(__ARM_EABI__) && !defined(__ARM_PCS_VFP) && !defined(__ARM_PCS)
#error "Can't identify floating point calling conventions.\nPlease ensure that your toolchain defines __ARM_PCS or __ARM_PCS_VFP."
#endif
Comment 3 Siarhei Siamashka 2010-11-12 15:30:24 UTC
Richard, what would be the appropriate target milestone to get this bug fixed?

This needs just a backport of a trivial patch from trunk to 4.5 branch, but delaying this fix increases the chances of penetration of problematic gcc into various linux distributions.
Comment 4 Siarhei Siamashka 2010-12-18 17:23:04 UTC
I'm sorry for asking again, but what is the status of this issue? Is it even feasible to get it resolved in upstream gcc 4.5.x? Previously this issue had a target milestone set to 4.5.2, but then is was simply removed.

While this is not strictly a regression compared to the previous releases, it makes the use of the new major feature for arm (-mfloat-abi=hard option) introduced in gcc 4.5 rather problematic. Just a few examples of the affected software are the upcoming mozilla firefox4 and libffi library which use __ARM_PCS_VFP define to identify floating point calling conventions.

The trivial fewliner patch which fixes the issue has been already adopted by linaro gcc [1]. It is also used by ubuntu [2] and probably some other linux distributions for the obvious pragmatic reasons.

So I wonder what is the current recommendation from your side? Make it a responsibility of each linux distribution to patch gcc themselves? Or maybe add some ugly hacks to the affected applications and libraries to identify floating point calling conventions in some other way specifically for gcc 4.5.x?


1. https://wiki.linaro.org/WorkingGroups/ToolChain/Changelogs/LinaroGCC4.5
2. http://packages.ubuntu.com/natty/gcc-4.5-multilib
Comment 5 Koen Kooi 2011-01-16 15:18:04 UTC
I just ran into this problem while trying to fix mplayer and ffmpeg. To quote the person who fixed that bug with __ARM_PCS_VFP:

"how the hell am I supposed to detect hardfp then?"