This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: adjust generation of component addresses
- From: Hans-Peter Nilsson <hp at bitrange dot com>
- To: Richard Henderson <rth at redhat dot com>
- Cc: Richard Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>, <gcc-patches at gcc dot gnu dot org>, <roger at eyesopen dot com>, <jakub at redhat dot com>
- Date: Wed, 27 Feb 2002 15:28:21 -0500 (EST)
- Subject: Re: adjust generation of component addresses
On Tue, 26 Feb 2002, Hans-Peter Nilsson wrote:
> On Mon, 25 Feb 2002, Richard Henderson wrote:
>
> > On Mon, Feb 25, 2002 at 07:13:49AM -0500, Richard Kenner wrote:
> > > I've built a cross gnat1; hopefully I'll be able to reproduce this.
> > >
> > > Note that the problem exists on all machines, but it's just the 32/64 where
> > > it always causes bad code.
> >
> > So you've identified the place within the compiler that the problem
> > appears? Care to share?
>
> I believe the discussed change of yours is a cause for the
> regression on mmix that I see:
That's was red herring, sorry. It's not your change causing the
fault I see
(<URL:http://gcc.gnu.org/ml/gcc-patches/2002-02/msg01907.html>).
It's actually this one:
2002-02-20 Roger Sayle <roger@eyesopen.com>
Jakub Jelinek <jakub@redhat.com>
PR c/4389
* tree.c (host_integerp): Ensure that the constant integer is
representable in a HOST_WIDE_INT or an unsigned HOST_WIDE_INT
when pos is zero or non-zero respectively. Clarify comment.
* c-format.c (check_format_info_recurse): Fix host_integerp
usage; the pos argument should be zero when assigning to a
signed HOST_WIDE_INT.
The fault is related to putting a negative offset in an unsigned
long int; the change to host_integerp causes that to be
considered an overflow.
brgds, H-P