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.
They are very likely overzealous.
For example from reorg.c:redundant_insn() in the loop /* Scan
Eric Botcazou ebotca...@adacore.com writes:
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.
They are very likely overzealous.
For example from
On Mon, Nov 26, 2012 at 07:08:41PM +, Richard Sandiford wrote:
In the long term it would be good to replace dbr_schedule altogether,
but in the medium term I thought we might want to update it so that
it can run before vartracking.
var-tracking definitely isn't prepared to handle
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
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
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
On Sun, Nov 25, 2012 at 11:09 PM, Jakub Jelinek ja...@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
