This is the mail archive of the
gcc-prs@gcc.gnu.org
mailing list for the GCC project.
Re: c/10339: strncmp generates imPure code
- From: Falk Hueffner <falk dot hueffner at student dot uni-tuebingen dot de>
- To: nobody at gcc dot gnu dot org
- Cc: gcc-prs at gcc dot gnu dot org,
- Date: 7 Apr 2003 19:06:01 -0000
- Subject: Re: c/10339: strncmp generates imPure code
- Reply-to: Falk Hueffner <falk dot hueffner at student dot uni-tuebingen dot de>
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