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
