Re: optimization/8300: [3.2/3.3/3.4 regression] [sparc] ICE in gen_reg_rtx, at emit-rtl.c:662

[Daniel Jacobowitz <drow at mvista dot com>]

The following reply was made to PR optimization/8300; it has been noted by GNATS.

From: Daniel Jacobowitz <drow at mvista dot com>
To: Robert Schiele <rschiele at uni-mannheim dot de>
Cc: Richard Henderson <rth at redhat dot com>, gcc-bugs at gcc dot gnu dot org,
	tneumann at pi3 dot informatik dot uni-mannheim dot de, gcc-gnats at gcc dot gnu dot org
Subject: Re: optimization/8300: [3.2/3.3/3.4 regression] [sparc] ICE in gen_reg_rtx, at emit-rtl.c:662
Date: Mon, 17 Mar 2003 09:29:37 -0500

 On Mon, Mar 17, 2003 at 10:25:04AM +0100, Robert Schiele wrote:
 > On Mon, Mar 17, 2003 at 01:05:55AM -0800, Richard Henderson wrote:
 > > On Mon, Mar 17, 2003 at 06:08:21AM +0100, Robert Schiele wrote:
 > > > *(&c + 1) is also well defined.
 > > 
 > > How's that?
 > 
 > It's pointer arithmetic:
 > 
 > Assume you have the following memory layout...
 > 
 > |   |
 > +---+
 > |   | <== ... then the contents of that address is *(&c + 1)
 > +---+
 > | c |
 > +---+
 > |   |
 > 
 > It is:
 > 
 > c: The contents of the variable c on the stack.
 > 
 > &c: The address where c is located on the stack.
 > 
 > &c + 1: That address plus 4 byte. (sizeof(int) == 4 on sparc)
 > 
 > *(&c + 1): The contents of the above address.
 > 
 > > > 1. My rewritten example is legal code with no doubt and produces an
 > > >    ICE whit optimization.
 > > 
 > > Nyet.
 > 
 > Well, I still don't see why this is illegal. Can you give me the
 > paragraph of the C standard that prohibits this sort of pointer
 > arithmetic?
 
 If you have a copy of the standard, it's 6.5.6#8.  Once a pointer is
 adjusted to point outside of the original object it must not be
 dereferenced.  Accessing memory in this way produces undefined
 behavior.
 
 -- 
 Daniel Jacobowitz
 MontaVista Software                         Debian GNU/Linux Developer