I just tried this with 4.0.3, 3.2.2, and 3.4.2, and the problem is in all of those versions as well.
-------------- Original message ---------------------- From: Matthew Burgess <[EMAIL PROTECTED]> > > On Tue, 20 Nov 2007 12:06:54 -0600, Bruce Dubbs <[EMAIL PROTECTED]> wrote: > > Alexander E. Patrakov wrote: > >> Code from http://lkml.org/lkml/2007/11/19/493: > >> > >> #include <stdio.h> > >> #include <stdlib.h> > >> > >> int main( void ) > >> { > >> int i=2; > >> if( -10*abs (i-1) == 10*abs(i-1) ) > >> printf ("OMG,-10==10 in linux!\n"); > >> else > >> printf ("nothing special here\n") ; > >> return 0 ; > >> } > >> > >> GCC miscompiles this, because it thinks that, for builtin abs(), > >> A*abs(B) is the same as abs(A*B) even if A is negative (this is also > >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34130). Patch is available > >> from > > > http://gcc.gnu.org/viewcvs/trunk/gcc/fold-const.c?r1=130258&r2=130257&view=patch > &pathrev=130258 > >> > >> Expectations on LKML are that distributions should handle this bug > >> with the same urgency as security vulnerabilities (but this is in fact > >> worse: one has to recompile almost anything with the new gcc to be > >> sure that all manifestations of this bug are removed). I.e., this is > >> an obvious candidate for the errata page, or even LFS-6.3.1 (because > >> of jhalfs). > > > > Don't panic. The combination of a constant times abs(something) is > > rare. I saw three instances in the kernel source and the constant was > > positive in all cases. > > But see http://www.ussg.iu.edu/hypermail/linux/kernel/0711.2/1296.html - the > kernel uses it's own abs macro, so GCC never sees the call to abs(). > Therefore > the kernel tarball isn't a suitable candidate to try finding instances of > this > bug in. I'd hazard a guess that something like mplayer or ffmpeg might be > more > suitable given the heavy use of maths in them...but it really is just a > guess. > So far, 3.3.x, 3.4.x, 4.1.x and 4.2.x are known to fail and we've not had a > single instance of this bug reported. So, either there is very little/no > code > that triggers the bug, or its affects aren't noticeable in the apps that do > trigger it. I'm not saying that the testsuites for LFS/BLFS packages provide > 100% coverage (my experience in the field has taught me not to be so naive), > but > all my builds pass them with the exception of the known failures. > > > However, we do need to address this, but it is not an emergency. An > > errata to 6.3 and an update to -dev is appropriate though. The first > > step is to put an appropriate patch out. We may need more than one: one > > for gcc-4.2.2 and one for gcc-4.1.2. (or should we do this with a sed?) > > I think a patch would be the safest bet, if only to save those that like > typing > in the commands by hand some trouble. > > > Incorporating the patch in -dev is easy enough, but how should we phrase > > the errata page? > > If we do put this into an errata, I think we'd need to explicitly state the > packageswe know of that need recompiling otherwise folks might think they > need > to recompile their entire system. At the moment, I'm yet to be convinced of > the > risk of this bug being triggered and the consequences thereof. Do we really > need to patch this, or can we wait until an upstream release contains a fix > for > it? > > Regards, > > Matt. > > -- > http://linuxfromscratch.org/mailman/listinfo/lfs-dev > FAQ: http://www.linuxfromscratch.org/faq/ > Unsubscribe: See the above information page -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
