This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Need suggestion about bug 68425
- From: Manuel LÃpez-IbÃÃez <lopezibanez at gmail dot com>
- To: David Malcolm <dmalcolm at redhat dot com>
- Cc: Prasad Ghangal <prasad dot ghangal at gmail dot com>, gcc Mailing List <gcc at gcc dot gnu dot org>, Joseph Myers <joseph at codesourcery dot com>
- Date: Fri, 19 Feb 2016 19:50:37 +0000
- Subject: Re: Need suggestion about bug 68425
- Authentication-results: sourceware.org; auth=none
- References: <CAE+uiWYLZ6ODDc3nR3zgAdxekTtSAD10Ba3pqJ4Y--FJYo5Fig at mail dot gmail dot com> <56C5D529 dot 9080700 at gmail dot com> <1455909237 dot 9333 dot 34 dot camel at redhat dot com>
On 19 February 2016 at 19:13, David Malcolm <dmalcolm@redhat.com> wrote:
>> 68425.c:3:34: warning: excess elements in array initializer (6
>> elements,
>> expected 2)
>> const int array[2] = { 1, 2, 3 ,6 ,89 ,193};
>> ^~~~~~~~~~~~~
>
> Yes, that would be ideal. Unfortunately, not every tree expression
> node has a location stored for it, so implementing the underlined range
> might be tricky to do. (in particular, INTEGER_CST doesn't. I hope to
> look into that for gcc 7, perhaps with a wrapper node to provide
> locations for expr nodes that don't have them).
Do you think that would be better than storing the locations in the
parent expression? That is, instead of adding extra wrapper nodes,
with all those tree nodes wasting space just to provide a location,
add extra location slots to every tree that may have an operand. Or
perhaps you are thinking about adding some lighter wrapper which is
just a loc+tree* or something like that.
In the case above (for C), struct constructor_stack could keep track
of token locations passed by the parser (all tokens have locations,
but those locations are not saved in all trees). In fact, I see that
there is already a lot of location passing in the corresponding code,
but probably all of them refer to input_location or some such.
Cheers,
Manuel.