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: Geoff Keating <geoffk at geoffk dot org>
- To: Joern Rennecke <joern dot rennecke at superh 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: 17 Apr 2003 11:02:16 -0700
- Subject: Re: 8 GCC regressions, 2 new, with your patch on 2003-04-16T21:21:05Z.
- References: <200304170236.h3H2aX9G000671@gcc-regress.apple.com><3E9E95DD.C4593F1B@superh.com>
Joern Rennecke <joern dot rennecke at superh dot com> writes:
> 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.
I'm inclined to agree, can you come up with a testsuite patch?
--
- Geoffrey Keating <geoffk at geoffk dot org>