Re: C++ patch ping
On 9/1/21 4:11 PM, Jakub Jelinek wrote: On Wed, Sep 01, 2021 at 03:25:17PM -0400, Jason Merrill wrote: On 8/30/21 3:11 AM, Jakub Jelinek wrote: Hi! I'd like to ping the following patches libcpp: __VA_OPT__ p1042r1 placemarker changes [PR101488] https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575621.html together with your https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577602.html incremental patch (successfully tested on x86_64-linux and i686-linux). OK, thanks. Thanks, committed both patches. My reply to that patch approved it with a suggestion for a tweak to ucn_valid_in_identifier. Quoting it here: I might check invalid_start_flags first, and return 1 if not set, then check all the other flags when not pedantic, and finally return 2 if nothing matches. OK with or without this change. Sorry for missing this, didn't scroll down enough. I don't think something like: if (CPP_OPTION (pfile, cxx23_identifiers)) invalid_start_flags = NXX23; else if (CPP_OPTION (pfile, c11_identifiers)) invalid_start_flags = N11; else if (CPP_OPTION (pfile, c99)) invalid_start_flags = N99; else invalid_start_flags = 0; /* In C99, UCN digits may not begin identifiers. In C11 and C++11, UCN combining characters may not begin identifiers. */ if ((ucnranges[mn].flags & invalid_start_flags) == 0) return 1; /* If not -pedantic, accept as character that may begin an identifier a union of characters allowed at that position in each of the character sets. */ if (!CPP_PEDANTIC (pfile) && ((ucnranges[mn].flags & (C99 | N99)) == C99 || (ucnranges[mn].flags & CXX) != 0 || (ucnranges[mn].flags & (C11 | N11)) == C11 || (ucnranges[mn].flags & (CXX23 | NXX23)) == CXX23)) return 1; return 2; would work, e.g. for C++98 invalid_start_flags is 0, so it would return always 1, while the previous patch returned 2 for non-pedantic if the char wasn't in the CXX set but was e.g. in the C99 set that wasn't allowed as the first char (i.e. in & (C99 | N99) == (C99 | N99) set) etc. While all C99 | N99 characters are C11 | 0, e.g. \u0304 (and many others) are not in C99 at all, not in CXX, and in C11 | N11 and in CXX23 | NXX23. So they are never valid as start characters. There are also some characters like \u1dfa which are not in C99 at all, not in CXX, not in CXX23 and in C11 | N11, so again not valid as start character in any of the pedantic modes. IMHO we want to return 2 for them in non-pedantic. And testing first if (ucnranges[mn].flags & invalid_start_flags) return 2; and then doing the if !CPP_PEDANTIC stuff wouldn't work either, e.g. \U0001d18b is in CXX23 | NXX23 and in C11 | 0, so we IMHO want to return 1 for that (allowed as start character in -pedantic -std=c++20, disallowed as start character in -pedantic -std=c++23) but we would return 2 in -std=c++23 mode. Fair enough. Go ahead without changes, then. Jason
Re: C++ patch ping
On Wed, Sep 01, 2021 at 03:25:17PM -0400, Jason Merrill wrote: > On 8/30/21 3:11 AM, Jakub Jelinek wrote: > > Hi! > > > > I'd like to ping the following patches > > > > libcpp: __VA_OPT__ p1042r1 placemarker changes [PR101488] > > https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575621.html > > together with your > > https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577602.html > > incremental patch (successfully tested on x86_64-linux and i686-linux). > > OK, thanks. Thanks, committed both patches. > My reply to that patch approved it with a suggestion for a tweak to > ucn_valid_in_identifier. Quoting it here: > > > I might check invalid_start_flags first, and return 1 if not set, then > > check all the other flags when not pedantic, and finally return 2 if > > nothing matches. OK with or without this change. Sorry for missing this, didn't scroll down enough. I don't think something like: if (CPP_OPTION (pfile, cxx23_identifiers)) invalid_start_flags = NXX23; else if (CPP_OPTION (pfile, c11_identifiers)) invalid_start_flags = N11; else if (CPP_OPTION (pfile, c99)) invalid_start_flags = N99; else invalid_start_flags = 0; /* In C99, UCN digits may not begin identifiers. In C11 and C++11, UCN combining characters may not begin identifiers. */ if ((ucnranges[mn].flags & invalid_start_flags) == 0) return 1; /* If not -pedantic, accept as character that may begin an identifier a union of characters allowed at that position in each of the character sets. */ if (!CPP_PEDANTIC (pfile) && ((ucnranges[mn].flags & (C99 | N99)) == C99 || (ucnranges[mn].flags & CXX) != 0 || (ucnranges[mn].flags & (C11 | N11)) == C11 || (ucnranges[mn].flags & (CXX23 | NXX23)) == CXX23)) return 1; return 2; would work, e.g. for C++98 invalid_start_flags is 0, so it would return always 1, while the previous patch returned 2 for non-pedantic if the char wasn't in the CXX set but was e.g. in the C99 set that wasn't allowed as the first char (i.e. in & (C99 | N99) == (C99 | N99) set) etc. While all C99 | N99 characters are C11 | 0, e.g. \u0304 (and many others) are not in C99 at all, not in CXX, and in C11 | N11 and in CXX23 | NXX23. So they are never valid as start characters. There are also some characters like \u1dfa which are not in C99 at all, not in CXX, not in CXX23 and in C11 | N11, so again not valid as start character in any of the pedantic modes. IMHO we want to return 2 for them in non-pedantic. And testing first if (ucnranges[mn].flags & invalid_start_flags) return 2; and then doing the if !CPP_PEDANTIC stuff wouldn't work either, e.g. \U0001d18b is in CXX23 | NXX23 and in C11 | 0, so we IMHO want to return 1 for that (allowed as start character in -pedantic -std=c++20, disallowed as start character in -pedantic -std=c++23) but we would return 2 in -std=c++23 mode. Jakub
Re: C++ patch ping
On 8/30/21 3:11 AM, Jakub Jelinek wrote:
Hi!
I'd like to ping the following patches
libcpp: __VA_OPT__ p1042r1 placemarker changes [PR101488]
https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575621.html
together with your
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577602.html
incremental patch (successfully tested on x86_64-linux and i686-linux).
OK, thanks.
libcpp, v2: Implement C++23 P1949R7 - C++ Identifier Syntax using Unicode
Standard Annex 31 [PR100977]
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/576854.html
The incremental patch for splitting tokens at unsupported characters
withdrawn, the above is the base patch.
My reply to that patch approved it with a suggestion for a tweak to
ucn_valid_in_identifier. Quoting it here:
@@ -998,6 +998,28 @@ ucn_valid_in_identifier (cpp_reader *pfi
nst->previous = c;
nst->prev_class = ucnranges[mn].combine;
+ if (!CPP_PEDANTIC (pfile))
+{
+ /* If not -pedantic, accept as character that may
+ begin an identifier a union of characters allowed
+ at that position in each of the character sets. */
+ if ((ucnranges[mn].flags & (C99 | N99)) == C99
+ || (ucnranges[mn].flags & CXX) != 0
+ || (ucnranges[mn].flags & (C11 | N11)) == C11
+ || (ucnranges[mn].flags & (CXX23 | NXX23)) == CXX23)
+return 1;
+ return 2;
+}
+
+ if (CPP_OPTION (pfile, cxx23_identifiers))
+invalid_start_flags = NXX23;
+ else if (CPP_OPTION (pfile, c11_identifiers))
+invalid_start_flags = N11;
+ else if (CPP_OPTION (pfile, c99))
+invalid_start_flags = N99;
+ else
+invalid_start_flags = 0;
+
/* In C99, UCN digits may not begin identifiers. In C11 and C++11,
UCN combining characters may not begin identifiers. */
if (ucnranges[mn].flags & invalid_start_flags)
I might check invalid_start_flags first, and return 1 if not set, then check all the other flags when not pedantic, and finally return 2 if nothing matches. OK with or without this change.
Jason
Re: C++ Patch ping
On 1/5/21 11:34 AM, Jakub Jelinek wrote: Hi! I'd like to ping the: https://gcc.gnu.org/pipermail/gcc-patches/2020-December/562099.html patch. OK, thanks.
Re: [C++ PATCH, PING^3] PR60531 - Wrong error about unresolved overloaded function
Applied, thanks for your persistence.
On 5/31/19 3:06 PM, Harald van Dijk wrote:
another ping
On 12/05/2019 17:57, Harald van Dijk wrote:
ping again
On 26/04/2019 19:58, Harald van Dijk wrote:
ping
On 13/04/2019 10:01, Harald van Dijk wrote:
Hi,
For PR60531, GCC wrongly rejects function templates with explicitly
specified template arguments as overloaded. They are resolved by
resolve_nondeduced_context, which is normally called by
cp_default_conversion through decay_conversion, but the latter have
extra effects making them unusable here. Calling the former directly
does work.
Bootstrapped on x86_64-pc-linux-gnu on top of r270264 with
--enable-languages=all; make check shows no regressions.
Does this look okay?
This is my first code contribution to GCC, please let me know if
anything is missing. I have not signed any copyright disclaimer or
copyright assignment; says that is not necessary
for small changes, which I trust this is. If it is needed after all,
please let me know what specifically will be required.
Cheers,
Harald van Dijk
PR c++/60531
* typeck.c (cp_build_binary_op): See if overload can be resolved.
(cp_build_unary_op): Ditto.
* g++.dg/template/operator15.C: New test.
diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c
index 03b14024738..e1ffe88ce2c 100644
--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -4384,10 +4384,6 @@ cp_build_binary_op (const op_location_t
&location,
/* True if both operands have arithmetic type. */
bool arithmetic_types_p;
- /* Apply default conversions. */
- op0 = orig_op0;
- op1 = orig_op1;
-
/* Remember whether we're doing / or %. */
bool doing_div_or_mod = false;
@@ -4397,6 +4393,10 @@ cp_build_binary_op (const op_location_t
&location,
/* Tree holding instrumentation expression. */
tree instrument_expr = NULL_TREE;
+ /* Apply default conversions. */
+ op0 = resolve_nondeduced_context (orig_op0, complain);
+ op1 = resolve_nondeduced_context (orig_op1, complain);
+
if (code == TRUTH_AND_EXPR || code == TRUTH_ANDIF_EXPR
|| code == TRUTH_OR_EXPR || code == TRUTH_ORIF_EXPR
|| code == TRUTH_XOR_EXPR)
@@ -6204,11 +6204,13 @@ cp_build_unary_op (enum tree_code code, tree
xarg, bool noconvert,
if (!arg || error_operand_p (arg))
return error_mark_node;
+ arg = resolve_nondeduced_context (arg, complain);
+
if ((invalid_op_diag
= targetm.invalid_unary_op ((code == UNARY_PLUS_EXPR
? CONVERT_EXPR
: code),
- TREE_TYPE (xarg
+ TREE_TYPE (arg
{
if (complain & tf_error)
error (invalid_op_diag);
diff --git a/gcc/testsuite/g++.dg/template/operator15.C
b/gcc/testsuite/g++.dg/template/operator15.C
new file mode 100644
index 000..755442266bb
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/operator15.C
@@ -0,0 +1,6 @@
+// PR c++/60531
+
+template < class T > T foo ();
+
+bool b1 = foo == foo;
+int (*fp1)() = +foo;
Re: [C++ PATCH, PING^2] PR60531 - Wrong error about unresolved overloaded function
ping again
On 26/04/2019 19:58, Harald van Dijk wrote:
ping
On 13/04/2019 10:01, Harald van Dijk wrote:
Hi,
For PR60531, GCC wrongly rejects function templates with explicitly
specified template arguments as overloaded. They are resolved by
resolve_nondeduced_context, which is normally called by
cp_default_conversion through decay_conversion, but the latter have
extra effects making them unusable here. Calling the former directly
does work.
Bootstrapped on x86_64-pc-linux-gnu on top of r270264 with
--enable-languages=all; make check shows no regressions.
Does this look okay?
This is my first code contribution to GCC, please let me know if
anything is missing. I have not signed any copyright disclaimer or
copyright assignment; says that is not necessary
for small changes, which I trust this is. If it is needed after all,
please let me know what specifically will be required.
Cheers,
Harald van Dijk
PR c++/60531
* typeck.c (cp_build_binary_op): See if overload can be resolved.
(cp_build_unary_op): Ditto.
* g++.dg/template/operator15.C: New test.
diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c
index 03b14024738..e1ffe88ce2c 100644
--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -4384,10 +4384,6 @@ cp_build_binary_op (const op_location_t &location,
/* True if both operands have arithmetic type. */
bool arithmetic_types_p;
- /* Apply default conversions. */
- op0 = orig_op0;
- op1 = orig_op1;
-
/* Remember whether we're doing / or %. */
bool doing_div_or_mod = false;
@@ -4397,6 +4393,10 @@ cp_build_binary_op (const op_location_t &location,
/* Tree holding instrumentation expression. */
tree instrument_expr = NULL_TREE;
+ /* Apply default conversions. */
+ op0 = resolve_nondeduced_context (orig_op0, complain);
+ op1 = resolve_nondeduced_context (orig_op1, complain);
+
if (code == TRUTH_AND_EXPR || code == TRUTH_ANDIF_EXPR
|| code == TRUTH_OR_EXPR || code == TRUTH_ORIF_EXPR
|| code == TRUTH_XOR_EXPR)
@@ -6204,11 +6204,13 @@ cp_build_unary_op (enum tree_code code, tree xarg, bool
noconvert,
if (!arg || error_operand_p (arg))
return error_mark_node;
+ arg = resolve_nondeduced_context (arg, complain);
+
if ((invalid_op_diag
= targetm.invalid_unary_op ((code == UNARY_PLUS_EXPR
? CONVERT_EXPR
: code),
- TREE_TYPE (xarg
+ TREE_TYPE (arg
{
if (complain & tf_error)
error (invalid_op_diag);
diff --git a/gcc/testsuite/g++.dg/template/operator15.C
b/gcc/testsuite/g++.dg/template/operator15.C
new file mode 100644
index 000..755442266bb
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/operator15.C
@@ -0,0 +1,6 @@
+// PR c++/60531
+
+template < class T > T foo ();
+
+bool b1 = foo == foo;
+int (*fp1)() = +foo;
Re: C++ patch ping
On 12/4/18 9:47 AM, Jakub Jelinek wrote: Hi! I'd like to ping PR87506 - https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01758.html You've acked the patch with the asserts but that FAILs as mentioned in the above mail. The following has been bootstrapped/regtested and works, can it be committed without those asserts and let those be handled incrementally later (though, I'm afraid I'm not familiar enough with resolving those). OK> Jason
Re: [C++ Patch PING] [C++ Patch] PR 85065 ("[concepts] ICE with invalid use of a concept")
On Mon, Sep 17, 2018 at 1:53 PM, Paolo Carlini wrote: > Hi again, > > On 9/3/18 10:59 PM, Paolo Carlini wrote: >> >> in this error-recovery ICE, upon the error make_constrained_auto assigns >> error_mark_node to PLACEHOLDER_TYPE_CONSTRAINTS (type) which then causes a >> crash later when hash_placeholder_constraint is called on it. I think we >> should cope with this somehow, I believe that consistency with the way we >> use error_mark_node in this part of the front-end prevents us from avoiding >> to assign the error_mark_node in the first place and, for the reasons >> explained in my previous patch, we want to unconditionally call >> make_constrained_auto. This said, catching in practice the error_mark_node >> would normally mean renouncing to the pattern 'if (tree c = ...)' which we >> lately appear to like a lot and seems indeed neat. Thus I'm wondering if we >> want instead to add a macro like ERROR_AS_NULL, which of course would be >> also useful in many other places - essentially in all the circumstances >> where we want to check for a kosher node, thus neither null nor >> error_mark_node. What do you think? What about the name, in case? Tested >> x86_64-linux. > > > Today I reviewed again this issue, for which I sent a tentative patch a > couple of weeks ago. All in all, I still believe that is the right place to > catch the error_mark_node and avoid ICE-ing later, the quick rationale being > that PLACEHOLDER_TYPE_CONSTRAINTS can be error_mark_node for other reasons > too. As regards the ERROR_AS_NULL idea, I'm still not sure, on one hand it > would allow for more compact and neat code in some cases, on the other hand > could be seen as some sort of obfuscation - well, some people out there > consider an obfuscation the very 'if (c =...)' pattern ;) Anyway, I'm > attaching the normal versions of the fix, which, per a recent message from > Jason, probably is almost obvious... Hmm, I do kind of like the ERROR_AS_NULL idea. I might call it NON_ERROR, though. OK with that change. Jason
Re: C++ patch ping
On Fri, Jul 13, 2018 at 12:24:02PM -0400, Nathan Sidwell wrote:
> On 07/13/2018 09:49 AM, Jakub Jelinek wrote:
> > Hi!
> >
> > I'd like to ping the following C++ patches:
> >
> > - PR c++/85515
> >make range for temporaries unspellable during parsing and only
> >turn them into spellable for debug info purposes
> >http://gcc.gnu.org/ml/gcc-patches/2018-07/msg00086.html
>
>
> How hard would it be to add the 6 special identifiers to the C++ global
> table via initialize_predefined_identifiers (decl.c) and then use them
> directly in the for range machinery? repeated get_identifier
> ("string-const") just smells bad.
Probably not too hard, but we have hundreds of other
get_identifier ("string-const") calls in the middle-end, C++ FE, other FEs.
Are those 6 more important than say "abi_tag", "gnu", "begin", "end", "get",
"tuple_size", "tuple_element", and many others?
Is it worth caching those?
Jakub
Re: C++ patch ping
On 07/13/2018 09:49 AM, Jakub Jelinek wrote: - PR c++/3698, PR c++/86208 extern_decl_map & TREE_USED fix (plus 2 untested variants) http://gcc.gnu.org/ml/gcc-patches/2018-07/msg00084.html ok, thanks -- Nathan Sidwell
Re: C++ patch ping
On 07/13/2018 09:49 AM, Jakub Jelinek wrote:
Hi!
I'd like to ping the following C++ patches:
- PR c++/85515
make range for temporaries unspellable during parsing and only
turn them into spellable for debug info purposes
http://gcc.gnu.org/ml/gcc-patches/2018-07/msg00086.html
How hard would it be to add the 6 special identifiers to the C++ global
table via initialize_predefined_identifiers (decl.c) and then use them
directly in the for range machinery? repeated get_identifier
("string-const") just smells bad.
nathan
--
Nathan Sidwell
Re: [C++ Patch PING] [C++ Patch] PR 82235 (Copy ctor is not found for copying array of an object when it's marked explicit)
Hi Jason, On 13/12/2017 23:27, Jason Merrill wrote: These two don't match: + When initializing a temporary to be bound to the first + parameter of a constructor where the parameter is of type +/* Return true if current_function_decl is a constructor + and its first argument is a reference type and it is The language is talking about the function being called, and ref_first_parm_of_constructor is looking at the function we're currently in. Indeed. Thanks Jason for the feedback. I was going to send an improved patch, among other things using CP_DECL_CONTEXT, when I noticed that this issue seems essentially a special case of *your* core/899, right? For 899 we already have some infrastructure in place and I believe we only have to figure out why we don't handle correctly *arrays*, because otherwise we already accept a similar testcase involving a plain 'Foo m' member. Please let me know, otherwise I'm going to work in this direction! Thanks again, Paolo.
Re: [C++ Patch PING] [C++ Patch] PR 82235 (Copy ctor is not found for copying array of an object when it's marked explicit)
On 12/12/2017 03:20 PM, Paolo Carlini wrote:
Hi,
On 15/11/2017 00:54, Mukesh Kapoor wrote:
Hi,
This patch fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82235
For the following test case
struct Foo {
Foo() {}
explicit Foo(const Foo& aOther) {}
};
struct Bar {
Foo m[1];
};
void test() {
Bar a;
Bar b = a;
}
the compiler issues an error when the compiler generated copy
constructor of class Bar calls the explicit copy constructor of class
Foo. The fix is to implement ISO C++/17 16.3.1.4 (over.match.copy)
correctly.
I'm pinging this patch sent a while by Mukesh (I'm taking over from him
about it). Any comments?
https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01133.html
These two don't match:
+ When initializing a temporary to be bound to the first
+ parameter of a constructor where the parameter is of type
+/* Return true if current_function_decl is a constructor
+ and its first argument is a reference type and it is
The language is talking about the function being called, and
ref_first_parm_of_constructor is looking at the function we're currently in.
Jason
Re: [C++ Patch Ping] PR 64644 (""warning: anonymous union with no members" should be an error with -pedantic-errors")
On 09/15/2017 05:53 AM, Paolo Carlini wrote: Hi, gently pinging this. On 16/06/2017 15:47, Paolo Carlini wrote: Hi, submitter and Manuel analyzed this a while ago and came to the conclusion - which I think is still valid vs the current working draft - that strictly speaking this kind of code violates [dcl.dcl], thus a pedwarn seems more suited than a plain warning. The below one-liner, suggested by Manuel at the time, passes testing on x86_64-linux together with my testsuite changes. https://gcc.gnu.org/ml/gcc-patches/2017-06/msg01193.html Ok. class.union.anon has the member-specification as non-optional. nathan -- Nathan Sidwell
Re: C++ Patch Ping
On 12/15/2016 07:26 AM, Jakub Jelinek wrote: I don't think so. complete_type (error_mark_node) returns error_mark_node, and COMPLETE_TYPE_P (error_mark_node) is invalid (should fail TYPE_CHECK in checking compiler). I can write it as inst = complete_type (inst); if (inst == error_mark_node || !COMPLETE_TYPE_P (inst)) return NULL_TREE; that's probably better, because complete_type can return error_mark_node if 'something goes horribly wrong' -- Nathan Sidwell
Re: C++ Patch Ping
On Thu, Dec 15, 2016 at 07:14:15AM -0500, Nathan Sidwell wrote: > On 12/15/2016 03:34 AM, Jakub Jelinek wrote: > > Hi! > > > > I'd like to ping the > > > > http://gcc.gnu.org/ml/gcc-patches/2016-12/msg00698.html > > P0490R0 GB 20: decomposition declaration should commit to tuple > > interpretation early > > + if (inst == error_mark_node) > +return NULL_TREE; > > This check is unneeded, because complete_type DTRT with error_mark_node > > + inst = complete_type (inst); > + if (!COMPLETE_TYPE_P (inst)) > +return NULL_TREE; I don't think so. complete_type (error_mark_node) returns error_mark_node, and COMPLETE_TYPE_P (error_mark_node) is invalid (should fail TYPE_CHECK in checking compiler). I can write it as inst = complete_type (inst); if (inst == error_mark_node || !COMPLETE_TYPE_P (inst)) return NULL_TREE; Jakub
Re: C++ Patch Ping
On 12/15/2016 03:34 AM, Jakub Jelinek wrote: Hi! I'd like to ping the http://gcc.gnu.org/ml/gcc-patches/2016-12/msg00698.html P0490R0 GB 20: decomposition declaration should commit to tuple interpretation early + if (inst == error_mark_node) +return NULL_TREE; This check is unneeded, because complete_type DTRT with error_mark_node + inst = complete_type (inst); + if (!COMPLETE_TYPE_P (inst)) +return NULL_TREE; -- Nathan Sidwell
Re: C++ patch ping
OK. Jason
Re: C++ patch ping
On Mon, Jan 11, 2016 at 05:04:16PM -0500, Jason Merrill wrote:
> >You mean:
> >
> >--- gcc/cp/pt.c.jj 2016-01-05 16:46:02.891896607 +0100
> >+++ gcc/cp/pt.c 2016-01-11 21:33:09.065184178 +0100
> >@@ -12207,6 +12207,8 @@ tsubst_decl (tree t, tree args, tsubst_f
> > DECL_TEMPLATE_INSTANTIATED (r) = 0;
> > if (type == error_mark_node)
> > RETURN (error_mark_node);
> >+if (DECL_LANG_SPECIFIC (r))
> >+ DECL_TEMPLATE_INFO (r) = NULL_TREE;
> > if (TREE_CODE (type) == FUNCTION_TYPE)
> > {
> > /* It may seem that this case cannot occur, since:
> >
> >I'm almost through bootstrapping that, but regtesting will take some more
> >time.
That version regressed:
+FAIL: g++.dg/cpp1y/var-templ16.C -std=c++14 (internal compiler error)
+FAIL: g++.dg/cpp1y/var-templ16.C -std=c++14 (test for excess errors)
+FAIL: g++.dg/cpp1y/var-templ18.C -std=c++14 (internal compiler error)
+FAIL: g++.dg/cpp1y/var-templ18.C -std=c++14 (test for excess errors)
+FAIL: g++.dg/cpp1y/var-templ27.C -std=c++14 (internal compiler error)
+FAIL: g++.dg/cpp1y/var-templ27.C -std=c++14 (test for excess errors)
> >Do you mean:
> >
> >--- gcc/cp/pt.c.jj 2016-01-05 16:46:02.891896607 +0100
> >+++ gcc/cp/pt.c 2016-01-11 22:49:12.303477700 +0100
> >@@ -12292,8 +12292,13 @@ tsubst_decl (tree t, tree args, tsubst_f
> > SET_DECL_IMPLICIT_INSTANTIATION (r);
> > register_specialization (r, gen_tmpl, argvec, false, hash);
> > }
> >-else if (!cp_unevaluated_operand)
> >- register_local_specialization (r, t);
> >+else
> >+ {
> >+if (VAR_P (r) && DECL_LANG_SPECIFIC (r))
> >+ DECL_TEMPLATE_INFO (r) = NULL_TREE;
> >+if (!cp_unevaluated_operand)
> >+ register_local_specialization (r, t);
> >+ }
> >
> > DECL_CHAIN (r) = NULL_TREE;
> >
> >or something different? Or should it be cleared also for non-VAR_DECLs
> >if they have DECL_LANG_SPECIFIC?
>
> Yes, like that. You don't need to check VAR_P, since TYPE_DECL also has
> DECL_TEMPLATE_INFO.
But following patch passed bootstrap on x86_64-linux and bootstrap + regtest
on i686-linux, ok for trunk if it also passes regtest on x86_64-linux?
2016-01-12 Jakub Jelinek
PR c++/66808
PR c++/69000
* pt.c (tsubst_decl): If not local_p, clear DECL_TEMPLATE_INFO.
* g++.dg/tls/pr66808.C: New test.
* g++.dg/tls/pr69000.C: New test.
--- gcc/cp/pt.c.jj 2016-01-05 16:46:02.891896607 +0100
+++ gcc/cp/pt.c 2016-01-11 23:22:54.742344987 +0100
@@ -12292,8 +12292,13 @@ tsubst_decl (tree t, tree args, tsubst_f
SET_DECL_IMPLICIT_INSTANTIATION (r);
register_specialization (r, gen_tmpl, argvec, false, hash);
}
- else if (!cp_unevaluated_operand)
- register_local_specialization (r, t);
+ else
+ {
+ if (DECL_LANG_SPECIFIC (r))
+ DECL_TEMPLATE_INFO (r) = NULL_TREE;
+ if (!cp_unevaluated_operand)
+ register_local_specialization (r, t);
+ }
DECL_CHAIN (r) = NULL_TREE;
--- gcc/testsuite/g++.dg/tls/pr69000.C.jj 2015-12-21 14:03:38.362847547
+0100
+++ gcc/testsuite/g++.dg/tls/pr69000.C 2015-12-21 14:04:17.839291295 +0100
@@ -0,0 +1,19 @@
+// PR c++/69000
+// { dg-do compile }
+// { dg-require-effective-target tls }
+
+class A {};
+
+template
+struct B
+{
+ static int *& foo () { static __thread int *c = 0; return c; }
+};
+
+B d;
+
+void
+bar ()
+{
+ d.foo ();
+}
--- gcc/testsuite/g++.dg/tls/pr66808.C.jj 2015-12-21 14:06:06.791756074
+0100
+++ gcc/testsuite/g++.dg/tls/pr66808.C 2015-12-21 14:06:02.651814409 +0100
@@ -0,0 +1,10 @@
+// PR c++/66808
+// { dg-do compile { target c++11 } }
+// { dg-require-effective-target tls }
+
+template
+class A {
+ int *b = foo ();
+ int *foo () { static __thread int a; return &a; }
+};
+A b;
Jakub
Re: C++ patch ping
On 01/11/2016 04:52 PM, Jakub Jelinek wrote:
On Mon, Jan 11, 2016 at 04:44:46PM -0500, Jason Merrill wrote:
On 01/11/2016 03:01 PM, Nathan Sidwell wrote:
On 01/09/16 02:41, Jakub Jelinek wrote:
Hi!
I'd like to ping the PR c++/66808, PR c++/69000
http://gcc.gnu.org/ml/gcc-patches/2015-12/msg02019.html
patch, fixing ICE with GNU __thread vars in templates.
Can't you unconditionally clear DECL_TEMPLATE_INFO regardless of local_p?
if (DECL_LANG_SPECIFIC(r))
DECL_TEMPLATE_INFO(r) == NULL_TREE;
?
You mean:
--- gcc/cp/pt.c.jj 2016-01-05 16:46:02.891896607 +0100
+++ gcc/cp/pt.c 2016-01-11 21:33:09.065184178 +0100
@@ -12207,6 +12207,8 @@ tsubst_decl (tree t, tree args, tsubst_f
DECL_TEMPLATE_INSTANTIATED (r) = 0;
if (type == error_mark_node)
RETURN (error_mark_node);
+ if (DECL_LANG_SPECIFIC (r))
+ DECL_TEMPLATE_INFO (r) = NULL_TREE;
if (TREE_CODE (type) == FUNCTION_TYPE)
{
/* It may seem that this case cannot occur, since:
I'm almost through bootstrapping that, but regtesting will take some more
time.
Or clear it for local_p down by where we're setting it for !local_p.
Do you mean:
--- gcc/cp/pt.c.jj 2016-01-05 16:46:02.891896607 +0100
+++ gcc/cp/pt.c 2016-01-11 22:49:12.303477700 +0100
@@ -12292,8 +12292,13 @@ tsubst_decl (tree t, tree args, tsubst_f
SET_DECL_IMPLICIT_INSTANTIATION (r);
register_specialization (r, gen_tmpl, argvec, false, hash);
}
- else if (!cp_unevaluated_operand)
- register_local_specialization (r, t);
+ else
+ {
+ if (VAR_P (r) && DECL_LANG_SPECIFIC (r))
+ DECL_TEMPLATE_INFO (r) = NULL_TREE;
+ if (!cp_unevaluated_operand)
+ register_local_specialization (r, t);
+ }
DECL_CHAIN (r) = NULL_TREE;
or something different? Or should it be cleared also for non-VAR_DECLs
if they have DECL_LANG_SPECIFIC?
Yes, like that. You don't need to check VAR_P, since TYPE_DECL also has
DECL_TEMPLATE_INFO.
Jason
Re: C++ patch ping
On Mon, Jan 11, 2016 at 04:44:46PM -0500, Jason Merrill wrote:
> On 01/11/2016 03:01 PM, Nathan Sidwell wrote:
> >On 01/09/16 02:41, Jakub Jelinek wrote:
> >>Hi!
> >>
> >>I'd like to ping the PR c++/66808, PR c++/69000
> >>http://gcc.gnu.org/ml/gcc-patches/2015-12/msg02019.html
> >>patch, fixing ICE with GNU __thread vars in templates.
> >
> >Can't you unconditionally clear DECL_TEMPLATE_INFO regardless of local_p?
> >
> >if (DECL_LANG_SPECIFIC(r))
> > DECL_TEMPLATE_INFO(r) == NULL_TREE;
> >?
You mean:
--- gcc/cp/pt.c.jj 2016-01-05 16:46:02.891896607 +0100
+++ gcc/cp/pt.c 2016-01-11 21:33:09.065184178 +0100
@@ -12207,6 +12207,8 @@ tsubst_decl (tree t, tree args, tsubst_f
DECL_TEMPLATE_INSTANTIATED (r) = 0;
if (type == error_mark_node)
RETURN (error_mark_node);
+ if (DECL_LANG_SPECIFIC (r))
+ DECL_TEMPLATE_INFO (r) = NULL_TREE;
if (TREE_CODE (type) == FUNCTION_TYPE)
{
/* It may seem that this case cannot occur, since:
I'm almost through bootstrapping that, but regtesting will take some more
time.
> Or clear it for local_p down by where we're setting it for !local_p.
Do you mean:
--- gcc/cp/pt.c.jj 2016-01-05 16:46:02.891896607 +0100
+++ gcc/cp/pt.c 2016-01-11 22:49:12.303477700 +0100
@@ -12292,8 +12292,13 @@ tsubst_decl (tree t, tree args, tsubst_f
SET_DECL_IMPLICIT_INSTANTIATION (r);
register_specialization (r, gen_tmpl, argvec, false, hash);
}
- else if (!cp_unevaluated_operand)
- register_local_specialization (r, t);
+ else
+ {
+ if (VAR_P (r) && DECL_LANG_SPECIFIC (r))
+ DECL_TEMPLATE_INFO (r) = NULL_TREE;
+ if (!cp_unevaluated_operand)
+ register_local_specialization (r, t);
+ }
DECL_CHAIN (r) = NULL_TREE;
or something different? Or should it be cleared also for non-VAR_DECLs
if they have DECL_LANG_SPECIFIC?
Jakub
Re: C++ patch ping
On 01/11/2016 03:01 PM, Nathan Sidwell wrote: On 01/09/16 02:41, Jakub Jelinek wrote: Hi! I'd like to ping the PR c++/66808, PR c++/69000 http://gcc.gnu.org/ml/gcc-patches/2015-12/msg02019.html patch, fixing ICE with GNU __thread vars in templates. Can't you unconditionally clear DECL_TEMPLATE_INFO regardless of local_p? if (DECL_LANG_SPECIFIC(r)) DECL_TEMPLATE_INFO(r) == NULL_TREE; ? Or clear it for local_p down by where we're setting it for !local_p. Jason
Re: C++ patch ping
On 01/09/16 02:41, Jakub Jelinek wrote: Hi! I'd like to ping the PR c++/66808, PR c++/69000 http://gcc.gnu.org/ml/gcc-patches/2015-12/msg02019.html patch, fixing ICE with GNU __thread vars in templates. Can't you unconditionally clear DECL_TEMPLATE_INFO regardless of local_p? if (DECL_LANG_SPECIFIC(r)) DECL_TEMPLATE_INFO(r) == NULL_TREE; ? nathan
Re: [C++ Patch PING] Re: [PATCH] make excessive template instantiation depth a fatal error
Hi, On 09/30/2014 04:51 PM, Manuel López-Ibáñez wrote: I don't want to cause you more work Paolo, but perhaps this should be documented in https://gcc.gnu.org/gcc-5/changes.html. ? Something like: * Excessive template instantiation depth is now a fatal error. This prevents excessive diagnostics that usually do not help to identify the problem. Thanks for taking care of this! You are welcome. No problem about the changes.html bits, I'll take care of that too. Paolo.
Re: [C++ Patch PING] Re: [PATCH] make excessive template instantiation depth a fatal error
I don't want to cause you more work Paolo, but perhaps this should be documented in https://gcc.gnu.org/gcc-5/changes.html. ? Something like: * Excessive template instantiation depth is now a fatal error. This prevents excessive diagnostics that usually do not help to identify the problem. Thanks for taking care of this! Cheers, Manuel. On 30 September 2014 16:38, Jason Merrill wrote: > OK. > > Jason
Re: [C++ Patch PING] Re: [PATCH] make excessive template instantiation depth a fatal error
OK. Jason
Re: [C++ Patch PING] Re: [PATCH] make excessive template instantiation depth a fatal error
... forgot to attach the complete patch ;)
Paolo.
Index: cp/cp-tree.h
===
--- cp/cp-tree.h(revision 215710)
+++ cp/cp-tree.h(working copy)
@@ -5418,7 +5418,6 @@ extern const char *lang_decl_name (tree, int, boo
extern const char *lang_decl_dwarf_name(tree, int, bool);
extern const char *language_to_string (enum languages);
extern const char *class_key_or_enum_as_string (tree);
-extern void print_instantiation_context(void);
extern void maybe_warn_variadic_templates (void);
extern void maybe_warn_cpp0x (cpp0x_warn_str str);
extern bool pedwarn_cxx98 (location_t, int, const char
*, ...) ATTRIBUTE_GCC_DIAG(3,4);
@@ -5633,7 +5632,7 @@ extern tree tsubst_copy_and_build (tree, tree, ts
tree, bool, bool);
extern tree most_general_template (tree);
extern tree get_mostly_instantiated_function_type (tree);
-extern int problematic_instantiation_changed (void);
+extern bool problematic_instantiation_changed (void);
extern void record_last_problematic_instantiation (void);
extern struct tinst_level *current_instantiation(void);
extern tree maybe_get_template_decl_from_type_decl (tree);
@@ -5661,7 +5660,8 @@ extern tree fold_non_dependent_expr_sfinae(tree,
extern bool alias_type_or_template_p(tree);
extern bool alias_template_specialization_p (const_tree);
extern bool explicit_class_specialization_p (tree);
-extern int push_tinst_level (tree);
+extern bool push_tinst_level(tree);
+extern bool push_tinst_level_loc(tree, location_t);
extern void pop_tinst_level (void);
extern struct tinst_level *outermost_tinst_level(void);
extern void init_template_processing (void);
Index: cp/error.c
===
--- cp/error.c (revision 215710)
+++ cp/error.c (working copy)
@@ -3360,16 +3360,6 @@ maybe_print_instantiation_context (diagnostic_cont
record_last_problematic_instantiation ();
print_instantiation_full_context (context);
}
-
-/* Report the bare minimum context of a template instantiation. */
-void
-print_instantiation_context (void)
-{
- print_instantiation_partial_context
-(global_dc, current_instantiation (), input_location);
- pp_newline (global_dc->printer);
- diagnostic_flush_buffer (global_dc);
-}
/* Report what constexpr call(s) we're trying to expand, if any. */
Index: cp/pt.c
===
--- cp/pt.c (revision 215710)
+++ cp/pt.c (working copy)
@@ -8347,26 +8347,26 @@ static GTY(()) struct tinst_level *last_error_tins
/* We're starting to instantiate D; record the template instantiation context
for diagnostics and to restore it later. */
-int
+bool
push_tinst_level (tree d)
{
+ return push_tinst_level_loc (d, input_location);
+}
+
+/* We're starting to instantiate D; record the template instantiation context
+ at LOC for diagnostics and to restore it later. */
+
+bool
+push_tinst_level_loc (tree d, location_t loc)
+{
struct tinst_level *new_level;
if (tinst_depth >= max_tinst_depth)
{
- last_error_tinst_level = current_tinst_level;
- if (TREE_CODE (d) == TREE_LIST)
- error ("template instantiation depth exceeds maximum of %d (use "
- "-ftemplate-depth= to increase the maximum) substituting %qS",
- max_tinst_depth, d);
- else
- error ("template instantiation depth exceeds maximum of %d (use "
- "-ftemplate-depth= to increase the maximum) instantiating %qD",
- max_tinst_depth, d);
-
- print_instantiation_context ();
-
- return 0;
+ fatal_error ("template instantiation depth exceeds maximum of %d"
+ " (use -ftemplate-depth= to increase the maximum)",
+ max_tinst_depth);
+ return false;
}
/* If the current instantiation caused problems, don't let it instantiate
@@ -8373,11 +8373,11 @@ push_tinst_level (tree d)
anything else. Do allow deduction substitution and decls usable in
constant expressions. */
if (limit_bad_template_recursion (d))
-return 0;
+return false;
new_level = ggc_alloc ();
new_level->decl = d;
- new_level->locus = input_location;
+ new_level->locus = loc;
new_level->errors = errorcount+sorrycount;
new_level->in_system_header_p = in_system_header_at (input_location);
new_level->next = current_tinst_level;
@@ -8387,7 +8387,7 @@ push_tinst_level (tree d)
if (GATHER_STATISTICS && (tinst_depth > depth_reached))
depth_reached = tinst_depth;
- return 1;
+ return true;
}
/* We're done instantiating this template; return to the instantiation
@@ -2
