On 4/13/11 3:59 PM, Eric Blake wrote: > On 04/13/2011 03:49 PM, Philip Prindeville wrote: >> It is sometimes useful to be able to detect the compiler version (as in the >> case of GCC 4.2 doing some fairly aggressive optimization that breaks >> fragile code). > Thanks for the report. > >> How about something like: >> >> AC_GCC_VERSION(VER, MATCHING-VERSION, [ NON-MATCHING-VERSION ]) > Unfortunately, I don't think that a macro like this belongs in autoconf. > Why not instead follow the autoconf philosophy of feature tests rather > than version tests, and specifically compile a problematic program that > gets miscompiled by broken compilers and changes OPTIMIZE in that case. > For all you know, gcc 4.2 on one machine may have some vendor-specific > patches that don't cause the same breakage that you are seeing with > out-of-the-box gcc 4.2. Or, fix your code to be standards-compliant so > that undefined code doesn't trip up a valid optimization; and if gcc is > still miscompiling your program in your eyes, then report that as a bug > to the gcc folks (who will help you either see where your program is > non-compliant or will fix gcc to avoid the miscompilation). >
We're building GCC out of the box from tarball, and unfortunately the exact issue with the failing code sequence was never root-caused... so we know where it occurs, just not why. The problem with the code is that it's legacy code that is poorly understood and not maintained. I don't actually believe GCC is miscompiling the code: I think the code is probably poorly annotated and there are constrained that should be explicitly stated that aren't, and a required side-effect is being optimized away. So yes, ideally, the troublesome code should be fixed, but after 5 years of people staring at it that seems unlikely. Equally unlikely, alas, is the likelihood that people will stop using GSM codecs in the next 5 years. So we have to continue to use this code. -Philip
