public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Manuel López-Ibáñez" <lopezibanez@gmail.com>
To: "Joseph S. Myers" <joseph@codesourcery.com>
Cc: "Ian Lance Taylor" <iant@google.com>,
	gcc-patches <gcc-patches@gcc.gnu.org>,
	 	"Gabriel Dos Reis" <gdr@integrable-solutions.net>,
	 	"Andrew Pinski" <pinskia@physics.uc.edu>,
	 	"Mark Mitchell" <mark@codesourcery.com>
Subject: Re: PATCH RFA: C++ frontend warning: comparing function pointer to NULL
Date: Sun, 07 Jan 2007 22:41:00 -0000	[thread overview]
Message-ID: <6c33472e0701071441w57b095e8qa345d325c74c6136@mail.gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0701072207000.3376@digraph.polyomino.org.uk>

On 07/01/07, Joseph S. Myers <joseph@codesourcery.com> wrote:
> On Sun, 7 Jan 2007, Manuel Lopez-Ibanez wrote:
>
> > Also, perhaps we could consider this something to take into account
> > before sending patches that add new testcases. Most of the time, a
> > simple grep on the option name or a representative part of the
> > expected output will bring up similar (and thus redundant) testcases.
> > Maybe this could be commented somewhere...
>
> It's generally a mistake to consider testcases redundant unless actually
> identical.  While two testcases may appear to test the same thing with the
> current implementation while the compiler is working correctly, a
> reimplementation of a feature or diagnostic could cause them to take
> different code paths, and a regression could break one similar case but
> not the other.

Of course, being strict, unless the two testcase files are byte-wise
identical, anything may happen. But I guess that there may be some
practical assumptions about the equivalence of testcases that allows
to avoid testing every possible variation of any random testcase.

For example, I would consider that it is generally safe to assume from
a practical point of view that if two testcases vary only in
whitespace, then they may be considered equivalent. I would go a bit
further and consider that if two testcases vary only on the names of
identifiers, then they may be considered equivalent. I guess we could
find more practical assumptions.

Of course, equivalence should be decided for each testcase. What I
wished to say is that it should be taken into account. Or perhaps not,
if we don't care about the testsuite size, regression testing time and
testcases getting silently obsolete. It was more a subtle question
that a firm proposal.

Here is another question, if I find a testcase in g++.old-deja that is
relevant for a patch that I am going to submit, would it be
appropriate to move it to g++.dg/X and give it an apter name?

For example, if I am preparing testcases such Wsuperwarning-1.C,
Wsuperwarning-2.C and I find that g++.old-deja/g++.mike/warn19.C is
relevant for -Wsuperwarning, should I do "mv
g++.old-deja/g++.mike/warn19.C g++.dg/warn/Wsuperwarning-3.C ?

Cheers,

Manuel.

  reply	other threads:[~2007-01-07 22:41 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-07 13:30 Manuel López-Ibáñez
2007-01-07 13:42 ` Gabriel Dos Reis
2007-01-07 19:28 ` Ian Lance Taylor
2007-01-07 21:12   ` Manuel López-Ibáñez
2007-01-07 22:09     ` Joseph S. Myers
2007-01-07 22:41       ` Manuel López-Ibáñez [this message]
2007-01-08  4:18     ` Ian Lance Taylor
  -- strict thread matches above, loose matches on Subject: below --
2007-01-04 15:23 Ian Lance Taylor
2007-01-04 18:47 ` Andrew Pinski
2007-01-05  2:42   ` Ian Lance Taylor
2007-01-05  5:14     ` Mark Mitchell
2007-01-05  6:58       ` Ian Lance Taylor
2007-01-05 17:45         ` Mark Mitchell
2007-01-05  6:48     ` Gabriel Dos Reis

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=6c33472e0701071441w57b095e8qa345d325c74c6136@mail.gmail.com \
    --to=lopezibanez@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=gdr@integrable-solutions.net \
    --cc=iant@google.com \
    --cc=joseph@codesourcery.com \
    --cc=mark@codesourcery.com \
    --cc=pinskia@physics.uc.edu \
    /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).