* [New file] Add testcase to ensure that #pragma GCC diagnostic push/pop works with -Wtraditional. @ 2017-03-24 18:46 Eric Gallager 2017-03-24 19:28 ` David Malcolm 0 siblings, 1 reply; 7+ messages in thread From: Eric Gallager @ 2017-03-24 18:46 UTC (permalink / raw) To: gcc-patches [-- Attachment #1: Type: text/plain, Size: 540 bytes --] 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. 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. Thanks, Eric Gallager gcc/testsuite/ChangeLog: 2017-03-24 Eric Gallager <egall@gwmail.gwu.edu> * gcc.dg/pragma-diag-7.c: New test. [-- Attachment #2: pragma-diag-7.c --] [-- Type: text/x-csrc, Size: 329 bytes --] /* { dg-do compile } */ unsigned long ok = 0UL; #pragma GCC diagnostic push #pragma GCC diagnostic warning "-Wtraditional" unsigned long bad = 1UL; /* { dg-warning "suffix" } */ /* Note the extra space before the pragma on this next line: */ #pragma GCC diagnostic pop unsigned long ok_again = 2UL; /* { dg-bogus "suffix" } */ ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [New file] Add testcase to ensure that #pragma GCC diagnostic push/pop works with -Wtraditional. 2017-03-24 18:46 [New file] Add testcase to ensure that #pragma GCC diagnostic push/pop works with -Wtraditional Eric Gallager @ 2017-03-24 19:28 ` David Malcolm 2017-03-24 20:49 ` Eric Gallager 0 siblings, 1 reply; 7+ messages in thread From: David Malcolm @ 2017-03-24 19:28 UTC (permalink / raw) To: Eric Gallager, gcc-patches 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 > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [New file] Add testcase to ensure that #pragma GCC diagnostic push/pop works with -Wtraditional. 2017-03-24 19:28 ` David Malcolm @ 2017-03-24 20:49 ` Eric Gallager 2017-03-26 9:54 ` Martin Sebor 2017-05-02 17:06 ` [New file, Ping] " Eric Gallager 0 siblings, 2 replies; 7+ messages in thread From: Eric Gallager @ 2017-03-24 20:49 UTC (permalink / raw) To: David Malcolm; +Cc: gcc-patches 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. > > 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [New file] Add testcase to ensure that #pragma GCC diagnostic push/pop works with -Wtraditional. 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 1 sibling, 1 reply; 7+ messages in thread From: Martin Sebor @ 2017-03-26 9:54 UTC (permalink / raw) To: Eric Gallager, David Malcolm; +Cc: gcc-patches On 03/24/2017 01:41 PM, Eric Gallager 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. Besides David's helpful tutorial, if you haven't seen them yet, there are a couple of guides on the GCC Wiki that are worth reviewing as well: https://gcc.gnu.org/wiki/Testing_GCC https://gcc.gnu.org/wiki/HowToPrepareATestcase Martin ^ permalink raw reply [flat|nested] 7+ messages in thread
* [PING] Re: [New file] Add testcase to ensure that #pragma GCC diagnostic push/pop works with -Wtraditional. 2017-03-26 9:54 ` Martin Sebor @ 2017-05-14 1:03 ` Eric Gallager 0 siblings, 0 replies; 7+ messages in thread From: Eric Gallager @ 2017-05-14 1:03 UTC (permalink / raw) To: Martin Sebor; +Cc: David Malcolm, gcc-patches Pinging this again: https://gcc.gnu.org/ml/gcc-patches/2017-05/msg00131.html On 3/25/17, Martin Sebor <msebor@gmail.com> wrote: > On 03/24/2017 01:41 PM, Eric Gallager 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. > > Besides David's helpful tutorial, if you haven't seen them yet, > there are a couple of guides on the GCC Wiki that are worth > reviewing as well: > > https://gcc.gnu.org/wiki/Testing_GCC > https://gcc.gnu.org/wiki/HowToPrepareATestcase > > Martin > ^ permalink raw reply [flat|nested] 7+ messages in thread
* [New file, Ping] Add testcase to ensure that #pragma GCC diagnostic push/pop works with -Wtraditional. 2017-03-24 20:49 ` Eric Gallager 2017-03-26 9:54 ` Martin Sebor @ 2017-05-02 17:06 ` Eric Gallager 2017-05-18 19:05 ` David Malcolm 1 sibling, 1 reply; 7+ messages in thread From: Eric Gallager @ 2017-05-02 17:06 UTC (permalink / raw) To: David Malcolm; +Cc: gcc-patches 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [New file, Ping] Add testcase to ensure that #pragma GCC diagnostic push/pop works with -Wtraditional. 2017-05-02 17:06 ` [New file, Ping] " Eric Gallager @ 2017-05-18 19:05 ` David Malcolm 0 siblings, 0 replies; 7+ messages in thread From: David Malcolm @ 2017-05-18 19:05 UTC (permalink / raw) To: Eric Gallager; +Cc: gcc-patches 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2017-05-18 18:56 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-03-24 18:46 [New file] Add testcase to ensure that #pragma GCC diagnostic push/pop works with -Wtraditional 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 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).