public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug preprocessor/33907] Empty macro definitions not considered equal
Date: Mon, 26 Nov 2007 13:15:00 -0000	[thread overview]
Message-ID: <20071126131549.32553.qmail@sourceware.org> (raw)
In-Reply-To: <bug-33907-10053@http.gcc.gnu.org/bugzilla/>



------- Comment #14 from rguenther at suse dot de  2007-11-26 13:15 -------
Subject: Re:  Empty macro definitions not considered
 equal

On Mon, 26 Nov 2007, manu at gcc dot gnu dot org wrote:

> ------- Comment #13 from manu at gcc dot gnu dot org  2007-11-26 13:03 -------
> (In reply to comment #11)
> > I see.  But sth changed in the cpp defaults for C++ in 4.3 as things
> > that were previously warnings (with 4.2) are now errors (with 4.3), such
> > as this one or the macro re-definition.
> > 
> 
> (My english must be getting pretty bad lately, please let me know what part is
> not clear. Perhaps we should put up some Developers FAQ in the wiki.)
> 
> * C++ front-end did not and does not enable -pedantic-errors by default. 
> 
> * C++ front-end makes pedwarns to be emitted as errors.
> 
> * -pedantic-errors sets the variable pedantic to true and makes pedwarns to be
> emitted as errors.
> 
> * C++ front-end in 4.3 now makes CPP's pedwarns to be emitted as errors.
> 
> * C++ front-end in 4.3 did not and does not set CPP's pedantic flag to true,
> you still need -pedantic or -pedantic-errors for that.
> 
> * So, a CPP's pedwarn that is guarded by the pedantic flag still requires an
> explicit -pedantic or -pedantic-errors in the command-line to be generated (as
> error by default, as a warning with -fpermissive).
> 
> Please, I am banging my head against the wall since comment #7 of why this is
> not clear. So, please, let me know which part I am explaining wrong.

I guess you are not explaining it wrong, but the situation is
extremely confusing:

  /* Adjust various flags for C++ based on command-line settings.  */
  if (c_dialect_cxx ())
    {
      if (!flag_permissive)
        {
          flag_pedantic_errors = 1;
          cpp_opts->pedantic_errors = 1;
        }
...
    }

which means by default pedantic is false but pedantic-errors is true
(though -fpedantic-errors also sets pedantic to true).  So all
pedwarns() that are not guarded by an extra if (pedantic) are errors
for C++ (and for libcpp now).  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.

I find this situation confusing (especially with the defintion of
pedwarn, which reads

/* A "pedantic" warning: issues a warning unless -pedantic-errors was
   given on the command line, in which case it issues an error.  Use
   this for diagnostics required by the relevant language standard,
   if you have chosen not to make them errors.

   Note that these diagnostics are issued independent of the setting
   of the -pedantic command-line switch.  To get a warning enabled
   only with that switch, write "if (pedantic) pedwarn (...);"  */
void
pedwarn (const char *gmsgid, ...)

so it suggests -pedantic-errors, but in reality it only checks for
flag_pedantic_errors:

diagnostic.h:#define pedantic_error_kind() (flag_pedantic_errors ? 
DK_ERROR : DK_WARNING)

So, for C++ you either get no warning by default for

 if (pedantic)
   pedwarn (...);

or you get an error by default for

 pedwarn (...);

But you cannot get a warning for pedwarn as its name suggests.
(-fpermissive -pedantic should work, but maybe doesn't)

Richard.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33907


  parent reply	other threads:[~2007-11-26 13:15 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-26 13:28 [Bug preprocessor/33907] New: " rguenth at gcc dot gnu dot org
2007-10-26 13:44 ` [Bug preprocessor/33907] " schwab at suse dot de
2007-10-26 13:46 ` rguenth at gcc dot gnu dot org
2007-10-26 13:56 ` schwab at suse dot de
2007-10-26 14:45 ` joseph at codesourcery dot com
2007-11-25 21:11 ` tromey at gcc dot gnu dot org
2007-11-25 21:34 ` rguenther at suse dot de
2007-11-25 22:23 ` manu at gcc dot gnu dot org
2007-11-25 22:29 ` rguenther at suse dot de
2007-11-25 22:56 ` manu at gcc dot gnu dot org
2007-11-25 22:59 ` manu at gcc dot gnu dot org
2007-11-26  9:56 ` rguenther at suse dot de
2007-11-26 12:44 ` joseph at codesourcery dot com
2007-11-26 13:03 ` manu at gcc dot gnu dot org
2007-11-26 13:15 ` rguenther at suse dot de [this message]
2007-11-26 17:47 ` manu at gcc dot gnu dot org
2007-11-27  9:10 ` rguenther at suse dot de
2007-11-27 13:51 ` manu at gcc dot gnu dot org
2007-11-27 13:57 ` manu at gcc dot gnu dot org
2007-11-30 21:10 ` gdr at gcc dot gnu dot org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20071126131549.32553.qmail@sourceware.org \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).