Re: [COMMITTED] Fix debug/60438 -- i686 stack vs fp operations

2014-04-26 Thread Tom de Vries
OK if bootstrap succeeds? With testing of the bootstrap build of the patch, I ran into the following regression compared to a reference bootstrap build without the patch: ... FAIL: g++.dg/tsan/cond_race.C -O2 output pattern test, is ==3087==WARNING: Program is run with unlimited stack size,

Re: [COMMITTED] Fix debug/60438 -- i686 stack vs fp operations

2014-04-26 Thread Uros Bizjak
On Sat, Apr 26, 2014 at 11:27 AM, Tom de Vries wrote: > On 13-03-14 21:49, Richard Henderson wrote: >> >> (define_expand "ldexpxf3" >> - [(set (match_dup 3) >> - (float:XF (match_operand:SI 2 "register_operand"))) >> - (parallel [(set (match_operand:XF 0 " register_operand") >> -

Re: [COMMITTED] Fix debug/60438 -- i686 stack vs fp operations

2014-04-26 Thread Tom de Vries
On 13-03-14 21:49, Richard Henderson wrote: (define_expand "ldexpxf3" - [(set (match_dup 3) - (float:XF (match_operand:SI 2 "register_operand"))) - (parallel [(set (match_operand:XF 0 " register_operand") - (unspec:XF [(match_operand:XF 1 "register_operand") -

[COMMITTED] Fix debug/60438 -- i686 stack vs fp operations

2014-03-13 Thread Richard Henderson
The original ICE is caused by the dwarf2cfi pass not noticing a stack adjustment in the insn stream. The reason for the miss is that the push/pop was added by a post-reload splitter, which did nothing to mark the insn for special treatment. In the PR, Jakub and I threw around several ideas. My f