This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: m32c, ivopts, 20000412-6.c
- From: "Richard Guenther" <richard dot guenther at gmail dot com>
- To: "DJ Delorie" <dj at redhat dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Wed, 7 Jan 2009 10:15:54 +0100
- Subject: Re: m32c, ivopts, 20000412-6.c
- References: <200901070046.n070k2DZ019258@greed.delorie.com>
On Wed, Jan 7, 2009 at 1:46 AM, DJ Delorie <dj@redhat.com> wrote:
>
> I'm looking a failure for m32c-elf (-mcpu=m32c) in
> gcc.c-torture/execute/20000412-6.c.
>
> I've narrowed it down to a transformation done in 107t.ivopts.
>
> In 104t.cunroll: (tmp_9 and tmp_16 are 24-bit pointer values):
>
> tmp_9 = tmp_16 + 2;
> if (bufend_6(D) > tmp_9)
>
> but in 107t.ivopts:
>
> tmp_9 = tmp_16 + 2;
> D.1229_1 = (unsigned int) tmp_9;
> tmp_13 = (short unsigned int *) D.1229_1;
> if (bufend_6(D) > tmp_13)
>
> The problem is that tmp_9 is a 24-bit value, and casting it to
> unsigned int (16 bits) truncates off eight of the bits. Why are we
> casting pointers to integer values at all? Is there any way to stop
> ivopts from performing this truncation?
As I repeatedly said having sizetype of a different precision than
pointer types will cause all sorts of problems ;) The middle-end
generally assumes it can cast between sizetype and pointers
arbitrarily.
In the above case, what type is tmp_9, what type is tmp_16?
Richard.