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, but
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 are in
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
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%
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
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 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
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:
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:
warning_at
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
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:
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
On 05/17/2012 10:33 AM, Gabriel Dos Reis wrote:
On Thu, May 17, 2012 at 2:52 AM, Paolo Carlinipaolo.carl...@oracle.com 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
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 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 plan to make a
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
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
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
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
On 16 May 2012 17:41, Jason Merrill ja...@redhat.com 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
On 16 May 2012 19:06, Gabriel Dos Reis g...@integrable-solutions.net wrote:
On Wed, May 16, 2012 at 11:56 AM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
On 16 May 2012 17:41, Jason Merrill ja...@redhat.com wrote:
On 05/16/2012 06:54 AM, Paolo Carlini wrote:
isn't the diagnostic
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_LOCATION
On 16 May 2012 19:09, Paolo Carlini pcarl...@gmail.com wrote:
Hi
On 16 May 2012 17:41, Jason Merrill ja...@redhat.com 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,
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), code,
On 16 May 2012 19:53, Paolo Carlini pcarl...@gmail.com 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
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
Hi,
On 16 May 2012 19:53, Paolo Carlini pcarl...@gmail.com 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
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.
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
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),
+
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 =
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/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 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
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/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
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
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?
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
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
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 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
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
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.
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,
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 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
47 matches
Mail list logo
