Status of LTO merge to mainline

Status of LTO merge to mainline

[Diego Novillo]

I am working on the last 60 testsuite failures on x86_64, but I'm
sure there will be other failures in other architectures.  My
merge plan is:

1- Fix the remaining failures on x86_64.  This includes fixing
   thunks for vararg functions which I plan to address as
   outlined in http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00953.html

2- Fix open PRs against the LTO branch.  There are 28 open bugs
   against the branch.  I need to triage them to see which ones
   may already be fixed.

3- Enable pass_ipa_free_lang_data by default.  This is the pass
   that removes all references to front end trees from GIMPLE,
   implicitly breaking debugging information.  My current plan is
   to implement Richi's and Cary's idea of generating debug info
   early.

4- Test on primary and secondary platforms.  What is the current
   suggested list of platforms?


The items that need active development are #1 and #3.  For #1, I
think I can have all the failures fixed in 2-3 weeks.  I do not
have a good estimate for #3 since I do not really know how much
work this will entail (Richi?  Cary?  would you have a rough
estimate for this?).

Any and all help I can get with #2 and #4 will be appreciated.
For #2, I need to triage the reports to see which ones can be
closed already.  For #4, it should be a matter of testing the
branch with:

$ svn co svn://gcc.gnu.org/svn/gcc/branches/lto
$ mkdir bld && cd bld
$ ../lto/configure --enable-lto && make && make -k check


Thanks.  Diego.

Re: Status of LTO merge to mainline

[H.J. Lu]

On Tue, Jul 7, 2009 at 6:09 AM, Diego Novillo<dnovillo@google.com> wrote:

> 4- Test on primary and secondary platforms.  What is the current
>   suggested list of platforms?
>
> Any and all help I can get with #2 and #4 will be appreciated.
> For #2, I need to triage the reports to see which ones can be
> closed already.  For #4, it should be a matter of testing the
> branch with:
>

I have been testing LTO on Linux/ia32 and Linux/x86-64.
I had to disable LTO test on Linux/ia64 since it miscompiled
several Java testcases into infinite loops. I can try to find out
which checkin caused this if needed.


-- 
H.J.

Re: Status of LTO merge to mainline

[Diego Novillo]

On Tue, Jul 7, 2009 at 09:31, H.J. Lu<hjl.tools@gmail.com> wrote:

> I have been testing LTO on Linux/ia32 and Linux/x86-64.
> I had to disable LTO test on Linux/ia64 since it miscompiled
> several Java testcases into infinite loops. I can try to find out
> which checkin caused this if needed.

Thanks, that would be interesting.  It's odd that Java is miscompiled
by the branch since LTO does not work with it, but there are some
changes in default codepaths, so it's worth tracking those down.


Diego.

Re: Status of LTO merge to mainline

[Richard Guenther]

On Tue, Jul 7, 2009 at 3:31 PM, H.J. Lu<hjl.tools@gmail.com> wrote:
> On Tue, Jul 7, 2009 at 6:09 AM, Diego Novillo<dnovillo@google.com> wrote:
>
>> 4- Test on primary and secondary platforms.  What is the current
>>   suggested list of platforms?
>>
>> Any and all help I can get with #2 and #4 will be appreciated.
>> For #2, I need to triage the reports to see which ones can be
>> closed already.  For #4, it should be a matter of testing the
>> branch with:
>>
>
> I have been testing LTO on Linux/ia32 and Linux/x86-64.
> I had to disable LTO test on Linux/ia64 since it miscompiled
> several Java testcases into infinite loops. I can try to find out
> which checkin caused this if needed.

I do SPEC 2000 runs on x86_64 triggered by changes on the branch.
See

http://gcc.opensuse.org/SPEC/CFP/sb-haydn-df-64/recent.html
http://gcc.opensuse.org/SPEC/CINT/sb-haydn-df-64/recent.html

Richard.

Re: Status of LTO merge to mainline

[Kaveh R. GHAZI]

On Tue, 7 Jul 2009, Diego Novillo wrote:

> 4- Test on primary and secondary platforms.  What is the current
>    suggested list of platforms?

http://gcc.gnu.org/gcc-4.5/criteria.html

Re: Status of LTO merge to mainline

[Diego Novillo]

On Wed, Jul 8, 2009 at 03:15, Kaveh R. GHAZI<ghazi@caip.rutgers.edu> wrote:
> On Tue, 7 Jul 2009, Diego Novillo wrote:
>
>> 4- Test on primary and secondary platforms.  What is the current
>>    suggested list of platforms?
>
> http://gcc.gnu.org/gcc-4.5/criteria.html

Thanks.  I've filtered the non-ELF platforms from both lists to get this:

Primary

    * i386-unknown-freebsd
    * i686-pc-linux-gnu
    * mipsisa64-elf
    * powerpc64-unknown-linux-gnu
    * sparc-sun-solaris2.10
    * x86_64-unknown-linux-gnu

Secondary

    * ia64-unknown-linux-gnu
    * s390-linux-gnu

I don't have access to s390 hosts.  Jakub, Richard, do you?


Thanks.  Diego.

Re: Status of LTO merge to mainline

[Richard Earnshaw]

On Wed, 2009-07-08 at 08:11 -0400, Diego Novillo wrote:
> On Wed, Jul 8, 2009 at 03:15, Kaveh R. GHAZI<ghazi@caip.rutgers.edu> wrote:
> > On Tue, 7 Jul 2009, Diego Novillo wrote:
> >
> >> 4- Test on primary and secondary platforms.  What is the current
> >>    suggested list of platforms?
> >
> > http://gcc.gnu.org/gcc-4.5/criteria.html
> 
> Thanks.  I've filtered the non-ELF platforms from both lists to get this:
> 
> Primary
> 
>     * i386-unknown-freebsd
>     * i686-pc-linux-gnu
>     * mipsisa64-elf
>     * powerpc64-unknown-linux-gnu
>     * sparc-sun-solaris2.10
>     * x86_64-unknown-linux-gnu

your non-elf filter has been too agressive.  ARM-EABI is an elf platform
in the primary category.

R.

Re: Status of LTO merge to mainline

[Diego Novillo]

On Mon, Jul 13, 2009 at 06:42, Richard Earnshaw<rearnsha@arm.com> wrote:

>> Primary
>>
>>     * i386-unknown-freebsd
>>     * i686-pc-linux-gnu
>>     * mipsisa64-elf
>>     * powerpc64-unknown-linux-gnu
>>     * sparc-sun-solaris2.10
>>     * x86_64-unknown-linux-gnu
>
> your non-elf filter has been too agressive.  ARM-EABI is an elf platform
> in the primary category.

Oops, thanks.  Fixed.


Diego.

Re: Status of LTO merge to mainline

[Joseph S. Myers]

On Wed, 8 Jul 2009, Diego Novillo wrote:

> > http://gcc.gnu.org/gcc-4.5/criteria.html
> 
> Thanks.  I've filtered the non-ELF platforms from both lists to get this:

You should test LTO-enabled cross tools from a non-ELF primary or 
secondary host to an ELF primary or secondary target, as well as testing 
that tools still work with LTO disabled.

-- 
Joseph S. Myers
joseph@codesourcery.com