From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7826 invoked by alias); 7 Apr 2003 19:46:00 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 7812 invoked by uid 71); 7 Apr 2003 19:46:00 -0000 Date: Mon, 07 Apr 2003 19:46:00 -0000 Message-ID: <20030407194600.7811.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: "Timothy C Prince" Subject: Re: Re: c/10339: strncmp generates imPure code Reply-To: "Timothy C Prince" X-SW-Source: 2003-04/txt/msg00301.txt.bz2 List-Id: The following reply was made to PR optimization/10339; it has been noted by GNATS. From: "Timothy C Prince" 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 To: Michael Ubell Date: 07 Apr 2003 21:27:02 +0200 Subject: Re: c/10339: strncmp generates imPure code Michael Ubell 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