This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 07/22] Implement token range tracking within libcpp and C/C++ FEs
- From: Manuel LÃpez-IbÃÃez <lopezibanez at gmail dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: Jakub Jelinek <jakub at redhat dot com>, David Malcolm <dmalcolm at redhat dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 15 Sep 2015 14:54:06 +0200
- Subject: Re: [PATCH 07/22] Implement token range tracking within libcpp and C/C++ FEs
- Authentication-results: sourceware.org; auth=none
- References: <1441916913-11547-1-git-send-email-dmalcolm at redhat dot com> <1441916913-11547-8-git-send-email-dmalcolm at redhat dot com> <CAFiYyc1_i55DkKTwxr5VF3gyEf89bAcMkA6h-kK_DLXo5DUePQ at mail dot gmail dot com> <20150915102045 dot GB1847 at tucnak dot redhat dot com> <55F80A57 dot 20104 at gmail dot com> <CAFiYyc3ZKHSD-ZRtCYSfVoyNed-SUBVcvRnrJOTaKb9Q05-Aiw at mail dot gmail dot com>
On 15 September 2015 at 14:18, Richard Biener
<richard.guenther@gmail.com> wrote:
> Of course this boils down to "uses" of a VAR_DECL using the shared tree
> node. On GIMPLE some stmt kinds have separate locations for each operand
> (PHI nodes), on GENERIC we'd have to invent a no-op expr tree code to
> wrap such uses to be able to give them distinct locations (can't use sth
> existing as frontends would need to ignore them in a different way than say
> NOP_EXPRs or NON_LVALUE_EXPRs).
>
The problem with that approach (besides the waste of memory implied by
a whole tree node just to store one location_t) is keeping those
wrappers in place while making them transparent for most of the
compiler. According to Arnaud, folding made this approach infeasible:
https://gcc.gnu.org/ml/gcc-patches/2012-09/msg01222.html
The other two alternatives are to store the location of the operands
on the expressions themselves or to store them as on-the-side
data-structure, but they come with their own drawbacks. I was
initially more in favour of the wrapper solution, but after dealing
with NOP_EXPRs, having to deal also with LOC_EXPR would be a nightmare
(as you say, they will have to be ignored in a different way). The
other alternatives seem less invasive and the problems mentioned here
https://gcc.gnu.org/ml/gcc-patches/2012-11/msg00164.html do not seem
as serious as I thought (passing down the location of the operand is
becoming the norm anyway).
Cheers,
Manuel.