On Mon, Dec 2, 2013 at 2:51 PM, Jakub Jelinek ja...@redhat.com wrote:
Hi!
On Sat, Nov 30, 2013 at 12:38:30PM +0100, Eric Botcazou wrote:
Rather than adding do_pending_stack_adjust () in all the places, especially
when it isn't clear whether emit_conditional_move will be called at all and
On Mon, 2 Dec 2013, Jeff Law wrote:
On 12/02/13 15:51, Jakub Jelinek wrote:
Hi!
On Sat, Nov 30, 2013 at 12:38:30PM +0100, Eric Botcazou wrote:
Rather than adding do_pending_stack_adjust () in all the places,
especially
when it isn't clear whether emit_conditional_move will be
Hi!
On Sat, Nov 30, 2013 at 12:38:30PM +0100, Eric Botcazou wrote:
Rather than adding do_pending_stack_adjust () in all the places, especially
when it isn't clear whether emit_conditional_move will be called at all and
whether it will actually do do_pending_stack_adjust (), I chose to add
On 12/02/13 15:51, Jakub Jelinek wrote:
Hi!
On Sat, Nov 30, 2013 at 12:38:30PM +0100, Eric Botcazou wrote:
Rather than adding do_pending_stack_adjust () in all the places, especially
when it isn't clear whether emit_conditional_move will be called at all and
whether it will actually do
Jakub Jelinek ja...@redhat.com wrote:
Hi!
The following testcase ICEs because expand_cond_expr_using_cmove
calls emit_conditional_move (which calls do_pending_stack_adjust
under some circumstances), but when that fails, just removes all the
insns generated by emit_conditional_move (and perhaps
Rather than adding do_pending_stack_adjust () in all the places, especially
when it isn't clear whether emit_conditional_move will be called at all and
whether it will actually do do_pending_stack_adjust (), I chose to add
two new functions to save/restore the pending stack adjustment state,
Hi!
The following testcase ICEs because expand_cond_expr_using_cmove
calls emit_conditional_move (which calls do_pending_stack_adjust
under some circumstances), but when that fails, just removes all the
insns generated by emit_conditional_move (and perhaps some earlier ones
too), thus it removes
