[Top][All Lists]

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

Re: manywarnings and -f options

From: Simon Josefsson
Subject: Re: manywarnings and -f options
Date: Sun, 04 Dec 2011 12:32:20 +0100
User-agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.91 (gnu/linux)

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.


reply via email to

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