* 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).