[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: manywarnings and -f options
From: |
Jim Meyering |
Subject: |
Re: manywarnings and -f options |
Date: |
Sun, 04 Dec 2011 13:05:52 +0100 |
Simon Josefsson wrote:
> Jim Meyering <address@hidden> writes:
>> Eric Blake wrote:
>>> On 12/03/2011 09:00 AM, Simon Josefsson wrote:
>>>> What does -funit-at-a-time really do? My gcc 4.4 manual says:
>>>>
>>>> `-funit-at-a-time'
>>>> This option is left for compatibility reasons. `-funit-at-a-time'
>>>> has no effect, while `-fno-unit-at-a-time' implies
>>>> `-fno-toplevel-reorder' and `-fno-section-anchors'.
>>>>
>>>> Enabled by default.
>>>
>>> That's the case for 4.4 and later. But in gcc 4.3, it was not
>>> unconditionally enabled, and as I said earlier, at least coreutils ran
>>> into a situation where gcc 4.3. failed to compile at -Werror because
>>> -Wdisabled-optimization warned that -fno-unit-at-a-time was required,
>>> which warning turned into an error.
>>>
>>> At this point, gcc 4.3 is slowly phasing out; most Linux distros and
>>> Cygwin have moved on to newer compilers, where the problem is less
>>> likely to happen.
>>
>> IMHO, we should treat --enable-gcc-warnings as something that must work
>> well with the latest stable version of gcc (currently 4.6) and recent
>> glibc headers. Trying to accommodate older versions of gcc does not seem
>> worthwhile. Just tell people who use old versions of gcc not to use
>> --enable-gcc-warnings, or even detect that and turn it off automatically.
>
> I think this is a good approach: I wouldn't want workarounds for issues
> in old gcc in manywarnings.m4. Manywarnings is a maintainer tool, and
> maintainers can be required to have newer tools than users, so
> manywarnings could require more recent tools. However, personally I
> still use gcc 4.4 on my primary development machine, so if it isn't
> difficult to support it, I'd prefer that.
That is reasonable, since you'll be motivated to address any problem
that is specific to your aging, er... "stable" environment ;-)
Besides, if it just-works even with gcc-4.4, we'll avoid at least
a few bug reports.