This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: 8 GCC regressions, 2 new, with your patch on 2003-04-16T21:21:05Z.
- From: Joern Rennecke <joern dot rennecke at superh dot com>
- To: gcc-regression at gcc dot gnu dot org, rth at redhat dot com
- Cc: aldyh at redhat dot com, dave dot anglin at nrc-cnrc dot gc dot ca, mark at codesourcery dot com, rearnsha at arm dot com, redi at gcc dot gnu dot org, gcc at gcc dot gnu dot org, Dale Johannesen <dalej at apple dot com>
- Date: Thu, 17 Apr 2003 12:54:05 +0100
- Subject: Re: 8 GCC regressions, 2 new, with your patch on 2003-04-16T21:21:05Z.
- Organization: SuperH UK Ltd.
- References: <200304170236.h3H2aX9G000671@gcc-regress.apple.com>
GCC regression checker wrote:
...
> The new failures are:
> native gcc.sum gcc.dg/debug/debug-1.c
> native gcc.sum gcc.dg/debug/debug-2.c
Looking at the debug-1.c case, I see that the relevant transformation
was done in combine, no doubt do to the patch that I applied yesterday:
==================== before combine ==================================
(insn 47 45 15 0 0x401c8a7c (set (reg/v:SI 120 [ xyzzy ])
(ashift:SI (reg:SI 126)
(const_int 1 [0x1]))) 132 {ashlsi3_no_power} (insn_list 45 (nil))
(expr_list:REG_DEAD (reg:SI 126)
(nil)))
..
(insn 29 27 32 0 (nil) (set (reg/i:SI 3 r3 [ <result> ])
(reg/v:SI 120 [ xyzzy ])) 314 {*movsi_internal1} (insn_list 47 (nil))
(expr_list:REG_DEAD (reg/v:SI 120 [ xyzzy ])
(nil)))
==================== after combine ===================================
(note 47 45 15 0 NOTE_INSN_DELETED)
..
(insn 29 27 32 0 (nil) (set (reg/i:SI 3 r3 [ <result> ])
(ashift:SI (reg:SI 126)
(const_int 1 [0x1]))) 132 {ashlsi3_no_power} (insn_list 45 (nil))
(expr_list:REG_DEAD (reg:SI 126)
(nil)))
on i386 and sh1..sh4, the return value is passed in a likely spilled register,
hence this failure was not triggered during my regression tests on these
targets. Still, the transformation is safe, and I see nothing fundamentally
wrong with removing a variable in an optimizing compilation - yes, it makes
debugging harder, but then so do a lot of optimizations.
--
--------------------------
SuperH (UK) Ltd.
2410 Aztec West / Almondsbury / BRISTOL / BS32 4QX
T:+44 1454 465658