This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.


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: fix memrchr for GCC 3.4


Jakub Jelinek <jakub@redhat.com> writes:

> On Thu, Sep 04, 2003 at 12:07:55PM +0200, Andreas Jaeger wrote:
>> 
>> GCC 3.4 miscompiles memrchr (the testsuite fails).  The GCC developers
>> closed my bugs as invalid:
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9196
>> 
>> with the following comment:
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> The C semantics for pointer arithmetic mean that GCC is allowed to assume that
>> this line
>> 
>>   return __res + 1;
>> 
>> never causes a null pointer to be returned.  The "mis-optimized" code has been
>> optimized based on that assumption.  In short, the bug is in glibc.
>> 
>> The simplest fix is to write "incl %0" as the last instruction of the assembly
>> block rather than trying to do this calculation in C. 
>
> Can't you just make __res unsigned long int instead of void * and
> add cast (ie. return (void *) (__res + 1); )?

It doesn't look cleaner than my code.

> Of course, best would be to add __builtin_memrchr to gcc and after making
> sure gcc finally does better job than all bits/string*.h macros use just gcc
> builtins.

Yes, that would be really the best thing to do.

Andreas
-- 
 Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj
  SuSE Linux AG, Deutschherrnstr. 15-19, 90429 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

Attachment: pgp00000.pgp
Description: PGP signature


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