This is the mail archive of the
mailing list for the GCC project.
Re: does "assign_stack_local" from "function.h" automatically Do The Right Thing with debug information? [relates to the RTL-level if-conversion improvement project]
- From: Jeff Law <law at redhat dot com>
- To: Abe <abe_skolnik at yahoo dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, Kyrill Tkachov <kyrylo dot tkachov at arm dot com>
- Date: Wed, 23 Sep 2015 15:12:28 -0600
- Subject: Re: does "assign_stack_local" from "function.h" automatically Do The Right Thing with debug information? [relates to the RTL-level if-conversion improvement project]
- Authentication-results: sourceware.org; auth=none
- References: <560311FF dot 2070303 at yahoo dot com>
On 09/23/2015 02:56 PM, Abe wrote:
Neither inherently affects debug information. So if one is working and
the other not, there's a deeper problem elsewhere.
I have a prototype of a "New And Improved" RTL-level if-conversion, and
it goes through "make check"
without any new regressions [on AMD64 GNU/Linux, Ubuntu 14.04.3 LTS] and
can pass the bootstrap
stage2-to-stage3 comparison [same platform] *_if_* I prevent the
"bootstrap-debug" value for
BUILD_CONFIG from being automatically chosen, e.g. via
configuration. With the default "BUILD_CONFIG=bootstrap-debug", it
fails at the comparison stage.
The stage0/system compiler is plain-vanilla GCC 5.2, compiled by myself
I have spot-checked manually that the file pairs of the
comparison-mismatch object filenames are,
in fact, different for at least one such filename, using the
"--preserve" option of "contrib/compare-debug".
In at least many [if not all] such pairs, the file size is actually
I wonder if "assign_stack_local" from "function.h" automatically Does
The Right Thing with debug information?
Especially, does it cause the debug information, if any, for stack-frame
size to be updated accordingly?
If not, then would switching to "assign_stack_temp" be very likely to
solve the problem?