Re: Re: c/10339: strncmp generates imPure code

["Timothy C Prince" <tprince@myrealbox.com>]

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

From: "Timothy C Prince" <tprince@myrealbox.com>
To: falk.hueffner@student.uni-tuebingen.de
Cc: ubell@mindspring.com,
	bangerth@ices.utexas.edu,
	gcc-bugs@gcc.gnu.org,
	gcc-gnats@gcc.gnu.org
Subject: Re: Re: c/10339: strncmp generates imPure code
Date: Mon, 07 Apr 2003 19:45:04 +0000

 -----Original Message-----
 From: Falk Hueffner <falk.hueffner@student.uni-tuebingen.de>
 To: Michael Ubell <ubell@mindspring.com>
 Date: 07 Apr 2003 21:27:02 +0200
 Subject: Re: c/10339: strncmp generates imPure code
 
 Michael Ubell <ubell@mindspring.com> writes:
 
 > > I suspect the extra byte read is actually not relevant for the result,
 > > and because of alignment, gcc knows the second problem cannot occur,
 > > but I have neither a SPARC nor SPARC knowledge to test that.
 >=20
 > Actually if you make the compare string longer you can get it to
 > look at an arbitrary number of bytes passed the allocated part, so I
 > think this could fault if you set it up right.  Also in the original
 > problem, the first argument was not allocated locally so the
 > compiler would have no idea how big or what its alignment was.  (In
 > fact it was in a loop comparing strings from an array.)
 
 Could you perhaps provide such an example? For your original example,
 gcc knows that malloc returns only aligned pointers.
 
 -- 
 =09Falk
 _________________________________________________
 I'm sure that gcc doesn't treat malloc specially to know that its pointers =
 are (almost) certainly more than byte-aligned. Nor would I expect it disc=
 riminate between a strncmp() which starts at the beginning of allocated m=
 emory and one which starts a variable number of bytes further along.  Sev=
 eral widespread implementations of gcc run on implementations where mallo=
 c() doesn't even provide a pointer sufficiently aligned for types wider t=
 han int.
 
 Tim Prince