Hi,
in this apparently simple regression we end up producing garbled
diagnostic because dump_expr (called via verify_constant) doesn't handle
RESULT_DECL. I think it makes sense to add the tree code together with
all the other *_DECL. Tested x86_64-linux.
Thanks, Paolo.
... the patch ;)
Paolo.
Fix "PR c++/94034 Broken diagnostic: 'result_decl' not supported by dump_expr"
A rather simple diagnostic issue where we failed to handle RESULT_DECL in
dump_expr.
Tested x86_64-linux.
/cp
PR c++/94034
* error.c (dump_expr): Handle RESULT_DECL like
Hi,
On 29/01/20 19:00, Jason Merrill wrote:
On 1/29/20 4:31 AM, Paolo Carlini wrote:
Hi,
in this regression we issue a diagnostic about an incomplete type
(only a warning by default) and then we crash when we try to query
has_attribute on a member of the type because in such cases the
Hi,
in this regression we issue a diagnostic about an incomplete type (only
a warning by default) and then we crash when we try to query
has_attribute on a member of the type because in such cases the member
remains an IDENTIFIER_NODE which of course doesn't have a TREE_TYPE
neither a DECL_AT
Hi,
On 22/01/20 22:32, Jason Merrill wrote:
On 1/22/20 3:31 PM, Paolo Carlini wrote:
Hi,
On 22/01/20 17:27, Jason Merrill wrote:
On 1/22/20 10:22 AM, Paolo Carlini wrote:
Hi,
in this simple issue we either wrongly talked about variable
template-id in c++17 mode or ICEd in c++2a. I think
Hi,
On 22/01/20 17:27, Jason Merrill wrote:
On 1/22/20 10:22 AM, Paolo Carlini wrote:
Hi,
in this simple issue we either wrongly talked about variable
template-id in c++17 mode or ICEd in c++2a. I think we simply want to
handle concept-ids first, both as represented in c++17 mode and as
Hi,
in this simple issue we either wrongly talked about variable template-id
in c++17 mode or ICEd in c++2a. I think we simply want to handle
concept-ids first, both as represented in c++17 mode and as represented
in c++2a mode. Tested x86_64-linux.
Thanks, Paolo.
///
F
Hi,
On 06/01/20 21:47, Jason Merrill wrote:
On 1/2/20 4:23 AM, Paolo Carlini wrote:
@@ -19320,8 +19320,8 @@ tsubst_copy_and_build (tree t,
tree op1 = tsubst (TREE_OPERAND (t, 1), args, complain,
in_decl);
tree op2 = RECUR (TREE_OPERAND (t, 2));
- ret = build_new
, I'd rather work on that at
a later time. Tested x86_64-linux.
Thanks, Paolo.
///
/gcc/cp
2020-01-02 Paolo Carlini
* init.c (build_new): Add location_t parameter and use it throughout.
(build_raw_new_expr): Likewise.
Paolo Carlini
* decl2.c (delete_sanity): Add location_t parameter and use
it throughout.
* init.c (build_vec_delete_1): Likewise.
(build_delete): Likewise.
(build_vec_delete): Likewise.
(perform_target_ctor): Adjust call.
(perform_member_init
few other minor changes, like two additional uses of
DECL_SOURCE_LOCATION, cp_expr_loc_or_input_loc, removal of an unused
function.
Tested x86_64-linux.
Thanks, Paolo.
//
/gcc/cp
2019-12-16 Paolo Carlini
* typeck.c (cxx_sizeof_or_alignof_type): Add
Hi,
On 08/12/19 18:51, Jason Merrill wrote:
Hmm, is the change to cp_expr really necessary vs. using
protected_set_expr_location?
Yes, using protected_set_expr_location works fine in this case, I
suppose because we are dealing with expressions anyway plus the cp_expr
constructor from a tree
Hi,
On 06/12/19 18:53, Jason Merrill wrote:
On 12/6/19 11:14 AM, Paolo Carlini wrote:
Hi,
as promised, the below takes care of the various remaining casts.
It's mostly mechanical, follows the same approach used for
build_functional_cast. Tested x86_64-linux.
It occurs to me that
Hi,
as promised, the below takes care of the various remaining casts. It's
mostly mechanical, follows the same approach used for
build_functional_cast. Tested x86_64-linux.
Thanks, Paolo.
gcc/cp
2019-12-06 Paolo Carlini
* typ
.
///
/gcc/cp
2019-12-04 Paolo Carlini
* typeck2.c (build_functional_cast): Add location_t parameter
and use it.
* cp-tree.h: Update declaration.
* parser.c (cp_parser_functional_cast): Adjust call.
* call.c (build_op_delete_call
Hi,
On 02/12/19 19:58, Jason Merrill wrote:
On 11/29/19 8:08 AM, Paolo Carlini wrote:
Hi,
a few more rather straightforward uses for cp_expr_loc_or_input_loc.
Additionally, while working on the latter, I noticed that, compared
to say, gcc-7, lately the code we have in cp_build_addr_expr_1
n the
argument is wrapped in a location_wrapper. The below fixes that by using
tree_strip_any_location_wrapper in the DECL_MAIN_P check, which works
fine, but I can imagine various other ways to solve the issue... Tested
x86_64-linux.
Thanks, Paolo.
//
/cp
2019-11-29
Hi,
a bunch of straightforward tweaks: let's use the available location in
some additional places. Tested x86_64-linux, as usual.
Thanks, Paolo.
///
/cp
2019-11-15 Paolo Carlini
* typeck.c (cp_build_unary_op): Consistently use the accurate
locati
ht to be" which is mostly about the type of 'rhs'. All the
other messages in one way or the other talk about both sides (the
primary clang caret appears to agree).
Tested x86_64-linux.
Thanks, Paolo.
//////
/gcc
2019-11-20 Paolo Carlini
*
t message. The amended behavior is also
consistent with EDG and CLANG.
Tested x86_64-linux, as usual.
Thanks, Paolo.
//////
/gcc
2019-11-20 Paolo Carlini
* typeck2.c (build_x_arrow): Early return if decay_conversion
returns error_mark_node.
/testsuite
201
Paolo.
///
/cp
2019-11-18 Paolo Carlini
* cvt.c (ocp_convert): Use additional warning sentinel.
/testsuite
2019-11-18 Paolo Carlini
* g++.dg/warn/multiple-sign-compare-warn-1.C: New.
Index: cp/
Hi again,
On 14/11/19 12:09, Paolo Carlini wrote:
Hi,
tested x86_64-linux.
Instead of sending a separate patch, the below has two additional uses.
Tested as usual.
Thanks, Paolo.
///
/cp
2019-11-14 Paolo Carlini
* typeck.c (cp_build_addr_expr_1): Use
Hi,
tested x86_64-linux.
Thanks, Paolo.
///
/cp
2019-11-14 Paolo Carlini
* typeck.c (cp_build_addr_expr_1): Use cp_expr_loc_or_input_loc
in three places.
(lvalue_or_else): Use it in one place.
/testsuite
2019-11-14 Paolo Carlini
* g
st_flags_t parameter to the latter and
everything looks finally good for these testcases.
Tested x86_64-linux.
Thanks, Paolo.
/cp
2019-11-12 Paolo Carlini
* typeck.c (cp_truthvalue_conversion): Add tsubst_flags_t parameter
and use it in calls; als
Hi again,
On 31/10/19 16:56, Paolo Carlini wrote:
Hi,
yesterday I noticed that we want to forward the location parameter of
cp_build_binary_op to composite_pointer_type and then
composite_pointer_error. Note, for the time being at least, this is
always for CPO_COMPARISON, the other two
x.
Thanks, Paolo.
/cp
2019-10-31 Paolo Carlini
* typeck.c (composite_pointer_type): Add a const op_location_t&
parameter and use it in diagnostics.
(composite_pointer_error): Likewise.
(composite_pointer_type_r): Add a const
Hi,
some additional straightforward bits in typeck.c, which I noticed when I
went through the cp_build_binary_op callers. Tested x86_64-linux.
Thanks, Paolo.
//
/cp
2019-10-24 Paolo Carlini
* typeck.c (cp_build_modify_expr): Prefer error + inform to
Paolo Carlini
* typeck.c (build_x_unary_op): Use the location_t argument in
three error_at.
/testsuite
2019-10-22 Paolo Carlini
* g++.dg/other/ptrmem8.C: Test locations too.
* g++.dg/template/dtor6.C: Likewise.
Index: cp/typ
ates', whereas
during error recovery we remain so to speak completely empty handed.
Thus, what about not clearing anything? That seems to work at least for
the two testcases below and doesn't cause regressions.
Thanks, Paolo.
/
/cp
2019-10-18 Paolo Car
.. hi again.
We have an issue with this idea which I didn't notice earlier today:
there are some libstdc++ *_neg testcases which rely on permerrors being
emitted for code in library headers. For example
20_util/ratio/cons/cons_overflow_neg.cc relies on a permerror for the
"overflow in constan
Hi,
On 17/10/19 05:15, Jason Merrill wrote:
On 10/16/19 11:59 AM, Paolo Carlini wrote:
... the below, slightly extended patch: 1- Makes sure the
in_system_header_at calls surviving in decl.c get the same location
used for the corresponding diagnostic
Hmm, we probably want to change permerror
.
/
/cp
2019-10-16 Paolo Carlini
* decl.c (grokfndecl): Remove redundant use of in_system_header_at.
(compute_array_index_type_loc): Likewise.
(grokdeclarator): Likewise.
* error.c (cp_printer): Likewise.
* lambda.c (add_default_capture
Hi,
On 12/10/19 00:28, Jakub Jelinek wrote:
@@ -10036,8 +10035,6 @@ compute_array_index_type_loc (location_t name_loc,
indicated by the state of complain), so that
another substitution can be found. */
return error_mark_node;
- else if (in_syste
.
///
2019-10-11 Paolo Carlini
* decl.c (grokfndecl): Remove redundant use of in_system_header_at.
(compute_array_index_type_loc): Likewise.
(grokdeclarator): Likewise.
* error.c (cp_printer): Likewise.
* lambda.c (add_default_capture
Hi,
On 11/10/19 18:25, Jason Merrill wrote:
On 10/10/19 2:33 PM, Paolo Carlini wrote:
Hi,
On 10/10/19 19:57, Jason Merrill wrote:
On 10/10/19 1:53 PM, Jakub Jelinek wrote:
On Thu, Oct 10, 2019 at 06:12:02PM +0200, Paolo Carlini wrote:
while working on cp_build_binary_op I noticed that the
Hi,
On 11/10/19 17:52, Jakub Jelinek wrote:
On Fri, Oct 11, 2019 at 05:34:16PM +0200, Paolo Carlini wrote:
Hi again...
On 11/10/19 17:30, Paolo Carlini wrote:
Oh nice, I wasn't aware of that, to be honest, probably we should audit
the front-end for more such redundant uses.
... and
Hi again...
On 11/10/19 17:30, Paolo Carlini wrote:
Oh nice, I wasn't aware of that, to be honest, probably we should
audit the front-end for more such redundant uses.
... and I can confirm that we have *many*. If we agree that removing all
of them is the way to go I can do that in a f
Hi,
On 11/10/19 17:23, Marek Polacek wrote:
I mean the latter; pedwarn will check for diagnostic_report_warnings_p so
the pedwarn will not trigger in a system header unless -Wsystem-headers
even without that check.
Oh nice, I wasn't aware of that, to be honest, probably we should audit
the fr
Hi,
On 11/10/19 15:37, Marek Polacek wrote:
Index: cp/decl.c
===
--- cp/decl.c (revision 276845)
+++ cp/decl.c (working copy)
@@ -4992,7 +4992,8 @@ check_tag_decl (cp_decl_specifier_seq *declspecs,
if (TREE_CODE (de
Hi,
another straightforward DECL_SOURCE_LOCATION (TYPE_MAIN_DECL consistent
with the one I used in build_anon_union_vars. Tested x86_64-linux.
Thanks, Paolo.
/
/cp
2019-10-11 Paolo Carlini
* decl.c (check_tag_decl): Use DECL_SOURCE_LOCATION.
/testsuite
2019
Hi,
On 10/10/19 19:57, Jason Merrill wrote:
On 10/10/19 1:53 PM, Jakub Jelinek wrote:
On Thu, Oct 10, 2019 at 06:12:02PM +0200, Paolo Carlini wrote:
while working on cp_build_binary_op I noticed that the testsuite wasn't
exercising the warnings in case RROTATE_EXPR / LROTATE_EXPR, even
I'm coming
to the conclusion that the C++ front-end bits too are now obsolete and
may be removed, because only the middle-end generates those codes in
order to implement optimizations. Anything I'm missing? Any additional
testing? Tested x86_64-linux.
Thanks, Paolo.
//
Paolo.
///
/cp
2019-10-09 Paolo Carlini
* decl.c (grok_ctor_properties): Use DECL_SOURCE_LOCATION.
* typeck.c (cp_build_binary_op): Use the op_location_t argument
in many error messages.
/testsuite
2019-10-09 Paolo Carlini
* c-c++-c
Hi,
the below fixes those two functions consistently with
cp_parser_new_expression. Additionally, a few rather straightforward
tweaks along the usual lines, more DECL_SOURCE_LOCATION and id_loc.
Tested x86_64-linux.
Thanks, Paolo.
/
/cp
2019-10-07 Paolo Carlini
Hi,
On 30/09/19 20:46, Jason Merrill wrote:
On Mon, Sep 30, 2019 at 6:54 AM Paolo Carlini wrote:
On 28/09/19 04:05, Jason Merrill wrote:
On 9/26/19 3:39 PM, Paolo Carlini wrote:
+template void foo( // { dg-error "15:template-id .foo.
used as a declarator" }
That's a str
Hi,
a few more in init.c and name-lookup.c, respectively. Tested
x86_64-linux, as usual.
Thanks, Paolo.
///
/cp
2019-09-30 Paolo Carlini
* init.c (build_new): Use cp_expr_loc_or_input_loc in two places.
* name-lookup.c (do_pushdecl): Use
Hi,
On 28/09/19 04:05, Jason Merrill wrote:
On 9/26/19 3:39 PM, Paolo Carlini wrote:
+template void foo( // { dg-error "15:template-id .foo.
used as a declarator" }
That's a strange diagnostic message; there's nothing wrong with using
a template-id as a declarator. Why
/cp
2019-09-26 Paolo Carlini
* decl.c (grokdeclarator): Immediately return error_mark_node
upon error about template-id used as a declarator.
/testsuite
2019-09-26 Paolo Carlini
* g++.dg/diagnostic/template-id-as-declarator-1.C: New.
Index: testsuite/g++.dg/diagnostic
Hi,
Marek's recent fix prompted an audit of name-lookup.c and I found a few
additional straightforward places where we should use a more accurate
location. Tested x86_64-linux.
Thanks, Paolo.
///
/cp
2019-09-24 Paolo Carlini
* name-loo
only for the c++17 errors, there are additional errors on the same
line, a few redundant ones, etc).
Tested x86_64-linux, as usual.
Thanks, Paolo.
/cp
2019-09-23 Paolo Carlini
* pt.c (check_explicit_specialization): Use cp_expr_loc_or_input_loc
Hi,
On 15/09/19 16:22, Jason Merrill wrote:
On 9/12/19 9:41 AM, Paolo Carlini wrote:
+ if (!valid_array_size_p (dname
+ ? declarator->id_loc : input_location,
Use the id_loc local variable?
This diagnostic is inside the loop over declarator->declarator.
Even
Hi,
nothing special here, various bits I missed so far or in the past meant
to test more thoroughly.
Thanks, Paolo.
//
/cp
2019-09-12 Paolo Carlini
* decl.c (grokdeclarator): Use declspecs->locations and
declarator->id_loc in a few error me
Hi again,
On 12/09/19 11:03, Paolo Carlini wrote:
Hi,
On 11/09/19 23:15, Marek Polacek wrote:
--- gcc/cp/pt.c
+++ gcc/cp/pt.c
@@ -26709,7 +26709,7 @@ build_non_dependent_expr (tree expr)
if (TREE_CODE (expr) == COND_EXPR)
return build3 (COND_EXPR,
TREE_TYPE (expr
Hi,
On 11/09/19 23:15, Marek Polacek wrote:
--- gcc/cp/pt.c
+++ gcc/cp/pt.c
@@ -26709,7 +26709,7 @@ build_non_dependent_expr (tree expr)
if (TREE_CODE (expr) == COND_EXPR)
return build3 (COND_EXPR,
TREE_TYPE (expr),
- TREE_OPERAND (expr, 0),
+
Hi,
On 02/09/19 16:28, Paolo Carlini wrote:
Hi,
all should be more or less straightforward. I also propose to use an
additional range for that error message about constinit && constexpr
mentioned to Marek a few days ago. Tested x86_64-linux.
I'm gently piniging this very earl
Hi,
all should be more or less straightforward. I also propose to use an
additional range for that error message about constinit && constexpr
mentioned to Marek a few days ago. Tested x86_64-linux.
Thanks, Paolo.
/
/cp
2019-09-02 Paolo Carlini
Hi,
On 14/08/19 23:22, Marek Polacek wrote:
+ /* [dcl.spec]/2 "At most one of the constexpr, consteval, and constinit
+ keywords shall appear in a decl-specifier-seq." */
+ if (constinit_p && constexpr_p)
+{
+ error_at (min_location (declspecs->locations[ds_constinit],
+
entities are involved, see for example all the 'if (name)' in
grokdeclarator and elsewhere: input_location is very rarely the best
location).
Testex x86_64-linux.
Thanks, Paolo.
/
/cp
2019-08-27 Paolo Carlini
* decl.c (check_var_
/cp
2019-08-23 Paolo Carlini
* semantics.c (finish_switch_cond): Improve error message location.
/testsuite
2019-08-23 Paolo Carlini
* g++.dg/conversion/simd4.C: Test all the locations.
Index: cp/semantics.c
Hi,
for this error message about the types involved in array subscripting I
think we can exploit the available location argument and point to the
open square bracket instead of simply using input_location. Tested
x86_64-linux.
Thanks, Paolo Carlini.
/cp
2019-08-13
Hi,
On 08/08/19 16:51, Jason Merrill wrote:
On 8/6/19 8:28 AM, Paolo Carlini wrote:
apparently this is now easy to do, likely because a while ago I made
sure that we consistently have meaningful locations for TYPE_DECLs too.
(I went through grokdeclarator and confirmed that when the third
nge
%qD to %qE because we are dealing with BIT_NOT_EXPRs.
Thanks, Paolo.
///
/cp
2019-08-08 Paolo Carlini
* decl.c (grokdeclarator): Use id_loc and EXPR_LOCATION in
a few error messages.
/testsuite
2019-08-08 Paolo Carlini
* g++.dg/cpp0x/enum20.C:
Hi,
On 31/07/19 21:26, Marek Polacek wrote:
+static void
+modifying_const_object_error (tree expr, tree obj)
+{
+ location_t loc = cp_expr_loc_or_loc (expr, input_location);
Nit: now we have cp_expr_loc_input_loc
Paolo.
-linux.
Thanks, Paolo.
/cp
2019-08-06 Paolo Carlini
* decl.c (start_function): Use DECL_SOURCE_LOCATION.
(grokmethod): Likewise.
/testsuite
2019-08-06 Paolo Carlini
* g++.dg/parse/typedef9.C: Test locations too.
Index: cp/decl.c
Hi,
just spotted an additional error which can benefit from
cp_expr_loc_or_input_loc. Tested x86_64-linux.
Thanks, Paolo.
/cp
2019-08-05 Paolo Carlini
* decl.c (check_array_designated_initializer): Use
cp_expr_loc_or_input_loc in one place
Hi,
On 31/07/19 21:39, David Malcolm wrote:
[snip]
I don't care for "cp_expr_loc_or_loc".
By "_or_here" do you mean "or input_location"?
Calling it "cp_expr_loc_or_input_location" would spell out what it
does, but would be rather long.
Thanks for your feedback. At this point I don't feel ve
warning when it encounters the [[nodiscard]] itself. Avoiding the latter
seems easy to me - the below passes testing. Something else?
Thanks, Paolo.
///
/cp
2019-08-01 Paolo Carlini
* tree.c (handle_nodiscard_attribute): Do not warn about nodiscard
applied to a
ested
x86_64-linux.
By the way, shall we add to cp-tree.h, at least temporarily, a:
inline location_t
cp_expr_loc_or_loc (const_tree t)
{
return cp_expr_loc_or_loc (t, input_location);
}
overload? We could use it in a ton of places.
Thanks, Paolo.
//
/cp
2019-0
Hi,
On 08/07/19 23:44, Jason Merrill wrote:
On 6/23/19 7:58 AM, Paolo Carlini wrote:
+ error_at (smallest_type_location (get_type_quals (declspecs),
+ declspecs->locations),
How about adding a smallest_type_location overload that just takes
declspecs?
Sure. The be
Hi,
On 23/06/19 13:58, Paolo Carlini wrote:
Hi,
here there are a couple of rather straightforward improvements in the
second half of grokdeclarator plus a check_tag_decl change consistent
with the other existing case of multiple_types_p diagnostic. Tested
x86_64-linux.
Gently pinging this
Hi,
On 27/06/19 23:19, Jason Merrill wrote:
Ah, thanks. Then perhaps we want to change the CLASSTYPE_FINAL in
build_over_call to resolves_to_fixed_type_p (arg), to also handle the
other reasons we might know the dynamic type of the argument, and
remove the related code from build_new_method_c
Hi,
On 23/06/19 19:45, Jason Merrill wrote:
On 6/23/19 7:53 AM, Paolo Carlini wrote:
... hi again ;)
The other day I was having a look at using declarations for this
issue and noticed that only a few lines below the de-virtualization
check we have to handle functions found by a using
about flexible
array member in union; use get_type_quals.
/testsuite
2019-06-23 Paolo Carlini
* g++.dg/diagnostic/static-cdtor-1.C: New.
* g++.dg/cpp1z/has-unique-obj-representations2.C: Test location
too.
* g++.dg/other/anon-union3.C: Adjust expected
... hi again ;)
The other day I was having a look at using declarations for this issue
and noticed that only a few lines below the de-virtualization check we
have to handle functions found by a using declaration, for various
reasons. In particular, we know whether we found a function fn where
... so, now that I see the issue more clearly, I'm adding to the
testsuite the below too.
Thanks, Paolo.
Index: final7.C
===
--- final7.C(nonexistent)
+++ final7.C(working copy)
@@ -0,0 +1,11 @@
+
and...
By the way, if S1:.f is not pure virtual, just a virtual declaration -
all the rest being the same - the code doesn't link: undefined
references to vtable and typeinfo for S1. The same happens with
current clang and icc. I don't know if this detail helps us in the
short term
... t
Hi,
On 21/06/19 21:27, Paolo Carlini wrote:
Hi,
On 21/06/19 20:50, Jason Merrill wrote:
On 6/20/19 12:24 AM, Paolo Carlini wrote:
Hi,
this bug notices that the more aggressive de-virtualization check
that we have now in place (fixed c++/67184) doesn't work correctly
for the
Hi,
On 21/06/19 20:50, Jason Merrill wrote:
On 6/20/19 12:24 AM, Paolo Carlini wrote:
Hi,
this bug notices that the more aggressive de-virtualization check
that we have now in place (fixed c++/67184) doesn't work correctly
for the below reproducer, which involves a pure virtual: w
e anyway (which then doesn't link). We could add back an '||
CLASSTYPE_FINAL (TYPE_METHOD_BASETYPE (TREE_TYPE (fn)))' for that. ICC
appears to behave this way.
Tested x86_64-linux.
Thanks, Paolo.
////
/cp
2019-06-20 Paolo Carlini
PR c++
o the
conclusion that some should really go. Any general procedural suggestions?
///
/cp
2019-06-14 Paolo Carlini
* decl.c (grokdeclarator): Use id_loc, typespec_loc, and
locations[ds_storage_class] in a few additional places.
/testsuite
2019-06-14 Paolo Ca
Hi,
On 12/06/19 22:24, Jason Merrill wrote:
On 6/6/19 9:00 AM, Paolo Carlini wrote:
Hi,
only minor functional changes here - more precise locations for two
error messages - but I think it's a step in the right direction: it
moves the declaration of id_loc way up, near typespec_loc a
ching back to 'A' (a while ago I already mentioned that we
don't have that option). Tested x86_64-linux.
Thanks, Paolo.
/
/cp
2019-06-10 Paolo Carlini
* decl.c (grokdeclarator): Use id_loc in five additional places
in the last part
Hi,
On 07/06/19 22:31, Marek Polacek wrote:
On Fri, Jun 07, 2019 at 10:20:02PM +0200, Paolo Carlini wrote:
Hi,
On 07/06/19 22:10, Matthew Beliveau wrote:
@@ -6025,6 +6025,10 @@ warn_about_ambiguous_bases (tree t)
Just a nit, but it seems weird to me that the function implementing
Hi,
On 07/06/19 22:10, Matthew Beliveau wrote:
@@ -6025,6 +6025,10 @@ warn_about_ambiguous_bases (tree t)
Just a nit, but it seems weird to me that the function implementing
warn_inaccessible_base is named warn_about_ambiguous_bases.
Paolo.
Tested
x86_64-linux.
Thanks, Paolo.
//////
/cp
2019-06-06 Paolo Carlini
* decl.c (grokdeclarator): Move further up the declaration of
id_loc, use it immediately, update its value after the loop
over declarator, use it again in the final part of functi
Hi,
On 05/06/19 19:45, Jason Merrill wrote:
On 6/4/19 11:57 AM, Paolo Carlini wrote:
Hi,
On 04/06/19 16:50, Jason Merrill wrote:
On 6/4/19 10:31 AM, Paolo Carlini wrote:
+ permerror (loc, "member functions are implicitly "
+ "friends of their class"
with the existing case of spurious qualifiers (ICC does
something similar AFAICS). Tested x86_64-linux.
Thanks, Paolo.
//
/cp
2019-06-05 Paolo Carlini
* decl.c (smallest_type_location): Add.
(check_special_function_return_type): Use it
Hi,
On 04/06/19 21:26, Nina Dinka Ranns wrote:
Good point, dg-do compile is sufficient to demonstrate the issue.
I agree.
A couple of additional nits, sorry for mentioning only now.
C++63149_2.diff
Index: gcc/cp/pt.c
===
---
Hi,
On 04/06/19 18:36, Nina Dinka Ranns wrote:
+// Test for PR63149
+// { dg-do run { target c++11 } }
Are you sure you want a dg-do run?
Paolo.
Hi,
On 04/06/19 16:50, Jason Merrill wrote:
On 6/4/19 10:31 AM, Paolo Carlini wrote:
+ permerror (loc, "member functions are implicitly "
+ "friends of their class");
Wouldn't it be better to use the location of "friend" in this di
Hi,
tested x86_64-linux, as usual.
Thanks, Paolo.
///
/cp
2019-06-04 Paolo Carlini
* decl.c (grokdeclarator): Use declarator->id_loc in three
additional places.
/testsuite
2019-06-04 Paolo Carlini
* g++.dg/concepts/pr60573.C: Test locati
Hi,
a few minor comments.
On 03/06/19 16:49, Qing Zhao wrote:
+fmax-include-depth=
+C ObjC C++ ObjC++ Joined RejectNegative UInteger
+fmax-include-depth= Set the maximum number of depth of nested #include.
I think you want something like "Set the maximum depth of nested #include".
+@item -f
cp_parser_unqualified_id, Certainly it has the advantage that the
location information survives in the tree node when cp_expr is
eventually converted to a plain tree... (below tests fine) What do you
think?
Thanks, Paolo.
2019-05-31 Paolo Carlini
* parser.c
Hi,
On 28/05/19 16:47, Jason Merrill wrote:
On 5/10/19 10:29 AM, Paolo Carlini wrote:
Hi,
a while ago Martin noticed that an unintended consequence of an old
tweak of mine - which avoided redundant error messages emitted from
cp_parser_init_declarator - is that, in some cases, we started
Hi,
gently pinging this...
On 10/05/19 16:29, Paolo Carlini wrote:
Hi,
a while ago Martin noticed that an unintended consequence of an old
tweak of mine - which avoided redundant error messages emitted from
cp_parser_init_declarator - is that, in some cases, we started
accepting ill-formed
Hi,
one more, rather straightforward, simply use the location stored in the
declarator. Tested x86_64-linux.
Thanks, Paolo.
/cp
2019-05-23 Paolo Carlini
* decl.c (grokdeclarator): Use declarator->id_loc in five error
error_at calls.
/testsuite
2
Hi,
On 23/05/19 00:04, Marek Polacek wrote:
On Thu, May 23, 2019 at 12:00:22AM +0200, Paolo Carlini wrote:
Hi,
On 22/05/19 23:45, Marek Polacek wrote:
I noticed this test fails since r271492. Probably obvious, but...
Tested on x86_64-linux, ok for trunk?
I was wondering why I didn&#
Hi,
On 22/05/19 23:45, Marek Polacek wrote:
I noticed this test fails since r271492. Probably obvious, but...
Tested on x86_64-linux, ok for trunk?
I was wondering why I didn't notice it... It's because it only fails
with check-c++-all not with check-c++. Anyway, it seems obvious to me
too
On 22/05/19 10:28, Christophe Lyon wrote:
On Tue, 21 May 2019 at 13:03, Paolo Carlini wrote:
Hi,
also in my back queue a few more location fixes (of course ;) Tested
x86_64-linux.
Thanks, Paolo.
Hi,
I think you incorrectly committed an additional chunk:
I fixed that
Hi,
On 21/05/19 16:57, Jason Merrill wrote:
On 5/16/19 7:12 PM, Paolo Carlini wrote:
Hi,
when Roberto Agostino and I implemented the front-end
devirtualization of final overriders we missed this case, where it
comes from the base. It seems to me that by way of access_path the
existing
1 - 100 of 3018 matches
Mail list logo
