From: David Malcolm <dmalcolm@redhat.com>
To: Eric Gallager <egall@gwmail.gwu.edu>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [New file, Ping] Add testcase to ensure that #pragma GCC diagnostic push/pop works with -Wtraditional.
Date: Thu, 18 May 2017 19:05:00 -0000 [thread overview]
Message-ID: <1495133801.9289.2.camel@redhat.com> (raw)
In-Reply-To: <CAMfHzOtOaGRADJpROj_z3wMo4w6wsK5_ijixFF_rYoULXAN7rg@mail.gmail.com>
On Tue, 2017-05-02 at 12:56 -0400, Eric Gallager wrote:
> On 3/24/17, Eric Gallager <egall@gwmail.gwu.edu> wrote:
> > On 3/24/17, David Malcolm <dmalcolm@redhat.com> wrote:
> > > On Fri, 2017-03-24 at 14:10 -0400, Eric Gallager wrote:
> > > > The attached test case failed with gcc 4.9 and older, but
> > > > started
> > > > compiling successfully with only the 1 expected warning with
> > > > gcc 5.
> > > > Adding it to the test suite would ensure that this behavior
> > > > doesn't
> > > > regress.
> > >
> > > Thanks for posting this.
> > >
> > > What's the significance of the leading space in the:
> > > #pragma GCC diagnostic pop
> > > line? Is *that* the bug? (did we have a bug # for this, I
> > > wonder?)
> > >
> >
> > It prints a warning without it, which would be entirely correct of
> > it to
> > do:
> >
> > /Users/ericgallager/gcc-git/gcc/testsuite/gcc.dg/pragma-diag
> > -7.c:8:2:
> > warning: suggest hiding #pragma from traditional C with an indented
> > #
> > [-Wtraditional]
> > #pragma GCC diagnostic pop
> > ^
> >
> > I only wanted the test case to be testing for the warnings about
> > suffixes; another warning about the pragma would just be noise,
> > albeit
> > correct noise.
> >
> > >
> > > > Note that I have only tested it by compiling it manually, and
> > > > not by actually running it as part of the entire test suite, so
> > > > please
> > > > let me know if I got any of the dejagnu directives wrong.
> > >
> > > When I started contributing to gcc, it took me a while to figure
> > > out
> > > how to run just one case in the testsuite, so in case it's
> > > helpful I'll
> > > post the recipe here:
> > >
> > > 1) Find the pertinent Tcl script that runs the test: a .exp
> > > script in
> > > the same directory, or one of the ancestors directories. For
> > > this case
> > > it's gcc.dg/dg.exp. The significant part is the filename: dg.exp
> > >
> > > 2) Figure out the appropriate "make" target, normally based on
> > > the
> > > source language for the test. For this case it's "check-gcc"
> > >
> > > 3) Run make in your BUILDDIR/gcc, passing in a suitable value for
> > > RUNTESTFLAGS based on the filename found in step 1 above.
> > > For this case, giving it a couple of "-v" flags for verbosity (so
> > > that
> > > we can see the command-line of the compiler invocation) it would
> > > be:
> > >
> > > $ make -jN && make check-gcc RUNTESTFLAGS="-v -v dg.exp=pragma
> > > -diag
> > > -7.c"
> > >
> > > (for some N; I like the "make && make check-FOO" construction to
> > > ensure
> > > that the compiler is rebuilt before running the tests).
> > >
> > > ...which leads to a summary of:
> > >
> > > # of expected passes 3
> > >
> > > which looks good.
> >
> > Okay, I tried this, and I also got:
> >
> > # of expected passes 3
> >
> > too, so that's good.
> >
> > >
> > > You can also use wildcards e.g.:
> > >
> > > make -j64 && make check-gcc RUNTESTFLAGS="-v -v dg.exp=pragma
> > > -diag-*.c"
> > >
> > > (and can use -jN on the "make check-FOO" invocation if there are
> > > a lot of
> > > tests; I tend not to use it for a small number of tests, to avoid
> > > interleaving of output in the logs).
> > >
> > > Thanks,
> > > > Eric Gallager
> > > >
> > > > gcc/testsuite/ChangeLog:
> > > >
> > > > 2017-03-24 Eric Gallager <egall@gwmail.gwu.edu>
> > > >
> > > > * gcc.dg/pragma-diag-7.c: New test.
> > >
> > > I tested your new test case via the above approach and it looks
> > > good to
> > > me.
> > >
> > > Although we're meant to only be accepting regression fixes and
> > > documentation fixes right now (stage 4 of gcc 7 development) I
> > > feel
> > > that extra test coverage like this also ought to be acceptable.
> >
> > It's okay to save it for next stage 1, I'm already submitting it
> > later
> > than I intended to, so extra waiting won't hurt.
> >
>
> Okay, GCC 7 has been released and GCC 8 stage 1 is open now, so I'm
> pinging this:
> https://gcc.gnu.org/ml/gcc-patches/2017-03/msg01319.html
>
> > >
> > > I don't know if the test case is sufficiently small to be exempt
> > > from
> > > the FSF's paperwork requirements here:
> > > https://gcc.gnu.org/contribute.html
> > > (do you have that paperwork in place?)
> > >
> > > Thanks
> > > Dave
> >
> > Yes, I dropped off my copyright assignment at the FSF in December,
> > but
> > I don't have commit access yet though.
> > Thanks,
> > Eric
> >
>
> David, can I list you as my sponsor when applying for
> write-after-approval SVN access? Or would someone else be better?
Yes.
I've gone ahead and committed this testcase to trunk as r248253.
prev parent reply other threads:[~2017-05-18 18:56 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-24 18:46 [New file] " Eric Gallager
2017-03-24 19:28 ` David Malcolm
2017-03-24 20:49 ` Eric Gallager
2017-03-26 9:54 ` Martin Sebor
2017-05-14 1:03 ` [PING] " Eric Gallager
2017-05-02 17:06 ` [New file, Ping] " Eric Gallager
2017-05-18 19:05 ` David Malcolm [this message]
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=1495133801.9289.2.camel@redhat.com \
--to=dmalcolm@redhat.com \
--cc=egall@gwmail.gwu.edu \
--cc=gcc-patches@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).