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. Again, sorry about the breakage. -- Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
