On 06/05/2012 12:14 AM, Mike Stump wrote:
On Jun 4, 2012, at 7:46 PM, Mike Stump wrote:
g++.dg/other/warning1.C -std=c++11 (test for warnings, line 10)
g++.dg/other/warning1.C -std=c++11 (test for warnings, line 11)
g++.dg/other/warning1.C -std=c++11 (test for excess errors)
g++.dg/other/warni
On Jun 4, 2012, at 7:46 PM, Mike Stump wrote:
> g++.dg/other/warning1.C -std=c++11 (test for warnings, line 10)
> g++.dg/other/warning1.C -std=c++11 (test for warnings, line 11)
> g++.dg/other/warning1.C -std=c++11 (test for excess errors)
> g++.dg/other/warning1.C -std=c++98 (test for warnings,
On Jun 4, 2012, at 2:34 PM, Jason Merrill wrote:
> On 06/04/2012 05:27 PM, Mike Stump wrote:
>> That one is, the problem is the work that added error: and warning:
>> processing differentiation puts together a new expression with concatenation
>> and it is that use that _also_ needs protecting.
>
On 06/04/2012 05:27 PM, Mike Stump wrote:
That one is, the problem is the work that added error: and warning: processing
differentiation puts together a new expression with concatenation and it is
that use that _also_ needs protecting.
Aha! Sneaky gcc-dg.exp.
- set expmsg [lindex $ne
On Jun 4, 2012, at 12:30 PM, Jason Merrill wrote:
> On 06/04/2012 02:54 PM, Mike Stump wrote:
>> Yup, that is truly weird. The problem is that the | operator is binding
>> funny because there are no () around the substituted variables in the
>> matching expressions in the .exp files, and the mes
On 06/04/2012 02:54 PM, Mike Stump wrote:
Yup, that is truly weird. The problem is that the | operator is binding funny
because there are no () around the substituted variables in the matching
expressions in the .exp files, and the messages for a single line get the
opportunity to match and e
On Jun 4, 2012, at 5:36 AM, Dodji Seketeli wrote:
>>> - s = s; // { dg-message "synthesized|deleted" }
>>> + s = s;
>>
>> Why do we lose this error?
>
> Good question.
>
> This is the result of a weird behaviour of DejaGNU, I think.
Yup, that is truly weird. The problem is that the | operato
OK.
Jason
Jason Merrill writes:
> On 06/04/2012 08:36 AM, Dodji Seketeli wrote:
>> - /* Build the assignment expression. */
>> + /* Build the assignment expression. Its default
>> + location is the location of the '=' token. */
>> + input_location = loc;
>>
On 06/04/2012 08:36 AM, Dodji Seketeli wrote:
- /* Build the assignment expression. */
+ /* Build the assignment expression. Its default
+location is the location of the '=' token. */
+ input_location = loc;
expr = build_x_modif
> > - s = s; // { dg-message "synthesized|deleted" }
> > + s = s;
>
> Why do we lose this error?
Good question.
This is the result of a weird behaviour of DejaGNU, I think.
For the record, here is the whole test:
1 // { dg-do compile }
2 // Origin: Mark Mitchell
3
4
On 06/03/2012 06:04 PM, Paolo Carlini wrote:
if I apply to
below, thus passing an actual loc to build_min_non_dep_loc, there is a
diagnostic regression for the locations of
libstdc++-v3/testsuite/20_util/bind_ref_neg.cc. If you see something
obviously wrong somewhere, just let me know...
Nope,
On 06/03/2012 05:27 AM, Jason Merrill wrote:
On 06/02/2012 12:40 PM, Paolo Carlini wrote:
That said, the tricks we are playing with the global input_location
vs the loc we are passing around still confuse me quite a lot.
Actually any *assignment* to input_location makes me a bit more
nervous t
On 06/02/2012 12:40 PM, Paolo Carlini wrote:
That said, the tricks we are playing with the global input_location vs the loc
we are passing around still confuse me quite a lot. Actually any *assignment*
to input_location makes me a bit more nervous than I was already ;) Do you have
any idea whe
Hi,
> - /* Build the assignment expression. */
> + /* Build the assignment expression. Its default
> + location is the location of the '=' token. */
> + input_location = loc;
> expr = build_x_modify_expr (loc, expr,
> assignment_o
For built-in macros, the patch is now stepping up until it sees a
location that is not for a built-in macro, and at point, checks if we
are in a system header.
It also uses the location of the '=' operator as the location for
assignment expressions. I had to adjust a couple of tests due to that c
[PATCH 2/2] Better system header location detection for built-
> in macro tokens
>
> Hello,
>
> The location for a built-in macro token is BUILTIN_LOCATION. When we
> see that location value, we cannot know if that token was used in a
> system header or not. And that can trigg
> From: Dodji Seketeli
> Date: Mon, 21 May 2012 15:55:19 +0200
> The location for a built-in macro token is BUILTIN_LOCATION. When we
> see that location value, we cannot know if that token was used in a
> system header or not. And that can trigger some unwanted warnings on
> e.g, the use of __
On 05/23/2012 04:52 AM, Dodji Seketeli wrote:
I tried to do what the C FE seems to do, which is to consider that the
default location (the global input_location variable) is on the LHS of
the assignment (on the usi variable), rather than on the token that
comes from DEC32_MAX.
That makes sense.
Jason Merrill writes:
> What if the built-in macro appears in a macro defined in a system
> header but used in user code? This would resolve the location all the
> way to the user code, and warn. I think we only want to step out
> until we reach a non-built-in macro, not all the way to the oute
What if the built-in macro appears in a macro defined in a system header
but used in user code? This would resolve the location all the way to
the user code, and warn. I think we only want to step out until we
reach a non-built-in macro, not all the way to the outermost expansion
point.
Jas
Hello,
The location for a built-in macro token is BUILTIN_LOCATION. When we
see that location value, we cannot know if that token was used in a
system header or not. And that can trigger some unwanted warnings on
e.g, the use of __LONG_LONG_MAX__ built-in macro in system headers
when we compile
22 matches
Mail list logo
