This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [lto] Enabling LTO in selected testsuite directories


On Mon, May 18, 2009 at 13:16, Janis Johnson <janis187@us.ibm.com> wrote:

> 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.

Thanks.  I'm not sure it's working as I want it to, though.  I played
with it a little bit and this is how I thought of using it:

1- In lib/target-supports.exp add:

proc check_effective_target_lto { } {
    return [check_no_compiler_messages lto object {
        void foo (void) { }
    } "-O0 -flto"]
}


2- In lib/c-torture.exp and lib/gcc-dg.exp add:

set LTO_TORTURE_OPTIONS ""
if [check_effective_target_lto] {
    set LTO_TORTURE_OPTIONS [list {} {-flto} {-fwhopr}]
}


3- Every .exp file that wants to test LTO calls:

set-torture-options <main-options-var> $LTO_TORTURE_OPTIONS


The problem I'm having is that check_no_compiler_messages uses
C, C++ or Fortran depending on the code snippet format
(naturally).  I actually need it to check the front end that is
currently used.  Is there some global flag that holds this?

In some .exp files, even if the front end supports LTO, it may
not want to use the LTO options.  For instance, pch.exp saves the
initial assembly without -flto, so all the tests trivially
miscompare with LTO enabled.

Maybe I could skip step #1 and always define LTO_TORTURE_OPTIONS?
Then it's up to every individual .exp file to decide if it wants
to add LTO to the mix.


> 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?

Yes.  For reference, I implemented this support in the lto branch
(testsuite/lib/lto.exp).  It has not been reviewed yet, so I
expect it to need fixes, but it does what we need for
LTO-specific testing.


Thanks.  Diego.

Attachment: lto.exp
Description: Binary data


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]