Re: bin/47301: Miscompilation by bundled GCC

[<Paul_Koning%Dell.com@localhost>]

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

From: <Paul_Koning%Dell.com@localhost>
To: <tg%gmplib.org@localhost>
Cc: <gnats-bugs%NetBSD.org@localhost>, <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 16:37:07 +0000

 On Dec 10, 2012, at 9:22 AM, Torbjorn Granlund wrote:
 
 > I looked a bit into this GCC problem, using gcc 4.7.2.
 >=20
 > It seems to be a reload problem, and I think the vax port is innocent.
 >=20
 > We have (slightly edited for legibility),
 >=20
 >  (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")))))
 >=20
 > which then gets reloaded into,
 >=20
 >  (set (reg:SI 1 %r1)
 >       (mem/f/c:SI (plus:SI (reg/f:SI 12 %ap)
 >                          (const_int 4))))
 >=20
 >  (set (reg:SI 1 %r1)
 >       (mem/c:SI (plus:SI (reg/f:SI 12 %ap)
 >                        (const_int 8))))
 >=20
 >  (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")))))
 >=20
 > i.e., reload puts both pseudo 261 and pseudo 262 into hard reg 1 in
 > the same live range.  That is bad.
 >=20
 > Very few current backends support mem-to-mem copying in a single
 > instruction.  It might be something that no longer works in reload.
 >=20
 > Assuming my assumption is correct, a possible fix would be to disallow
 > mem-to-mem insns, at least until reload.
 >=20
 > --=20
 > Torbj=F6rn
 
 I wonder what that workaround would do to performance.  This sort of reload=
  case could pop up in lots of machine architectures -- any CISC-like machin=
 e might be affected.  pdp11, 68k, i386, ...
 
        paul