This is the mail archive of the
mailing list for the GCC project.
Re: PR rtl-optimization/15248 -- semi-latent reload bug
(re-added gcc-patches Cc)
Note that we can still have a single_set which appears inside a
PARALLEL (the other expressions will be CLOBBERS, USEs and SETs with
an output that is not used).
Shouldn't matter; the intention is quite clearly that an insn marked as
an initializing insn can be deleted - if that doesn't hold in some case,
the bug is in update_equiv_regs. I don't think there's anything to
Now, I think update_equiv_regs only handles two cases.
1. A register used inside one basic block only, set only once,
and written to memory, becomes REG_EQUIV to that location.
2. Register always set to the same value which is REG_EQUAL to
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
../../../egcs/libjava/jni.cc: In function 'void*
_Jv_LookupJNIMethod(java::lang::Class*, _Jv_Utf8Const*, _Jv_Utf8Const*,
../../../egcs/libjava/jni.cc:2141: error: Statement marked for throw,
# VUSE <D.15132_67(ab)>;
D.27993_69 = D.15132;
../../../egcs/libjava/jni.cc:2141: internal compiler error: verify_stmts
which I believe has been reported before and is unrelated.
Any further concerns? If not, I'm checking in my patch.