NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: bin/47301: Miscompilation by bundled GCC

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

From: Torbjorn Granlund <>
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.

Home | Main Index | Thread Index | Old Index