On 11/15/14 14:37, Matthew Fortune wrote:
Eric Botcazou writes:
IIRC, fill_eager and its related friends are all speculative in some
way
and aren't those precisely the ones that are causing us problems.
Also
note we have backends working around this stuff in fairly blunt ways:
I'd say tha
Eric Botcazou writes:
> > IIRC, fill_eager and its related friends are all speculative in some
> way
> > and aren't those precisely the ones that are causing us problems.
> Also
> > note we have backends working around this stuff in fairly blunt ways:
>
> I'd say that the PA back-end went a bit t
> IIRC, fill_eager and its related friends are all speculative in some way
> and aren't those precisely the ones that are causing us problems. Also
> note we have backends working around this stuff in fairly blunt ways:
I'd say that the PA back-end went a bit too far here, especially if it marks
On 11/14/14 03:44, Eric Botcazou wrote:
I wonder how many other problems of this nature are lurking in reorg.c.
For example steal_delay_list_from_{target,fallthrough} or the code
which searches for arithmetic at the branch target, and puts the
opposite insn in a delay slot.
Right, and the latte
> I wonder how many other problems of this nature are lurking in reorg.c.
> For example steal_delay_list_from_{target,fallthrough} or the code
> which searches for arithmetic at the branch target, and puts the
> opposite insn in a delay slot.
Right, and the latter has already been dealt with by Ri
On 11/11/14 15:28, Eric Botcazou wrote:
In https://gcc.gnu.org/ml/gcc-patches/2012-01/msg00363.html, Tom reported an
ICE in the DWARF CFI pass because a frame-related insn was speculated by the
reorg pass and, therefore, disabled the optimization. It turns out that the
same code (when condition
