| Message ID | CABu31nMhyrBUwmNPAgg-AhZXyT29c5pdobfazAKCKq+RUjS6Gw@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
On Sun, 25 Nov 2012, Steven Bosscher wrote: > stop_search_p will reach the default case on DEBUG_INSN, and the > default case is "gcc_unreachable()". I suppose this means nobody is > using DWARF3+ on a dbr_sched target, it can't possibly ever have > worked. Eric? There must be something else (something more) going on; I should have noticed massive breakage in test-results (big differences to other targets' test-results) for cris-elf. brgds, H-P
On Sun, Nov 25, 2012 at 12:59:48PM +0100, Steven Bosscher wrote: > stop_search_p will reach the default case on DEBUG_INSN, and the > default case is "gcc_unreachable()". I suppose this means nobody is > using DWARF3+ on a dbr_sched target, it can't possibly ever have > worked. Eric? Isn't dbr scheduling after var-tracking, which removes DEBUG_INSNs (and instead adds NOTE_INSN_VAR_LOCATION and NOTE_INSN_CALL_ARG_LOCATION notes)? So, your patch is unnecessary. > Anyway, also obvious: Don't stop on DEBUG_INSNs. > > * reorg.c (stop_search_p): Don't crash on DEBUG_INSNs. > > Index: reorg.c > =================================================================== > --- reorg.c (revision 193787) > +++ reorg.c (working copy) > @@ -260,6 +260,7 @@ stop_search_p (rtx insn, int labels_p) > { > case NOTE: > case CALL_INSN: > + case DEBUG_INSN: > return 0; > > case CODE_LABEL: Jakub
On Sun, Nov 25, 2012 at 11:09 PM, Jakub Jelinek <jakub@redhat.com> wrote: > On Sun, Nov 25, 2012 at 12:59:48PM +0100, Steven Bosscher wrote: >> stop_search_p will reach the default case on DEBUG_INSN, and the >> default case is "gcc_unreachable()". I suppose this means nobody is >> using DWARF3+ on a dbr_sched target, it can't possibly ever have >> worked. Eric? > > Isn't dbr scheduling after var-tracking, which removes DEBUG_INSNs (and > instead adds NOTE_INSN_VAR_LOCATION and NOTE_INSN_CALL_ARG_LOCATION notes)? > So, your patch is unnecessary. If that is true, then why are there so many post var-tracking passes using NONDEBUG_INSN_P and/or looking for the DEBUG_INSN code? See e.g. shorten_branches, reorg.c, various machine reorgs, etc. For example from reorg.c:redundant_insn() in the loop "/* Scan backwards looking for a match. */": 151731 nemet if (!NONDEBUG_INSN_P (trial)) 99 kenner continue; 151731 nemet --insns_to_search; This was introduced to fix PR41349. Apparently DEBUG_INSN live on beyond var-tracking...? Ciao! Steven
Index: reorg.c =================================================================== --- reorg.c (revision 193787) +++ reorg.c (working copy) @@ -260,6 +260,7 @@ stop_search_p (rtx insn, int labels_p) { case NOTE: case CALL_INSN: + case DEBUG_INSN: return 0; case CODE_LABEL:
Hi, stop_search_p will reach the default case on DEBUG_INSN, and the default case is "gcc_unreachable()". I suppose this means nobody is using DWARF3+ on a dbr_sched target, it can't possibly ever have worked. Eric? Anyway, also obvious: Don't stop on DEBUG_INSNs. Ciao! Steven * reorg.c (stop_search_p): Don't crash on DEBUG_INSNs.