On 05/23/2012 12:30 PM, Paolo Carlini wrote:
On 05/23/2012 06:30 AM, Jason Merrill wrote:
On 05/22/2012 05:18 PM, Paolo Carlini wrote:
Uhhm, I have an "out of the blue" idea, so please excuse me if for some
"obvious" reason doesn't make sense: don't we have a global variable
saying "where we ar
On 05/23/2012 06:30 AM, Jason Merrill wrote:
On 05/22/2012 05:18 PM, Paolo Carlini wrote:
Uhhm, I have an "out of the blue" idea, so please excuse me if for some
"obvious" reason doesn't make sense: don't we have a global variable
saying "where we are" in the compiler pipeline?
I'm not sure, b
On 05/22/2012 05:18 PM, Paolo Carlini wrote:
Uhhm, I have an "out of the blue" idea, so please excuse me if for some
"obvious" reason doesn't make sense: don't we have a global variable
saying "where we are" in the compiler pipeline?
I'm not sure, but the question led me to thinking about only
Hi again,
On 05/22/2012 06:42 PM, Jason Merrill wrote:
On 05/22/2012 11:55 AM, Paolo Carlini wrote:
FAIL: gcc.dg/opts-1.c (internal compiler error)
FAIL: gcc.dg/opts-1.c -fno-abi-version (test for errors, line )
FAIL: gcc.dg/opts-1.c -fno-lto-compression-level (test for errors,
line )
FAIL: gc
On 05/22/2012 08:03 PM, Mike Stump wrote:
On May 22, 2012, at 8:42 AM, Jason Merrill wrote:
On 05/22/2012 08:22 AM, Paolo Carlini wrote:
Ok, thanks. Today I wanted to concretely test and post a patch but I
noticed this other objc bit in objc-next-runtime-abi-01.c which I don't
know how to handl
On May 22, 2012, at 8:42 AM, Jason Merrill wrote:
> On 05/22/2012 08:22 AM, Paolo Carlini wrote:
>> Ok, thanks. Today I wanted to concretely test and post a patch but I
>> noticed this other objc bit in objc-next-runtime-abi-01.c which I don't
>> know how to handle due to the OPT_Wall gate:
>>
>>
On 05/22/2012 06:42 PM, Jason Merrill wrote:
On 05/22/2012 11:55 AM, Paolo Carlini wrote:
FAIL: gcc.dg/opts-1.c (internal compiler error)
FAIL: gcc.dg/opts-1.c -fno-abi-version (test for errors, line )
FAIL: gcc.dg/opts-1.c -fno-lto-compression-level (test for errors,
line )
FAIL: gcc.dg/opts-1
On 05/22/2012 11:55 AM, Paolo Carlini wrote:
FAIL: gcc.dg/opts-1.c (internal compiler error)
FAIL: gcc.dg/opts-1.c -fno-abi-version (test for errors, line )
FAIL: gcc.dg/opts-1.c -fno-lto-compression-level (test for errors, line )
FAIL: gcc.dg/opts-1.c -fno-tree-parallelize-loops (test for errors
On 05/22/2012 05:49 PM, Paolo Carlini wrote:
On 05/22/2012 05:42 PM, Jason Merrill wrote:
On 05/22/2012 08:22 AM, Paolo Carlini wrote:
Ok, thanks. Today I wanted to concretely test and post a patch but I
noticed this other objc bit in objc-next-runtime-abi-01.c which I don't
know how to handle
On 05/22/2012 05:42 PM, Jason Merrill wrote:
On 05/22/2012 08:22 AM, Paolo Carlini wrote:
Ok, thanks. Today I wanted to concretely test and post a patch but I
noticed this other objc bit in objc-next-runtime-abi-01.c which I don't
know how to handle due to the OPT_Wall gate:
warning_at (UNKNOWN
On 05/22/2012 08:22 AM, Paolo Carlini wrote:
Ok, thanks. Today I wanted to concretely test and post a patch but I
noticed this other objc bit in objc-next-runtime-abi-01.c which I don't
know how to handle due to the OPT_Wall gate:
warning_at (UNKNOWN_LOCATION, OPT_Wall,
"%<-fobjc-sjlj-exceptions
Hi,
On 05/17/2012 10:29 PM, Iain Sandoe wrote:
On 17 May 2012, at 21:16, Mike Stump wrote:
On May 17, 2012, at 12:53 PM, Paolo Carlini wrote:
On 05/17/2012 09:47 PM, Jason Merrill wrote:
On 05/17/2012 05:06 AM, Paolo Carlini wrote:
On 05/17/2012 10:33 AM, Gabriel Dos Reis wrote:
I am stil
On 17 May 2012, at 21:16, Mike Stump wrote:
On May 17, 2012, at 12:53 PM, Paolo Carlini wrote:
On 05/17/2012 09:47 PM, Jason Merrill wrote:
On 05/17/2012 05:06 AM, Paolo Carlini wrote:
On 05/17/2012 10:33 AM, Gabriel Dos Reis wrote:
I am still puzzled by why we need to assert, as opposed to
On May 17, 2012, at 12:53 PM, Paolo Carlini wrote:
> On 05/17/2012 09:47 PM, Jason Merrill wrote:
>> On 05/17/2012 05:06 AM, Paolo Carlini wrote:
>>> On 05/17/2012 10:33 AM, Gabriel Dos Reis wrote:
I am still puzzled by why we need to assert, as opposed to just
ignore, unless we have a pl
On 05/17/2012 09:47 PM, Jason Merrill wrote:
On 05/17/2012 05:06 AM, Paolo Carlini wrote:
On 05/17/2012 10:33 AM, Gabriel Dos Reis wrote:
I am still puzzled by why we need to assert, as opposed to just
ignore, unless we have a plan to make a wholesale move -- but even
there I am bit
nervous.
On 05/17/2012 05:06 AM, Paolo Carlini wrote:
On 05/17/2012 10:33 AM, Gabriel Dos Reis wrote:
I am still puzzled by why we need to assert, as opposed to just
ignore, unless we have a plan to make a wholesale move -- but even there I am
bit
nervous.
Eh, don't ask me ;) Anyway, in terms of testin
On 05/17/2012 10:33 AM, Gabriel Dos Reis wrote:
On Thu, May 17, 2012 at 2:52 AM, Paolo Carlini wrote:
On 05/17/2012 09:48 AM, Paolo Carlini wrote:
Can we concisely characterize those messages and exclude them from the
gcc_assert?
Well, if don't quickly figure out something better, I guess we
On Thu, May 17, 2012 at 2:52 AM, Paolo Carlini wrote:
> On 05/17/2012 09:48 AM, Paolo Carlini wrote:
>>
>> Can we concisely characterize those messages and exclude them from the
>> gcc_assert?
>
> Well, if don't quickly figure out something better, I guess we can always
> add the assert at the beg
On 05/17/2012 09:48 AM, Paolo Carlini wrote:
Can we concisely characterize those messages and exclude them from the
gcc_assert?
Well, if don't quickly figure out something better, I guess we can
always add the assert at the beginning of warning_at, error_at, etc.
Paolo.
On 05/17/2012 05:32 AM, Jason Merrill wrote:
On 05/16/2012 08:34 PM, Paolo Carlini wrote:
Ok. Something like p2 below?
Yes. Since the earlier patch without LOC_OR_HERE passed testing,
let's apply that plus this p2.
Ok, great.
Does Manuel's suggestion of aborting if we get UNKNOWN_LOCATION
On 05/16/2012 08:34 PM, Paolo Carlini wrote:
Ok. Something like p2 below?
Yes. Since the earlier patch without LOC_OR_HERE passed testing, let's
apply that plus this p2.
Does Manuel's suggestion of aborting if we get UNKNOWN_LOCATION for a
diagnostic pass the testsuite?
Jason
Hi,
On 05/16/2012 05:41 PM, Jason Merrill wrote:
On 05/16/2012 06:54 AM, Paolo Carlini wrote:
isn't the diagnostic machinery able to cope with UNKNOWN_LOCATION? By
default should be interpreted as input_location, no?
That would make sense to me; I don't know if it works that way now,
though.
Hi,
> On 16 May 2012 19:53, Paolo Carlini wrote:
>>> -expr = build_new_op (loc, code, LOOKUP_NORMAL, arg1, arg2, NULL_TREE,
>>> +expr = build_new_op (LOC_OR_HERE (loc), code, LOOKUP_NORMAL,
>>> + arg1, arg2, NULL_TREE,
>>> overload, complain);
>>>
>>> This doesn't
On 05/16/2012 01:15 PM, Manuel López-Ibáñez wrote:
My proposal is to assert when checking is enabled (gcc_checking_assert
instead of gcc_assert) and degrade gracefully when not (use
input_location if given an UNKNOWN_LOCATION).
That makes sense if we want to require the front end to move to exp
On 16 May 2012 19:53, Paolo Carlini wrote:
>> - expr = build_new_op (loc, code, LOOKUP_NORMAL, arg1, arg2, NULL_TREE,
>> + expr = build_new_op (LOC_OR_HERE (loc), code, LOOKUP_NORMAL,
>> + arg1, arg2, NULL_TREE,
>> overload, complain);
>>
>> This doesn't seem correct
Hi,
>
> I cannot answer because I don't know what are the defaults. What does
> build_min_nt use by default?
UNKNOWN_LOCATION. I think this answers most of your concerns.
> -expr = build_new_op (loc, code, LOOKUP_NORMAL, arg1, arg2, NULL_TREE,
> +expr = build_new_op (LOC_OR_HERE (loc), c
On 16 May 2012 19:09, Paolo Carlini wrote:
> Hi
>
>> On 16 May 2012 17:41, Jason Merrill wrote:
>>> On 05/16/2012 06:54 AM, Paolo Carlini wrote:
isn't the diagnostic machinery able to cope with UNKNOWN_LOCATION? By
default should be interpreted as input_location, no?
>>>
>>>
>>> Th
Hi again,
> In any case, the general rule should be that input_location (or
> variants using that) should be only used in the parser (who actually
> knows what input_location is pointing at). Other functions should use
> a location coming from somewhere else (an argument or a tree).
> UNKNOWN_LOCA
On 16 May 2012 19:06, Gabriel Dos Reis wrote:
> On Wed, May 16, 2012 at 11:56 AM, Manuel López-Ibáñez
> wrote:
>> On 16 May 2012 17:41, Jason Merrill wrote:
>>> On 05/16/2012 06:54 AM, Paolo Carlini wrote:
isn't the diagnostic machinery able to cope with UNKNOWN_LOCATION? By
defau
Hi
> On 16 May 2012 17:41, Jason Merrill wrote:
>> On 05/16/2012 06:54 AM, Paolo Carlini wrote:
>>>
>>> isn't the diagnostic machinery able to cope with UNKNOWN_LOCATION? By
>>> default should be interpreted as input_location, no?
>>
>>
>> That would make sense to me; I don't know if it works
On Wed, May 16, 2012 at 11:56 AM, Manuel López-Ibáñez
wrote:
> On 16 May 2012 17:41, Jason Merrill wrote:
>> On 05/16/2012 06:54 AM, Paolo Carlini wrote:
>>>
>>> isn't the diagnostic machinery able to cope with UNKNOWN_LOCATION? By
>>> default should be interpreted as input_location, no?
>>
>>
>>
On 16 May 2012 17:41, Jason Merrill wrote:
> On 05/16/2012 06:54 AM, Paolo Carlini wrote:
>>
>> isn't the diagnostic machinery able to cope with UNKNOWN_LOCATION? By
>> default should be interpreted as input_location, no?
>
>
> That would make sense to me; I don't know if it works that way now, th
On 05/16/2012 06:54 AM, Paolo Carlini wrote:
isn't the diagnostic machinery able to cope with UNKNOWN_LOCATION? By
default should be interpreted as input_location, no?
That would make sense to me; I don't know if it works that way now, though.
@@ -11968,7 +11968,8 @@ tsubst_qualified_id (tree
On 05/16/2012 01:25 PM, Paolo Carlini wrote:
Thus at this point in our location work I don't believe we can do much
(in terms of simple obvious changes) for UNKNOWN_LOCATIONs coming from
upstream, besides maybe using the LOC_OR_HERE trick for the immediate
error messages (but maybe isn't really
On 05/16/2012 12:54 PM, Paolo Carlini wrote:
I think I was wrong when I indicated that, and that EXPR_LOCATION is
better there, too. EXPR_LOC_OR_HERE is good for error messages, but
not for setting the location of a tree. Though it occurs to me that
we're likely to use the passed in location
Hi,
On 05/16/2012 06:02 AM, Jason Merrill wrote:
On 05/15/2012 07:56 PM, Paolo Carlini wrote:
But, speaking of incremental work: what if, post the build_min_nt_loc
chunk, we handle build_min_non_dep and build_min in a case by case way?
Thus we keep around the non-_loc variant and gradually repl
On 05/15/2012 07:56 PM, Paolo Carlini wrote:
But, speaking of incremental work: what if, post the build_min_nt_loc
chunk, we handle build_min_non_dep and build_min in a case by case way?
Thus we keep around the non-_loc variant and gradually replace each
call? With testcases (small!) checking col
On 05/16/2012 01:56 AM, Paolo Carlini wrote:
But, speaking of incremental work: what if, post the build_min_nt_loc
chunk, we handle build_min_non_dep and build_min in a case by case
way? Thus we keep around the non-_loc variant and gradually replace
each call? With testcases (small!) checking c
Hi,
On 05/16/2012 01:36 AM, Jason Merrill wrote:
On 05/15/2012 06:44 PM, Paolo Carlini wrote:
I can't change the build_min_non_dep_loc call in build_x_binary_op to
simply use loc, that causes the diagnostic regression I mentioned
before. Sorry, I wasn't clear in my previous message, it happens
On 05/15/2012 06:44 PM, Paolo Carlini wrote:
I can't change the build_min_non_dep_loc call in build_x_binary_op to
simply use loc, that causes the diagnostic regression I mentioned
before. Sorry, I wasn't clear in my previous message, it happens when
one "naturally" just passes loc, not the EXPR_
Hi,
On 05/16/2012 12:11 AM, Jason Merrill wrote:
On 05/15/2012 04:56 PM, Paolo Carlini wrote:
@@ -2753,7 +2754,8 @@ build_x_indirect_ref (location_t loc, tree expr, r
rval = cp_build_indirect_ref (expr, errorstring, complain);
if (processing_template_decl&& rval != error_mark_node)
On 05/15/2012 04:56 PM, Paolo Carlini wrote:
@@ -2753,7 +2754,8 @@ build_x_indirect_ref (location_t loc, tree expr, r
rval = cp_build_indirect_ref (expr, errorstring, complain);
if (processing_template_decl&& rval != error_mark_node)
-return build_min_non_dep (INDIRECT_REF, rval,
Hi,
On 05/15/2012 08:53 PM, Jason Merrill wrote:
On 05/14/2012 07:17 PM, Paolo Carlini wrote:
@@ -5670,7 +5672,8 @@ build_x_compound_expr_from_list (tree list, expr_l
return error_mark_node;
for (list = TREE_CHAIN (list); list; list = TREE_CHAIN (list))
-expr = build_x_compou
On 05/14/2012 07:17 PM, Paolo Carlini wrote:
@@ -5670,7 +5672,8 @@ build_x_compound_expr_from_list (tree list, expr_l
return error_mark_node;
for (list = TREE_CHAIN (list); list; list = TREE_CHAIN (list))
- expr = build_x_compound_expr (expr, TREE_VALUE (list),
+ expr
Hi,
On 05/14/2012 07:38 PM, Jason Merrill wrote:
On 05/14/2012 12:53 PM, Paolo Carlini wrote:
Yeah. I'm trying to replace *all* the current ones with the _loc
variant. The patch as you can imagine is becoming *huge*. Some details
will probably need another pass.
One approach would be to make
On 05/14/2012 07:38 PM, Jason Merrill wrote:
On 05/14/2012 12:53 PM, Paolo Carlini wrote:
Yeah. I'm trying to replace *all* the current ones with the _loc
variant. The patch as you can imagine is becoming *huge*. Some details
will probably need another pass.
One approach would be to make the non
On 05/14/2012 12:53 PM, Paolo Carlini wrote:
Yeah. I'm trying to replace *all* the current ones with the _loc
variant. The patch as you can imagine is becoming *huge*. Some details
will probably need another pass.
One approach would be to make the non-_loc names macros that just call
the _loc
On 05/14/2012 06:24 PM, Jason Merrill wrote:
On 05/14/2012 09:22 AM, Paolo Carlini wrote:
In terms of implementation details: the new _loc variant (I'm also
finding useful a build_min_loc and a build_min_non_dep_loc, by the way)
seems identical to the non-_loc variant besides calling
SET_EXPR_LO
On 05/14/2012 09:22 AM, Paolo Carlini wrote:
In terms of implementation details: the new _loc variant (I'm also
finding useful a build_min_loc and a build_min_non_dep_loc, by the way)
seems identical to the non-_loc variant besides calling
SET_EXPR_LOCATION, thus I'm thinking: would it make sense
Hi,
On 05/14/2012 05:58 AM, Jason Merrill wrote:
On 05/13/2012 11:24 PM, Paolo Carlini wrote:
tree r = build_x_modify_expr
- (RECUR (TREE_OPERAND (t, 0)),
+ (input_location,
And EXPR_LOC_OR_HERE (t).
Here I think EXPR_LOC_OR_HERE (TREE_OPERAND (t, 1)) is better.
Why? TREE_O
On 05/13/2012 11:24 PM, Paolo Carlini wrote:
tree r = build_x_modify_expr
- (RECUR (TREE_OPERAND (t, 0)),
+ (input_location,
And EXPR_LOC_OR_HERE (t).
Here I think EXPR_LOC_OR_HERE (TREE_OPERAND (t, 1)) is better.
Why? TREE_OPERAND (t,1) is a dummy tree that we only use for i
Hi,
On 05/14/2012 03:50 AM, Jason Merrill wrote:
On 05/13/2012 07:25 PM, Paolo Carlini wrote:
You're adding a lot of uses of input_location; I think we can do better.
if (TREE_CODE (incr) == MODIFY_EXPR)
-incr = build_x_modify_expr (RECUR (TREE_OPERAND (incr, 0)),
NOP_EXPR,
+
On 05/13/2012 07:25 PM, Paolo Carlini wrote:
You're adding a lot of uses of input_location; I think we can do better.
if (TREE_CODE (incr) == MODIFY_EXPR)
- incr = build_x_modify_expr (RECUR (TREE_OPERAND (incr, 0)), NOP_EXPR,
+ incr = build_x_modify_expr (input_location,
Hi,
this fixes the remaining bit of 44516 - the wrong location, thus caret
position - in the obvious way, that is by passing from
cp_parser_assignment_expression the right one to build_x_modify_expr via
an additional location_t parameter. The latter can simply forward it to
build_new_op.
Te
54 matches
Mail list logo
