This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] [gsoc] [gimplefe] GIMPLE FE Project


On 08/23/2016 08:46 AM, Richard Biener wrote:
> On Mon, Aug 22, 2016 at 11:54 PM, Pedro Alves <palves@redhat.com> wrote:

>> I believe that only stage 1 is built with -std=gnu++98 forced, and also
>> stage 1 is built without -Werror, so I think you'd need to start with a
>> compiler that predates support for that construct, not just one
>> that predates the flip of the default.
> 
> Uh, so we don't actually catch these errors during bootstrap with a too
> recent host compiler?  That's pretty bad.  

...

> In the end conditionally allowing C++11 code in stage2+ was a mistake
> if we can't catch
> this kind of issues reliably.

Generally speaking, let me state my current view on the theme:

The oldest compiler that people are using in practice to
bootstrap gcc with is what matters in the end.  Forcing -std=foo and
-pedantic is useful as a proxy but it can only go so far.  Routinely
testing bootstrap with the oldest compiler version people are
willing to support, is the only reliable check, and better
yet if that is left for auto testers / buildbot.

Because, even if a feature is in the standard, if compilers
that people want to bootstrap gcc with don't implement it,
or don't implement it correctly, then we'll find ways to
work around it.  That happens once in a while.

On the same vein, if some code using some newer language feature
that is supported as a GNU extension manages to land in the tree, and
nobody trips on it for a long while, then that indicates that no one
is actually building with ancient compilers anymore.  That indicates
that we should be able to start using the feature and bump the
minimum bootstrapping compiler in the documentation.

>From that angle, forcing pedantic errors is a little counter
productive, as it may be imposing an artificial barrier, leading
to a glacier pace of newer language feature adoption in the
compiler itself.  E.g., what if all of gcc/clang/foo/bar
have been supporting some language/library feature for a decade,
as an extension?  Why restrict usage of the feature?

That said, I don't know when was support for the construct
first added, and this patch hasn't landed yet.  Support
for it probably postdates gcc 4.3 and your autotesters would
likely catch it (and you'd probably be annoyed).

> So should we change config/warnings.m4:ACX_PROG_CXX_WARNING_ALMOST_PEDANTIC
> to use -pedantic-errors?

That might well be the best proxy available, but others will
know better whether that is likely to cause fallout.

Thanks,
Pedro Alves


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]