On Fri, 2 Aug 2024, Jonathan Wakely wrote:
> On Fri, 2 Aug 2024 at 10:35, Giuseppe D'Angelo wrote:
> >
> > Hello,
> >
> > On 31/07/2024 00:55, Jonathan Wakely wrote:
> > > If __cpp_lib_is_virtual_base_of depends on __has_builtin, then that
> > > will do the right thing for #ifdef __cpp_lib_is_virt
On Fri, 2 Aug 2024, Jonathan Wakely wrote:
> On Fri, 2 Aug 2024 at 10:35, Giuseppe D'Angelo wrote:
> >
> > Hello,
> >
> > On 31/07/2024 00:55, Jonathan Wakely wrote:
> > > If __cpp_lib_is_virtual_base_of depends on __has_builtin, then that
> > > will do the right thing for #ifdef __cpp_lib_is_virt
https://gcc.gnu.org/g:9fc5b8f956948e069d9b69ceed7316940bc798e2
commit r15-4087-g9fc5b8f956948e069d9b69ceed7316940bc798e2
Author: Giuseppe D'Angelo
Date: Mon Jul 29 19:23:54 2024 +0200
libstdc++: add std::is_virtual_base_of
Added by P2985R0 for C++26. This simply exposes the compil
https://gcc.gnu.org/g:7c0d1e9f2a2f1d41d9eb755c36c871d92638c4b7
commit r15-4086-g7c0d1e9f2a2f1d41d9eb755c36c871d92638c4b7
Author: Patrick Palka
Date: Sat Oct 5 13:48:06 2024 -0400
libstdc++: Implement LWG 3664 changes to ranges::distance
libstdc++-v3/ChangeLog
Tested on x86_64-pc-linux-gnu, does this look OK for trunk/backports?
-- >8 --
libstdc++-v3/ChangeLog:
* include/bits/ranges_base.h (__distance_fn::operator()):
Adjust iterator/sentinel overloads as per LWG 3664.
* testsuite/24_iterators/range_operations/distance.cc:
Tested on x86_64-pc-linux-gnu, does this look OK for trunk/backports?
-- >8 --
libstdc++-v3/ChangeLog:
* include/bits/ranges_base.h (__distance_fn::operator()):
Adjust iterator/sentinel overloads as per LWG 3664.
* testsuite/24_iterators/range_operations/distance.cc:
On Thu, 3 Oct 2024, Jason Merrill wrote:
> On 10/3/24 12:38 PM, Jason Merrill wrote:
> > On 10/2/24 7:50 AM, Richard Biener wrote:
> > > This reduces peak memory usage by 20% for a specific testcase.
> > >
> > > Bootstrapped and tested on x86_64-unknown-linux-gnu.
> > >
> > > It's very ugly so I
https://gcc.gnu.org/g:20165d0107abd0f839f2519818b904f029f4ae55
commit r15-4070-g20165d0107abd0f839f2519818b904f029f4ae55
Author: Patrick Palka
Date: Fri Oct 4 10:01:39 2024 -0400
libstdc++/ranges: Implement various small LWG issues
This implements the following small LWG issues
Tested on x86_64-pc-linux-gnu, does this look OK for trunk/14 and perhaps
13?
-- >8 --
This implements the following small LWG issues:
3848. adjacent_view, adjacent_transform_view and slide_view missing base
accessor
3851. chunk_view::inner-iterator missing custom iter_move and iter_swap
Tested on x86_64-pc-linux-gnu, does this look OK for trunk/14 and perhaps
13?
-- >8 --
This implements the following small LWG issues:
3848. adjacent_view, adjacent_transform_view and slide_view missing base
accessor
3851. chunk_view::inner-iterator missing custom iter_move and iter_swap
On Wed, 2 Oct 2024, Jonathan Wakely wrote:
> I think we should do this.
>
> Tested x86_64-linux.
>
> -- >8 --
>
> Too many users don't know about -D_GLIBCXX_ASSERTIONS and so are missing
> valuable checks for C++ standard library preconditions. This change
> enables libstdc++ assertions by defa
On Wed, 2 Oct 2024, Jonathan Wakely wrote:
> I think we should do this.
>
> Tested x86_64-linux.
>
> -- >8 --
>
> Too many users don't know about -D_GLIBCXX_ASSERTIONS and so are missing
> valuable checks for C++ standard library preconditions. This change
> enables libstdc++ assertions by defa
On Thu, 12 Sep 2024, Patrick Palka wrote:
> (Sorry to resurrect this thread so late, I lost track of this patch...)
>
> On Fri, 2 Dec 2022, Jason Merrill wrote:
>
> > On 12/2/22 09:30, Patrick Palka wrote:
> > > On Thu, 1 Dec 2022, Jason Merrill wrote:
> > >
On Mon, 16 Sep 2024, Patrick Palka wrote:
> On Thu, 30 Nov 2023, Patrick Palka wrote:
>
> > On Fri, 3 Nov 2023, Patrick Palka wrote:
> >
> > > On Tue, 3 May 2022, Jason Merrill wrote:
> > >
> > > > On 5/2/22 14:50, Patrick Palka wrote:
> &
This implements the C++23 container adaptors std::flat_set and
std::flat_multiset from P1222R4. The implementation is essentially
an simpler and pared down version of std::flat_map.
The main known issues are:
* exception safety is likely incomplete/buggy
* unimplemented from_range_t construc
This implements the C++23 container adaptors std::flat_set and
std::flat_multiset from P1222R4. The implementation is essentially
an simpler and pared down version of std::flat_map.
The main known issues are:
* exception safety is likely incomplete/buggy
* unimplemented from_range_t construc
This implements the C++23 container adaptors std::flat_map and
std::flat_multimap from P0429R9. The implementation is shared
as much as possible between the two adaptors via a common base
class that's parameterized according to key uniqueness.
The main known issues are:
* the range insert() ov
This implements the C++23 container adaptors std::flat_map and
std::flat_multimap from P0429R9. The implementation is shared
as much as possible between the two adaptors via a common base
class that's parameterized according to key uniqueness.
The main known issues are:
* the range insert() ov
On Wed, 25 Sep 2024, Jason Merrill wrote:
> On 7/30/24 6:49 PM, Giuseppe D'Angelo wrote:
> > On 29/07/2024 22:53, Giuseppe D'Angelo wrote:
> > > Hi,
> > >
> > > The attached patch is a stab at adding the necessary compiler builtin to
> > > support std::is_virtual_base_of (P2985R0, approved for C+
On Wed, 25 Sep 2024, Jason Merrill wrote:
> On 7/30/24 6:49 PM, Giuseppe D'Angelo wrote:
> > On 29/07/2024 22:53, Giuseppe D'Angelo wrote:
> > > Hi,
> > >
> > > The attached patch is a stab at adding the necessary compiler builtin to
> > > support std::is_virtual_base_of (P2985R0, approved for C+
[CC'ing Jason]
On Wed, 25 Sep 2024, Patrick Palka wrote:
> On Wed, 31 Jul 2024, Giuseppe D'Angelo wrote:
>
> > On 29/07/2024 22:53, Giuseppe D'Angelo wrote:
> > > Hi,
> > >
> > > The attached patch is a stab at adding the necessary com
[CC'ing Jason]
On Wed, 25 Sep 2024, Patrick Palka wrote:
> On Wed, 31 Jul 2024, Giuseppe D'Angelo wrote:
>
> > On 29/07/2024 22:53, Giuseppe D'Angelo wrote:
> > > Hi,
> > >
> > > The attached patch is a stab at adding the necessary com
On Wed, 31 Jul 2024, Giuseppe D'Angelo wrote:
> On 29/07/2024 22:53, Giuseppe D'Angelo wrote:
> > Hi,
> >
> > The attached patch is a stab at adding the necessary compiler builtin to
> > support std::is_virtual_base_of (P2985R0, approved for C++26). The name
> > of the builtin matches the one jus
On Wed, 31 Jul 2024, Giuseppe D'Angelo wrote:
> On 29/07/2024 22:53, Giuseppe D'Angelo wrote:
> > Hi,
> >
> > The attached patch is a stab at adding the necessary compiler builtin to
> > support std::is_virtual_base_of (P2985R0, approved for C++26). The name
> > of the builtin matches the one jus
https://gcc.gnu.org/g:abdea396e12e66185d810435bbc363845cf4664a
commit r14-10697-gabdea396e12e66185d810435bbc363845cf4664a
Author: Patrick Palka
Date: Thu Sep 12 12:45:03 2024 -0400
c++: decltype(auto) deduction of statement-expression [PR116418]
r8-7538 for PR84968 made
https://gcc.gnu.org/g:659f32ea9de57661f8a37dcfb0b9a01bfe29acce
commit r14-10696-g659f32ea9de57661f8a37dcfb0b9a01bfe29acce
Author: Patrick Palka
Date: Fri Sep 20 17:37:03 2024 -0400
c++: CWG 2789 and usings [PR116492]
For GCC 14, narrowly fix this PR by implementing the missing
https://gcc.gnu.org/g:1f70503232d4183b4b58f2910c460569d05907b9
commit r15-3744-g1f70503232d4183b4b58f2910c460569d05907b9
Author: Patrick Palka
Date: Fri Sep 20 15:41:42 2024 -0400
c++: CWG 2789 and reversed operator candidates
As a follow-up to r15-3741-gee3efe06c9c49c, which was
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
-- >8 --
As a follow-up to r15-3741-gee3efe06c9c49c, which was only concerned
with usings, it seems we should also compare contexts of a reversed
vs non-reversed (member) candidate during operator overload
resolution.
On Fri, 20 Sep 2024, Jason Merrill wrote:
> On 9/20/24 6:51 PM, Patrick Palka wrote:
> > On Fri, 20 Sep 2024, Jason Merrill wrote:
> >
> > > On 9/18/24 10:59 PM, Patrick Palka wrote:
> > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
>
On Fri, 20 Sep 2024, Jason Merrill wrote:
> On 9/18/24 10:59 PM, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
> > look OK for trunk? I'm not sure this is worth backporting
> > without the previous CWG 2273 tweak since it'll
https://gcc.gnu.org/g:06557ba12b64c57368673c46a21b14cf4e6afb50
commit r15-3740-g06557ba12b64c57368673c46a21b14cf4e6afb50
Author: Patrick Palka
Date: Fri Sep 20 12:31:40 2024 -0400
c++: CWG 2273 and non-constructors
Our implementation of the CWG 2273 inheritedness tiebreaker seems
https://gcc.gnu.org/g:ee3efe06c9c49c04eaa4e195a7ae8774a1b3faa2
commit r15-3741-gee3efe06c9c49c04eaa4e195a7ae8774a1b3faa2
Author: Patrick Palka
Date: Fri Sep 20 12:33:13 2024 -0400
c++: CWG 2789 and usings [PR116492]
After CWG 2789, the "more constrained" tiebreak
On Wed, 18 Sep 2024, Patrick Palka wrote:
> Our implementation of the CWG 2273 inheritedness tiebreaker seems to be
> incorrectly considering all inherited members, not just inherited
> constructors. This patch restricts the tiebreaker accordingly.
>
> DR 2273
>
Our implementation of the CWG 2273 inheritedness tiebreaker seems to be
incorrectly considering all inherited members, not just inherited
constructors. This patch restricts the tiebreaker accordingly.
DR 2273
gcc/cp/ChangeLog:
* call.cc (joust): Restrict inheritedness tiebreaker
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
look OK for trunk? I'm not sure this is worth backporting
without the previous CWG 2273 tweak since it'll mean inconsistent
behavior between implict vs explicit object members in GCC 14: the call
to S<>{}.f() in concepts-memfun4.C would
https://gcc.gnu.org/g:82c2acd0bc4411524a8248fcdce219927d921a71
commit r15-3694-g82c2acd0bc4411524a8248fcdce219927d921a71
Author: Patrick Palka
Date: Wed Sep 18 13:50:43 2024 -0400
c++: alias of decltype(lambda) is opaque [PR116714, PR107390]
Here for
using type
On Tue, 17 Sep 2024, Marek Polacek wrote:
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14/13?
Why not backport this to 12 as well?
>
> -- >8 --
> r12-3495 added maybe_warn_about_constant_value which will crash if
> it gets a nameless VAR_DECL, which is what happens in this PR.
On Mon, 16 Sep 2024, Patrick Palka wrote:
> On Mon, 16 Sep 2024, Andrew Pinski wrote:
>
> > On Mon, Sep 16, 2024 at 8:12 AM Patrick Palka wrote:
> > >
> > > Bootstrapped and regtested on x86_64-pc-linuxgnu, does this look
> > > OK for trunk?
On Mon, 16 Sep 2024, Andrew Pinski wrote:
> On Mon, Sep 16, 2024 at 8:12 AM Patrick Palka wrote:
> >
> > Bootstrapped and regtested on x86_64-pc-linuxgnu, does this look
> > OK for trunk? Sadly the prerequisity patch r15-2331-g523836716137d0
> > probably isn'
On Thu, 30 Nov 2023, Patrick Palka wrote:
> On Fri, 3 Nov 2023, Patrick Palka wrote:
>
> > On Tue, 3 May 2022, Jason Merrill wrote:
> >
> > > On 5/2/22 14:50, Patrick Palka wrote:
> > > > Currently when checking the constraints of a class template,
Bootstrapped and regtested on x86_64-pc-linuxgnu, does this look
OK for trunk? Sadly the prerequisity patch r15-2331-g523836716137d0
probably isn't suitable for backporting, so I reckon this should be
trunk-only.
-- >8 --
Here we're prematurely stripping the decltype(lambda) alias used inside
th
On Fri, 13 Sep 2024, Patrick Palka wrote:
> On Fri, 13 Sep 2024, Patrick Palka wrote:
>
> > On Fri, 13 Sep 2024, Jonathan Wakely wrote:
> >
> > > On Sat, 3 Aug 2024 at 00:10, Jonathan Wakely wrote:
> > > >
> > > > On Fri, 2
On Fri, 13 Sep 2024, Patrick Palka wrote:
> On Fri, 13 Sep 2024, Patrick Palka wrote:
>
> > On Fri, 13 Sep 2024, Jonathan Wakely wrote:
> >
> > > On Sat, 3 Aug 2024 at 00:10, Jonathan Wakely wrote:
> > > >
> > > > On Fri, 2
On Fri, 13 Sep 2024, Patrick Palka wrote:
> On Fri, 13 Sep 2024, Jonathan Wakely wrote:
>
> > On Sat, 3 Aug 2024 at 00:10, Jonathan Wakely wrote:
> > >
> > > On Fri, 2 Aug 2024 at 23:49, Giuseppe D'Angelo
> > > wrote:
> > > >
> > &g
On Fri, 13 Sep 2024, Patrick Palka wrote:
> On Fri, 13 Sep 2024, Jonathan Wakely wrote:
>
> > On Sat, 3 Aug 2024 at 00:10, Jonathan Wakely wrote:
> > >
> > > On Fri, 2 Aug 2024 at 23:49, Giuseppe D'Angelo
> > > wrote:
> > > >
> > &g
On Fri, 13 Sep 2024, Jonathan Wakely wrote:
> On Sat, 3 Aug 2024 at 00:10, Jonathan Wakely wrote:
> >
> > On Fri, 2 Aug 2024 at 23:49, Giuseppe D'Angelo
> > wrote:
> > >
> > > Hello,
> > >
> > > as usual thank you for the review. V2 is attached.
> > >
> > > On 02/08/2024 14:38, Jonathan Wakely w
On Fri, 13 Sep 2024, Jonathan Wakely wrote:
> On Sat, 3 Aug 2024 at 00:10, Jonathan Wakely wrote:
> >
> > On Fri, 2 Aug 2024 at 23:49, Giuseppe D'Angelo
> > wrote:
> > >
> > > Hello,
> > >
> > > as usual thank you for the review. V2 is attached.
> > >
> > > On 02/08/2024 14:38, Jonathan Wakely w
On Thu, 12 Sep 2024, Jonathan Wakely wrote:
> Tested x86_64-linux. OK for trunk?
>
> -- >8 --
>
> The standard says that std::launder is ill-formed for function pointers
> and cv void pointers, so there's no reason for __builtin_launder to
> accept them. This change allows implementations of std
On Thu, 12 Sep 2024, Jonathan Wakely wrote:
> Tested x86_64-linux. OK for trunk?
>
> -- >8 --
>
> The standard says that std::launder is ill-formed for function pointers
> and cv void pointers, so there's no reason for __builtin_launder to
> accept them. This change allows implementations of std
On Mon, 12 Aug 2024, Seyed Sajad Kahani wrote:
> When deducing auto for `adc_return_type`, `adc_variable_type`, and
> `adc_decomp_type` contexts (at the usage time), we try to resolve the
> outermost
> template arguments to be used for satisfaction. This is done by one of the
> following, dependi
On Fri, 23 Aug 2024, Nathaniel Shead wrote:
> On Thu, Aug 22, 2024 at 02:20:14PM -0400, Patrick Palka wrote:
> > On Mon, 12 Aug 2024, Nathaniel Shead wrote:
> >
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
> > >
> > > I tried
(Sorry to resurrect this thread so late, I lost track of this patch...)
On Fri, 2 Dec 2022, Jason Merrill wrote:
> On 12/2/22 09:30, Patrick Palka wrote:
> > On Thu, 1 Dec 2022, Jason Merrill wrote:
> >
> > > On 12/1/22 14:51, Patrick Palka wrote:
> > > > On
https://gcc.gnu.org/g:12bdcc3d7970860b9d66ed4dea203bde8fd68d4d
commit r15-3611-g12bdcc3d7970860b9d66ed4dea203bde8fd68d4d
Author: Patrick Palka
Date: Thu Sep 12 12:45:03 2024 -0400
c++: decltype(auto) deduction of statement-expression [PR116418]
r8-7538 for PR84968 made
On Wed, 11 Sep 2024, Patrick Palka wrote:
> On Wed, 11 Sep 2024, Patrick Palka wrote:
>
> > On Wed, 4 Sep 2024, Marek Polacek wrote:
> >
> > > On Wed, Sep 04, 2024 at 10:58:25AM -0400, Jason Merrill wrote:
> > > > On 9/3/24 6:12 PM, Marek Polacek wro
On Wed, 11 Sep 2024, Patrick Palka wrote:
> On Wed, 4 Sep 2024, Marek Polacek wrote:
>
> > On Wed, Sep 04, 2024 at 10:58:25AM -0400, Jason Merrill wrote:
> > > On 9/3/24 6:12 PM, Marek Polacek wrote:
> > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for
On Wed, 4 Sep 2024, Marek Polacek wrote:
> On Wed, Sep 04, 2024 at 10:58:25AM -0400, Jason Merrill wrote:
> > On 9/3/24 6:12 PM, Marek Polacek wrote:
> > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14?
> >
> > The change to return bool seems like unrelated cleanup; please push t
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk/backports?
-- >8 --
r8-7538 for PR84968 made strip_typedefs_expr diagnose seeing
STATEMENT_LIST, which effectively makes us reject statement-expressions
noexcept-specifiers (we already diagnose them in template argumen
https://gcc.gnu.org/g:149d87fbe661da29d8a0aa671b42bd532206a8b8
commit r14-10656-g149d87fbe661da29d8a0aa671b42bd532206a8b8
Author: Patrick Palka
Date: Thu Aug 15 10:23:54 2024 -0400
c++: c->B::m access resolved through current inst [PR116320]
Here when checking the access of (
https://gcc.gnu.org/g:b5ed381d05e0ed9edf2f320b71f8775ea96a4866
commit r14-10655-gb5ed381d05e0ed9edf2f320b71f8775ea96a4866
Author: Patrick Palka
Date: Fri Aug 9 21:15:25 2024 -0400
c++: inherited CTAD fixes [PR116276]
This implements the overlooked inherited vs non-inherited guide
https://gcc.gnu.org/g:140aab25a4865433d987d73c57f4ddf11fdac1e2
commit r14-10654-g140aab25a4865433d987d73c57f4ddf11fdac1e2
Author: Patrick Palka
Date: Sat Aug 3 09:05:05 2024 -0400
libstdc++: use concrete return type for std::forward_like
Inspired by https://github.com/llvm/llvm
https://gcc.gnu.org/g:0c80216b7bb0938bff7db230cbefa5bc3e8b3034
commit r14-10652-g0c80216b7bb0938bff7db230cbefa5bc3e8b3034
Author: Patrick Palka
Date: Sat Sep 7 14:10:09 2024 -0400
c++: template depth of lambda in default targ [PR116567]
For GCC 14, let's narrowly fix this b
https://gcc.gnu.org/g:dfb63765e994bee74d533c810fdf75d3269530ad
commit r15-3530-gdfb63765e994bee74d533c810fdf75d3269530ad
Author: Patrick Palka
Date: Sat Sep 7 14:06:37 2024 -0400
c++: deferring partial substitution into lambda [PR116567]
Here we correctly defer partial
On Thu, 5 Sep 2024, Jason Merrill wrote:
> On 9/5/24 2:28 PM, Patrick Palka wrote:
> > On Thu, 5 Sep 2024, Jason Merrill wrote:
> >
> > > On 9/5/24 1:26 PM, Patrick Palka wrote:
> > > > On Thu, 5 Sep 2024, Jason Merrill wrote:
> > > >
&
https://gcc.gnu.org/g:37977343ff4f9dcb047d966d8cbaa222964763f9
commit r15-3491-g37977343ff4f9dcb047d966d8cbaa222964763f9
Author: Patrick Palka
Date: Thu Sep 5 14:31:00 2024 -0400
c++: local class memfn synth from noexcept context [PR113063]
Extending the PR113063 testcase to
On Thu, 5 Sep 2024, Jason Merrill wrote:
> On 9/5/24 1:26 PM, Patrick Palka wrote:
> > On Thu, 5 Sep 2024, Jason Merrill wrote:
> >
> > > On 9/5/24 10:54 AM, Patrick Palka wrote:
> > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, do
On Thu, 5 Sep 2024, Jason Merrill wrote:
> On 9/5/24 10:54 AM, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
> > for trunk/14?
> >
> > -- >8 --
> >
> > A lambda within a default template argument used
On Thu, 5 Sep 2024, Patrick Palka wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
> for trunk/14?
>
> -- >8 --
>
> A lambda within a default template argument used in some template-id
> may have a smaller template depth than the context o
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk/14?
-- >8 --
A lambda within a default template argument used in some template-id
may have a smaller template depth than the context of the template-id.
For example, the lambda in v1's default template argument has tem
On Mon, 12 Aug 2024, Nathaniel Shead wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
>
> I tried to implement a remapping of the slots for TARGET_EXPRs for the
> FIXME but I wasn't able to work out how to do so effectively. Given
> that I doubt this will be a common iss
https://gcc.gnu.org/g:8e0da56f18b3678beee9d2bae27e08a0e122573a
commit r15-3094-g8e0da56f18b3678beee9d2bae27e08a0e122573a
Author: Patrick Palka
Date: Thu Aug 22 11:24:07 2024 -0400
libstdc++: Add some missing ranges feature-test macro tests
libstdc++-v3/ChangeLog
Tested on x86_64-pc-linux-gnu, does this look OK for trunk and
perhaps 14?
-- >8 --
libstdc++-v3/ChangeLog:
* testsuite/25_algorithms/contains/1.cc: Verify value of
__cpp_lib_ranges_contains.
* testsuite/25_algorithms/find_last/1.cc: Verify value of
__cpp_lib_rang
Tested on x86_64-pc-linux-gnu, does this look OK for trunk and
perhaps 14?
-- >8 --
libstdc++-v3/ChangeLog:
* testsuite/25_algorithms/contains/1.cc: Verify value of
__cpp_lib_ranges_contains.
* testsuite/25_algorithms/find_last/1.cc: Verify value of
__cpp_lib_rang
https://gcc.gnu.org/g:51761c50f843d5be4e24172535e4524b5072f24c
commit r15-3091-g51761c50f843d5be4e24172535e4524b5072f24c
Author: Patrick Palka
Date: Thu Aug 22 09:24:39 2024 -0400
libstdc++: Optimize std::projected
Algorithms that are generalized to take projections typically
https://gcc.gnu.org/g:620232426bd83a79c81cd2be6f485834c618e920
commit r15-3090-g620232426bd83a79c81cd2be6f485834c618e920
Author: Patrick Palka
Date: Thu Aug 22 09:24:20 2024 -0400
libstdc++: Implement P2997R1 changes to the indirect invocability concepts
This implements the
https://gcc.gnu.org/g:b552730faf36f1eae1dc6e73ccc93a016dec5401
commit r15-3089-gb552730faf36f1eae1dc6e73ccc93a016dec5401
Author: Patrick Palka
Date: Thu Aug 22 09:24:11 2024 -0400
libstdc++: Implement P2609R3 changes to the indirect invocability concepts
This implements the
On Wed, 21 Aug 2024, Jonathan Wakely wrote:
> On Wed, 21 Aug 2024 at 01:40, Patrick Palka wrote:
> >
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps
> > 14?
> >
> > -- >8 --
> >
> > This implements the changes of this C+
On Wed, 21 Aug 2024, Jonathan Wakely wrote:
> On Wed, 21 Aug 2024 at 01:40, Patrick Palka wrote:
> >
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps
> > 14?
> >
> > -- >8 --
> >
> > This implements the changes of this C+
Tested on x86_64-pc-linux-gnu, does this look OK for trunk? I'm not
sure if the current specification of 'projected' strictly speaking
allows for this optimization, but it seems like a natural one that
should be allowed.
-- >8 --
Algorithms that are generalized to take projections usually defaul
Tested on x86_64-pc-linux-gnu, does this look OK for trunk? I'm not
sure if the current specification of 'projected' strictly speaking
allows for this optimization, but it seems like a natural one that
should be allowed.
-- >8 --
Algorithms that are generalized to take projections usually defaul
Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps
14?
-- >8 --
This implements the changes of this C++23 paper as a DR against C++20.
Note that since the later P2538R1 "ADL-proof std::projected" which we
already implement, we can't use a simple partial specialization to matc
Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps
14?
-- >8 --
This implements the changes of this C++26 paper as a DR against C++20.
libstdc++-v3/ChangeLog:
* include/bits/iterator_concepts.h (indirectly_unary_invocable):
Relax as per P2997R1.
(indi
Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps
14?
-- >8 --
This implements the changes of this C++23 paper as a DR against C++20.
Note that since the later P2538R1 "ADL-proof std::projected" which we
already implement, we can't use a simple partial specialization to matc
Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps
14?
-- >8 --
This implements the changes of this C++26 paper as a DR against C++20.
libstdc++-v3/ChangeLog:
* include/bits/iterator_concepts.h (indirectly_unary_invocable):
Relax as per P2997R1.
(indi
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk only?
-- >8 --
Extending the PR113063 testcase to additionally constant evaluate the <=>
expression causes us to trip over the assert in cxx_eval_call_expression
/* We used to shortcut trivial constructor/op= here,
https://gcc.gnu.org/g:5348e3cb9bc99d2ee4d7438b8eca5c92fff5b931
commit r15-3038-g5348e3cb9bc99d2ee4d7438b8eca5c92fff5b931
Author: Patrick Palka
Date: Tue Aug 20 08:34:36 2024 -0400
c++: default targ eligibility refinement [PR101463]
On Tue, 9 Jan 2024, Jason Merrill wrote
> > Here during default template argument substitution we wrongly consider
> > the (substituted) default arguments v and vt as value-dependent[1]
> > which ultimately leads to deduction failure for the calls.
> >
> > The bogus value_dependent_expression_p result aside, I noticed
> > type_unificatio
Compiling with optimizations is needed to trigger the bug fixed
by r15-2369.
PR c++/115583
gcc/testsuite/ChangeLog:
* g++.dg/cpp23/consteval-if13.C: Compile with -O.
---
gcc/testsuite/g++.dg/cpp23/consteval-if13.C | 1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/testsuite
https://gcc.gnu.org/g:580fe7979f3c873eae885568d2c17c9e110670b4
commit r15-2938-g580fe7979f3c873eae885568d2c17c9e110670b4
Author: Patrick Palka
Date: Thu Aug 15 14:38:47 2024 -0400
c++: fix up cpp23/consteval-if3.C test [PR115583]
Compiling with optimizations is needed to trigger
https://gcc.gnu.org/g:63c51e09d160a44fdce1199e8efe9d293f773a2c
commit r14-10586-g63c51e09d160a44fdce1199e8efe9d293f773a2c
Author: Patrick Palka
Date: Thu Aug 15 10:20:18 2024 -0400
c++/coroutines: fix passing *this to promise type, again [PR116327]
In r15-2210 we got rid of the
https://gcc.gnu.org/g:484f139ccd3b631a777802e810a632678b42ffab
commit r15-2933-g484f139ccd3b631a777802e810a632678b42ffab
Author: Patrick Palka
Date: Thu Aug 15 10:23:54 2024 -0400
c++: c->B::m access resolved through current inst [PR116320]
Here when checking the access of (
https://gcc.gnu.org/g:303bed670af962c01b77a4f0c51de97f70e8167e
commit r15-2932-g303bed670af962c01b77a4f0c51de97f70e8167e
Author: Patrick Palka
Date: Thu Aug 15 10:20:18 2024 -0400
c++/coroutines: fix passing *this to promise type, again [PR116327]
In r15-2210 we got rid of the
On Mon, 5 Aug 2024, Cassio Neri wrote:
> Implement the template function teju_jagua which finds the shortest
> representation of a floating-point number. The floating-point type is a
> template parameter and the implementation is generic enough to handle all
> floating-point types of interest, nam
On Mon, 5 Aug 2024, Cassio Neri wrote:
> Implement the template function teju_jagua which finds the shortest
> representation of a floating-point number. The floating-point type is a
> template parameter and the implementation is generic enough to handle all
> floating-point types of interest, nam
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk and later backports?
-- >8 --
Here when checking the access of (the injected-class-name) B in c->B::m
at parse time, we notice its scope B (now the type) is a base of the
object type C, so we proceed to use C as qualif
On Tue, 13 Aug 2024, Jason Merrill wrote:
> On 8/13/24 7:52 PM, Patrick Palka wrote:
> > On Tue, 13 Aug 2024, Jason Merrill wrote:
> >
> > > On 8/12/24 10:01 PM, Patrick Palka wrote:
> > > > Tested on x86_64-pc-linux-gnu, does this look OK
On Tue, 13 Aug 2024, Jason Merrill wrote:
> On 8/12/24 10:01 PM, Patrick Palka wrote:
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk/14?
> >
> > -- >8 --
> >
> > In r15-2210 we got rid of the unnecessary cast to lvalue reference when
> &
Tested on x86_64-pc-linux-gnu, does this look OK for trunk/14?
-- >8 --
In r15-2210 we got rid of the unnecessary cast to lvalue reference when
passing *this to the promise type ctor, and as a drive-by change we also
simplified the code to use cp_build_fold_indirect_ref.
But cp_build_fold_indire
https://gcc.gnu.org/g:8cc67b520968ca9a13fd96896522aa66e39a99e2
commit r15-2864-g8cc67b520968ca9a13fd96896522aa66e39a99e2
Author: Patrick Palka
Date: Fri Aug 9 21:15:25 2024 -0400
c++: inherited CTAD fixes [PR116276]
This implements the overlooked inherited vs non-inherited guide
https://gcc.gnu.org/g:70da0ca1239faefa6dec0494a85e998eae34beff
commit r15-2863-g70da0ca1239faefa6dec0494a85e998eae34beff
Author: Patrick Palka
Date: Fri Aug 9 21:13:05 2024 -0400
c++: DECL_UNINSTANTIATED_TEMPLATE_FRIEND_P tweaks
DECL_UNINSTANTIATED_TEMPLATE_FRIEND_P templates can
https://gcc.gnu.org/g:cf7feae517d4819cd33ef6bb123217ea39845fd1
commit r15-2862-gcf7feae517d4819cd33ef6bb123217ea39845fd1
Author: Patrick Palka
Date: Fri Aug 9 21:13:03 2024 -0400
c++: clean up cp_identifier_kind checks
The predicates for checking an IDENTIFIER node&#
1 - 100 of 1235 matches
Mail list logo
