[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:1.9.2.15) 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:
>>
>> 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