[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: autoconf: feature request: test for GCC version

From: Philip Prindeville
Subject: Re: autoconf: feature request: test for GCC version
Date: Wed, 13 Apr 2011 16:19:45 -0600
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv: Gecko/20110303 Thunderbird/3.1.9

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:
> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]