C++ Patch ping - Re: [PATCH] c++: Fix parsing of abstract-declarator starting with ... followed by [ or ( [PR115012]
Hi! I'd like to ping the https://gcc.gnu.org/pipermail/gcc-patches/2024-May/651199.html patch. Thanks. On Thu, May 09, 2024 at 08:12:30PM +0200, Jakub Jelinek wrote: > The C++26 P2662R3 Pack indexing paper mentions that both GCC > and MSVC don't handle T...[10] parameter declaration when T > is a pack. While that will change meaning in C++26, in C++11 .. C++23 > this ought to be valid. Also, T...(args) as well. > > The following patch handles those in cp_parser_direct_declarator. > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? > > 2024-05-09 Jakub Jelinek > > PR c++/115012 > * parser.cc (cp_parser_direct_declarator): Handle > abstract declarator starting with ... followed by [ > or (. > > * g++.dg/cpp0x/variadic185.C: New test. > * g++.dg/cpp0x/variadic186.C: New test. Jakub
C++ Patch ping^2
Hi! On Wed, Apr 03, 2024 at 11:48:20AM +0200, Jakub Jelinek wrote: > I'd like to ping the following patches: > > https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647445.html > PR111284 P2 > > https://gcc.gnu.org/pipermail/gcc-patches/2024-March/648215.html > PR114409 (part of a P1) > > https://gcc.gnu.org/pipermail/gcc-patches/2024-March/648381.html > PR114426 P1 Thanks Jakub
C++ Patch ping
Hi! I'd like to ping the following patches: https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647445.html PR111284 P2 https://gcc.gnu.org/pipermail/gcc-patches/2024-March/648215.html PR114409 (part of a P1) https://gcc.gnu.org/pipermail/gcc-patches/2024-March/648381.html PR114426 P1 Thanks. Jakub
C++ Patch ping
Hi! I'd like to ping the https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647445.html PR111284 P2 patch. Thanks. Jakub
C++ patch ping
Hi!
https://gcc.gnu.org/pipermail/gcc-patches/2024-February/thread.html#645781
[PATCH] c++: Fix up parameter pack diagnostics on xobj vs. varargs functions
[PR113802]
The thread contains two possible further versions of the patch.
https://gcc.gnu.org/pipermail/gcc-patches/2024-February/thread.html#645782
[PATCH] dwarf2out: Emit DW_AT_export_symbols on anon unions/structs [PR113918]
The thread contains another version of the patch at the end.
https://gcc.gnu.org/pipermail/gcc-patches/2024-February/thread.html#645916
[PATCH] c-family, c++: Fix up handling of types which may have padding in
__atomic_{compare_}exchange
Seems Richi would like to use MEM_REF in the c-family code, that is then
the https://gcc.gnu.org/pipermail/gcc-patches/2024-February/646040.html
version.
Thanks
Jakub
C++ patch ping^3
Hi! I'd like to ping a couple of C++ patches. - c++, v2: Implement C++26 P2169R4 - Placeholder variables with no name [PR110349] https://gcc.gnu.org/pipermail/gcc-patches/2023-September/630802.html - c++, v2: Implement C++26 P2741R3 - user-generated static_assert messages [PR110348] https://gcc.gnu.org/pipermail/gcc-patches/2023-September/630803.html - c++: Implement C++ DR 2406 - [[fallthrough]] attribute and iteration statements [PR107571] https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628487.html (from this one Richi approved the middle-end changes) - c++, v2: Implement C++26 P1854R4 - Making non-encodable string literals ill-formed [PR110341] https://gcc.gnu.org/pipermail/gcc-patches/2023-November/635170.html - c++: Fix error recovery ICE [PR112365] https://gcc.gnu.org/pipermail/gcc-patches/2023-November/635210.html Thanks Jakub
C++ patch ping^2
Hi! I'd like to ping a couple of C++ patches. - c++, v2: Implement C++26 P2169R4 - Placeholder variables with no name [PR110349] https://gcc.gnu.org/pipermail/gcc-patches/2023-September/630802.html - c++: Implement C++26 P2361R6 - Unevaluated strings [PR110342] https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628375.html - c++, v2: Implement C++26 P2741R3 - user-generated static_assert messages [PR110348] https://gcc.gnu.org/pipermail/gcc-patches/2023-September/630803.html - c++: Implement C++ DR 2406 - [[fallthrough]] attribute and iteration statements [PR107571] https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628487.html (from this one Richi approved the middle-end changes) - c++: Implement C++26 P1854R4 - Making non-encodable string literals ill-formed [PR110341] https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628490.html - libcpp, v2: Small incremental patch for P1854R4 [PR110341] https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628586.html Jakub
C++ patch ping
Hi! I'd like to ping a couple of C++ patches. All of them together with the 2 updated patches posted yesterday have been bootstrapped/regtested on x86_64-linux and i686-linux again yesterday. - c++: Implement C++26 P2361R6 - Unevaluated strings [PR110342] https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628375.html - c++: Implement C++26 P2741R3 - user-generated static_assert messages [PR110348] https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628378.html - c++: Implement C++ DR 2406 - [[fallthrough]] attribute and iteration statements https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628487.html (from this one Richi approved the middle-end changes) - c++: Implement C++26 P1854R4 - Making non-encodable string literals ill-formed [PR110341] https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628490.html - libcpp, v2: Small incremental patch for P1854R4 [PR110341] https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628586.html Thanks Jakub
C++ patch ping
Hi! I'd like to ping the: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590276.html PR102586 - reject __builtin_clear_padding on non-trivially-copyable types with one exception https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590641.html PR104568 - fix up constexpr evaluation of new with zero sized types patches. Thanks Jakub
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
C++ patch ping
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). 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. Thanks. Jakub
C++ Patch ping
Hi! I'd like to ping 3 patches: c++: Add C++20 #__VA_OPT__ support https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575355.html libcpp: __VA_OPT__ p1042r1 placemarker changes [PR101488] https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575621.html 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 Thanks Jakub
C++ Patch ping
Hi! I'd like to ping 3 patches: c++: Add C++20 #__VA_OPT__ support https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575355.html libcpp: __VA_OPT__ p1042r1 placemarker changes [PR101488] https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575621.html c++: Accept C++11 attribute-definition [PR101582] https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575897.html Thanks Jakub
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.
C++ Patch ping
Hi! I'd like to ping the: https://gcc.gnu.org/pipermail/gcc-patches/2020-December/562099.html patch. Thanks Jakub
C++ patch ping
Hi! I'd like to ping https://gcc.gnu.org/pipermail/gcc-patches/2020-November/560372.html - v3 of the __builtin_bit_cast (with (hopefully) all earlier feedback incorporated). Thanks Jakub
C++ patch ping^2
Hi! I'd like to ping the updated bit_cast patch: https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557781.html Thanks Jakub
C++ patch ping
Hi! I'd like to ping the updated bit_cast patch: https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557781.html Thanks Jakub
C++ patch ping
Hi! I'd like to ping 2 patches: - https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556370.html PR95808 - diagnose constexpr delete [] new int; and delete new int[N]; - https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556548.html PR97388 - fix up constexpr evaluation of arguments passed by invisible reference Thanks Jakub
C++ Patch ping
Hi! I'd like to ping the https://gcc.gnu.org/ml/gcc-patches/2020-March/541542.html P2 PR91993 patch If you think it is too dangerous for GCC10 and should be postponed, I can ping it after 10.1 is released, or e.g. if you think for GCC10 we should for all codes handle that way only orig_op0 and not orig_op1, I can tweak that too (in that case, unless something reorders the operands of the binary expressions, it shouldn't evaluate side-effects differently from the order we've been using in the past). Thanks Jakub
C++ Patch Ping (was Re: [C++ PATCH] Improve C++ error recovery (PR c++/59655))
Hi! On Tue, Dec 10, 2019 at 10:02:47PM +0100, Jakub Jelinek wrote: > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? > Or do you want to use an additional bit for that? > > 2019-12-10 Jakub Jelinek > > PR c++/59655 > * pt.c (push_tinst_level_loc): If limit_bad_template_recursion, > set TREE_NO_WARNING on tldcl. > * decl2.c (no_linkage_error): Treat templates with TREE_NO_WARNING > as defined during error recovery. > > * g++.dg/cpp0x/diag3.C: New test. I'd like to ping this patch (or whether you want a special bit for it in addition to TREE_NO_WARNING). Thanks. Jakub
C++ patch ping
Hi! I'd like to ping: https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00581.html PR92414, Fix error-recovery with constexpr dtor https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00808.html PR92458, Fix concepts vs. PCH Thanks. Jakub
[C++ Patch ping] Bunch of location improvements
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 early because the first time I forgot to add the C++ Patch tag. https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00063.html Cheers, Paolo.
[C++ Patch PING] Re: [C++ Patch] A few additional location improvements to grokdeclarator and check_tag_decl
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... https://gcc.gnu.org/ml/gcc-patches/2019-06/msg01391.html Thanks, Paolo.
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
,
/* 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
,
/* 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;
[C++ PATCH, PING^3] PR60531 - Wrong error about unresolved overloaded function
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 ,
/* 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 ,
/* 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 ,
/* 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 ,
/* 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;
[C++ PATCH, PING] PR60531 - Wrong error about unresolved overloaded function
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 ,
/* 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 ,
/* 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
C++ patch ping
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).
Thanks.
2018-11-21 Jakub Jelinek
PR c++/87506
* constexpr.c (adjust_temp_type): Handle EMPTY_CLASS_EXPR.
* g++.dg/cpp0x/constexpr-87506.C: New test.
--- gcc/cp/constexpr.c.jj 2018-11-16 21:35:34.551110868 +0100
+++ gcc/cp/constexpr.c 2018-11-19 09:35:06.880386449 +0100
@@ -1280,6 +1280,8 @@ adjust_temp_type (tree type, tree temp)
/* Avoid wrapping an aggregate value in a NOP_EXPR. */
if (TREE_CODE (temp) == CONSTRUCTOR)
return build_constructor (type, CONSTRUCTOR_ELTS (temp));
+ if (TREE_CODE (temp) == EMPTY_CLASS_EXPR)
+return build0 (EMPTY_CLASS_EXPR, type);
gcc_assert (scalarish_type_p (type));
return cp_fold_convert (type, temp);
}
--- gcc/testsuite/g++.dg/cpp0x/constexpr-87506.C.jj 2018-11-19
09:33:07.795341369 +0100
+++ gcc/testsuite/g++.dg/cpp0x/constexpr-87506.C2018-11-19
09:33:07.795341369 +0100
@@ -0,0 +1,12 @@
+// PR c++/87506
+// { dg-do compile { target c++11 } }
+
+struct A {};
+struct B { constexpr B (const A) {} };
+struct C : B { using B::B; };
+
+void
+foo ()
+{
+ C c (A{});
+}
Jakub
[C++ Patch PING] Re: [C++ Patch] Improve compute_array_index_type locations
Hi, gently pinging this older patch of mine: given the previous create_array_type_for_decl change, its gist should not be very controversial... On 06/11/18 10:01, Paolo Carlini wrote: Hi, when I improved create_array_type_for_decl I didn't notice that it calls compute_array_index_type as helper, which simply needs to have the location information propagated. Tested x86_64-linux. https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00331.html Thanks, Paolo.
[C++ Patch PING] Re: [C++ Patch] PR 84423 ("[6/7/8/9 Regression] [concepts] ICE with invalid using declaration")
Hi, gently pinging the below... On 29/09/18 21:27, Paolo Carlini wrote: Hi again, On 9/28/18 9:15 PM, Paolo Carlini wrote: Thanks. About the location, you are certainly right, but doesn't seem trivial. Something we can do *now* is using declspecs->locations[ds_typedef] and declspecs->locations[ds_alias], but that gives us the location of the keyword 'typedef' and 'using', respectively, whereas I think that we would like to have the location of 'auto' itself. I could look into that as a follow-up piece work In fact, completing the work turned out to be easy: ensure that cp_parser_alias_declaration saves the location of the defining-type-id too and then consistently use locations[ds_type_spec] in the error messages. Tested x86_64-linux. Still Ok? ;) https://gcc.gnu.org/ml/gcc-patches/2018-09/msg01773.html Thanks! Paolo.
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
[C++ Patch PING] [C++ Patch] PR 85065 ("[concepts] ICE with invalid use of a concept")
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...
Thanks, Paolo.
/
Index: cp/pt.c
===
--- cp/pt.c (revision 264362)
+++ cp/pt.c (working copy)
@@ -26121,7 +26121,8 @@ struct auto_hash : default_hash_traits
inline hashval_t
auto_hash::hash (tree t)
{
- if (tree c = PLACEHOLDER_TYPE_CONSTRAINTS (t))
+ tree c = PLACEHOLDER_TYPE_CONSTRAINTS (t);
+ if (c && c != error_mark_node)
/* Matching constrained-type-specifiers denote the same template
parameter, so hash the constraint. */
return hash_placeholder_constraint (c);
@@ -26880,50 +26881,53 @@ do_auto_deduction (tree type, tree init, tree auto
/* Check any placeholder constraints against the deduced type. */
if (flag_concepts && !processing_template_decl)
-if (tree constr = PLACEHOLDER_TYPE_CONSTRAINTS (auto_node))
- {
-/* Use the deduced type to check the associated constraints. If we
- have a partial-concept-id, rebuild the argument list so that
- we check using the extra arguments. */
-gcc_assert (TREE_CODE (constr) == CHECK_CONSTR);
-tree cargs = CHECK_CONSTR_ARGS (constr);
-if (TREE_VEC_LENGTH (cargs) > 1)
- {
-cargs = copy_node (cargs);
-TREE_VEC_ELT (cargs, 0) = TREE_VEC_ELT (targs, 0);
- }
-else
- cargs = targs;
-if (!constraints_satisfied_p (constr, cargs))
- {
-if (complain & tf_warning_or_error)
- {
- auto_diagnostic_group d;
-switch (context)
- {
- case adc_unspecified:
- case adc_unify:
-error("placeholder constraints not satisfied");
-break;
- case adc_variable_type:
- case adc_decomp_type:
-error ("deduced initializer does not satisfy "
- "placeholder constraints");
-break;
- case adc_return_type:
-error ("deduced return type does not satisfy "
- "placeholder constraints");
-break;
- case adc_requirement:
- error ("deduced expression type does not satisfy "
- "placeholder constraints");
-break;
- }
-diagnose_constraints (input_location, constr, targs);
- }
-return error_mark_node;
- }
- }
+{
+ tree constr = PLACEHOLDER_TYPE_CONSTRAINTS (auto_node);
+ if (constr && constr != error_mark_node)
+ {
+ /* Use the deduced type to check the associated constraints. If we
+have a partial-concept-id, rebuild the argument list so that
+we check using the extra arguments. */
+ gcc_assert (TREE_CODE (constr) == CHECK_CONSTR);
+ tree cargs = CHECK_CONSTR_ARGS (constr);
+ if (TREE_VEC_LENGTH (cargs) > 1)
+ {
+ cargs = copy_node (cargs);
+ TREE_VEC_ELT (cargs, 0) = TREE_VEC_ELT (targs, 0);
+
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
C++ patch ping
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 - 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 Jakub
C++ patch ping
Hi! I'd like to ping following patches: http://gcc.gnu.org/ml/gcc-patches/2018-01/msg02066.html - PR83993 - fix constexpr handling of arrays with unknown bound http://gcc.gnu.org/ml/gcc-patches/2018-01/msg02067.html - PR83993 - don't clear TREE_CONSTANT on ADDR_EXPRs in constexpr.c Thanks Jakub
[C++ Patch Ping] Two pending patches
Hi,
I'd like to gently point to two pending patches of mine:
The updated fix for PR 81055 ("[6/7/8 Regression] ICE with invalid
initializer for array new")
https://gcc.gnu.org/ml/gcc-patches/2017-12/msg01428.html
and also
PR 78344 ("ICE on invalid c++ code (tree check: expected tree_list,
have error_mark in cp_check_const_attributes, at cp/decl2.c:1347")
https://gcc.gnu.org/ml/gcc-patches/2017-12/msg01498.html
which seems a tad bold (but frankly I like it a lot because of that ;)
Thanks, Paolo.
C++ patch ping
Hi! I'd like to ping the: http://gcc.gnu.org/ml/gcc-patches/2017-12/msg01499.html - PR83556 fix replace_placeholders patch. Thanks. Jakub
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
[C++ Patch PING] [C++ Patch] PR 82235 (Copy ctor is not found for copying array of an object when it's marked explicit)
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
Thanks!
Paolo.
C++ patch ping
Hi! I'd like to ping two patches: http://gcc.gnu.org/ml/gcc-patches/2017-11/msg02521.html PR c++/83205 - diagnose invalid std::tuple_size::value for structured bindings; the follow-up with plural spelling is approved already http://gcc.gnu.org/ml/gcc-patches/2017-11/msg02629.html PR c++/83217 - handle references to non-complete type in structured bindings Jakub
C++ patch ping
Hi! I'd like to ping 2 C++2A patches: http://gcc.gnu.org/ml/gcc-patches/2017-09/msg01235.html P0683R1 - default member initializers for bit-fields http://gcc.gnu.org/ml/gcc-patches/2017-09/msg01237.html P0704R1 - fixing const-qualified pointers to members Thanks Jakub
C++ patch ping
Hi! I'd like to ping the http://gcc.gnu.org/ml/gcc-patches/2017-09/msg00937.html - fix compile time hog in replace_placeholders patch. Thanks Jakub
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
[C++ Patch Ping] PR 64644 (""warning: anonymous union with no members" should be an error with -pedantic-errors")
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 Thanks! Paolo.
[C++ Patch Ping] Re: [C++ Patch] PR 79790 ("[C++17] ICE class template argument deduction")
Hi, On 14/07/2017 19:51, Nathan Sidwell wrote: On 07/14/2017 01:32 PM, Paolo Carlini wrote: While working on the bug I also noticed that we can simplify a bit the code generating the implicit deduction guides: if I'm not mistaken, when we pass types as first argument of build_deduction_guide - for implicit guides, that is - the deduction guide is never explicit. thus DECL_NONCONVERTING_P is never true. It's an unrelated tweak, anyway, which we can consider applying by itself if we don't change the code generating the implicit deduction guides. I recall wondering the same thing when adding the 'elided = true' pieces, but didn't investigate enough to confirm/deny. Thanks for getting this. You are welcome! I think the rest of the patch - the bug fix proper - still awaits a review... Thanks! Paolo.
[C++ Patch PING] (was: [C++ Patch] PR 62315 ("do not print typename in diagnostic if the original code does not have it"))
Hi, gently pingning this: On 02/06/2017 10:35, Paolo Carlini wrote: Hi, a while ago Manuel noticed that printing 'typename' in error messages about missing 'typename' can be confusing. That seems easy to fix, in fact we already handle correctly a similar situation in grokdeclarator. Tested x86_64-linux. https://gcc.gnu.org/ml/gcc-patches/2017-06/msg00099.html Thanks! Paolo.
[C++ Patch Ping] Re: [C++ Patch/RFC] PR 80145
Hi,
gently pinging this...
On 23/03/2017 20:07, Paolo Carlini wrote:
Hi,
this ICE on invalid code isn't a regression, thus a patch probably
doesn't qualify for Stage 4, but IMHO I made good progress on it and
I'm sending what I have now anyway... The ICE happens during error
recovery after a sensible diagnostic for the first declaration in:
auto* foo() { return 0; }
auto* foo();
After the error, finish_function does:
apply_deduced_return_type (fndecl, void_type_node);
fntype = TREE_TYPE (fndecl);
which then is inconsistent with the auto* return type of the second
declaration and leads to an ICE in merge_types (which duplicate_decls
thought was safe to call because types_match is true (evidently:
decls_match uses fndecl_declared_return_type)). Thus, in terms of
error recovery, I think that in cases like the one at issue it makes
sense not to replace auto* after the error and leave the return type
untouched: certainly the below passes testing and avoids ICEing on the
testcase at issue and a variant of it.
Thanks,
Paolo.
C++ patch ping
Hi! I'd like to ping 2 C++ patches: - P1 PR79232 - ICEs and wrong-code with COMPOUND_EXPR on lhs of assignment http://gcc.gnu.org/ml/gcc-patches/2017-01/msg02341.html - P1 PR79288 - wrong default TLS model for __thread static data members http://gcc.gnu.org/ml/gcc-patches/2017-01/msg02349.html Thanks Jakub
C++ patch ping
Hi! I'd like to ping the PR77830 fix for out of bounds constexpr stores: https://gcc.gnu.org/ml/gcc-patches/2016-12/msg01319.html Jakub
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
C++ Patch Ping
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 patch. Thanks Jakub
C++ patch ping
Hi! I'd like to ping 3 patches from a week ago: http://gcc.gnu.org/ml/gcc-patches/2016-08/msg01995.html - PR77375 - wrong-code with mutable members in base classes http://gcc.gnu.org/ml/gcc-patches/2016-08/msg01998.html - PR77338 - fix constexpr ICE on PARM_DECL with incomplete type http://gcc.gnu.org/ml/gcc-patches/2016-08/msg02002.html - PR77379 - fix testcase mangling regexps for 32-bit targets Jakub
[C PATCH PING] PR43651: add warning for duplicate qualifier
On 04/10/2016 11:12 PM, Martin Sebor wrote: > On 04/09/2016 06:28 AM, Mikhail Maltsev wrote: >> On 04/08/2016 08:54 PM, Martin Sebor wrote: The name for new option "-Wduplicate-decl-specifier" and wording was chosen to match the same option in Clang. >>> >>> My version of Clang also warns in C++ mode but if I'm reading >>> the patch right, GCC would warn only C mode. I would find it >>> surprising if GCC provided the same option as Clang but didn't >>> make it available in the same languages. Do you have some >>> reason for leaving it out that I'm not thinking of? >> It is an error in C++ mode. Do we want to change this behavior? > > You're right, G++ does give an error. I missed it in my testing. > Unlike C11, C++ requires a diagnostic for duplicated cv-qualifiers > so by issuing a warning Clang is more permissive. My personal > inclination would be to treat this consistently between C and C++ > but whether or not to change it is something Jason would need to > weigh in on. Ping. -- Regards, Mikhail Maltsev
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 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 b;
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
OK. 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
C++ patch ping
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. Thanks Jakub
[C++ PATCH PING] Reject trailing return type for operator auto()
On 28 December 2014 at 20:21, Ville Voutilainen ville.voutilai...@gmail.com wrote: Any comments on this? Re-ping. :) The original message is https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01614.html On 19 December 2014 at 09:21, Ville Voutilainen ville.voutilai...@gmail.com wrote: Tested on Linux-x64. /cp 2014-12-19 Ville Voutilainen ville.voutilai...@gmail.com Reject trailing return type for an operator auto(). * decl.c (grokdeclarator): Reject trailing return types for all conversion operators, don't handle conversion operators in the previous checks that deal with auto. /testsuite 2014-12-19 Ville Voutilainen ville.voutilai...@gmail.com Reject trailing return type for an operator auto(). * g++.dg/cpp0x/auto9.C: Adjust.
[C++ PATCH PING] Reject trailing return type for operator auto()
Any comments on this? On 19 December 2014 at 09:21, Ville Voutilainen ville.voutilai...@gmail.com wrote: Tested on Linux-x64. /cp 2014-12-19 Ville Voutilainen ville.voutilai...@gmail.com Reject trailing return type for an operator auto(). * decl.c (grokdeclarator): Reject trailing return types for all conversion operators, don't handle conversion operators in the previous checks that deal with auto. /testsuite 2014-12-19 Ville Voutilainen ville.voutilai...@gmail.com Reject trailing return type for an operator auto(). * g++.dg/cpp0x/auto9.C: Adjust.
[C++ Patch PING] Re: [PATCH] make excessive template instantiation depth a fatal error
Hi all, hi Jason, On 08/24/2014 12:11 PM, Manuel López-Ibáñez wrote: PING: https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01709.html Today, I picked this unreviewed patch prepared by Manuel back in August and trivially completed it by adjusting the testcases (all the tweaks seem the expected ones given the patch proper, no surprises). How does it look? Thanks! Paolo. // 2014-09-30 Paolo Carlini paolo.carl...@oracle.com * g++.dg/cpp0x/decltype26.C: Adjust. * g++.dg/cpp0x/decltype28.C: Likewise. * g++.dg/cpp0x/decltype29.C: Likewise. * g++.dg/cpp0x/decltype32.C: Likewise. * g++.dg/cpp0x/enum11.C: Likewise. * g++.dg/template/arrow1.C: Likewise. * g++.dg/template/pr23510.C: Likewise. * g++.dg/template/recurse.C: Likewise. * g++.dg/template/recurse2.C: Likewise. * g++.dg/template/vtable2.C: Likewise. * g++.old-deja/g++.pt/infinite1.C: Likewise.
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_alloctinst_level ();
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
@@ -20291,10
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
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 ja...@redhat.com wrote: OK. Jason
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.
[C++ Patch ping] Re: [C++ Patch] PR 59165 (aka Core/1442)
Hi, assuming I didn't miss anything (I'm still catching up with my emails), I'd like to ping the below. Thanks! Paolo. /// On 12/10/2013 01:54 PM, Paolo Carlini wrote: Hi, as far as I can see, this bug asks for the implementation of Core/1442, thus don't do a special Koenig lookup including namespace std in cp_parser_perform_range_for_lookup. Tested x86_64-linux. Thanks, Paolo. /
[C++ Patch Ping] PR 58724
Hi, http://gcc.gnu.org/ml/gcc-patches/2013-10/msg01166.html Thanks! Paolo.
[C++ Patch Ping] PR 54485 (diagnose default arguments in out-of-line definitions for class template member functions)
Hi, pinging this patch of mine, sent beginning of September: http://gcc.gnu.org/ml/gcc-patches/2013-08/msg01435.html Just checked that it still applies cleanly and passes testing. Thanks! Paolo.
[C++ Patch PING] PR 54526 (again)
Hi, I'd like to ping this recent patch of mine: http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02509.html Thanks! Paolo.
[C++ Patch PING] PR 53761
Hi, I'm pinging this patchlet: http://gcc.gnu.org/ml/gcc-patches/2012-10/msg01013.html For sure not an high priority issue, neither I can say to fully understand whether in C++ we can and should have the exact same semantics of the __transparent_union__ attribute in C, but I think that it would be good to decide one way or the other what we want to do and resolve the issue. Thanks! Paolo.
