------- Comment #15 from manu at gcc dot gnu dot org 2007-11-26 17:47 ------- (In reply to comment #14) > > I guess you are not explaining it wrong, but the situation is > extremely confusing: >
Oh, I fully agree on that. But it is exactly the same situation that was there pre-4.3 for the C++ front-end. It is just that now CPP and C++ front-end defaults are consistent. > So, to get regular -pedantic behavior > you need -fpermissive -pedantic (?) (because obviously the C++ default > is not what you get from enabling any of the -pedantic -pedantic-errors > or -fpermissive flags) And of course there's no -no-pedantic-errors > either. That is a good point. But it is not new. It seems to have been like this for the C++ front-end forever. > But you cannot get a warning for pedwarn as its name suggests. > (-fpermissive -pedantic should work, but maybe doesn't) -fpermissive gets a warning for pedwarn(). -fpermissive -pedantic gets you a warning for "if (pedantic) pedwarn()". Think about it like this: pedwarns are diagnostics required by the standard. Some of them are nice, others are a pain in the ass. So we "hide" away the latter under "if (pedantic)" or more precisely under "-pedantic". Now, why the C++ front-end has pedwarns as errors by default, I don't know. But if you have that, then you need -fpermissive. In the C front-end there is no flag to get pedwarns as warnings back: once you issue -pedantic-errors in the command-line, then you cannot take it back. Of course, finding all this took me to read the code and do some tests. You wasn't able to guess it from invoke.texi. So for this bug, I am proposing that we only give the pointless diagnostic if the flag "pedantic" is set to 1 (either by using -pedantic or -pedantic-errors). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33907
