[PATCH roland/arm-vfp] Test [__VFP_FP__] in place of [!__SOFTFP__].

[PATCH roland/arm-vfp] Test [__VFP_FP__] in place of [!__SOFTFP__].

[Roland McGrath]

The compiler predefines __SOFTFP__ to indicate that the calling convention
is the one using only integer registers.  It predefines __VFP_FP__ to
indicate that it is configured to generate VFP instructions.  It makes
sense for the setjmp/longjmp code to use VFP hardware unconditionally if
the compiler building libc might generate any instructions that require
that hardware, not just if VFP registers are being used in the calling
conventions.

Ok?


Thanks,
Roland


ports/ChangeLog.arm
2012-08-22  Roland McGrath  <roland@hack.frob.com>

	* sysdeps/arm/setjmp.S: Test [__VFP_FP__] in place of [!__SOFTFP__].
	* sysdeps/arm/__longjmp.S: Likewise.
	* sysdeps/arm/arm-features.h: Likewise.

diff --git a/ports/sysdeps/arm/__longjmp.S b/ports/sysdeps/arm/__longjmp.S
index b3c2860..b6a29f4 100644
--- a/ports/sysdeps/arm/__longjmp.S
+++ b/ports/sysdeps/arm/__longjmp.S
@@ -47,7 +47,7 @@ ENTRY (__longjmp)
 	cfi_restore (sp)
 	cfi_restore (lr)
 
-#if !defined ARM_ASSUME_NO_IWMMXT || defined __SOFTFP__
+#if !defined ARM_ASSUME_NO_IWMMXT || !defined __VFP_FP__
 # define NEED_HWCAP 1
 #endif
 
@@ -72,7 +72,7 @@ ENTRY (__longjmp)
 # endif
 #endif
 
-#ifdef __SOFTFP__
+#ifndef __VFP_FP__
 	tst	a2, #HWCAP_ARM_VFP
 	beq	.Lno_vfp
 #endif
diff --git a/ports/sysdeps/arm/arm-features.h b/ports/sysdeps/arm/arm-features.h
index 41befb5..6b32507 100644
--- a/ports/sysdeps/arm/arm-features.h
+++ b/ports/sysdeps/arm/arm-features.h
@@ -24,7 +24,7 @@
    hardware is present.  We'll then redefine it to a constant if we
    know at compile time that we can assume VFP.  */
 
-#ifndef __SOFTFP__
+#ifdef __VFP_FP__
 /* The compiler is generating VFP instructions, so we're already
    assuming the hardware exists.  */
 # undef ARM_HAVE_VFP
diff --git a/ports/sysdeps/arm/setjmp.S b/ports/sysdeps/arm/setjmp.S
index dbd59dd..57556af 100644
--- a/ports/sysdeps/arm/setjmp.S
+++ b/ports/sysdeps/arm/setjmp.S
@@ -29,7 +29,7 @@ ENTRY (__sigsetjmp)
 	/* Save registers */
 	stmia	ip!, {v1-v6, sl, fp, sp, lr}
 
-#if !defined ARM_ASSUME_NO_IWMMXT || defined __SOFTFP__
+#if !defined ARM_ASSUME_NO_IWMMXT || !defined __VFP_FP__
 # define NEED_HWCAP 1
 #endif
 
@@ -55,7 +55,7 @@ ENTRY (__sigsetjmp)
 # endif
 #endif
 
-#ifdef __SOFTFP__
+#ifndef __VFP_FP__
 	tst	a3, #HWCAP_ARM_VFP
 	beq	.Lno_vfp
 #endif

Re: [PATCH roland/arm-vfp] Test [__VFP_FP__] in place of [!__SOFTFP__].

[Joseph S. Myers]

On Wed, 22 Aug 2012, Roland McGrath wrote:

> The compiler predefines __SOFTFP__ to indicate that the calling convention
> is the one using only integer registers.

No, this indicates that it is not generating floating-point instructions.  
It defines __SOFTFP__ only for -mfloat-abi=soft, not -mfloat-abi=softfp (= 
hardware floating point but using integer registers in the calling 
convention) or -mfloat-abi=hard.

> It predefines __VFP_FP__ to
> indicate that it is configured to generate VFP instructions.

No, this indicates that floating-point types have VFP layout as opposed to 
FPA layout.  For an EABI compiler, all three of -mfloat-abi=soft, 
-mfloat-abi=softp and -mfloat-abi=hard predefine __VFP_FP__.

The predefine that relates to the calling convention is __ARM_PCS_VFP.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH roland/arm-vfp] Test [__VFP_FP__] in place of [!__SOFTFP__].

[Roland McGrath]

I see.  Sorry for the confusion.  
-mfloat-abi=softfp is the case I am concerned with.


Thanks,
Roland

Re: [PATCH roland/arm-vfp] Test [__VFP_FP__] in place of [!__SOFTFP__].

[Carlos O'Donell]

On 8/22/2012 4:54 PM, Joseph S. Myers wrote:
> On Wed, 22 Aug 2012, Roland McGrath wrote:
> 
>> The compiler predefines __SOFTFP__ to indicate that the calling convention
>> is the one using only integer registers.
> 
> No, this indicates that it is not generating floating-point instructions.  
> It defines __SOFTFP__ only for -mfloat-abi=soft, not -mfloat-abi=softfp (= 
> hardware floating point but using integer registers in the calling 
> convention) or -mfloat-abi=hard.
> 
>> It predefines __VFP_FP__ to
>> indicate that it is configured to generate VFP instructions.
> 
> No, this indicates that floating-point types have VFP layout as opposed to 
> FPA layout.  For an EABI compiler, all three of -mfloat-abi=soft, 
> -mfloat-abi=softp and -mfloat-abi=hard predefine __VFP_FP__.
> 
> The predefine that relates to the calling convention is __ARM_PCS_VFP.
 
For which we also define HAVE_ARM_PCS_VFP.

Cheers,
Carlos.