[PATCH RFC 3/3] Hookize PROMOTE_FUNCTION_MODE with provision for HFmode
Paolo Bonzini
bonzini@gnu.org
Wed Apr 22 07:46:00 GMT 2009
Eric Botcazou wrote:
>> What if TARGET_ARCH64 and not TARGET_PTR64? This is the case I was
>> thinking about; FUNCTION_VALUE will extend pointers to 64-bit,
>> PROMOTE_FUNCTION_MODE doesn't (not even my posted version). It's
>> probably harmless though, maybe a bit inefficient.
>
> Pmode == word_mode
Got it now, POINTER_SIZE != GET_MODE_BITSIZE (Pmode).
I'd commit this to make it easier to grasp, do you agree?
Index: gcc/config/sparc/sparc.h
===================================================================
--- gcc/config/sparc/sparc.h (revision 146547)
+++ gcc/config/sparc/sparc.h (working copy)
@@ -625,8 +625,10 @@ extern struct sparc_cpu_select sparc_sel
/* The widest floating-point format really supported by the hardware. */
#define WIDEST_HARDWARE_FP_SIZE 64
-/* Width in bits of a pointer.
- See also the macro `Pmode' defined below. */
+/* Width in bits of a pointer. Note that the size of `Pmode' (defined
+ below) is not POINTER_SIZE; when pointers are 32-bit but
+ TARGET_ARCH64 is set, Pmode is a 64-bit mode to which pointers are
+ extended before being accessed. */
#define POINTER_SIZE (TARGET_PTR64 ? 64 : 32)
/* If we have to extend pointers (only when TARGET_ARCH64 and not
> so in both cases we get Pmode, don't we? Or do you want to
> add a POINTER_TYPE_P case to function_value for consistency?
Maybe, but it's a different patch.
Paolo
More information about the Gcc-patches
mailing list