On Fri, Jun 15, 2012 at 3:21 PM, Alexandre Oliva <aol...@redhat.com> wrote: > On Jun 14, 2012, "H.J. Lu" <hjl.to...@gmail.com> wrote: > >> On Tue, Jun 12, 2012 at 1:42 PM, Richard Henderson <r...@redhat.com> wrote: >>> On 2012-06-05 12:33, Alexandre Oliva wrote: >>>> for gcc/ChangeLog >>>> from Alexandre Oliva <aol...@redhat.com> >>>> >>>> PR debug/49888 >>>> * var-tracking.c: Include alias.h. >>>> (overlapping_mems): New struct. >>>> (drop_overlapping_mem_locs): New. >>>> (clobber_overlapping_mems): New. >>>> (var_mem_delete_and_set, var_mem_delete): Call it. >>>> (val_bind): Likewise, but only if modified. >>>> (compute_bb_dataflow, emit_notes_in_bb): Call it on MEMs. >>>> * Makefile.in (var-tracking.o): Depend in $(ALIAS_H). >>>> >>>> for gcc/testsuite/ChangeLog >>>> from Alexandre Oliva <aol...@redhat.com> >>>> >>>> PR debug/49888 >>>> * gcc.dg/guality/pr49888.c: New. >>> >>> Ok. > >> It caused: > >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53671 > > I see a few of these failures myself. They're in my test results. I > guess I was so caught up in assessing the debug info quality changes > with this patch that I completely failed to look at the test results, > because they've been around for a while, and I have a few pristine-build > baselines in between. Apologies for this mistake. > > Anyway... The problem is not too hard to understand, but it may be > somewhat hard to fix. Basically, pushing registers to save them on the > stack implies writes that are currently thought to conflict with the > MEMs holding incoming arguments, and apparently there isn't enough > information in the cselib static table for us to realize the write > doesn't alias with any of the incoming arguments. > > Using the dynamic tables during alias testing is one possibility I'm > looking into, but this won't be trivial and it could get expensive; > another, that has just occurred to me while composing this message, is > to use the cselib static table itself, for it *should* have enough info > for us to realize that argp and sp offset are related and, given proper > offsets, non-overlapping. > > Now, neither approach is going to be an immediate fix. Should I revert > the patch, or can we live with some debug info completeness regressions > for a bit? I wouldn't mind reverting it, but I won't unless the broken > patch is actually causing trouble to any of us. >
If I understand it correctly, the new approach fails to handle push properly. If it is true, I think the patch should be reverted. Thanks. -- H.J.
