On Mon, Nov 18, 2013 at 5:36 AM, Jeff Law wrote:
> On 11/17/13 04:28, Steven Bosscher wrote:
>>
>>
>> TRAP_CONDITION (PATTERN (i3)) == const1_rtx
>>
>> But shouldn't the check be on const_true_rtx? Or does combine put a
>> const1_rtx there?
>
> I took const1_rtx from control_flow_insn_p. That's u
On 11/17/13 04:28, Steven Bosscher wrote:
TRAP_CONDITION (PATTERN (i3)) == const1_rtx
But shouldn't the check be on const_true_rtx? Or does combine put a
const1_rtx there?
I took const1_rtx from control_flow_insn_p. That's ultimately what we
need to be consistent with.
+{
+ ba
On Sun, Nov 17, 2013 at 7:48 AM, Jeff Law wrote:
>
> * combine.c (try_combine): If we have created an unconditional trap,
> make sure to fixup the insn stream & CFG appropriately.
>
> diff --git a/gcc/combine.c b/gcc/combine.c
> index 13f5e29..b3d20f2 100644
> --- a/gcc/combine.c
>
59019 is currently latent on the trunk, but it's likely to fail again at
some point.
The problem we have is combine transforms a conditional trap into an
unconditional trap.
conditional traps are not considered control flow insns, but
unconditional traps are.
Thus, if we turn a condition
