rfc: constant pool and floats

[Geoff Keating]

On 15/10/2004, at 7:30 PM, Aldy Hernandez wrote:

>> That's the problem.  Clearly, (reg:SF 120) is not equal to the
>> CONST_INT; it's equal to a SFmode CONST_DOUBLE.
>
> I played around kludging the REG_EQUAL to be equal to a CONST_DOUBLE.
> That didn't fix the problem because when we fill in the constant pool
> (force_const_mem) with the value, we fill it in with a const_int/SFmode
> pair, which still causes the abort while dumping the constant pool.

Where did the CONST_INT come from, if not the REG_EQUAL note?

>   /* If VALUE is a floating-point mode, access it as an integer of the
>      corresponding size.  This can occur on a machine with 64 bit 
> registers
>      that uses SFmode for float.  This can also occur for unaligned 
> float
>      structure fields.  */
>   if (GET_MODE_CLASS (GET_MODE (value)) != MODE_INT
>       && GET_MODE_CLASS (GET_MODE (value)) != MODE_PARTIAL_INT)
>     value = gen_lowpart ((GET_MODE (value) == VOIDmode
> 			  ? word_mode : int_mode_for_mode (GET_MODE (value))),
> 			 value);

This code is not wrong, as such, but I'm a bit confused about what then 
happens to 'value'.  The routine appears to return it, but there's no 
documentation about what the routine is *supposed* to return, and every 
use of it in the compiler appears to ignore the return value.

Anyway, what you want to look for is the first point where SFmode and 
CONST_INT get associated with each other.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2410 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20041017/850d1271/attachment.p7s>