This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Patch for incorrect execute/divconst-2.c)
- To: hp at bitrange dot com
- Subject: Re: Patch for incorrect execute/divconst-2.c)
- From: Geoff Keating <geoffk at cygnus dot com>
- Date: Mon, 29 May 2000 22:42:00 -0700
- CC: gcc-patches at gcc dot gnu dot org
- References: <Pine.BSF.4.10.10005300037270.7378-100000@dair.pair.com>
> Date: Tue, 30 May 2000 00:49:42 -0400 (EDT)
> From: Hans-Peter Nilsson <hp@bitrange.com>
> On 29 May 2000, Geoff Keating wrote:
> > Hans-Peter Nilsson <hp@bitrange.com> writes:
> >
> > > Mon May 29 22:41:35 2000 Hans-Peter Nilsson <hp@bitrange.com>
> > >
> > > * varasm.c (immed_double_const): Avoid using const_int to represent
> > > - (1 << (HOST_BITS_PER_WIDE_INT - 1).
> >
> > This is exactly wrong. CONST_INT must _always_ be used to represent
> > such values.
>
> Hm? Can you tell me how to distinguish
> - (1 << (HOST_BITS_PER_WIDE_INT - 1) from
> (1 << (HOST_BITS_PER_WIDE_INT - 1) then, for use in a mode where these
> numbers have different representation? (Here, DImode vs. SImode.)
Sure. Assuming that DImode is 2*HOST_BITS_PER_WIDE_INT wide,
- (1 << (HOST_BITS_PER_WIDE_INT - 1) is a CONST_INT, and
(1 << (HOST_BITS_PER_WIDE_INT - 1) is a CONST_DOUBLE.
CONST_INTs are sign-extended, so that -1 has the same representation
in all modes.
> If it is the *latter* number that should be const_double here, then it
> seems there are other bugs that makes it "work" the opposite right now.
Probably. There's quite a number of bugs in GCC related to folding
CONST_INT constants---loop is particularly bad at deciding that, say,
0x40000000*2=-0x80000000 without bothering to check which mode the
numbers are in.
--
- Geoffrey Keating <geoffk@cygnus.com>