Re: Kill hack in java disabling unit-at-a-time

[Jan Hubicka <jh at suse dot cz>]

> Jan Hubicka writes:
>  > > Jan Hubicka writes:
>  > > 
>  > >  > apparently this hack went in with tree-ssa merge causing unit-at-a-time
>  > >  > to be disabled by default since 4.0.0.  Fortunately re-enabling it don't
>  > >  > seem to cause any regressions, however I will wait a day before
>  > >  > commiting this so people might comment if this don't seem appropriate
>  > >  > for stage3.
>  > >  > 
>  > >  > Bootstrapped/regtested i686-pc-gnu-linux, will commit it as obvious if
>  > >  > no-one objects :)
>  > > 
>  > > It's far from obvious.  There were severe problems with unit-at-a-time
>  > > and gcj, and this shouldn't go in without extensive testing.  A simple
>  > > 'make check' and bootstrap isn't enough.  We'll need time to test this.
>  > 
>  > How do you propose to test it? 
> 
> With a bunch of large Java applications -- these are in the code base
> of Fedora Core 5.

Will you handle the testing or can you at least be more specific?  Are
there any PRs open for the ICEs and blowups?
> 
>  > If we don't want unit-at-a-time to be enabled for 4.1, can we just
>  > move it into option handling instead of such a hidden hack?
> 
> Sure, that seems reasonable.  Perhaps change it so that unit-at-a-time
> can be enabled, but is not the default.

OK, for the very moment I will add the flag so we can at least make the
testing easier.  For 4.2 however there are definite plans for dropping
non-unit-at-a-time (there are still problem with few specific sources in
glibc and runtime but at very minimum I plan to drop non-unit-at-a-time
inliner) so we need to have this resolved by then.

Honza
> 
> Andrew.