This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.

> > 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/ In function 'void* 
> _Jv_LookupJNIMethod(java::lang::Class*, _Jv_Utf8Const*, _Jv_Utf8Const*, 
> int)':
> ../../../egcs/libjava/ error: Statement marked for throw, 
> but doesn't.
> #   VUSE <D.15132_67(ab)>;
> D.27993_69 = D.15132;
> ../../../egcs/libjava/ 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]