This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Update source location for PRE inserted stmt
- From: Eric Botcazou <ebotcazou at adacore dot com>
- To: Diego Novillo <dnovillo at google dot com>
- Cc: gcc-patches at gcc dot gnu dot org, Xinliang David Li <davidxl at google dot com>, Richard Biener <richard dot guenther at gmail dot com>, Steven Bosscher <stevenb dot gcc at gmail dot com>, Dehao Chen <dehao at google dot com>
- Date: Thu, 15 Nov 2012 17:46:59 +0100
- Subject: Re: [PATCH] Update source location for PRE inserted stmt
- References: <CAO2gOZWF4=vpgWhX+duS7B5z3dN_cvy7AjkefZ18hi2QsY6SPA@mail.gmail.com> <3351289.lb7ZpLPCld@polaris> <50A4EA0A.5070506@google.com>
> But UNKNOWN_LOCATION is effectively wrong as well. If other
> optimizations move the statements above the inserted instruction, then
> the new instruction ends up inheriting whatever location happens to be
> in the previous statement.
That's correct, UNKNOWN_LOCATION isn't a panacea either, although it can help
in some cases. The only safe thing to do is to put the exact source location
of the statement, i.e. the location of the source construct for which the
statement has been generated.
> Fixing the location when the statement is inserted will reduce this
> randomness. I'm not sure I understand why you think this will break
> coverage. The examples given in this thread were helped by this
> location fixing.
What do you call randomness exactly? GDB jumpiness? I'm a little wary of
fixing GDB jumpiness by distorting the debug info. Ian has clearly outlined
the correct approach to addressing it.
Note that I didn't specifically reply to Dehao's patch here, which might be
acceptable in the end, only to David's seemingly general statement about the
"natural way" of putting a location on these statements.
--
Eric Botcazou