C++ Patch ping

C++ Patch ping

[Jakub Jelinek]

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^2

[Jakub Jelinek]

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

[Jakub Jelinek]

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

[Jakub Jelinek]

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

[Jakub Jelinek]

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

[Jakub Jelinek]

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

[Jason Merrill]

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

[Jakub Jelinek]

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

[Jason Merrill]

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

[Jakub Jelinek]

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

[Jakub Jelinek]

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

[Jakub Jelinek]

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

[Jason Merrill]

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

[Jakub Jelinek]

Hi!

I'd like to ping the:
https://gcc.gnu.org/pipermail/gcc-patches/2020-December/562099.html
patch.

Thanks

	Jakub

C++ patch ping

[Jakub Jelinek]

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

[Jakub Jelinek]

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

[Jakub Jelinek]

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

[Jakub Jelinek]

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

[Jakub Jelinek]

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

Re: C++ patch ping

[Jason Merrill]

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

[Jakub Jelinek]

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

Re: C++ patch ping

[Jakub Jelinek]

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

[Nathan Sidwell]

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

[Nathan Sidwell]

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

[Jakub Jelinek]

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

[Jakub Jelinek]

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

[Jakub Jelinek]

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

C++ patch ping

[Jakub Jelinek]

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

C++ patch ping

[Jakub Jelinek]

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

[Jakub Jelinek]

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

C++ patch ping

[Jakub Jelinek]

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

[Jakub Jelinek]

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

[Nathan Sidwell]

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

[Jakub Jelinek]

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

[Nathan Sidwell]

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

[Jakub Jelinek]

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

[Jakub Jelinek]

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

Re: C++ patch ping

[Jason Merrill]

OK.

Jason

Re: C++ patch ping

[Jakub Jelinek]

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

Re: C++ patch ping

[Jason Merrill]

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

[Jakub Jelinek]

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

[Jason Merrill]

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

[Nathan Sidwell]

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

[Jakub Jelinek]

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

Re: C++ patch ping

[Mark Mitchell]

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

Re: C++ patch ping

[Jakub Jelinek]

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

Re: C++ patch ping

[Mark Mitchell]

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

C++ patch ping

[Jakub Jelinek]

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

Re: C++ patch ping

[Mark Mitchell]

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

C++ patch ping

[Giovanni Bajo]

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