public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Janis Johnson <janis187@us.ibm.com>
To: Diego Novillo <dnovillo@google.com>
Cc: gcc@gcc.gnu.org
Subject: Re: [lto] Enabling LTO in selected testsuite directories
Date: Tue, 19 May 2009 00:34:00 -0000	[thread overview]
Message-ID: <1242666987.6074.15.camel@janis-laptop> (raw)
In-Reply-To: <b798aad50905160745s6d5a3dcbh1d05ff9713179f75@mail.gmail.com>

On Sat, 2009-05-16 at 10:45 -0400, Diego Novillo wrote:
> On the LTO branch, I am brute-forcing LTO compilation on all the
> testsuite directories.  This causes many spurious failures because we
> are not going to support LTO compiles on everything.  For instance,
> LTO is not supported for fortran, java, ada, mudflap.  Also, for some
> tests like pch, the tests fail trivially because of assembly
> miscomparison (due to the LTO sections).
> 
> I am trying to come up with a generic mechanism that can be used in
> individual .exp files so they can decide whether to test the two LTO
> modes.  In terms of dg.exp, it would mean adding 3 or 4 new entries to
> DG_TORTURE_OPTIONS ({-O0 -flto}, {-O2 -flto}, {-O0 -fwhopr}, {-O2
> -fwhopr}).
> 
> Do you have any suggestion on how I could implement that?

Implement check_effective_target_lto to report whether LTO is supported
and check that when setting up TORTURE_OPTIONS in one of the files in
gcc/testsuite/lib/*.exp.  Look at fortran-torture.exp, which adds
options for vectorization if appropriate.

I was supposed to get back to you, Diego, about what's needed for
LTO-specific tests, but there is probably other functionality, like
plugins, that have similar needs.  What are the general requirements
for an LTO test?  I'd guess that there will be multiple source files
that have their own compile options, and multiple links with different
link options, a final link, and execute; is that about right?

Janis

  parent reply	other threads:[~2009-05-18 17:17 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-16 20:09 Diego Novillo
2009-05-17 18:20 ` Toon Moene
2009-05-18  7:58   ` Diego Novillo
2009-05-19  0:34 ` Janis Johnson [this message]
2009-05-19 16:52   ` Diego Novillo
2009-05-19 17:10     ` Diego Novillo

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=1242666987.6074.15.camel@janis-laptop \
    --to=janis187@us.ibm.com \
    --cc=dnovillo@google.com \
    --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).