UltraSPARC 16-bit assignments severely broken [analysis]
Geoff Keating
geoffk@cygnus.com
Tue Jul 25 10:49:00 GMT 2000
> Date: Mon, 24 Jul 2000 20:37:52 -0400 (EDT)
> From: "Charles M. Hannum" <root@ihack.net>
>> (insn 21 19 22 (set (reg:HI 110)
>> (const_double (const_int 0 [0x0]) -32768 [0xffff8000] 0 [0x0] 0 [0x0] 0 [0x0] 0 [0x0])) -1 (nil)
>> (nil))
> This is a special case for cross-compiling from a 32-bit platform.
> See:
>
>
> if (TARGET_ARCH64
> && HOST_BITS_PER_WIDE_INT != 64
> && (INTVAL (op1) & 0x80000000) != 0)
> {
>
> There's a comment elsewhere (that I'm failing to find now) that
> suggests this is because somewhere in the bowels of the optimizer it
> assumes that the value will be sign-extended.
The comment is correct. Everywhere in GCC we assume that all
constants are sign-extended properly for the mode that they're in.
That's what I said, the RTL is simply not valid and whatever created
it must be wrong.
> Of course, given that we're doing a sethi, the upper bits don't
> actually matter...
Except that cse will think (const_double 0 0xffff8000) is different to
(const_int 0xffff8000), simplify-rtx will compare it wrong, it won't
be recognised, and really bizzare stuff will happen in a number of
corner cases.
--
- Geoffrey Keating <geoffk@cygnus.com>
More information about the Gcc-bugs
mailing list