public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Janis Johnson <janis187@us.ibm.com>
To: Eric Botcazou <ebotcazou@libertysurf.fr>
Cc: Janis Johnson <janis187@us.ibm.com>, gcc@gcc.gnu.org
Subject: Re: Running the compat testsuite in "non-mirror" mode
Date: Fri, 19 Nov 2004 18:37:00 -0000	[thread overview]
Message-ID: <20041119175829.GA4515@us.ibm.com> (raw)
In-Reply-To: <200411190914.31279.ebotcazou@libertysurf.fr>

On Fri, Nov 19, 2004 at 09:17:04AM +0100, Eric Botcazou wrote:
> > I'm sorry, I still don't understand what you mean my mirror and non-mirror
> > modes.
> 
> OK, sorry for being obtuse.
> 
> The compat testsuite is currently automatically run only once, in what I call 
> mirror mode, that is the newly built compiler is tested against (an identical 
> copy of) itself.  While this is useful for catching problems in the 
> argument/return value handling machinery of the back-end, this is only 
> moderately useful for compatibility purposes.  Of course this is 
> customizable, but only externally (i.e. manually or with an external Makefile 
> for example).
> 
> What I would like to have is the possibility to automatically run (i.e. with a 
> bare make -k check-gcc) the compat testsuite twice, once in the mirror mode 
> described above and once in a non-mirror mode.  The latter would mean that 
> the newly built compiler is tested against a slight variation of itself, i.e. 
> typically with a non-default option, that could have an impact on the calling 
> conventions, turned on.  So it would be possible to specify in the compat 
> testsuite harness (e.g. a platform-specific driver) that it should be 
> automatically run twice on a particular platform, in mirror mode and with an 
> hardcoded pair (-mfoo/-mno-foo) of options.

I think I understand now.  For anyone testing a particular target, the
compat tests would be run first using the compiler under test to compile
both parts of each test using default options, and again using different
sets of options for the two parts of each test to make sure those
options don't affect binary compatibility.  Is that right?

This is probably easy to set up in the compat.exp file for each compat
testsuite; I'll take a look.

Janis

  reply	other threads:[~2004-11-19 17:58 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-18  9:21 Eric Botcazou
2004-11-18 22:35 ` Janis Johnson
2004-11-18 23:36   ` Eric Botcazou
2004-11-19  0:14     ` Janis Johnson
2004-11-19  0:15       ` Eric Botcazou
2004-11-19  0:37         ` Janis Johnson
2004-11-19 11:20           ` Eric Botcazou
2004-11-19 18:37             ` Janis Johnson [this message]
2004-11-19 19:17               ` Eric Botcazou
2004-11-20  1:01                 ` Janis Johnson
2004-11-20  1:30                   ` Eric Botcazou
2004-11-22  0:59                   ` Eric Botcazou

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=20041119175829.GA4515@us.ibm.com \
    --to=janis187@us.ibm.com \
    --cc=ebotcazou@libertysurf.fr \
    --cc=gcc@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).