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] | |
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); )? 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. Jakub
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |