On Tue, May 19, 2009 at 10:30, Diego Novillo wrote:
> 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.
Actually, scratch this idea. This is still needed to protect against
builds that do
On Mon, May 18, 2009 at 13:16, Janis Johnson 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
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
On Sun, May 17, 2009 at 09:26, Toon Moene wrote:
> Does this mean:
>
> You do not support these languages *yet*.
This one.
Supporting new languages is, in principle, very simple. In theory,
there is nothing special to be done. Every FE already generates
gimple and that's what we are writing t
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.
I almost missed
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
