Bug 45886

Summary: [ARM] support for __ARM_PCS_VFP predefined symbol in gcc 4.5.x would be very nice
Product: gcc Reporter: Siarhei Siamashka <siarhei.siamashka>
Component: targetAssignee: Not yet assigned to anyone <unassigned>
Status: NEW ---    
Severity: normal CC: koen, mans, ramana, rearnsha, toolchain
Priority: P3    
Version: 4.5.1   
Target Milestone: ---   
URL: http://gcc.gnu.org/ml/gcc-patches/2010-07/msg02186.html
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

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.

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."
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?"