This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: optimization/7799: [3.2/3.3 regression] Loop bug withoptimization flag -Os in gcc


"Christian Ehrhardt" <ehrhardt@mathematik.uni-ulm.de> writes:

|> On Fri, Dec 13, 2002 at 01:57:56PM +0000, Andrew Haley wrote:
|> > Christian Ehrhardt writes:
|> >  > void fill (int* p, int* q[10])
|> >  > [ ... ]
|> >  > If p is initially 0x7ffffffc the comparison must be treated as unsigned,
|> >  > however, if p is initially 0xfffffffc the comparison must be treated as
|> >  > signed.
|> > 
|> > How can p be initially 0xfffffffc ?
|> 
|> By calling fill ((int*) 0xffffffc, q);

Undefined behaviour.

|> > The only way you could get such an address is to cast an int to a
|> > pointer, in which case it's your responsibility to make sure the
|> > address is valid.
|> 
|> I think you missed the point. The memory pointed to by p is never
|> accessed.

The pointer itself must be valid, independent of how you use it.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]