This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PR rtl-optimization/15248 -- semi-latent reload bug
On Wed, 2005-05-18 at 16:01 +0200, Bernd Schmidt wrote:
> > Do we need to worry about the case where we have a pseudo equivalenced
> > to a read-only memory location that initially gets a hard register, but
> > later that hard reg is spilled? Do we replace the pseudo with its
> > equivalent memory location in that case? If so, then I think we need
> > some compensation code for that case as well.
>
> If we spill a hard reg, we just deallocate it from the pseudo using it.
> That means in the next iteration of reload we'll use the equivalence
> in the same way as if the pseudo never got a hard register.
OK.
>
> > As for testcode -- if it passes mainline bootstrap, then you've
> > exercised the testcode.
>
> Bootstraps on i686-linux with yesterday's mainline. Today's bootstrap
> fails with
> ../../../egcs/libjava/jni.cc: In function 'void*
> _Jv_LookupJNIMethod(java::lang::Class*, _Jv_Utf8Const*, _Jv_Utf8Const*,
> int)':
> ../../../egcs/libjava/jni.cc:2141: error: Statement marked for throw,
> but doesn't.
> # VUSE <D.15132_67(ab)>;
> D.27993_69 = D.15132;
>
> ../../../egcs/libjava/jni.cc:2141: internal compiler error: verify_stmts
> failed.
That was unrelated to your patch -- it was a semi-latent but in the
ADDR_EXPR changes. It's fixed now.
No further concerns from me. Once it's in the mainline for a little
while we should seriously consider backporting it to 4.0 and maybe
even the 3.x series.
Jeff