This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH [2/n]: Prepare x32: Convert pointer to TLS symbol if needed
- From: Richard Sandiford <richard dot sandiford at linaro dot org>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Wed, 29 Jun 2011 09:45:06 +0100
- Subject: Re: PATCH [2/n]: Prepare x32: Convert pointer to TLS symbol if needed
- References: <20110611154235.GA19926@intel.com>
"H.J. Lu" <hongjiu.lu@intel.com> writes:
> @@ -706,7 +706,13 @@ precompute_register_parameters (int num_actuals, struct arg_data *args,
> pseudo now. TLS symbols sometimes need a call to resolve. */
> if (CONSTANT_P (args[i].value)
> && !targetm.legitimate_constant_p (args[i].mode, args[i].value))
> - args[i].value = force_reg (args[i].mode, args[i].value);
> + {
> + if (GET_MODE (args[i].value) != args[i].mode)
> + args[i].value = convert_to_mode (args[i].mode,
> + args[i].value,
> + args[i].unsignedp);
> + args[i].value = force_reg (args[i].mode, args[i].value);
> + }
But if GET_MODE (args[i].value) != args[i].mode, then the call to
targetm.legitimate_constant_p looks wrong. The mode passed in the
first argument is supposed to the mode of the second argument.
Is there any reason why this and the following:
/* If we are to promote the function arg to a wider mode,
do it now. */
if (args[i].mode != TYPE_MODE (TREE_TYPE (args[i].tree_value)))
args[i].value
= convert_modes (args[i].mode,
TYPE_MODE (TREE_TYPE (args[i].tree_value)),
args[i].value, args[i].unsignedp);
need to be done in the current order? I 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.)
Richard