[New file, Ping] Add testcase to ensure that #pragma GCC diagnostic push/pop works with -Wtraditional.

Eric Gallager egall@gwmail.gwu.edu
Tue May 2 17:06:00 GMT 2017


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?
Thanks,
Eric



More information about the Gcc-patches mailing list