public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Joseph Myers <joseph@codesourcery.com>
To: Longjun Luo <luolongjuna@gmail.com>
Cc: <gcc-patches@gcc.gnu.org>, <sangyan@huawei.com>
Subject: Re: [PATCH] libcpp: suppress builtin macro redefined warnings for __LINE__
Date: Thu, 1 Dec 2022 19:07:21 +0000	[thread overview]
Message-ID: <587de9c9-e46f-b69e-84d8-7356a19db74@codesourcery.com> (raw)
In-Reply-To: <8767c6bc-5b37-ca10-1176-e341081c555f@gmail.com>

On Fri, 2 Dec 2022, Longjun Luo via Gcc-patches wrote:

> 
> On 12/2/2022 1:01 AM, Joseph Myers wrote:
> > On Thu, 1 Dec 2022, Longjun Luo via Gcc-patches wrote:
> > 
> > > diff --git a/gcc/testsuite/gcc.dg/builtin-redefine.c
> > > b/gcc/testsuite/gcc.dg/builtin-redefine.c
> > > index 882b2210992..9d5b42252ee 100644
> > > --- a/gcc/testsuite/gcc.dg/builtin-redefine.c
> > > +++ b/gcc/testsuite/gcc.dg/builtin-redefine.c
> > > @@ -71,7 +71,6 @@
> > >   /* { dg-bogus "Expected built-in is not defined" "" { target *-*-* } .-1
> > > } */
> > >   #endif
> > >   -#define __LINE__ 0           /* { dg-warning "-:\"__LINE__\" redef" }
> > > */
> > >   #define __INCLUDE_LEVEL__ 0  /* { dg-warning "-:\"__INCLUDE_LEVEL__\"
> > > redef" } */
> > >   #define __COUNTER__ 0        /* { dg-warning "-:\"__COUNTER__\" redef" }
> > > */
> > Is there some existing test that verifies that this redefinition is still
> > diagnosed by default (in the absence of -Wno-builtin-macro-redefined)?
> 
> I am not sure I have fully understood your meaning. The problem here is that
> if I try to redefine __LINE__ macro in the situation that projects use the
> option '-Werror', the compile will fail.

There are two cases:

(a) Is redefinition of __LINE__ diagnosed *without* 
-Wno-builtin-macro-redefined?

(b) Is redefinition of __LINE__ diagnosed *with* 
-Wno-builtin-macro-redefined?

My understanding is that both (a) and (b) have answer "yes" at present, 
and your patch would change the answer to (b) to "no", without changing 
the answer to (a).

My question is about whether there is a test verifying the answer to (a).  
If not, I think the patch should add one.

-- 
Joseph S. Myers
joseph@codesourcery.com

  reply	other threads:[~2022-12-01 19:07 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-01  4:31 Longjun Luo
2022-12-01 17:01 ` Joseph Myers
2022-12-01 18:23   ` Longjun Luo
2022-12-01 19:07     ` Joseph Myers [this message]
2022-12-01 19:51       ` Longjun Luo
2022-12-01 21:10         ` Joseph Myers
2023-01-12 16:02           ` Longjun Luo
2023-04-30 18:30             ` Jeff Law
2023-04-30 23:14               ` Jeff Law
2023-04-30 23:19                 ` Andrew Pinski
2023-01-12 16:05           ` Longjun Luo

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=587de9c9-e46f-b69e-84d8-7356a19db74@codesourcery.com \
    --to=joseph@codesourcery.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=luolongjuna@gmail.com \
    --cc=sangyan@huawei.com \
    /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).