This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [New file] Add testcase to ensure that #pragma GCC diagnostic push/pop works with -Wtraditional.
- From: David Malcolm <dmalcolm at redhat dot com>
- To: Eric Gallager <egall at gwmail dot gwu dot edu>, gcc-patches at gcc dot gnu dot org
- Date: Fri, 24 Mar 2017 15:13:30 -0400
- Subject: Re: [New file] Add testcase to ensure that #pragma GCC diagnostic push/pop works with -Wtraditional.
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=dmalcolm at redhat dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 15414C05AA54
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 15414C05AA54
- References: <CAMfHzOs+5om2mwrY7o0JCK28+_ThCBU6Y6CY6yEwDQA4nnczkQ@mail.gmail.com>
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?)
> 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.
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.
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
>