This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: UltraSPARC 16-bit assignments severely broken [analysis]
- To: root at ihack dot net
- Subject: Re: UltraSPARC 16-bit assignments severely broken [analysis]
- From: Geoff Keating <geoffk at cygnus dot com>
- Date: Tue, 25 Jul 2000 10:48:45 -0700
- CC: gcc-bugs at gcc dot gnu dot org
- References: <200007250037.e6P0bq016407@lop-nor.ihack.net>
> 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>