[RFC] PR/27390, latent complex-mode bug in regstack

[Paolo Bonzini]

This patch fixes two problems in regstack involving complex modes.

The problem is latent on 4.1 too, and manifests as a stack underflow in 
gcc.target/x86_64/abi/test_complex_returning.c at -O0.  Unluckily, after 
the PR/19653 patch something convinces reload to produce slightly 
different RTL, and the stack underflow turns into a wrong-code generation.

The problematic RTL is a clobber in complex mode. When regstack 
encounters one, it calls move_nan_to_stack_reg twice on the same insn.  
However, the second call does *not* add a new insn, so we get only one 
stack load instead of two.

Then, however, when popping a complex floating-point value, the real 
part is popped first and the imaginary part is popped second.  However, 
this seems to produce wrong code in this case.  For this part, I would 
appreciate help because I am not sure whether what I should reorder 
these two, or rather I should invert the two pushes in subst_stack_regs_pat.

So, I propose two patches: the first one does not change the 
move_nan_to_stack_reg order, and only makes sure that both are emitted 
in the insn stream, and reorders the pops in emit_pop_insn.  This patch 
was bootstrapped/regtested on x86_64-pc-linux-gnu and fixes the 
regression without introducing any new failure.

The second one changes the move_nan_to_stack_reg order, and of course 
makes sure that both are emitted in the insn stream.  This seems to fix 
the regression too.  It was not bootstrapped/regtested because I do not 
have access to the affected hardware; Richard Guenther has been very 
kind in testing the patches for this regression, but I'd rather have 
counsel from the reg-stack expert before asking him for a third 
bootstrap/regtest.

Does any of these sound ok, or is either approach completely wrong?  (I 
am not asking explicitly for approval of either patch, but would not be 
unhappy with it).

Paolo