* C++ patch ping
@ 2019-11-18 15:32 Jakub Jelinek
0 siblings, 0 replies; 49+ messages in thread
From: Jakub Jelinek @ 2019-11-18 15:32 UTC (permalink / raw)
To: Jason Merrill; +Cc: gcc-patches
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
^ permalink raw reply [flat|nested] 49+ messages in thread
* C++ Patch ping
@ 2024-04-03 9:48 Jakub Jelinek
0 siblings, 0 replies; 49+ messages in thread
From: Jakub Jelinek @ 2024-04-03 9:48 UTC (permalink / raw)
To: Jason Merrill; +Cc: gcc-patches
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
^ permalink raw reply [flat|nested] 49+ messages in thread
* C++ Patch ping
2024-03-08 8:56 [PATCH] c++: Fix constexpr evaluation of parameters passed by invisible reference [PR111284] Jakub Jelinek
@ 2024-03-25 18:27 ` Jakub Jelinek
0 siblings, 0 replies; 49+ messages in thread
From: Jakub Jelinek @ 2024-03-25 18:27 UTC (permalink / raw)
To: Jason Merrill; +Cc: gcc-patches
Hi!
I'd like to ping the
https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647445.html
PR111284 P2 patch.
Thanks.
Jakub
^ permalink raw reply [flat|nested] 49+ messages in thread
* C++ patch ping
@ 2024-03-06 14:12 Jakub Jelinek
0 siblings, 0 replies; 49+ messages in thread
From: Jakub Jelinek @ 2024-03-06 14:12 UTC (permalink / raw)
To: Jason Merrill; +Cc: gcc-patches
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
^ permalink raw reply [flat|nested] 49+ messages in thread
* C++ patch ping
@ 2023-09-19 7:19 Jakub Jelinek
0 siblings, 0 replies; 49+ messages in thread
From: Jakub Jelinek @ 2023-09-19 7:19 UTC (permalink / raw)
To: Jason Merrill; +Cc: gcc-patches
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
^ permalink raw reply [flat|nested] 49+ messages in thread
* C++ patch ping
@ 2022-03-02 9:46 Jakub Jelinek
0 siblings, 0 replies; 49+ messages in thread
From: Jakub Jelinek @ 2022-03-02 9:46 UTC (permalink / raw)
To: Jason Merrill; +Cc: gcc-patches
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
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ patch ping
2021-09-01 20:11 ` Jakub Jelinek
@ 2021-09-01 21:46 ` Jason Merrill
0 siblings, 0 replies; 49+ messages in thread
From: Jason Merrill @ 2021-09-01 21:46 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: gcc-patches
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
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ patch ping
2021-09-01 19:25 ` Jason Merrill
@ 2021-09-01 20:11 ` Jakub Jelinek
2021-09-01 21:46 ` Jason Merrill
0 siblings, 1 reply; 49+ messages in thread
From: Jakub Jelinek @ 2021-09-01 20:11 UTC (permalink / raw)
To: Jason Merrill; +Cc: gcc-patches
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
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ patch ping
2021-08-30 7:11 Jakub Jelinek
@ 2021-09-01 19:25 ` Jason Merrill
2021-09-01 20:11 ` Jakub Jelinek
0 siblings, 1 reply; 49+ messages in thread
From: Jason Merrill @ 2021-09-01 19:25 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: gcc-patches
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
^ permalink raw reply [flat|nested] 49+ messages in thread
* C++ patch ping
@ 2021-08-30 7:11 Jakub Jelinek
2021-09-01 19:25 ` Jason Merrill
0 siblings, 1 reply; 49+ messages in thread
From: Jakub Jelinek @ 2021-08-30 7:11 UTC (permalink / raw)
To: Jason Merrill; +Cc: gcc-patches
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
^ permalink raw reply [flat|nested] 49+ messages in thread
* C++ Patch ping
@ 2021-08-16 17:37 Jakub Jelinek
0 siblings, 0 replies; 49+ messages in thread
From: Jakub Jelinek @ 2021-08-16 17:37 UTC (permalink / raw)
To: Jason Merrill; +Cc: gcc-patches
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
^ permalink raw reply [flat|nested] 49+ messages in thread
* C++ Patch ping
@ 2021-07-27 16:09 Jakub Jelinek
0 siblings, 0 replies; 49+ messages in thread
From: Jakub Jelinek @ 2021-07-27 16:09 UTC (permalink / raw)
To: Jason Merrill; +Cc: gcc-patches
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
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ Patch ping
2021-01-05 16:34 Jakub Jelinek
@ 2021-01-05 20:53 ` Jason Merrill
0 siblings, 0 replies; 49+ messages in thread
From: Jason Merrill @ 2021-01-05 20:53 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: gcc-patches
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.
^ permalink raw reply [flat|nested] 49+ messages in thread
* C++ Patch ping
@ 2021-01-05 16:34 Jakub Jelinek
2021-01-05 20:53 ` Jason Merrill
0 siblings, 1 reply; 49+ messages in thread
From: Jakub Jelinek @ 2021-01-05 16:34 UTC (permalink / raw)
To: Jason Merrill; +Cc: gcc-patches
Hi!
I'd like to ping the:
https://gcc.gnu.org/pipermail/gcc-patches/2020-December/562099.html
patch.
Thanks
Jakub
^ permalink raw reply [flat|nested] 49+ messages in thread
* C++ patch ping
@ 2020-12-03 13:59 Jakub Jelinek
0 siblings, 0 replies; 49+ messages in thread
From: Jakub Jelinek @ 2020-12-03 13:59 UTC (permalink / raw)
To: Jason Merrill; +Cc: gcc-patches
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
^ permalink raw reply [flat|nested] 49+ messages in thread
* C++ patch ping
@ 2020-11-09 19:24 Jakub Jelinek
0 siblings, 0 replies; 49+ messages in thread
From: Jakub Jelinek @ 2020-11-09 19:24 UTC (permalink / raw)
To: Jason Merrill; +Cc: gcc-patches
Hi!
I'd like to ping the updated bit_cast patch:
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557781.html
Thanks
Jakub
^ permalink raw reply [flat|nested] 49+ messages in thread
* C++ patch ping
@ 2020-10-29 14:14 Jakub Jelinek
0 siblings, 0 replies; 49+ messages in thread
From: Jakub Jelinek @ 2020-10-29 14:14 UTC (permalink / raw)
To: Jason Merrill; +Cc: gcc-patches
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
^ permalink raw reply [flat|nested] 49+ messages in thread
* C++ Patch ping
@ 2020-03-16 15:45 Jakub Jelinek
0 siblings, 0 replies; 49+ messages in thread
From: Jakub Jelinek @ 2020-03-16 15:45 UTC (permalink / raw)
To: Jason Merrill; +Cc: gcc-patches
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
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ patch ping
2018-12-04 14:47 C++ patch ping Jakub Jelinek
@ 2018-12-06 21:43 ` Jason Merrill
0 siblings, 0 replies; 49+ messages in thread
From: Jason Merrill @ 2018-12-06 21:43 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: gcc-patches
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
^ permalink raw reply [flat|nested] 49+ messages in thread
* C++ patch ping
@ 2018-12-04 14:47 Jakub Jelinek
2018-12-06 21:43 ` Jason Merrill
0 siblings, 1 reply; 49+ messages in thread
From: Jakub Jelinek @ 2018-12-04 14:47 UTC (permalink / raw)
To: Jason Merrill; +Cc: gcc-patches
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 <jakub@redhat.com>
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.C 2018-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
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ patch ping
2018-07-13 16:24 ` Nathan Sidwell
@ 2018-07-13 16:53 ` Jakub Jelinek
0 siblings, 0 replies; 49+ messages in thread
From: Jakub Jelinek @ 2018-07-13 16:53 UTC (permalink / raw)
To: Nathan Sidwell; +Cc: Jason Merrill, gcc-patches
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
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ patch ping
2018-07-13 13:49 Jakub Jelinek
2018-07-13 16:24 ` Nathan Sidwell
@ 2018-07-13 16:42 ` Nathan Sidwell
1 sibling, 0 replies; 49+ messages in thread
From: Nathan Sidwell @ 2018-07-13 16:42 UTC (permalink / raw)
To: Jakub Jelinek, Jason Merrill; +Cc: gcc-patches
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
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ patch ping
2018-07-13 13:49 Jakub Jelinek
@ 2018-07-13 16:24 ` Nathan Sidwell
2018-07-13 16:53 ` Jakub Jelinek
2018-07-13 16:42 ` Nathan Sidwell
1 sibling, 1 reply; 49+ messages in thread
From: Nathan Sidwell @ 2018-07-13 16:24 UTC (permalink / raw)
To: Jakub Jelinek, Jason Merrill; +Cc: gcc-patches
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
^ permalink raw reply [flat|nested] 49+ messages in thread
* C++ patch ping
@ 2018-07-13 13:49 Jakub Jelinek
2018-07-13 16:24 ` Nathan Sidwell
2018-07-13 16:42 ` Nathan Sidwell
0 siblings, 2 replies; 49+ messages in thread
From: Jakub Jelinek @ 2018-07-13 13:49 UTC (permalink / raw)
To: Jason Merrill, Nathan Sidwell; +Cc: gcc-patches
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
^ permalink raw reply [flat|nested] 49+ messages in thread
* C++ patch ping
@ 2018-01-31 16:05 Jakub Jelinek
0 siblings, 0 replies; 49+ messages in thread
From: Jakub Jelinek @ 2018-01-31 16:05 UTC (permalink / raw)
To: Jason Merrill, Nathan Sidwell; +Cc: gcc-patches
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
^ permalink raw reply [flat|nested] 49+ messages in thread
* C++ patch ping
@ 2018-01-02 15:12 Jakub Jelinek
0 siblings, 0 replies; 49+ messages in thread
From: Jakub Jelinek @ 2018-01-02 15:12 UTC (permalink / raw)
To: Jason Merrill, Nathan Sidwell; +Cc: gcc-patches
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
^ permalink raw reply [flat|nested] 49+ messages in thread
* C++ patch ping
@ 2017-12-08 13:42 Jakub Jelinek
0 siblings, 0 replies; 49+ messages in thread
From: Jakub Jelinek @ 2017-12-08 13:42 UTC (permalink / raw)
To: Jason Merrill, Nathan Sidwell; +Cc: gcc-patches
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<X>::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
^ permalink raw reply [flat|nested] 49+ messages in thread
* C++ patch ping
@ 2017-09-27 10:05 Jakub Jelinek
0 siblings, 0 replies; 49+ messages in thread
From: Jakub Jelinek @ 2017-09-27 10:05 UTC (permalink / raw)
To: Jason Merrill, Nathan Sidwell; +Cc: gcc-patches
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
^ permalink raw reply [flat|nested] 49+ messages in thread
* C++ patch ping
@ 2017-09-22 14:36 Jakub Jelinek
0 siblings, 0 replies; 49+ messages in thread
From: Jakub Jelinek @ 2017-09-22 14:36 UTC (permalink / raw)
To: Jason Merrill, Nathan Sidwell; +Cc: gcc-patches
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
^ permalink raw reply [flat|nested] 49+ messages in thread
* C++ patch ping
@ 2017-02-06 14:13 Jakub Jelinek
0 siblings, 0 replies; 49+ messages in thread
From: Jakub Jelinek @ 2017-02-06 14:13 UTC (permalink / raw)
To: Jason Merrill; +Cc: gcc-patches
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
^ permalink raw reply [flat|nested] 49+ messages in thread
* C++ patch ping
@ 2016-12-21 11:50 Jakub Jelinek
0 siblings, 0 replies; 49+ messages in thread
From: Jakub Jelinek @ 2016-12-21 11:50 UTC (permalink / raw)
To: Jason Merrill; +Cc: gcc-patches
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
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ Patch Ping
2016-12-15 12:38 ` Jakub Jelinek
@ 2016-12-15 12:48 ` Nathan Sidwell
0 siblings, 0 replies; 49+ messages in thread
From: Nathan Sidwell @ 2016-12-15 12:48 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: Jason Merrill, gcc-patches
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
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ Patch Ping
2016-12-15 12:26 ` Nathan Sidwell
@ 2016-12-15 12:38 ` Jakub Jelinek
2016-12-15 12:48 ` Nathan Sidwell
0 siblings, 1 reply; 49+ messages in thread
From: Jakub Jelinek @ 2016-12-15 12:38 UTC (permalink / raw)
To: Nathan Sidwell; +Cc: Jason Merrill, gcc-patches
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
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ Patch Ping
2016-12-15 8:38 C++ Patch Ping Jakub Jelinek
@ 2016-12-15 12:26 ` Nathan Sidwell
2016-12-15 12:38 ` Jakub Jelinek
0 siblings, 1 reply; 49+ messages in thread
From: Nathan Sidwell @ 2016-12-15 12:26 UTC (permalink / raw)
To: Jakub Jelinek, Jason Merrill; +Cc: gcc-patches
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
^ permalink raw reply [flat|nested] 49+ messages in thread
* C++ Patch Ping
@ 2016-12-15 8:38 Jakub Jelinek
2016-12-15 12:26 ` Nathan Sidwell
0 siblings, 1 reply; 49+ messages in thread
From: Jakub Jelinek @ 2016-12-15 8:38 UTC (permalink / raw)
To: Jason Merrill; +Cc: gcc-patches
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
^ permalink raw reply [flat|nested] 49+ messages in thread
* C++ patch ping
@ 2016-09-05 15:13 Jakub Jelinek
0 siblings, 0 replies; 49+ messages in thread
From: Jakub Jelinek @ 2016-09-05 15:13 UTC (permalink / raw)
To: Jason Merrill; +Cc: gcc-patches
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
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ patch ping
2016-01-11 23:53 ` Jakub Jelinek
@ 2016-01-12 5:21 ` Jason Merrill
0 siblings, 0 replies; 49+ messages in thread
From: Jason Merrill @ 2016-01-12 5:21 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: Nathan Sidwell, gcc-patches
OK.
Jason
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ patch ping
2016-01-11 22:04 ` Jason Merrill
@ 2016-01-11 23:53 ` Jakub Jelinek
2016-01-12 5:21 ` Jason Merrill
0 siblings, 1 reply; 49+ messages in thread
From: Jakub Jelinek @ 2016-01-11 23:53 UTC (permalink / raw)
To: Jason Merrill; +Cc: Nathan Sidwell, gcc-patches
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 <jakub@redhat.com>
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 <typename T>
+struct B
+{
+ static int *& foo () { static __thread int *c = 0; return c; }
+};
+
+B<A> 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 <typename>
+class A {
+ int *b = foo ();
+ int *foo () { static __thread int a; return &a; }
+};
+A<int> b;
Jakub
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ patch ping
2016-01-11 21:52 ` Jakub Jelinek
@ 2016-01-11 22:04 ` Jason Merrill
2016-01-11 23:53 ` Jakub Jelinek
0 siblings, 1 reply; 49+ messages in thread
From: Jason Merrill @ 2016-01-11 22:04 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: Nathan Sidwell, gcc-patches
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
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ patch ping
2016-01-11 21:45 ` Jason Merrill
@ 2016-01-11 21:52 ` Jakub Jelinek
2016-01-11 22:04 ` Jason Merrill
0 siblings, 1 reply; 49+ messages in thread
From: Jakub Jelinek @ 2016-01-11 21:52 UTC (permalink / raw)
To: Jason Merrill; +Cc: Nathan Sidwell, gcc-patches
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
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ patch ping
2016-01-11 20:01 ` Nathan Sidwell
@ 2016-01-11 21:45 ` Jason Merrill
2016-01-11 21:52 ` Jakub Jelinek
0 siblings, 1 reply; 49+ messages in thread
From: Jason Merrill @ 2016-01-11 21:45 UTC (permalink / raw)
To: Nathan Sidwell, Jakub Jelinek; +Cc: gcc-patches
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
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ patch ping
2016-01-09 7:41 Jakub Jelinek
@ 2016-01-11 20:01 ` Nathan Sidwell
2016-01-11 21:45 ` Jason Merrill
0 siblings, 1 reply; 49+ messages in thread
From: Nathan Sidwell @ 2016-01-11 20:01 UTC (permalink / raw)
To: Jakub Jelinek, Jason Merrill; +Cc: gcc-patches
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
^ permalink raw reply [flat|nested] 49+ messages in thread
* C++ patch ping
@ 2016-01-09 7:41 Jakub Jelinek
2016-01-11 20:01 ` Nathan Sidwell
0 siblings, 1 reply; 49+ messages in thread
From: Jakub Jelinek @ 2016-01-09 7:41 UTC (permalink / raw)
To: Jason Merrill; +Cc: gcc-patches
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
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ patch ping
2008-04-28 20:43 ` Jakub Jelinek
@ 2008-04-28 20:59 ` Mark Mitchell
0 siblings, 0 replies; 49+ messages in thread
From: Mark Mitchell @ 2008-04-28 20:59 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: Jason Merrill, gcc-patches
Jakub Jelinek wrote:
> So, if I should use error_operand_p instead, I guess it should be changed
> consistently for all 3 cases, or none.
Oh, I see. My brain's being a little dumb. Yes, we can rely on
cp_build_modify_expr to return an error_mark_node on error, and in that
case it's fine as is. So, go with your original patch.
Thanks,
--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ patch ping
2008-04-28 20:43 ` Mark Mitchell
@ 2008-04-28 20:43 ` Jakub Jelinek
2008-04-28 20:59 ` Mark Mitchell
0 siblings, 1 reply; 49+ messages in thread
From: Jakub Jelinek @ 2008-04-28 20:43 UTC (permalink / raw)
To: Mark Mitchell; +Cc: Jason Merrill, gcc-patches
On Mon, Apr 28, 2008 at 10:06:35AM -0700, Mark Mitchell wrote:
> Jakub Jelinek wrote:
>
> >- http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01609.html PR c++/35650
>
> I think this patch is OK. As you say, we could also change
Thanks.
> >- http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01559.html PR c++/35987
>
> This is OK, too, though I would prefer using error_operand_p to the
> direct comparision with error_mark_node. In this case, error_mark_node
> is probably correct -- but using error_operand_p for expressions is more
> mnemonic.
cp_build_modify_expr starts with:
/* Avoid duplicate error messages from operands that had errors. */
if (error_operand_p (lhs) || error_operand_p (rhs))
return error_mark_node;
so it should turn many results
res != error_mark_node && TREE_TYPE (res) == error_mark_node
into error_mark_node. And the following cases also use direct
error_mark_node comparison:
/* Handle (a, b) used as an "lvalue". */
case COMPOUND_EXPR:
newrhs = cp_build_modify_expr (TREE_OPERAND (lhs, 1),
modifycode, rhs, complain);
if (newrhs == error_mark_node)
^^^^ here
return error_mark_node;
return build2 (COMPOUND_EXPR, lhstype,
TREE_OPERAND (lhs, 0), newrhs);
case MODIFY_EXPR:
if (TREE_SIDE_EFFECTS (TREE_OPERAND (lhs, 0)))
lhs = build2 (TREE_CODE (lhs), TREE_TYPE (lhs),
stabilize_reference (TREE_OPERAND (lhs, 0)),
TREE_OPERAND (lhs, 1));
newrhs = cp_build_modify_expr (TREE_OPERAND (lhs, 0), modifycode, rhs,
complain);
if (newrhs == error_mark_node)
^^^^ and here
return error_mark_node;
return build2 (COMPOUND_EXPR, lhstype, lhs, newrhs);
(and later code in the function does similarly).
So, if I should use error_operand_p instead, I guess it should be changed
consistently for all 3 cases, or none.
Jakub
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ patch ping
2008-04-28 20:18 Jakub Jelinek
@ 2008-04-28 20:43 ` Mark Mitchell
2008-04-28 20:43 ` Jakub Jelinek
0 siblings, 1 reply; 49+ messages in thread
From: Mark Mitchell @ 2008-04-28 20:43 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: Jason Merrill, gcc-patches
Jakub Jelinek wrote:
> - http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01609.html PR c++/35650
I think this patch is OK. As you say, we could also change
reference_binding or initialize_reference, but the general policy in the
front end has been to resolve single OVERLOADs at the point of lookup.
In fact, if we were you going to make a more substantial change here, it
would probably be to have the USING_DECL record only a FUNCTION_DECL,
rather than an OVERLOAD.
> - http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01559.html PR c++/35987
This is OK, too, though I would prefer using error_operand_p to the
direct comparision with error_mark_node. In this case, error_mark_node
is probably correct -- but using error_operand_p for expressions is more
mnemonic.
Thanks,
--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713
^ permalink raw reply [flat|nested] 49+ messages in thread
* C++ patch ping
@ 2008-04-28 20:18 Jakub Jelinek
2008-04-28 20:43 ` Mark Mitchell
0 siblings, 1 reply; 49+ messages in thread
From: Jakub Jelinek @ 2008-04-28 20:18 UTC (permalink / raw)
To: Jason Merrill, Mark Mitchell; +Cc: gcc-patches
Hi!
- http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01609.html PR c++/35650
- http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01559.html PR c++/35987
Jakub
^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ patch ping
2005-02-11 14:44 Giovanni Bajo
@ 2005-02-18 12:21 ` Mark Mitchell
0 siblings, 0 replies; 49+ messages in thread
From: Mark Mitchell @ 2005-02-18 12:21 UTC (permalink / raw)
To: Giovanni Bajo; +Cc: gcc-patches
Giovanni Bajo wrote:
> Hello,
>
> [PR19508] Do not apply attributes to template parms
> http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01325.html
>
> OK with the suggested modification (sorry() instead of warning())?
OK.
--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304
^ permalink raw reply [flat|nested] 49+ messages in thread
* C++ patch ping
@ 2005-02-11 14:44 Giovanni Bajo
2005-02-18 12:21 ` Mark Mitchell
0 siblings, 1 reply; 49+ messages in thread
From: Giovanni Bajo @ 2005-02-11 14:44 UTC (permalink / raw)
To: gcc-patches; +Cc: Mark Mitchell
Hello,
[PR19508] Do not apply attributes to template parms
http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01325.html
OK with the suggested modification (sorry() instead of warning())?
Giovanni Bajo
^ permalink raw reply [flat|nested] 49+ messages in thread
end of thread, other threads:[~2024-04-03 9:48 UTC | newest]
Thread overview: 49+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-11-18 15:32 C++ patch ping Jakub Jelinek
-- strict thread matches above, loose matches on Subject: below --
2024-04-03 9:48 C++ Patch ping Jakub Jelinek
2024-03-08 8:56 [PATCH] c++: Fix constexpr evaluation of parameters passed by invisible reference [PR111284] Jakub Jelinek
2024-03-25 18:27 ` C++ Patch ping Jakub Jelinek
2024-03-06 14:12 C++ patch ping Jakub Jelinek
2023-09-19 7:19 Jakub Jelinek
2022-03-02 9:46 Jakub Jelinek
2021-08-30 7:11 Jakub Jelinek
2021-09-01 19:25 ` Jason Merrill
2021-09-01 20:11 ` Jakub Jelinek
2021-09-01 21:46 ` Jason Merrill
2021-08-16 17:37 C++ Patch ping Jakub Jelinek
2021-07-27 16:09 Jakub Jelinek
2021-01-05 16:34 Jakub Jelinek
2021-01-05 20:53 ` Jason Merrill
2020-12-03 13:59 C++ patch ping Jakub Jelinek
2020-11-09 19:24 Jakub Jelinek
2020-10-29 14:14 Jakub Jelinek
2020-03-16 15:45 C++ Patch ping Jakub Jelinek
2018-12-04 14:47 C++ patch ping Jakub Jelinek
2018-12-06 21:43 ` Jason Merrill
2018-07-13 13:49 Jakub Jelinek
2018-07-13 16:24 ` Nathan Sidwell
2018-07-13 16:53 ` Jakub Jelinek
2018-07-13 16:42 ` Nathan Sidwell
2018-01-31 16:05 Jakub Jelinek
2018-01-02 15:12 Jakub Jelinek
2017-12-08 13:42 Jakub Jelinek
2017-09-27 10:05 Jakub Jelinek
2017-09-22 14:36 Jakub Jelinek
2017-02-06 14:13 Jakub Jelinek
2016-12-21 11:50 Jakub Jelinek
2016-12-15 8:38 C++ Patch Ping Jakub Jelinek
2016-12-15 12:26 ` Nathan Sidwell
2016-12-15 12:38 ` Jakub Jelinek
2016-12-15 12:48 ` Nathan Sidwell
2016-09-05 15:13 C++ patch ping Jakub Jelinek
2016-01-09 7:41 Jakub Jelinek
2016-01-11 20:01 ` Nathan Sidwell
2016-01-11 21:45 ` Jason Merrill
2016-01-11 21:52 ` Jakub Jelinek
2016-01-11 22:04 ` Jason Merrill
2016-01-11 23:53 ` Jakub Jelinek
2016-01-12 5:21 ` Jason Merrill
2008-04-28 20:18 Jakub Jelinek
2008-04-28 20:43 ` Mark Mitchell
2008-04-28 20:43 ` Jakub Jelinek
2008-04-28 20:59 ` Mark Mitchell
2005-02-11 14:44 Giovanni Bajo
2005-02-18 12:21 ` Mark Mitchell
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).