Make assemble_real generate canonical CONST_INTs
authorRichard Sandiford <richard.sandiford@arm.com>
Wed, 18 Sep 2019 11:37:02 +0000 (11:37 +0000)
committerRichard Sandiford <rsandifo@gcc.gnu.org>
Wed, 18 Sep 2019 11:37:02 +0000 (11:37 +0000)
commit743a16d57a4f9f65bbc663100d5e16c564f283ec
treec8f6533dc06f9ec92b25c46db395fd42100eaf58
parenta3d09469041ab66ee1e12c2f3e4de33c4bf96732
Make assemble_real generate canonical CONST_INTs

assemble_real used GEN_INT to create integers directly from the
longs returned by real_to_target.  assemble_integer then went on
to interpret the const_ints as though they had the mode corresponding
to the accompanying size parameter:

      imode = mode_for_size (size * BITS_PER_UNIT, mclass, 0).require ();

      for (i = 0; i < size; i += subsize)
{
  rtx partial = simplify_subreg (omode, x, imode, i);

But in the assemble_real case, X might not be canonical for IMODE.

If the interface to assemble_integer is supposed to allow outputting
(say) the low 4 bytes of a DImode integer, then the simplify_subreg
above is wrong.  But if the number of bytes passed to assemble_integer
is supposed to be the number of bytes that the integer actually contains,
assemble_real is wrong.

This patch takes the latter interpretation and makes assemble_real
generate const_ints that are canonical for the number of bytes passed.

The flip_storage_order handling assumes that each long is a full
SImode, which e.g. excludes BITS_PER_UNIT != 8 and float formats
whose memory size is not a multiple of 32 bits (which includes
HFmode at least).  The patch therefore leaves that code alone.
If interpreting each integer as SImode is correct, the const_ints
that it generates are also correct.

2019-09-18  Richard Sandiford  <richard.sandiford@arm.com>

gcc/
* varasm.c (assemble_real): Generate canonical const_ints.

From-SVN: r275873
gcc/ChangeLog
gcc/varasm.c