From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-295558-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 30370 invoked by alias); 29 Jun 2011 14:06:49 -0000
Received: (qmail 30346 invoked by uid 22791); 29 Jun 2011 14:06:47 -0000
X-SWARE-Spam-Status: No, hits=-2.3 required=5.0	tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,T_TO_NO_BRKTS_FREEMAIL
X-Spam-Check-By: sourceware.org
Received: from mail-qy0-f175.google.com (HELO mail-qy0-f175.google.com) (209.85.216.175)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 29 Jun 2011 14:06:32 +0000
Received: by qyk30 with SMTP id 30so2583402qyk.20        for <gcc-patches@gcc.gnu.org>; Wed, 29 Jun 2011 07:06:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.98.206 with SMTP id r14mr622834qcn.18.1309356391969; Wed, 29 Jun 2011 07:06:31 -0700 (PDT)
Received: by 10.229.214.83 with HTTP; Wed, 29 Jun 2011 07:06:31 -0700 (PDT)
In-Reply-To: <g4liwlm3fx.fsf@linaro.org>
References: <20110611154235.GA19926@intel.com>	<g4liwlm3fx.fsf@linaro.org>
Date: Wed, 29 Jun 2011 14:39:00 -0000
Message-ID: <BANLkTinuPKbSHAfE+DviMYCwhHmqVVk-fg@mail.gmail.com>
Subject: Re: PATCH [2/n]: Prepare x32: Convert pointer to TLS symbol if needed
From: "H.J. Lu" <hjl.tools@gmail.com>
To: gcc-patches@gcc.gnu.org, richard.sandiford@linaro.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-IsSubscribed: yes
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
X-SW-Source: 2011-06/txt/msg02243.txt.bz2

On Wed, Jun 29, 2011 at 1:45 AM, Richard Sandiford
<richard.sandiford@linaro.org> wrote:
> "H.J. Lu" <hongjiu.lu@intel.com> writes:
>> @@ -706,7 +706,13 @@ precompute_register_parameters (int num_actuals, st=
ruct arg_data *args,
>> =A0 =A0 =A0 =A0 =A0pseudo now. =A0TLS symbols sometimes need a call to r=
esolve. =A0*/
>> =A0 =A0 =A0 if (CONSTANT_P (args[i].value)
>> =A0 =A0 =A0 =A0 =A0 && !targetm.legitimate_constant_p (args[i].mode, arg=
s[i].value))
>> - =A0 =A0 =A0 args[i].value =3D force_reg (args[i].mode, args[i].value);
>> + =A0 =A0 =A0 {
>> + =A0 =A0 =A0 =A0 if (GET_MODE (args[i].value) !=3D args[i].mode)
>> + =A0 =A0 =A0 =A0 =A0 args[i].value =3D convert_to_mode (args[i].mode,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0args[i].value,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0args[i].unsignedp);
>> + =A0 =A0 =A0 =A0 args[i].value =3D force_reg (args[i].mode, args[i].val=
ue);
>> + =A0 =A0 =A0 }
>
> But if GET_MODE (args[i].value) !=3D args[i].mode, then the call to
> targetm.legitimate_constant_p looks wrong. =A0The mode passed in the
> first argument is supposed to the mode of the second argument.
>
> Is there any reason why this and the following:
>
> =A0 =A0 =A0 =A0/* If we are to promote the function arg to a wider mode,
> =A0 =A0 =A0 =A0 =A0 do it now. =A0*/
>
> =A0 =A0 =A0 =A0if (args[i].mode !=3D TYPE_MODE (TREE_TYPE (args[i].tree_v=
alue)))
> =A0 =A0 =A0 =A0 =A0args[i].value
> =A0 =A0 =A0 =A0 =A0 =A0=3D convert_modes (args[i].mode,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 TYPE_MODE (TREE_T=
YPE (args[i].tree_value)),
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 args[i].value, ar=
gs[i].unsignedp);
>
> need to be done in the current order? =A0I can't think of any off-hand.
> If not, would swapping them also fix the bug?
>
> (I can't review this either way, of course.)

It works on the testcase.  I will do a full test.

Thanks.

--=20
H.J.