Re: bin/47301: Miscompilation by bundled GCC

[Torbjorn Granlund <tg%gmplib.org@localhost>]

The following reply was made to PR bin/47301; it has been noted by GNATS.

From: Torbjorn Granlund <tg%gmplib.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: toolchain-manager%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
         netbsd-bugs%netbsd.org@localhost
Subject: Re: bin/47301: Miscompilation by bundled GCC
Date: Mon, 10 Dec 2012 15:22:41 +0100

 I looked a bit into this GCC problem, using gcc 4.7.2.
 
 It seems to be a reload problem, and I think the vax port is innocent.
 
 We have (slightly edited for legibility),
 
   (set (mem:SI (mem/f:SI (plus:SI (reg/v/f:SI 261 [ x ])
                                  (const_int 8))))
        (mem/u:SI (plus:SI (mult:SI (reg/v:SI 262 [ n ])
                                   (const_int 4))
                          (symbol_ref:SI ("__gmp_oddfac_table")))))
 
 which then gets reloaded into,
 
   (set (reg:SI 1 %r1)
        (mem/f/c:SI (plus:SI (reg/f:SI 12 %ap)
                            (const_int 4))))
 
   (set (reg:SI 1 %r1)
        (mem/c:SI (plus:SI (reg/f:SI 12 %ap)
                          (const_int 8))))
 
   (set (mem:SI (mem/f:SI (plus:SI (reg:SI 1 %r1)
                                  (const_int 8))))
        (mem/u:SI (plus:SI (mult:SI (reg:SI 1 %r1)
                                   (const_int 4))
                          (symbol_ref:SI ("__gmp_oddfac_table")))))
 
 i.e., reload puts both pseudo 261 and pseudo 262 into hard reg 1 in
 the same live range.  That is bad.
 
 Very few current backends support mem-to-mem copying in a single
 instruction.  It might be something that no longer works in reload.
 
 Assuming my assumption is correct, a possible fix would be to disallow
 mem-to-mem insns, at least until reload.
 
 --=20
 Torbj=C3=B6rn