rfc: constant pool and floats

[Aldy Hernandez <aldyh at redhat dot com>]

Hi folks.

The following testcase is failing on powerpc-linux as well as the embedded
variants.

FAIL: tmpdir-gcc.dg-struct-layout-1/t001 c_compat_x_tst.o compile

I have narrowed the problem down to:

	typedef float Tal1float __attribute__ ((aligned (2)));
	struct S38 { Tal1float a; };
	struct S38 s38;
	void test38 (void) { s38.a = 91611.765625; }

Where 2 would be an unaligned access to a float.

store_bit_field() changes the floating constant to a const_int
because of the unalignment:

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

All this eventually creates a REG_EQUAL note with a const_int, instead
of a const_double:

(insn 11 10 0 (set (reg:SF 120)
        (mem/u/i:SF (lo_sum:SI (reg:SI 121)
                (symbol_ref/u:SI ("*.LC0") [flags 0x2])) [0 S4 A32])) -1 (nil)
    (expr_list:REG_EQUAL (const_int 1202908642 [0x47b2ede2])
        (nil)))

The constant pool will contain a value of (const_int 1202908642) with
a mode of SF.  This will cause output_constant_pool_2() to abort because
we have a MODE_FLOAT, but an integer as a constant.

Is the REG_EQUAL note correct being a const_int?  If so, is the constant
pool correct having SFmode, but a const_int?  If so, then we need
to change output_constant_pool_2() to allow const_int's for MODE_FLOATS.

However...I'm not sure if this is all sane (rtl, and all).

Thoughts?

Aldy