C++ patch ping

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]

I'd like to ping 18 C++ patches:

https://gcc.gnu.org/pipermail/gcc-patches/2024-July/658137.html
  libcpp, c++: Optimize initializers using #embed in C++

https://gcc.gnu.org/pipermail/gcc-patches/2024-August/659333.html
  c++: Speed up compilation of large char array initializers when not using #embed

https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662507.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662750.html
  CWG 2867 - Order of initialization for structured bindings - rest of implementation [PR115769]

https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661904.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661905.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661906.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662330.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662331.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662333.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662334.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662336.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662379.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662380.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662381.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662545.html
  P2552R3 - On the ignorability of standard attributes - series [PR110345]

https://gcc.gnu.org/pipermail/gcc-patches/2024-September/663390.html
  Use type_id_in_expr_sentinel in 6 further spots in the parser

https://gcc.gnu.org/pipermail/gcc-patches/2024-August/659836.html
  c++: Attempt to implement C++26 P3034R1 - Module Declarations Shouldn't be Macros [PR114461]

Thanks

	Jakub

C++ patch ping

[Jakub Jelinek]

Hi!

I'd like to ping 16 C++ patches:

https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662507.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662750.html
  CWG 2867 - Order of initialization for structured bindings - rest of implementation [PR115769]

https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661904.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661905.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661906.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662330.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662331.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662333.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662334.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662336.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662379.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662380.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662381.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662545.html
  P2552R3 - On the ignorability of standard attributes - series [PR110345]

https://gcc.gnu.org/pipermail/gcc-patches/2024-September/663390.html
  Use type_id_in_expr_sentinel in 6 further spots in the parser

https://gcc.gnu.org/pipermail/gcc-patches/2024-August/659836.html
  c++: Attempt to implement C++26 P3034R1 - Module Declarations Shouldn't be Macros [PR114461]

	Jakub

C++ patch ping

[Jakub Jelinek]

Hi!

I'd like to ping 16 C++ patches:

https://gcc.gnu.org/pipermail/gcc-patches/2024-August/660046.html
  c++: Implement C++23 P2718R0 - Wording for P2644R1 Fix for Range-based for Loop [PR107637]

https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662507.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662750.html
  CWG 2867 - Order of initialization for structured bindings - rest of implementation [PR115769]

https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661904.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661905.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661906.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662330.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662331.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662333.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662334.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662336.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662379.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662380.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662381.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662545.html
  P2552R3 - On the ignorability of standard attributes - series [PR110345]

https://gcc.gnu.org/pipermail/gcc-patches/2024-August/659836.html
  c++: Attempt to implement C++26 P3034R1 - Module Declarations Shouldn't be Macros [PR114461]

Thanks

	Jakub

C++ patch ping

[Jakub Jelinek]

Hi!

I'd like to ping 2 patches:

https://gcc.gnu.org/pipermail/gcc-patches/2024-August/660046.html
  c++: Implement C++23 P2718R0 - Wording for P2644R1 Fix for Range-based for Loop [PR107637]

https://gcc.gnu.org/pipermail/gcc-patches/2024-August/659836.html
  c++: Attempt to implement C++26 P3034R1 - Module Declarations Shouldn't be Macros [PR114461]

Thanks

	Jakub

C++ Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping the
https://gcc.gnu.org/pipermail/gcc-patches/2024-July/thread.html#656299
patch.

Jonathan has acked the libstdc++ side thereof (I've added the
requested #undef on my side), is the c-cppbuiltin.cc side ok for trunk?

And, shall we (incrementally or right away) add some new tree to represent
the new expressions so that constant evaluation can do the required
diagnostics?

Thanks.

On Wed, Jul 03, 2024 at 04:37:00PM +0200, Jakub Jelinek wrote:
> 2024-07-03  Jakub Jelinek  <jakub@redhat.com>
> 
> 	PR c++/115744
> gcc/c-family/
> 	* c-cppbuiltin.cc (c_cpp_builtins): Change __cpp_constexpr
> 	from 202306L to 202406L for C++26.
> gcc/testsuite/
> 	* g++.dg/cpp2a/construct_at.h (operator new, operator new[]):
> 	Use constexpr instead of inline if __cpp_constexpr >= 202406L.
> 	* g++.dg/cpp26/constexpr-new1.C: New test.
> 	* g++.dg/cpp26/constexpr-new2.C: New test.
> 	* g++.dg/cpp26/constexpr-new3.C: New test.
> 	* g++.dg/cpp26/feat-cxx26.C (__cpp_constexpr): Adjust expected
> 	value.
> libstdc++-v3/
> 	* libsupc++/new (__glibcxx_want_constexpr_new): Define before
> 	including bits/version.h.
> 	(_GLIBCXX_PLACEMENT_CONSTEXPR): Define.
> 	(operator new, operator new[]): Use it for placement new instead
> 	of inline.
> 	* include/bits/version.def (constexpr_new): New FTM.
> 	* include/bits/version.h: Regenerate.

	Jakub

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

[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 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