On Mon, Nov 18, 2013 at 5:36 AM, Jeff Law <l...@redhat.com> 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 ultimately what we need > to be consistent with.
Hmm, I agree but look at the test in ifcvt.c... >> Bah... Emitting the barrier is necessary here because >> fixup_reorder_chain doesn't handle cases where a basic block is a dead >> end. That is actually a bug in fixup_reorder_chain: Other passes could >> create dead ends in the CFG in cfglayout mode and not emit a barrier >> into BB_FOOTER, and fixup_reorder_chain wouldn't be able to handle >> that (resulting in verify_flow_info failure). > > Umm, no. Failure to emit the barrier will result in a checking failure. > Been there, done that. Read my comment again: "... is necessary ..." and "... fixup_reorder_chain should emit a BARRIER ...". So yes, you need to emit that barrier with GCC as-is. But in a perfect, ideal world where everyone is happy all the time, the sun always shines, lunch is always free, and everything smells like red roses at dawn, you shouldn't have to emit a BARRIER when the compiler is in cfglayout mode. Instead, fixup_reorder_chain *should* do it for you, but obviously doesn't. There are several places where GCC code emits barriers while in cfglayout mode, and that makes no sense because barriers are meaningless in cfglayout mode :-) > To trigger use the test in 59019 with an itanic cross compiler and comment > out these two lines from gimple-ssa-isolate-paths.c: > > > TREE_THIS_VOLATILE (op) = 1; > TREE_SIDE_EFFECTS (op) = 1; OK, thanks. Let's see if I can tackle this one. Ciao! Steven
