Reported upstream, including test case and patch. Patch is suitable for adding to gentoo.org glibc ebuild.
would you mind providing a little more information here? this is a pretty sparse bug report. of course, we should really roll out a new snapshot anyways.
Sorry. Upstream URL is http://sources.redhat.com/bugzilla/show_bug.cgi?id=130 Copy of bug: ============================================= > $ cat foo.c > #include <string.h> > int main(int argc, char *argv[]) { > return (int) ((strpbrk("string", "n")) - "string"); > } > $ /usr/i686-pc-linux-gnu/gcc-bin/3.4/gcc -O foo.c > foo.c: In function `main': > foo.c:3: error: invalid operands to binary - -O is necessary to make gcc include the optimising macro definition of strpbrk() in bits/string2.h: # define strpbrk(s, accept) \ __extension__ \ ({ char __a0, __a1, __a2; \ (__builtin_constant_p (accept) && __string2_1bptr_p (accept) \ ? ((__a0 = ((__const char *) (accept))[0], __a0 == '\0') \ ? ((void) (s), NULL) \ : ((__a1 = ((__const char *) (accept))[1], __a1 == '\0') \ ? strchr (s, __a0) \ : ((__a2 = ((__const char *) (accept))[2], __a2 == '\0') \ ? __strpbrk_c2 (s, __a0, __a1) \ : (((__const char *) (accept))[3] == '\0' \ ? __strpbrk_c3 (s, __a0, __a1, __a2) \ : strpbrk (s, accept))))) \ : strpbrk (s, accept)); }) # endif Offending line is: ? ((void) (s), NULL) \ This is not detected as a bug when compiling with gcc 3.3. Test case and patch attached. ========================================== I have checked the glibc ViewCVS and the bug is in the current CVS head, so a new snapshot will not help with this bug (not yet, anyway).
To be perfectly clear: This is a bug in bits/string2.h in glibc: the macro definition of strpbrk() expands to a ?: expression which can have a type of (char *) or NULL, which in Linux is of type (void *). This is a bug as one cannot use (void *) everywhere (char *) is allowable, in this instance on the LHS of the - operator. It manifests itself with gcc 3.4, when compiling with -O{,1,2,3}: gcc 3.4 as gcc 3.3 is lax and does not detect the bug (possibly an implicit cast is performed, but what do I know) and -O{,1,2,3} as -Os and (no -O flag) prevent the macro form of strpbrk() being used. This needs to be fixed upstream, but in the meantime can be fixed within gentoo.org. It will show up as bugs compiling packages with gcc 3.4, e.g. bug 48798.
Upstream: > ------- Additional Comment #3 From Jakub Jelinek 2004-04-30 08:52 [reply] ------- > > Fix commited to glibc CVS on 2004-04-29. Will close when new glibc is packaged from cvs.
http://sources.redhat.com/bugzilla/show_bug.cgi?id=130#c3
I'm testing a glibc compile that includes a patch for this bug and a sparc bug (taken from their CVS). If it works out okay, I'll make a -r1 ebuild with them.
well, this should work if using a snapshot later than 2004-04-29 like amd64 does... anyone object to adding this patch to 20040420 so that x86 gets the fix? i'll poke at morfic too, since he's working on getting gcc 3.4 up to par on x86.
<morfic> and when i make x86-gcc-3.4 profile ill make 0605 glibc part of it
i plan on making a x86-gcc3.4 profile based on sys-libs/glibc-2.3.4.20040605 upstream fixes like this show exactly why it makes sense to stick to this version that has worked for me (x86) for the last 36 days w/o a hitch, all i have come across was lousy sources needing fixing, so far nothing relating to glibc Travis: stop causing mid air collisions!
