This is the mail archive of the gcc-prs@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: c/10339: strncmp generates imPure code


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

From: Falk Hueffner <falk dot hueffner at student dot uni-tuebingen dot de>
To: Wolfgang Bangerth <bangerth at ices dot utexas dot edu>
Cc: Michael Ubell <ubell at mindspring dot com>, gcc-bugs at gcc dot gnu dot org,
   <gcc-gnats at gcc dot gnu dot org>
Subject: Re: c/10339: strncmp generates imPure code
Date: 07 Apr 2003 20:56:15 +0200

 Wolfgang Bangerth <bangerth at ices dot utexas dot edu> writes:
 
 > > It generates a memcmp of 4 bytes when one of the arguments
 > > is 3 bytes long.
 > 
 > You're a little terse in your descriptions of the problem :-]
 > 
 > I think I understand now what you mean: with -O, gcc optimizes the strncmp 
 > away and replaces it by a call to memcmp. However, it doesn't take into 
 > account that strncmp compares _at most_ n  characters, but that the actual 
 > number may be less than n if one of the two strings is shorter. memcmp on 
 > the other hand always does n bytes.
 
 Well, just like in real life, we can do anything we like as long as
 nobody notices. This optimiziation would only be invalid if
 
 * it gives a different result,
 * or the memory read straddles a page boundary and faults.
 
 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.
 
 -- 
 	Falk


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