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] |
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] |