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

[Paolo Bonzini]

Paolo Bonzini wrote:
> 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).

ENOPATCH^2.  Sorry.

Paolo
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: pr27390-more.patch
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20060605/0848f143/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: pr27390.patch
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20060605/0848f143/attachment-0001.ksh>