On Mon, Nov 23, 2015 at 8:25 PM, Jason Merrill wrote:
> On 11/23/2015 12:07 PM, Marek Polacek wrote:
>>
>> On Mon, Nov 23, 2015 at 05:57:54PM +0100, Jakub Jelinek wrote:
>>>
>>> On Mon, Nov 23, 2015 at 11:53:40AM -0500, David Malcolm wrote:
Does the following look like
On Tue, 2015-11-24 at 10:40 +0100, Richard Biener wrote:
> On Mon, Nov 23, 2015 at 8:25 PM, Jason Merrill wrote:
> > On 11/23/2015 12:07 PM, Marek Polacek wrote:
> >>
> >> On Mon, Nov 23, 2015 at 05:57:54PM +0100, Jakub Jelinek wrote:
> >>>
> >>> On Mon, Nov 23, 2015 at
On Tue, Nov 24, 2015 at 11:58 AM, David Malcolm wrote:
> On Tue, 2015-11-24 at 10:40 +0100, Richard Biener wrote:
>> On Mon, Nov 23, 2015 at 8:25 PM, Jason Merrill wrote:
>> > On 11/23/2015 12:07 PM, Marek Polacek wrote:
>> >>
>> >> On Mon, Nov 23, 2015 at
On Tue, Nov 24, 2015 at 05:58:30AM -0500, David Malcolm wrote:
> +/* Language-dependent macro for stripping away location wrapper nodes. */
> +
> +#define STRIP_LOCATION_EXPRS(EXP) \
> + while (TREE_CODE (EXP) == LOCATION_EXPR) \
> +(EXP) = TREE_OPERAND ((EXP), 0)
This BTW implies that we
On 11/23/2015 12:07 PM, Marek Polacek wrote:
On Mon, Nov 23, 2015 at 05:57:54PM +0100, Jakub Jelinek wrote:
On Mon, Nov 23, 2015 at 11:53:40AM -0500, David Malcolm wrote:
Does the following look like the kind of thing you had in mind? (just
the tree.def part for now). Presumably usable for
On Sat, Nov 21, 2015 at 9:21 AM, Jakub Jelinek wrote:
> On Sat, Nov 21, 2015 at 02:16:49AM -0500, Jason Merrill wrote:
>> On 11/19/2015 03:46 PM, Jason Merrill wrote:
>> >On 11/15/2015 12:01 AM, David Malcolm wrote:
>> >>As with the C frontend, there's an issue with tree nodes
On Mon, 2015-11-23 at 10:59 +0100, Richard Biener wrote:
> On Sat, Nov 21, 2015 at 9:21 AM, Jakub Jelinek wrote:
> > On Sat, Nov 21, 2015 at 02:16:49AM -0500, Jason Merrill wrote:
> >> On 11/19/2015 03:46 PM, Jason Merrill wrote:
> >> >On 11/15/2015 12:01 AM, David Malcolm
On Mon, Nov 23, 2015 at 11:53:40AM -0500, David Malcolm wrote:
> Does the following look like the kind of thing you had in mind? (just
> the tree.def part for now). Presumably usable for both lvalues and
> rvalues, where the thing it wraps is what's important. It merely exists
> to add an
On Mon, Nov 23, 2015 at 05:57:54PM +0100, Jakub Jelinek wrote:
> On Mon, Nov 23, 2015 at 11:53:40AM -0500, David Malcolm wrote:
> > Does the following look like the kind of thing you had in mind? (just
> > the tree.def part for now). Presumably usable for both lvalues and
> > rvalues, where the
On Sat, Nov 21, 2015 at 02:16:49AM -0500, Jason Merrill wrote:
> On 11/19/2015 03:46 PM, Jason Merrill wrote:
> >On 11/15/2015 12:01 AM, David Malcolm wrote:
> >>As with the C frontend, there's an issue with tree nodes that
> >>don't have locations: VAR_DECL, INTEGER_CST, etc:
> >>
> >> int test
On 11/19/2015 03:46 PM, Jason Merrill wrote:
On 11/15/2015 12:01 AM, David Malcolm wrote:
As with the C frontend, there's an issue with tree nodes that
don't have locations: VAR_DECL, INTEGER_CST, etc:
int test (int foo)
{
return foo * 100;
^^^ ^^^
}
where we'd
On 11/15/2015 12:01 AM, David Malcolm wrote:
As with the C frontend, there's an issue with tree nodes that
don't have locations: VAR_DECL, INTEGER_CST, etc:
int test (int foo)
{
return foo * 100;
^^^ ^^^
}
where we'd like to access the source spelling ranges of the
(v2 of the patch, fixing some issues, and rebasing to be on top of
r230393 i.e. after the merge of delayed-folding).
This patch is analogous to:
"[PATCH 06/10] Track expression ranges in C frontend"
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg02535.html
in that it adds range information to
13 matches
Mail list logo