Re: autoconf: feature request: test for GCC version

[Philip Prindeville]

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