This is the mail archive of the
gcc-regression@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: Richard Henderson <rth at redhat dot com>
- To: Joern Rennecke <joern dot rennecke at superh dot com>
- Cc: gcc-regression at gcc dot gnu dot org, 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 11:27:59 -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>
On Thu, Apr 17, 2003 at 12:54:05PM +0100, Joern Rennecke wrote:
> 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.
The original motivation for the test was a bit more
complicated than that:
http://gcc.gnu.org/ml/gcc-patches/2001-12/msg02450.html
Interestingly, this test continues to pass with dwarf2:
.uleb128 0x4 // (DIE (0x5c) DW_TAG_variable)
data4.ua @secrel(.LASF3) // DW_AT_name: "xyzzy"
data1 0x1 // DW_AT_decl_file
data1 0x9 // DW_AT_decl_line
data4.ua 0x68 // DW_AT_type
Note that there is no DW_AT_location entry, so indeed
this variable has been optimized away, but the lexical
block still exists, which is the real point of the test.
I guess stabs can't represent this. I'd much prefer we
XFAIL these tests in that case rather than remove or
modify the test.
It's also a point that perhaps it would be best to remove
Dale's patch after the new register allocator is enabled
by default -- we'll get better debug information in that case.
r~