public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* PATCH [3/n] X32: Promote pointers to Pmode
@ 2011-07-09 21:37 H.J. Lu
  2011-07-10 16:37 ` Uros Bizjak
  0 siblings, 1 reply; 22+ messages in thread
From: H.J. Lu @ 2011-07-09 21:37 UTC (permalink / raw)
  To: gcc-patches, Uros Bizjak

Hi,

X32 psABI requires promoting pointers to Pmode when passing/returning
in registers.  OK for trunk?

Thanks.

H.J.
--
2011-07-09  H.J. Lu  <hongjiu.lu@intel.com>

	* config/i386/i386.c (ix86_promote_function_mode): New.
	(TARGET_PROMOTE_FUNCTION_MODE): Likewise.

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 04cb07d..c852719 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -7052,6 +7061,23 @@ ix86_function_value (const_tree valtype, const_tree fntype_or_decl,
   return ix86_function_value_1 (valtype, fntype_or_decl, orig_mode, mode);
 }
 
+/* Pointer function arguments and return values are promoted to
+   Pmode.  */
+
+static enum machine_mode
+ix86_promote_function_mode (const_tree type, enum machine_mode mode,
+			    int *punsignedp, const_tree fntype,
+			    int for_return)
+{
+  if (for_return != 1 && type != NULL_TREE && POINTER_TYPE_P (type))
+    {
+      *punsignedp = POINTERS_EXTEND_UNSIGNED;
+      return Pmode;
+    }
+  return default_promote_function_mode (type, mode, punsignedp, fntype,
+					for_return);
+}
+
 rtx
 ix86_libcall_value (enum machine_mode mode)
 {
@@ -34810,6 +35154,9 @@ ix86_autovectorize_vector_sizes (void)
 #undef TARGET_FUNCTION_VALUE_REGNO_P
 #define TARGET_FUNCTION_VALUE_REGNO_P ix86_function_value_regno_p
 
+#undef TARGET_PROMOTE_FUNCTION_MODE
+#define TARGET_PROMOTE_FUNCTION_MODE ix86_promote_function_mode
+
 #undef TARGET_SECONDARY_RELOAD
 #define TARGET_SECONDARY_RELOAD ix86_secondary_reload
 

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: PATCH [3/n] X32: Promote pointers to Pmode
  2011-07-09 21:37 PATCH [3/n] X32: Promote pointers to Pmode H.J. Lu
@ 2011-07-10 16:37 ` Uros Bizjak
  2011-07-10 19:56   ` H.J. Lu
  0 siblings, 1 reply; 22+ messages in thread
From: Uros Bizjak @ 2011-07-10 16:37 UTC (permalink / raw)
  To: H.J. Lu; +Cc: gcc-patches

On Sat, Jul 9, 2011 at 11:28 PM, H.J. Lu <hongjiu.lu@intel.com> wrote:

> X32 psABI requires promoting pointers to Pmode when passing/returning
> in registers.  OK for trunk?
>
> Thanks.
>
> H.J.
> --
> 2011-07-09  H.J. Lu  <hongjiu.lu@intel.com>
>
>        * config/i386/i386.c (ix86_promote_function_mode): New.
>        (TARGET_PROMOTE_FUNCTION_MODE): Likewise.
>
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index 04cb07d..c852719 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -7052,6 +7061,23 @@ ix86_function_value (const_tree valtype, const_tree fntype_or_decl,
>   return ix86_function_value_1 (valtype, fntype_or_decl, orig_mode, mode);
>  }
>
> +/* Pointer function arguments and return values are promoted to
> +   Pmode.  */
> +
> +static enum machine_mode
> +ix86_promote_function_mode (const_tree type, enum machine_mode mode,
> +                           int *punsignedp, const_tree fntype,
> +                           int for_return)
> +{
> +  if (for_return != 1 && type != NULL_TREE && POINTER_TYPE_P (type))
> +    {
> +      *punsignedp = POINTERS_EXTEND_UNSIGNED;
> +      return Pmode;
> +    }
> +  return default_promote_function_mode (type, mode, punsignedp, fntype,
> +                                       for_return);
> +}

Please rewrite the condition to:

if (for_return == 1)
  /* Do not promote function return values.  */
  ;
else if (type != NULL_TREE && ...)

Also, please add some comments.

Your comment also says that pointer return arguments are promoted to
Pmode. The documentation says that:

     FOR_RETURN allows to distinguish the promotion of arguments and
     return values.  If it is `1', a return value is being promoted and
     `TARGET_FUNCTION_VALUE' must perform the same promotions done here.
     If it is `2', the returned mode should be that of the register in
     which an incoming parameter is copied, or the outgoing result is
     computed; then the hook should return the same mode as
     `promote_mode', though the signedness may be different.

You bypass promotions when FOR_RETURN is 1.

Uros.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: PATCH [3/n] X32: Promote pointers to Pmode
  2011-07-10 16:37 ` Uros Bizjak
@ 2011-07-10 19:56   ` H.J. Lu
  2011-07-10 23:51     ` Richard Henderson
  2011-07-13 13:42     ` H.J. Lu
  0 siblings, 2 replies; 22+ messages in thread
From: H.J. Lu @ 2011-07-10 19:56 UTC (permalink / raw)
  To: Uros Bizjak; +Cc: gcc-patches

On Sun, Jul 10, 2011 at 7:32 AM, Uros Bizjak <ubizjak@gmail.com> wrote:
> On Sat, Jul 9, 2011 at 11:28 PM, H.J. Lu <hongjiu.lu@intel.com> wrote:
>
>> X32 psABI requires promoting pointers to Pmode when passing/returning
>> in registers.  OK for trunk?
>>
>> Thanks.
>>
>> H.J.
>> --
>> 2011-07-09  H.J. Lu  <hongjiu.lu@intel.com>
>>
>>        * config/i386/i386.c (ix86_promote_function_mode): New.
>>        (TARGET_PROMOTE_FUNCTION_MODE): Likewise.
>>
>> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
>> index 04cb07d..c852719 100644
>> --- a/gcc/config/i386/i386.c
>> +++ b/gcc/config/i386/i386.c
>> @@ -7052,6 +7061,23 @@ ix86_function_value (const_tree valtype, const_tree fntype_or_decl,
>>   return ix86_function_value_1 (valtype, fntype_or_decl, orig_mode, mode);
>>  }
>>
>> +/* Pointer function arguments and return values are promoted to
>> +   Pmode.  */
>> +
>> +static enum machine_mode
>> +ix86_promote_function_mode (const_tree type, enum machine_mode mode,
>> +                           int *punsignedp, const_tree fntype,
>> +                           int for_return)
>> +{
>> +  if (for_return != 1 && type != NULL_TREE && POINTER_TYPE_P (type))
>> +    {
>> +      *punsignedp = POINTERS_EXTEND_UNSIGNED;
>> +      return Pmode;
>> +    }
>> +  return default_promote_function_mode (type, mode, punsignedp, fntype,
>> +                                       for_return);
>> +}
>
> Please rewrite the condition to:
>
> if (for_return == 1)
>  /* Do not promote function return values.  */
>  ;
> else if (type != NULL_TREE && ...)
>
> Also, please add some comments.
>
> Your comment also says that pointer return arguments are promoted to
> Pmode. The documentation says that:
>
>     FOR_RETURN allows to distinguish the promotion of arguments and
>     return values.  If it is `1', a return value is being promoted and
>     `TARGET_FUNCTION_VALUE' must perform the same promotions done here.
>     If it is `2', the returned mode should be that of the register in
>     which an incoming parameter is copied, or the outgoing result is
>     computed; then the hook should return the same mode as
>     `promote_mode', though the signedness may be different.
>
> You bypass promotions when FOR_RETURN is 1.
>
> Uros.
>

Here is the updated patch. OK for trunk?

Thanks.

-- 
H.J.
--
2011-07-10  H.J. Lu  <hongjiu.lu@intel.com>

	* config/i386/i386.c (ix86_promote_function_mode): New.
	(TARGET_PROMOTE_FUNCTION_MODE): Likewise.

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 04cb07d..1b02312 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -2973,6 +2973,9 @@ ix86_option_override_internal (bool main_args_p)
   SUBSUBTARGET_OVERRIDE_OPTIONS;
 #endif

+  if (TARGET_X32)
+    ix86_isa_flags |= OPTION_MASK_ISA_64BIT;
+
   /* -fPIC is the default for x86_64.  */
   if (TARGET_MACHO && TARGET_64BIT)
@@ -7052,6 +7061,27 @@ ix86_function_value (const_tree valtype,
const_tree fntype_or_decl,
   return ix86_function_value_1 (valtype, fntype_or_decl, orig_mode, mode);
 }

+/* Pointer function arguments and return values are promoted to Pmode.
+   If FOR_RETURN is 1, this function must behave in the same way with
+   regard to function returns as TARGET_FUNCTION_VALUE.  */
+
+static enum machine_mode
+ix86_promote_function_mode (const_tree type, enum machine_mode mode,
+			    int *punsignedp, const_tree fntype,
+			    int for_return)
+{
+  if (for_return == 1)
+    /* Do not promote function return values.  */
+    ;
+  else if (type != NULL_TREE && POINTER_TYPE_P (type))
+    {
+      *punsignedp = POINTERS_EXTEND_UNSIGNED;
+      return Pmode;
+    }
+  return default_promote_function_mode (type, mode, punsignedp, fntype,
+					for_return);
+}
+
 rtx
 ix86_libcall_value (enum machine_mode mode)
 {
@@ -34810,6 +35157,9 @@ ix86_autovectorize_vector_sizes (void)
 #undef TARGET_FUNCTION_VALUE_REGNO_P
 #define TARGET_FUNCTION_VALUE_REGNO_P ix86_function_value_regno_p

+#undef TARGET_PROMOTE_FUNCTION_MODE
+#define TARGET_PROMOTE_FUNCTION_MODE ix86_promote_function_mode
+
 #undef TARGET_SECONDARY_RELOAD
 #define TARGET_SECONDARY_RELOAD ix86_secondary_reload

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: PATCH [3/n] X32: Promote pointers to Pmode
  2011-07-10 19:56   ` H.J. Lu
@ 2011-07-10 23:51     ` Richard Henderson
  2011-07-11  0:04       ` H.J. Lu
  2011-07-13 13:42     ` H.J. Lu
  1 sibling, 1 reply; 22+ messages in thread
From: Richard Henderson @ 2011-07-10 23:51 UTC (permalink / raw)
  To: H.J. Lu; +Cc: Uros Bizjak, gcc-patches

On 07/10/2011 12:43 PM, H.J. Lu wrote:
> +/* Pointer function arguments and return values are promoted to Pmode.
> +   If FOR_RETURN is 1, this function must behave in the same way with
> +   regard to function returns as TARGET_FUNCTION_VALUE.  */
> +
> +static enum machine_mode
> +ix86_promote_function_mode (const_tree type, enum machine_mode mode,
> +			    int *punsignedp, const_tree fntype,
> +			    int for_return)
> +{
> +  if (for_return == 1)
> +    /* Do not promote function return values.  */
> +    ;
> +  else if (type != NULL_TREE && POINTER_TYPE_P (type))

These two comments still conflict.  And why wouldn't you want to 
promote return values?


r~

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: PATCH [3/n] X32: Promote pointers to Pmode
  2011-07-10 23:51     ` Richard Henderson
@ 2011-07-11  0:04       ` H.J. Lu
  2011-07-11  1:16         ` Richard Henderson
  0 siblings, 1 reply; 22+ messages in thread
From: H.J. Lu @ 2011-07-11  0:04 UTC (permalink / raw)
  To: Richard Henderson; +Cc: Uros Bizjak, gcc-patches

On Sun, Jul 10, 2011 at 2:44 PM, Richard Henderson <rth@redhat.com> wrote:
> On 07/10/2011 12:43 PM, H.J. Lu wrote:
>> +/* Pointer function arguments and return values are promoted to Pmode.
>> +   If FOR_RETURN is 1, this function must behave in the same way with
>> +   regard to function returns as TARGET_FUNCTION_VALUE.  */
>> +
>> +static enum machine_mode
>> +ix86_promote_function_mode (const_tree type, enum machine_mode mode,
>> +                         int *punsignedp, const_tree fntype,
>> +                         int for_return)
>> +{
>> +  if (for_return == 1)
>> +    /* Do not promote function return values.  */
>> +    ;
>> +  else if (type != NULL_TREE && POINTER_TYPE_P (type))
>
> These two comments still conflict.  And why wouldn't you want to
> promote return values?

We only want to promote function parameters passed/returned in register.
But  I can't tell if a value will be passed in register or memory inside of
TARGET_FUNCTION_VALUE.  So when FOR_RETURN is 1, we don't
promote. Even if we don't promote it explicitly, hardware still zero-extends
it for us. So it isn't a real issue.

-- 
H.J.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: PATCH [3/n] X32: Promote pointers to Pmode
  2011-07-11  0:04       ` H.J. Lu
@ 2011-07-11  1:16         ` Richard Henderson
  2011-07-11  1:47           ` H.J. Lu
  0 siblings, 1 reply; 22+ messages in thread
From: Richard Henderson @ 2011-07-11  1:16 UTC (permalink / raw)
  To: H.J. Lu; +Cc: Uros Bizjak, gcc-patches

On 07/10/2011 03:01 PM, H.J. Lu wrote:
> We only want to promote function parameters passed/returned in register.
> But  I can't tell if a value will be passed in register or memory inside of
> TARGET_FUNCTION_VALUE.  So when FOR_RETURN is 1, we don't
> promote. Even if we don't promote it explicitly, hardware still zero-extends
> it for us. So it isn't a real issue.

The hardware *usually* zero-extends.  It all depends on where the data is
coming from.  Without certainty, i.e. actually representing it properly,
you're designing a broken ABI.

What you wrote above re T_F_V not being able to tell register or 
memory doesn't make sense.  Did you really mean inside TARGET_PROMOTE_FUNCTION_MODE?
And why exactly wouldn't you be able to tell there?  Can you not find out
via a call to ix86_return_in_memory?


r~

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: PATCH [3/n] X32: Promote pointers to Pmode
  2011-07-11  1:16         ` Richard Henderson
@ 2011-07-11  1:47           ` H.J. Lu
  2011-07-13 14:07             ` H.J. Lu
  0 siblings, 1 reply; 22+ messages in thread
From: H.J. Lu @ 2011-07-11  1:47 UTC (permalink / raw)
  To: Richard Henderson; +Cc: Uros Bizjak, gcc-patches

On Sun, Jul 10, 2011 at 5:48 PM, Richard Henderson <rth@redhat.com> wrote:
> On 07/10/2011 03:01 PM, H.J. Lu wrote:
>> We only want to promote function parameters passed/returned in register.
>> But  I can't tell if a value will be passed in register or memory inside of
>> TARGET_FUNCTION_VALUE.  So when FOR_RETURN is 1, we don't
>> promote. Even if we don't promote it explicitly, hardware still zero-extends
>> it for us. So it isn't a real issue.
>
> The hardware *usually* zero-extends.  It all depends on where the data is
> coming from.  Without certainty, i.e. actually representing it properly,
> you're designing a broken ABI.
>
> What you wrote above re T_F_V not being able to tell register or
> memory doesn't make sense.  Did you really mean inside TARGET_PROMOTE_FUNCTION_MODE?
> And why exactly wouldn't you be able to tell there?  Can you not find out
> via a call to ix86_return_in_memory?
>

TARGET_PROMOTE_FUNCTION_MODE is for passing/returning
value in a register and the documentation says that:

    FOR_RETURN allows to distinguish the promotion of arguments and
    return values.  If it is `1', a return value is being promoted and
    `TARGET_FUNCTION_VALUE' must perform the same promotions done here.
    If it is `2', the returned mode should be that of the register in
    which an incoming parameter is copied, or the outgoing result is
    computed; then the hook should return the same mode as
    `promote_mode', though the signedness may be different.


But for TARGET_FUNCTION_VALUE, there is no difference for
register and memory.  That is why I don't promote when
FOR_RETURN is 1.  mmix/mmix.c and rx/rx.c have similar
treatment.

-- 
H.J.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: PATCH [3/n] X32: Promote pointers to Pmode
  2011-07-10 19:56   ` H.J. Lu
  2011-07-10 23:51     ` Richard Henderson
@ 2011-07-13 13:42     ` H.J. Lu
  2011-07-13 13:48       ` Uros Bizjak
  1 sibling, 1 reply; 22+ messages in thread
From: H.J. Lu @ 2011-07-13 13:42 UTC (permalink / raw)
  To: Uros Bizjak; +Cc: gcc-patches

PING.

On Sun, Jul 10, 2011 at 12:43 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Sun, Jul 10, 2011 at 7:32 AM, Uros Bizjak <ubizjak@gmail.com> wrote:
>> On Sat, Jul 9, 2011 at 11:28 PM, H.J. Lu <hongjiu.lu@intel.com> wrote:
>>
>>> X32 psABI requires promoting pointers to Pmode when passing/returning
>>> in registers.  OK for trunk?
>>>
>>> Thanks.
>>>
>>> H.J.
>>> --
>>> 2011-07-09  H.J. Lu  <hongjiu.lu@intel.com>
>>>
>>>        * config/i386/i386.c (ix86_promote_function_mode): New.
>>>        (TARGET_PROMOTE_FUNCTION_MODE): Likewise.
>>>
>>> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
>>> index 04cb07d..c852719 100644
>>> --- a/gcc/config/i386/i386.c
>>> +++ b/gcc/config/i386/i386.c
>>> @@ -7052,6 +7061,23 @@ ix86_function_value (const_tree valtype, const_tree fntype_or_decl,
>>>   return ix86_function_value_1 (valtype, fntype_or_decl, orig_mode, mode);
>>>  }
>>>
>>> +/* Pointer function arguments and return values are promoted to
>>> +   Pmode.  */
>>> +
>>> +static enum machine_mode
>>> +ix86_promote_function_mode (const_tree type, enum machine_mode mode,
>>> +                           int *punsignedp, const_tree fntype,
>>> +                           int for_return)
>>> +{
>>> +  if (for_return != 1 && type != NULL_TREE && POINTER_TYPE_P (type))
>>> +    {
>>> +      *punsignedp = POINTERS_EXTEND_UNSIGNED;
>>> +      return Pmode;
>>> +    }
>>> +  return default_promote_function_mode (type, mode, punsignedp, fntype,
>>> +                                       for_return);
>>> +}
>>
>> Please rewrite the condition to:
>>
>> if (for_return == 1)
>>  /* Do not promote function return values.  */
>>  ;
>> else if (type != NULL_TREE && ...)
>>
>> Also, please add some comments.
>>
>> Your comment also says that pointer return arguments are promoted to
>> Pmode. The documentation says that:
>>
>>     FOR_RETURN allows to distinguish the promotion of arguments and
>>     return values.  If it is `1', a return value is being promoted and
>>     `TARGET_FUNCTION_VALUE' must perform the same promotions done here.
>>     If it is `2', the returned mode should be that of the register in
>>     which an incoming parameter is copied, or the outgoing result is
>>     computed; then the hook should return the same mode as
>>     `promote_mode', though the signedness may be different.
>>
>> You bypass promotions when FOR_RETURN is 1.
>>
>> Uros.
>>
>
> Here is the updated patch. OK for trunk?
>
> Thanks.
>
> --
> H.J.
> --
> 2011-07-10  H.J. Lu  <hongjiu.lu@intel.com>
>
>        * config/i386/i386.c (ix86_promote_function_mode): New.
>        (TARGET_PROMOTE_FUNCTION_MODE): Likewise.
>
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index 04cb07d..1b02312 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -7052,6 +7061,27 @@ ix86_function_value (const_tree valtype,
> const_tree fntype_or_decl,
>   return ix86_function_value_1 (valtype, fntype_or_decl, orig_mode, mode);
>  }
>
> +/* Pointer function arguments and return values are promoted to Pmode.
> +   If FOR_RETURN is 1, this function must behave in the same way with
> +   regard to function returns as TARGET_FUNCTION_VALUE.  */
> +
> +static enum machine_mode
> +ix86_promote_function_mode (const_tree type, enum machine_mode mode,
> +                           int *punsignedp, const_tree fntype,
> +                           int for_return)
> +{
> +  if (for_return == 1)
> +    /* Do not promote function return values.  */
> +    ;
> +  else if (type != NULL_TREE && POINTER_TYPE_P (type))
> +    {
> +      *punsignedp = POINTERS_EXTEND_UNSIGNED;
> +      return Pmode;
> +    }
> +  return default_promote_function_mode (type, mode, punsignedp, fntype,
> +                                       for_return);
> +}
> +
>  rtx
>  ix86_libcall_value (enum machine_mode mode)
>  {
> @@ -34810,6 +35157,9 @@ ix86_autovectorize_vector_sizes (void)
>  #undef TARGET_FUNCTION_VALUE_REGNO_P
>  #define TARGET_FUNCTION_VALUE_REGNO_P ix86_function_value_regno_p
>
> +#undef TARGET_PROMOTE_FUNCTION_MODE
> +#define TARGET_PROMOTE_FUNCTION_MODE ix86_promote_function_mode
> +
>  #undef TARGET_SECONDARY_RELOAD
>  #define TARGET_SECONDARY_RELOAD ix86_secondary_reload
>



-- 
H.J.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: PATCH [3/n] X32: Promote pointers to Pmode
  2011-07-13 13:42     ` H.J. Lu
@ 2011-07-13 13:48       ` Uros Bizjak
  0 siblings, 0 replies; 22+ messages in thread
From: Uros Bizjak @ 2011-07-13 13:48 UTC (permalink / raw)
  To: H.J. Lu; +Cc: gcc-patches, Richard Henderson

On Wed, Jul 13, 2011 at 3:17 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> PING.

>> 2011-07-10  H.J. Lu  <hongjiu.lu@intel.com>
>>
>>        * config/i386/i386.c (ix86_promote_function_mode): New.
>>        (TARGET_PROMOTE_FUNCTION_MODE): Likewise.

You have discussed this with rth, the final approval should be from him.

Uros.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: PATCH [3/n] X32: Promote pointers to Pmode
  2011-07-11  1:47           ` H.J. Lu
@ 2011-07-13 14:07             ` H.J. Lu
  2011-07-13 15:36               ` Richard Henderson
  0 siblings, 1 reply; 22+ messages in thread
From: H.J. Lu @ 2011-07-13 14:07 UTC (permalink / raw)
  To: Richard Henderson; +Cc: Uros Bizjak, gcc-patches

Hi Richard,

Is my patch OK?

Thanks.


H.J.
----
On Sun, Jul 10, 2011 at 6:14 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Sun, Jul 10, 2011 at 5:48 PM, Richard Henderson <rth@redhat.com> wrote:
>> On 07/10/2011 03:01 PM, H.J. Lu wrote:
>>> We only want to promote function parameters passed/returned in register.
>>> But  I can't tell if a value will be passed in register or memory inside of
>>> TARGET_FUNCTION_VALUE.  So when FOR_RETURN is 1, we don't
>>> promote. Even if we don't promote it explicitly, hardware still zero-extends
>>> it for us. So it isn't a real issue.
>>
>> The hardware *usually* zero-extends.  It all depends on where the data is
>> coming from.  Without certainty, i.e. actually representing it properly,
>> you're designing a broken ABI.
>>
>> What you wrote above re T_F_V not being able to tell register or
>> memory doesn't make sense.  Did you really mean inside TARGET_PROMOTE_FUNCTION_MODE?
>> And why exactly wouldn't you be able to tell there?  Can you not find out
>> via a call to ix86_return_in_memory?
>>
>
> TARGET_PROMOTE_FUNCTION_MODE is for passing/returning
> value in a register and the documentation says that:
>
>    FOR_RETURN allows to distinguish the promotion of arguments and
>    return values.  If it is `1', a return value is being promoted and
>    `TARGET_FUNCTION_VALUE' must perform the same promotions done here.
>    If it is `2', the returned mode should be that of the register in
>    which an incoming parameter is copied, or the outgoing result is
>    computed; then the hook should return the same mode as
>    `promote_mode', though the signedness may be different.
>
>
> But for TARGET_FUNCTION_VALUE, there is no difference for
> register and memory.  That is why I don't promote when
> FOR_RETURN is 1.  mmix/mmix.c and rx/rx.c have similar
> treatment.
>

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: PATCH [3/n] X32: Promote pointers to Pmode
  2011-07-13 14:07             ` H.J. Lu
@ 2011-07-13 15:36               ` Richard Henderson
  2011-07-13 15:38                 ` H.J. Lu
  0 siblings, 1 reply; 22+ messages in thread
From: Richard Henderson @ 2011-07-13 15:36 UTC (permalink / raw)
  To: H.J. Lu; +Cc: Uros Bizjak, gcc-patches

On 07/13/2011 07:02 AM, H.J. Lu wrote:
> Hi Richard,
> 
> Is my patch OK?

No, I don't think it is.


r~

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: PATCH [3/n] X32: Promote pointers to Pmode
  2011-07-13 15:36               ` Richard Henderson
@ 2011-07-13 15:38                 ` H.J. Lu
  2011-07-13 16:13                   ` Richard Henderson
  0 siblings, 1 reply; 22+ messages in thread
From: H.J. Lu @ 2011-07-13 15:38 UTC (permalink / raw)
  To: Richard Henderson; +Cc: Uros Bizjak, gcc-patches

On Wed, Jul 13, 2011 at 8:27 AM, Richard Henderson <rth@redhat.com> wrote:
> On 07/13/2011 07:02 AM, H.J. Lu wrote:
>> Hi Richard,
>>
>> Is my patch OK?
>
> No, I don't think it is.
>

What is your suggestion?


-- 
H.J.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: PATCH [3/n] X32: Promote pointers to Pmode
  2011-07-13 15:38                 ` H.J. Lu
@ 2011-07-13 16:13                   ` Richard Henderson
  2011-07-14  7:36                     ` H.J. Lu
  2011-07-21 22:30                     ` H.J. Lu
  0 siblings, 2 replies; 22+ messages in thread
From: Richard Henderson @ 2011-07-13 16:13 UTC (permalink / raw)
  To: H.J. Lu; +Cc: Uros Bizjak, gcc-patches

On 07/13/2011 08:35 AM, H.J. Lu wrote:
> On Wed, Jul 13, 2011 at 8:27 AM, Richard Henderson <rth@redhat.com> wrote:
>> On 07/13/2011 07:02 AM, H.J. Lu wrote:
>>> Hi Richard,
>>>
>>> Is my patch OK?
>>
>> No, I don't think it is.
>>
> 
> What is your suggestion?

Promote the return value.  If that means it doesn't match function_value,
then I suggest that function_value is wrong.


r~

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: PATCH [3/n] X32: Promote pointers to Pmode
  2011-07-13 16:13                   ` Richard Henderson
@ 2011-07-14  7:36                     ` H.J. Lu
  2011-07-21 22:30                     ` H.J. Lu
  1 sibling, 0 replies; 22+ messages in thread
From: H.J. Lu @ 2011-07-14  7:36 UTC (permalink / raw)
  To: Richard Henderson; +Cc: Uros Bizjak, gcc-patches

On Wed, Jul 13, 2011 at 8:37 AM, Richard Henderson <rth@redhat.com> wrote:
> On 07/13/2011 08:35 AM, H.J. Lu wrote:
>> On Wed, Jul 13, 2011 at 8:27 AM, Richard Henderson <rth@redhat.com> wrote:
>>> On 07/13/2011 07:02 AM, H.J. Lu wrote:
>>>> Hi Richard,
>>>>
>>>> Is my patch OK?
>>>
>>> No, I don't think it is.
>>>
>>
>> What is your suggestion?
>
> Promote the return value.  If that means it doesn't match function_value,
> then I suggest that function_value is wrong.
>
>

static enum machine_mode
ix86_promote_function_mode (const_tree type, enum machine_mode mode,
                            int *punsignedp, const_tree fntype,
                            int for_return)
{
  if (type != NULL_TREE && POINTER_TYPE_P (type))
    {
      *punsignedp = POINTERS_EXTEND_UNSIGNED;
      return Pmode;
    }
  return default_promote_function_mode (type, mode, punsignedp, fntype,
                                        for_return);
}

doesn't work.  I got

In file included from
/export/gnu/import/git/gcc-x32/libgcc/config/libbid/bid_div_macros.h:27:0,
                 from
/export/gnu/import/git/gcc-x32/libgcc/config/libbid/bid128_div.c:25:
/export/gnu/import/git/gcc-x32/libgcc/config/libbid/bid_internal.h: In
function \u2018handle_UF_128.constprop.7\u2019:
/export/gnu/import/git/gcc-x32/libgcc/config/libbid/bid_internal.h:1626:1:
internal compiler error: in emit_move_insn, at expr.c:3349
Please submit a full bug report,
with preprocessed source if appropriate.

TARGET_FUNCTION_VALUE shouldn't promote pointers to Pmode
since it will also promote pointers passed in memory, which aren't
needed nor desired.

Since x86-64 processors ALWAYS zero-extend 32bit to 64bit
when writing 32bit registers, it is OK not to promote pointers
in TARGET_FUNCTION_VALUE.  We only need to promote
pointers to

static enum machine_mode
ix86_promote_function_mode (const_tree type, enum machine_mode mode,
                            int *punsignedp, const_tree fntype,
                            int for_return)
{
  if (for_return == 1)
    /* Do not promote function return values.  */
    ;
  else if (type != NULL_TREE && POINTER_TYPE_P (type))
    {
      *punsignedp = POINTERS_EXTEND_UNSIGNED;
      return Pmode;
    }
  return default_promote_function_mode (type, mode, punsignedp, fntype,
                                        for_return);
}

Richard, can you tell me what the real problem with my approach is?

Thanks.


-- 
H.J.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: PATCH [3/n] X32: Promote pointers to Pmode
  2011-07-13 16:13                   ` Richard Henderson
  2011-07-14  7:36                     ` H.J. Lu
@ 2011-07-21 22:30                     ` H.J. Lu
  2011-07-21 22:46                       ` Richard Henderson
  1 sibling, 1 reply; 22+ messages in thread
From: H.J. Lu @ 2011-07-21 22:30 UTC (permalink / raw)
  To: Richard Henderson; +Cc: Uros Bizjak, gcc-patches

[-- Attachment #1: Type: text/plain, Size: 807 bytes --]

On Wed, Jul 13, 2011 at 8:37 AM, Richard Henderson <rth@redhat.com> wrote:
> On 07/13/2011 08:35 AM, H.J. Lu wrote:
>> On Wed, Jul 13, 2011 at 8:27 AM, Richard Henderson <rth@redhat.com> wrote:
>>> On 07/13/2011 07:02 AM, H.J. Lu wrote:
>>>> Hi Richard,
>>>>
>>>> Is my patch OK?
>>>
>>> No, I don't think it is.
>>>
>>
>> What is your suggestion?
>
> Promote the return value.  If that means it doesn't match function_value,
> then I suggest that function_value is wrong.
>
>
> r~
>

This is the patch I am testing.  I will check it in if it works.

Thanks.

-- 
H.J.
---
2011-07-21  H.J. Lu  <hongjiu.lu@intel.com>

	* config/i386/i386.c (function_value_64): Always return pointers
	in Pmode.
	(ix86_promote_function_mode): New.
	(TARGET_PROMOTE_FUNCTION_MODE): Likewise.

[-- Attachment #2: gcc-x32-abi-3.patch --]
[-- Type: text/x-diff, Size: 1798 bytes --]

2011-07-21  H.J. Lu  <hongjiu.lu@intel.com>

	* config/i386/i386.c (function_value_64): Always return pointers
	in Pmode.
	(ix86_promote_function_mode): New.
	(TARGET_PROMOTE_FUNCTION_MODE): Likewise.

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index da6c888..32af303 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -7078,6 +7078,11 @@ function_value_64 (enum machine_mode orig_mode, enum machine_mode mode,
 	  return gen_rtx_REG (mode, AX_REG);
 	}
     }
+  else if (POINTER_TYPE_P (valtype))
+    {
+      /* Pointers are always returned in Pmode. */
+      mode = Pmode;
+    }
 
   ret = construct_container (mode, orig_mode, valtype, 1,
 			     X86_64_REGPARM_MAX, X86_64_SSE_REGPARM_MAX,
@@ -7147,6 +7152,22 @@ ix86_function_value (const_tree valtype, const_tree fntype_or_decl,
   return ix86_function_value_1 (valtype, fntype_or_decl, orig_mode, mode);
 }
 
+/* Pointer function arguments and return values are promoted to Pmode.  */
+
+static enum machine_mode
+ix86_promote_function_mode (const_tree type, enum machine_mode mode,
+			    int *punsignedp, const_tree fntype,
+			    int for_return)
+{
+  if (type != NULL_TREE && POINTER_TYPE_P (type))
+    {
+      *punsignedp = POINTERS_EXTEND_UNSIGNED;
+      return Pmode;
+    }
+  return default_promote_function_mode (type, mode, punsignedp, fntype,
+					for_return);
+}
+
 rtx
 ix86_libcall_value (enum machine_mode mode)
 {
@@ -34970,6 +35055,9 @@ ix86_autovectorize_vector_sizes (void)
 #undef TARGET_FUNCTION_VALUE_REGNO_P
 #define TARGET_FUNCTION_VALUE_REGNO_P ix86_function_value_regno_p
 
+#undef TARGET_PROMOTE_FUNCTION_MODE
+#define TARGET_PROMOTE_FUNCTION_MODE ix86_promote_function_mode
+
 #undef TARGET_SECONDARY_RELOAD
 #define TARGET_SECONDARY_RELOAD ix86_secondary_reload
 

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: PATCH [3/n] X32: Promote pointers to Pmode
  2011-07-21 22:30                     ` H.J. Lu
@ 2011-07-21 22:46                       ` Richard Henderson
  2011-07-22  0:10                         ` H.J. Lu
  0 siblings, 1 reply; 22+ messages in thread
From: Richard Henderson @ 2011-07-21 22:46 UTC (permalink / raw)
  To: H.J. Lu; +Cc: Uros Bizjak, gcc-patches

On 07/21/2011 03:02 PM, H.J. Lu wrote:
> 	* config/i386/i386.c (function_value_64): Always return pointers
> 	in Pmode.
> 	(ix86_promote_function_mode): New.
> 	(TARGET_PROMOTE_FUNCTION_MODE): Likewise.

Much better, thanks.


r~

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: PATCH [3/n] X32: Promote pointers to Pmode
  2011-07-21 22:46                       ` Richard Henderson
@ 2011-07-22  0:10                         ` H.J. Lu
  2011-07-22  3:23                           ` Richard Henderson
  0 siblings, 1 reply; 22+ messages in thread
From: H.J. Lu @ 2011-07-22  0:10 UTC (permalink / raw)
  To: Richard Henderson; +Cc: Uros Bizjak, gcc-patches

On Thu, Jul 21, 2011 at 3:05 PM, Richard Henderson <rth@redhat.com> wrote:
> On 07/21/2011 03:02 PM, H.J. Lu wrote:
>>       * config/i386/i386.c (function_value_64): Always return pointers
>>       in Pmode.
>>       (ix86_promote_function_mode): New.
>>       (TARGET_PROMOTE_FUNCTION_MODE): Likewise.
>
> Much better, thanks.
>
>
> r~
>

Also need this patch.  Otherwise, I got

FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2a.c (internal compiler error)
FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2a.c (test for excess errors)
FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2b.c (internal compiler error)
FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2b.c (test for excess errors)

OK for trunk?

Thanks.


-- 
H.J.
--
2011-07-21  H.J. Lu  <hongjiu.lu@intel.com>

	* config/i386/i386.c (function_value_ms_64): Take a new argument.
	Always return pointers in Pmode.
	(ix86_function_value_1): Updated.

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index b603f4e..9bc2eef 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -7097,11 +7097,17 @@ function_value_64 (enum machine_mode
orig_mode, enum machine_mode mode,
 }

 static rtx
-function_value_ms_64 (enum machine_mode orig_mode, enum machine_mode mode)
+function_value_ms_64 (enum machine_mode orig_mode, enum machine_mode mode,
+		      const_tree valtype)
 {
   unsigned int regno = AX_REG;

-  if (TARGET_SSE)
+  if (valtype && POINTER_TYPE_P (valtype))
+    {
+      /* Pointers are always returned in Pmode. */
+      orig_mode = Pmode;
+    }
+  else if (TARGET_SSE)
     {
       switch (GET_MODE_SIZE (mode))
         {
@@ -7134,7 +7140,7 @@ ix86_function_value_1 (const_tree valtype,
const_tree fntype_or_decl,
   fntype = fn ? TREE_TYPE (fn) : fntype_or_decl;

   if (TARGET_64BIT && ix86_function_type_abi (fntype) == MS_ABI)
-    return function_value_ms_64 (orig_mode, mode);
+    return function_value_ms_64 (orig_mode, mode, valtype);
   else if (TARGET_64BIT)
     return function_value_64 (orig_mode, mode, valtype);
   else

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: PATCH [3/n] X32: Promote pointers to Pmode
  2011-07-22  0:10                         ` H.J. Lu
@ 2011-07-22  3:23                           ` Richard Henderson
  2011-07-22  4:22                             ` H.J. Lu
  0 siblings, 1 reply; 22+ messages in thread
From: Richard Henderson @ 2011-07-22  3:23 UTC (permalink / raw)
  To: H.J. Lu; +Cc: Uros Bizjak, gcc-patches

On 07/21/2011 04:28 PM, H.J. Lu wrote:
> On Thu, Jul 21, 2011 at 3:05 PM, Richard Henderson <rth@redhat.com> wrote:
>> On 07/21/2011 03:02 PM, H.J. Lu wrote:
>>>       * config/i386/i386.c (function_value_64): Always return pointers
>>>       in Pmode.
>>>       (ix86_promote_function_mode): New.
>>>       (TARGET_PROMOTE_FUNCTION_MODE): Likewise.
>>
>> Much better, thanks.
>>
>>
>> r~
>>
> 
> Also need this patch.  Otherwise, I got
> 
> FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2a.c (internal compiler error)
> FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2a.c (test for excess errors)
> FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2b.c (internal compiler error)
> FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2b.c (test for excess errors)
> 
> OK for trunk?

Hmm.  Should we even be running ms_64 callabi tests across pointer sizes though?


r~

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: PATCH [3/n] X32: Promote pointers to Pmode
  2011-07-22  3:23                           ` Richard Henderson
@ 2011-07-22  4:22                             ` H.J. Lu
  2011-07-22  8:08                               ` H.J. Lu
  0 siblings, 1 reply; 22+ messages in thread
From: H.J. Lu @ 2011-07-22  4:22 UTC (permalink / raw)
  To: Richard Henderson; +Cc: Uros Bizjak, gcc-patches

On Thu, Jul 21, 2011 at 4:51 PM, Richard Henderson <rth@redhat.com> wrote:
> On 07/21/2011 04:28 PM, H.J. Lu wrote:
>> On Thu, Jul 21, 2011 at 3:05 PM, Richard Henderson <rth@redhat.com> wrote:
>>> On 07/21/2011 03:02 PM, H.J. Lu wrote:
>>>>       * config/i386/i386.c (function_value_64): Always return pointers
>>>>       in Pmode.
>>>>       (ix86_promote_function_mode): New.
>>>>       (TARGET_PROMOTE_FUNCTION_MODE): Likewise.
>>>
>>> Much better, thanks.
>>>
>>>
>>> r~
>>>
>>
>> Also need this patch.  Otherwise, I got
>>
>> FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2a.c (internal compiler error)
>> FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2a.c (test for excess errors)
>> FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2b.c (internal compiler error)
>> FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2b.c (test for excess errors)
>>
>> OK for trunk?
>
> Hmm.  Should we even be running ms_64 callabi tests across pointer sizes though?
>

Good question.  I can disable the test.  But compiler will still ICE on this
input.


-- 
H.J.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: PATCH [3/n] X32: Promote pointers to Pmode
  2011-07-22  4:22                             ` H.J. Lu
@ 2011-07-22  8:08                               ` H.J. Lu
  2011-07-22 13:31                                 ` H.J. Lu
  0 siblings, 1 reply; 22+ messages in thread
From: H.J. Lu @ 2011-07-22  8:08 UTC (permalink / raw)
  To: Richard Henderson; +Cc: Uros Bizjak, gcc-patches

On Thu, Jul 21, 2011 at 5:36 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Thu, Jul 21, 2011 at 4:51 PM, Richard Henderson <rth@redhat.com> wrote:
>> On 07/21/2011 04:28 PM, H.J. Lu wrote:
>>> On Thu, Jul 21, 2011 at 3:05 PM, Richard Henderson <rth@redhat.com> wrote:
>>>> On 07/21/2011 03:02 PM, H.J. Lu wrote:
>>>>>       * config/i386/i386.c (function_value_64): Always return pointers
>>>>>       in Pmode.
>>>>>       (ix86_promote_function_mode): New.
>>>>>       (TARGET_PROMOTE_FUNCTION_MODE): Likewise.
>>>>
>>>> Much better, thanks.
>>>>
>>>>
>>>> r~
>>>>
>>>
>>> Also need this patch.  Otherwise, I got
>>>
>>> FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2a.c (internal compiler error)
>>> FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2a.c (test for excess errors)
>>> FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2b.c (internal compiler error)
>>> FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2b.c (test for excess errors)
>>>
>>> OK for trunk?
>>
>> Hmm.  Should we even be running ms_64 callabi tests across pointer sizes though?
>>
>
> Good question.  I can disable the test.  But compiler will still ICE on this
> input.
>
>

How about this patch?  OK for trunk?

Thanks.

-- 
H.J.
---
gcc/

2011-07-21  H.J. Lu  <hongjiu.lu@intel.com>

	* config/i386/i386.c (ix86_option_override_internal): Disallow
	MS ABI in x32 mode.
	(ix86_init_builtins): Call ix86_init_builtins_va_builtins_abi
	only for TARGET_LP64.
	(ix86_handle_abi_attribute): Check TARGET_LP64 instead of
	TARGET_64BIT.

gcc/testsuite/

2011-07-21  H.J. Lu  <hongjiu.lu@intel.com>

	* gcc.target/x86_64/abi/callabi/callabi.exp: Check ilp32
	instead of ia32.

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 9e3532e..6e030d9 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -3133,6 +3133,9 @@ ix86_option_override_internal (bool main_args_p)
   if (!global_options_set.x_ix86_abi)
     ix86_abi = DEFAULT_ABI;

+  if (ix86_abi == MS_ABI && TARGET_X32)
+    error ("MS ABI not supported in x32 mode");
+
   if (global_options_set.x_ix86_cmodel)
     {
       switch (ix86_cmodel)
@@ -25520,7 +25523,7 @@ ix86_init_builtins (void)

   ix86_init_mmx_sse_builtins ();

-  if (TARGET_64BIT)
+  if (TARGET_LP64)
     ix86_init_builtins_va_builtins_abi ();

 #ifdef SUBTARGET_INIT_BUILTINS
@@ -29340,7 +29343,7 @@ ix86_handle_abi_attribute (tree *node, tree name,
       *no_add_attrs = true;
       return NULL_TREE;
     }
-  if (!TARGET_64BIT)
+  if (!TARGET_LP64)
     {
       warning (OPT_Wattributes, "%qE attribute only available for 64-bit",
 	       name);
diff --git a/gcc/testsuite/gcc.target/x86_64/abi/callabi/callabi.exp
b/gcc/testsuite/gcc.target/x86_64/abi/callabi/callabi.exp
index b0cba17..e76d0c1 100644
--- a/gcc/testsuite/gcc.target/x86_64/abi/callabi/callabi.exp
+++ b/gcc/testsuite/gcc.target/x86_64/abi/callabi/callabi.exp
@@ -20,7 +20,7 @@
 load_lib gcc-dg.exp

 if { (![istarget x86_64-*-*] && ![istarget i?86-*-*])
-     || [is-effective-target ia32] } then {
+     || [is-effective-target ilp32] } then {
   return
 }

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: PATCH [3/n] X32: Promote pointers to Pmode
  2011-07-22  8:08                               ` H.J. Lu
@ 2011-07-22 13:31                                 ` H.J. Lu
  2011-07-22 16:34                                   ` Richard Henderson
  0 siblings, 1 reply; 22+ messages in thread
From: H.J. Lu @ 2011-07-22 13:31 UTC (permalink / raw)
  To: Richard Henderson; +Cc: Uros Bizjak, gcc-patches

[-- Attachment #1: Type: text/plain, Size: 2203 bytes --]

On Thu, Jul 21, 2011 at 10:14 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Thu, Jul 21, 2011 at 5:36 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Thu, Jul 21, 2011 at 4:51 PM, Richard Henderson <rth@redhat.com> wrote:
>>> On 07/21/2011 04:28 PM, H.J. Lu wrote:
>>>> On Thu, Jul 21, 2011 at 3:05 PM, Richard Henderson <rth@redhat.com> wrote:
>>>>> On 07/21/2011 03:02 PM, H.J. Lu wrote:
>>>>>>       * config/i386/i386.c (function_value_64): Always return pointers
>>>>>>       in Pmode.
>>>>>>       (ix86_promote_function_mode): New.
>>>>>>       (TARGET_PROMOTE_FUNCTION_MODE): Likewise.
>>>>>
>>>>> Much better, thanks.
>>>>>
>>>>>
>>>>> r~
>>>>>
>>>>
>>>> Also need this patch.  Otherwise, I got
>>>>
>>>> FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2a.c (internal compiler error)
>>>> FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2a.c (test for excess errors)
>>>> FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2b.c (internal compiler error)
>>>> FAIL: gcc.target/x86_64/abi/callabi/func-indirect-2b.c (test for excess errors)
>>>>
>>>> OK for trunk?
>>>
>>> Hmm.  Should we even be running ms_64 callabi tests across pointer sizes though?
>>>
>>
>> Good question.  I can disable the test.  But compiler will still ICE on this
>> input.
>>
>>
>
> How about this patch?  OK for trunk?
>

Need to skip all ms_abi tests for x32.  OK for trunk?

Thanks.

H.J.
----
gcc/

2011-07-21  H.J. Lu  <hongjiu.lu@intel.com>

	* config/i386/i386.c (ix86_option_override_internal): Disallow
	MS ABI in x32 mode.
	(ix86_init_builtins): Call ix86_init_builtins_va_builtins_abi
	only for TARGET_LP64.
	(ix86_handle_abi_attribute): Check TARGET_LP64 instead of
	TARGET_64BIT.

gcc/testsuite/

2011-07-21  H.J. Lu  <hongjiu.lu@intel.com>

	* gcc/testsuite/gcc.target/i386/avx-vzeroupper-16.c: Only run
	on lp64 targets.
	* gcc/testsuite/gcc.target/i386/avx-vzeroupper-17.c: Likewise.
	* gcc/testsuite/gcc.target/i386/avx-vzeroupper-18.c: Likewise.
	* gcc/testsuite/gcc.target/i386/pr43662.c: Likewise.
	* gcc/testsuite/gcc.target/i386/pr43869.c: Likewise.

	* gcc.target/x86_64/abi/callabi/callabi.exp: Check ilp32
	instead of ia32.

[-- Attachment #2: gcc-x32-abi-ms-2.patch --]
[-- Type: text/plain, Size: 4504 bytes --]

gcc/

2011-07-21  H.J. Lu  <hongjiu.lu@intel.com>
 
	* config/i386/i386.c (ix86_option_override_internal): Disallow
	MS ABI in x32 mode.
	(ix86_init_builtins): Call ix86_init_builtins_va_builtins_abi
	only for TARGET_LP64.
	(ix86_handle_abi_attribute): Check TARGET_LP64 instead of
	TARGET_64BIT.

gcc/testsuite/

2011-07-21  H.J. Lu  <hongjiu.lu@intel.com>

	* gcc/testsuite/gcc.target/i386/avx-vzeroupper-16.c: Only run
	on lp64 targets.
	* gcc/testsuite/gcc.target/i386/avx-vzeroupper-17.c: Likewise.
	* gcc/testsuite/gcc.target/i386/avx-vzeroupper-18.c: Likewise.
	* gcc/testsuite/gcc.target/i386/pr43662.c: Likewise.
	* gcc/testsuite/gcc.target/i386/pr43869.c: Likewise.

	* gcc.target/x86_64/abi/callabi/callabi.exp: Check ilp32
	instead of ia32.

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 9e3532e..6e030d9 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -3133,6 +3133,9 @@ ix86_option_override_internal (bool main_args_p)
   if (!global_options_set.x_ix86_abi)
     ix86_abi = DEFAULT_ABI;
 
+  if (ix86_abi == MS_ABI && TARGET_X32)
+    error ("MS ABI not supported in x32 mode");
+
   if (global_options_set.x_ix86_cmodel)
     {
       switch (ix86_cmodel)
@@ -25520,7 +25523,7 @@ ix86_init_builtins (void)
 
   ix86_init_mmx_sse_builtins ();
 
-  if (TARGET_64BIT)
+  if (TARGET_LP64)
     ix86_init_builtins_va_builtins_abi ();
 
 #ifdef SUBTARGET_INIT_BUILTINS
@@ -29340,7 +29343,7 @@ ix86_handle_abi_attribute (tree *node, tree name,
       *no_add_attrs = true;
       return NULL_TREE;
     }
-  if (!TARGET_64BIT)
+  if (!TARGET_LP64)
     {
       warning (OPT_Wattributes, "%qE attribute only available for 64-bit",
 	       name);
diff --git a/gcc/testsuite/gcc.target/x86_64/abi/callabi/callabi.exp b/gcc/testsuite/gcc.target/x86_64/abi/callabi/callabi.exp
index b0cba17..e76d0c1 100644
--- a/gcc/testsuite/gcc.target/x86_64/abi/callabi/callabi.exp
+++ b/gcc/testsuite/gcc.target/x86_64/abi/callabi/callabi.exp
@@ -20,7 +20,7 @@
 load_lib gcc-dg.exp
 
 if { (![istarget x86_64-*-*] && ![istarget i?86-*-*])
-     || [is-effective-target ia32] } then {
+     || [is-effective-target ilp32] } then {
   return
 }
 
diff --git a/gcc/testsuite/gcc.target/i386/avx-vzeroupper-16.c b/gcc/testsuite/gcc.target/i386/avx-vzeroupper-16.c
index 095640a..bc6e0d2 100644
--- a/gcc/testsuite/gcc.target/i386/avx-vzeroupper-16.c
+++ b/gcc/testsuite/gcc.target/i386/avx-vzeroupper-16.c
@@ -1,4 +1,4 @@
-/* { dg-do compile { target { ! { ia32 } } } } */
+/* { dg-do compile { target lp64 } } */
 /* { dg-options "-O2 -mavx -mabi=ms -mtune=generic -dp" } */
 
 typedef float __m256 __attribute__ ((__vector_size__ (32), __may_alias__));
diff --git a/gcc/testsuite/gcc.target/i386/avx-vzeroupper-17.c b/gcc/testsuite/gcc.target/i386/avx-vzeroupper-17.c
index ef293b3..5d3aa48 100644
--- a/gcc/testsuite/gcc.target/i386/avx-vzeroupper-17.c
+++ b/gcc/testsuite/gcc.target/i386/avx-vzeroupper-17.c
@@ -1,4 +1,4 @@
-/* { dg-do compile { target { ! { ia32 } } } } */
+/* { dg-do compile { target lp64 } } */
 /* { dg-options "-O2 -mavx -mabi=ms -mtune=generic -dp" } */
 
 typedef float __m256 __attribute__ ((__vector_size__ (32), __may_alias__));
diff --git a/gcc/testsuite/gcc.target/i386/avx-vzeroupper-18.c b/gcc/testsuite/gcc.target/i386/avx-vzeroupper-18.c
index 046b7ef..0630752 100644
--- a/gcc/testsuite/gcc.target/i386/avx-vzeroupper-18.c
+++ b/gcc/testsuite/gcc.target/i386/avx-vzeroupper-18.c
@@ -1,4 +1,4 @@
-/* { dg-do compile { target { ! { ia32 } } } } */
+/* { dg-do compile { target lp64 } } */
 /* { dg-options "-O0 -mavx -mabi=ms -mtune=generic -dp" } */
 
 typedef float __m256 __attribute__ ((__vector_size__ (32), __may_alias__));
diff --git a/gcc/testsuite/gcc.target/i386/pr43662.c b/gcc/testsuite/gcc.target/i386/pr43662.c
index 5e75dc5..2896a1a 100644
--- a/gcc/testsuite/gcc.target/i386/pr43662.c
+++ b/gcc/testsuite/gcc.target/i386/pr43662.c
@@ -1,4 +1,4 @@
-/* { dg-do compile { target { ! { ia32 } } } } */
+/* { dg-do compile { target lp64 } } */
 /* { dg-options "-O2" } */
 
 void __attribute__ ((ms_abi)) foo (void)
diff --git a/gcc/testsuite/gcc.target/i386/pr43869.c b/gcc/testsuite/gcc.target/i386/pr43869.c
index 5513b19..4157db1 100644
--- a/gcc/testsuite/gcc.target/i386/pr43869.c
+++ b/gcc/testsuite/gcc.target/i386/pr43869.c
@@ -1,4 +1,4 @@
-/* { dg-do compile { target { ! { ia32 } } } } */
+/* { dg-do compile { target lp64 } } */
 
 int __attribute__((__noinline__))
 bugged(float f1, float f2, float f3, float f4,

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: PATCH [3/n] X32: Promote pointers to Pmode
  2011-07-22 13:31                                 ` H.J. Lu
@ 2011-07-22 16:34                                   ` Richard Henderson
  0 siblings, 0 replies; 22+ messages in thread
From: Richard Henderson @ 2011-07-22 16:34 UTC (permalink / raw)
  To: H.J. Lu; +Cc: Uros Bizjak, gcc-patches

On 07/22/2011 06:07 AM, H.J. Lu wrote:
> 2011-07-21  H.J. Lu  <hongjiu.lu@intel.com>
> 
> 	* config/i386/i386.c (ix86_option_override_internal): Disallow
> 	MS ABI in x32 mode.
> 	(ix86_init_builtins): Call ix86_init_builtins_va_builtins_abi
> 	only for TARGET_LP64.
> 	(ix86_handle_abi_attribute): Check TARGET_LP64 instead of
> 	TARGET_64BIT.
> 
> gcc/testsuite/
> 
> 2011-07-21  H.J. Lu  <hongjiu.lu@intel.com>
> 
> 	* gcc/testsuite/gcc.target/i386/avx-vzeroupper-16.c: Only run
> 	on lp64 targets.
> 	* gcc/testsuite/gcc.target/i386/avx-vzeroupper-17.c: Likewise.
> 	* gcc/testsuite/gcc.target/i386/avx-vzeroupper-18.c: Likewise.
> 	* gcc/testsuite/gcc.target/i386/pr43662.c: Likewise.
> 	* gcc/testsuite/gcc.target/i386/pr43869.c: Likewise.
> 
> 	* gcc.target/x86_64/abi/callabi/callabi.exp: Check ilp32
> 	instead of ia32.

Ok.


r~

^ permalink raw reply	[flat|nested] 22+ messages in thread

end of thread, other threads:[~2011-07-22 15:54 UTC | newest]

Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-07-09 21:37 PATCH [3/n] X32: Promote pointers to Pmode H.J. Lu
2011-07-10 16:37 ` Uros Bizjak
2011-07-10 19:56   ` H.J. Lu
2011-07-10 23:51     ` Richard Henderson
2011-07-11  0:04       ` H.J. Lu
2011-07-11  1:16         ` Richard Henderson
2011-07-11  1:47           ` H.J. Lu
2011-07-13 14:07             ` H.J. Lu
2011-07-13 15:36               ` Richard Henderson
2011-07-13 15:38                 ` H.J. Lu
2011-07-13 16:13                   ` Richard Henderson
2011-07-14  7:36                     ` H.J. Lu
2011-07-21 22:30                     ` H.J. Lu
2011-07-21 22:46                       ` Richard Henderson
2011-07-22  0:10                         ` H.J. Lu
2011-07-22  3:23                           ` Richard Henderson
2011-07-22  4:22                             ` H.J. Lu
2011-07-22  8:08                               ` H.J. Lu
2011-07-22 13:31                                 ` H.J. Lu
2011-07-22 16:34                                   ` Richard Henderson
2011-07-13 13:42     ` H.J. Lu
2011-07-13 13:48       ` Uros Bizjak

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).