Changes in C++ FE regarding pedwarns to be errors are harmful

[Richard Guenther]

On Jan 8, 2008 10:34 PM, Joe Buck <Joe.Buck@synopsys.com> wrote:
> On Tue, Jan 08, 2008 at 11:28:22PM +0200, Ismail Dönmez wrote:
> > Hi all,
> >
> > Looks like gcc 4.3 has some rather inconvenient changes in C++ FE, with the
> > latest trunk. Lets see with an example :
> >
> > [~]> cat test.cpp
> > #define foo bar
> > #define foo baz
> >
> > [~]> g++ -c test.cpp
> > test.cpp:2:1: error: "foo" redefined
> > test.cpp:1:1: error: this is the location of the previous definition
> >
> > I don't know the reasoning behind this change but this breaks many C++
> > programs unless -fpermissive is used. Why? Because everybody loves to install
> > their own config.h (Python, libmp4v2 being nice examples) which just
> > carelessly #define anything its asked for with ifndef ... endif .
> >
> > Now flash back to real world: this breaks any C++ application that uses
> > Python, libmp4v2, libjpeg and possibly many others. And I think this is a
> > real bad behaviour change and I am not sure if its worth all the trouble.
>
> There's certainly an argument that this change is ill-advised.  However,
> your statements in the last paragraph aren't true: most quality open
> source projects have a "no warnings" rule (or at least try to eliminate
> warnings), and most programmers know about #undef.  Since people have
> already built whole distros with the gcc from the trunk, clearly they
> are managing to build C++ applications that use Python, libmp4v2, libjpeg
> etc.

Yep, in the worst case we stick a -fpermissive in.  See also PR33907 for
more obscure cases of the standard.

Richard.