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
