On Fri, 2 Feb 2024, Jason Merrill wrote:
> On 2/2/24 14:41, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
> > look OK for trunk?
> >
> > -- >8 --
> >
> > In r11-3261-gb28b621ac67bee we made tsubst_requires_
Bootstrapped and regtested on x86_64-pc-linux, does this look like
an improvement? This is not a bugfix and barely related to the previous
patch, but the previous patch's new use of entering_scope=true motivated
me to submit this patch since it seems like a nice simplification.
-- >8 --
lookup_t
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
look OK for trunk?
-- >8 --
In r11-3261-gb28b621ac67bee we made tsubst_requires_expr never partially
substitute into a requires-expression so as to avoid checking its
requirements out of order during e.g. generic lambda regeneration.
U
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
-- >8 --
Here when streaming in the fields of the as-base version of
_Formatting_scanner we end up clobbering ANON_AGGR_TYPE_FIELD
of the anonymous union type, since it turns out this type is shared
between the original FIELD_DECL and th
On Wed, 31 Jan 2024, Patrick Palka wrote:
> On Wed, 31 Jan 2024, Jason Merrill wrote:
>
> > On 1/31/24 12:12, Patrick Palka wrote:
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> > > trunk?
> > >
> > > -- >8
On Wed, 31 Jan 2024, Jason Merrill wrote:
> On 1/31/24 12:12, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> > trunk?
> >
> > -- >8 --
> >
> > Here during declaration matching we undesirably consider
On Wed, 24 Jan 2024, Patrick Palka wrote:
> On Wed, 24 Jan 2024, Patrick Palka wrote:
>
> > On Wed, 24 Jan 2024, Jonathan Wakely wrote:
> >
> > > On Wed, 24 Jan 2024 at 15:24, Patrick Palka wrote:
> > > >
> > > > On Wed, 24 Jan 2024, Jonathan
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
Here during declaration matching we undesirably consider the two TT{42}
CTAD expressions to be non-equivalent ultimately because for CTAD
placeholder equivalence we compare the TEMPLATE_DECLs (which uses
poin
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
-- >8 --
The original testcase from this PR (fixed by r14-8291) is rather
different from the others, so let's add it to the testsuite.
PR c++/67898
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/temp_default8.C: New test.
---
Bootstrapped and regtested on x86_64-pc-linu-xgnu, does this
look OK for trunk?
-- >8 --
We miscompile the below testcase because keep_unused_object_arg
duplicates the side effects of a (by-value) object argument of a
xobj member function.
PR c++/113640
gcc/cp/ChangeLog:
* call
On Mon, 29 Jan 2024, Patrick Palka wrote:
> On Fri, 26 Jan 2024, Jason Merrill wrote:
>
> > On 1/26/24 17:11, Jason Merrill wrote:
> > > On 1/26/24 16:52, Jason Merrill wrote:
> > > > On 1/25/24 14:18, Patrick Palka wrote:
> > > > > Bootstrapped
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
-- >8 --
Here when trying to unify P=42 A=T::value we ICE due to the latter's
empty type, which same_type_p dislikes. If the argument has empty type
then it can't be an INTEGER_CST, so unification should fail.
On Fri, 26 Jan 2024, Jason Merrill wrote:
> On 1/26/24 17:11, Jason Merrill wrote:
> > On 1/26/24 16:52, Jason Merrill wrote:
> > > On 1/25/24 14:18, Patrick Palka wrote:
> > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > >
On Fri, 26 Jan 2024, Nathaniel Shead wrote:
> This patch just adds enough of the fields from 'function' to fix the ICE
> in the linked PR. I suppose there might be more fields from this type
> that should be propagated, but I don't know enough to find out which
> they might be yet, since a lot of
On Thu, 25 Jan 2024, Patrick Palka wrote:
> On Thu, 25 Jan 2024, Jakub Jelinek wrote:
>
> > Hi!
> >
> > The following testcase reduced from GDB is miscompiled starting with
> > r14-5503 PR112427 change.
> > The problem is in the build_m_component_ref
On Thu, 25 Jan 2024, Jakub Jelinek wrote:
> Hi!
>
> The following testcase reduced from GDB is miscompiled starting with
> r14-5503 PR112427 change.
> The problem is in the build_m_component_ref hunk, which changed
> - datum = fold_build_pointer_plus (fold_convert (ptype, datum),
> componen
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk/13? This isn't a very satisfactory fix, but at least
it safely fixes these testcases I guess. Note that there's
implementation disagreement about the second testcase, GCC always
accepted it but Clang/MSVC/icc reject it
On Wed, 24 Jan 2024, Patrick Palka wrote:
> On Wed, 24 Jan 2024, Jonathan Wakely wrote:
>
> > On Wed, 24 Jan 2024 at 15:24, Patrick Palka wrote:
> > >
> > > On Wed, 24 Jan 2024, Jonathan Wakely wrote:
> > >
> > > > On Tue, 23 Jan 2024 at
On Wed, 24 Jan 2024, Jonathan Wakely wrote:
> On Wed, 24 Jan 2024 at 15:24, Patrick Palka wrote:
> >
> > On Wed, 24 Jan 2024, Jonathan Wakely wrote:
> >
> > > On Tue, 23 Jan 2024 at 23:54, Patrick Palka wrote:
> > > > diff --git a/libstdc++-v3/inclu
On Wed, 24 Jan 2024, Jonathan Wakely wrote:
> On Tue, 23 Jan 2024 at 23:54, Patrick Palka wrote:
> > diff --git a/libstdc++-v3/include/bits/stl_pair.h
> > b/libstdc++-v3/include/bits/stl_pair.h
> > index b81b479ad43..a9b20fbe7ca 100644
> > --- a/libstdc++-v3/includ
Tested on x86_64-pc-linux-gnu, does this look OK for trunK?
-- >8 --
This implements the C++23 paper P2165R4 Compatibility between tuple,
pair and tuple-like objects, which builds upon many changes from the
earlier C++23 paper P2321R2 zip.
Some declarations had to be moved around so that they're
This is consistent with std::tuple's __const_assignable member function,
and will be reused when implementing the new pair::operator= overloads
from P2165R4.
libstdc++-v3/ChangeLog:
* include/bits/stl_pair.h (pair::_S_const_assignable): Define,
factored out from ...
(pair:
On Tue, 23 Jan 2024, Jason Merrill wrote:
> On 1/22/24 13:11, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > OK for trunk/13?
> >
> > -- >8 --
> >
> > Here we handle the operator expression u < v incon
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk/13?
-- >8 --
Here we handle the operator expression u < v inconsistently: in a SFINAE
context (such as a requires-expression) we accept the it, and in a
non-SFINAE context we reject it with
error: request for member
On Wed, 3 Jan 2024, Nathaniel Shead wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
>
> -- >8 --
>
> Static data members marked 'inline' should be emitted in TUs where they
> are ODR-used. We need to make sure that statics imported from modules
> are correctly added to
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
-- >8 --
libstdc++-v3/ChangeLog:
* include/precompiled/stdc++.h [_GLIBCXX_HOSTED]: Include
and for C++23 and C++26 respectively.
---
libstdc++-v3/include/precompiled/stdc++.h | 5 +
1 file changed, 5 insertions(+)
On Thu, 18 Jan 2024, Jonathan Wakely wrote:
> On Thu, 18 Jan 2024 at 02:48, Patrick Palka wrote:
> >
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
>
> Please add PR109536 to the commit message.
Done.
>
>
>
> >
> > -- >8 --
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
-- >8 --
Some _Safe_iterator member functions define a variable of non-literal
type __gnu_cxx::__scoped_lock, which automatically disqualifies them from
being constexpr in C++20 mode even if that code path is never constant
evaluated. T
On Mon, 15 Jan 2024, Jason Merrill wrote:
> On 1/5/24 11:50, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
> > for trunk and perhaps 13?
> >
> > -- >8 --
> >
> > invalid_tparm_referent_p was rejecting us
Guard additions from P2321R2 zip with __cpp_lib_ranges_zip
instead of __cplusplus > 202020L.
libstdc++-v3/ChangeLog:
* include/std/tuple [__cplusplus > 202002L]: Guard P2321R2
changes with __cpp_lib_ranges_zip instead.
---
libstdc++-v3/include/std/tuple | 18 +-
Similar to the previous change for , but since stl_pair.h is an
internal header we need to use the corresponding internal macro instead.
libstdc++-v3/ChangeLog:
* include/bits/stl_pair.h [__cplusplus > 202002L]:
Guard P2321R2 changes with __glibcxx_ranges_zip instead.
---
libstdc
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
-- >8 --
This compile-time and diagnostic improvement[1] is less important in
C++23 mode where deducing this is available and used in _Pipe, but for
benefit of C++20 mode and for consistency let's set the flag on the most
recently added
On Tue, 16 Jan 2024, Jonathan Wakely wrote:
> On Tue, 16 Jan 2024 at 14:39, Patrick Palka wrote:
> >
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk/13?
>
> Oh! I thought this went in as part of the original cartesian_product
> commit. I would have asked
Tested on x86_64-pc-linux-gnu, does this look OK for trunk/13?
-- >8 --
This paper changes the identity element of views::cartesian_product to
be a single empty tuple instead of an empty range.
libstdc++-v3/ChangeLog:
* include/std/ranges (views::_CartesianProduct::operator()):
On Mon, 15 Jan 2024, Jonathan Wakely wrote:
> I think I'm happy with this now. It has tests for all the new functions,
> and the performance of the charset alias match algorithm is improved by
> reusing part of .
>
> Tested x86_64-linux.
>
> -- >8 --
>
> This is another C++26 change, approved i
On Wed, Jan 3, 2024 at 3:06 PM Patrick Palka wrote:
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> OK for trunk?
Ping.
>
> -- >8 --
>
> Since partial template specializations can't be named directly, access
> control (when declared at cl
On Wed, Jan 3, 2024 at 1:49 PM Patrick Palka wrote:
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
> for trunk and perhaps 13?
Ping.
>
> -- >8 --
>
> Here we neglect to emit the definitions of A::f2 and A::f4
> despite the explicit instan
On Fri, Jan 5, 2024 at 11:50 AM Patrick Palka wrote:
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
> for trunk and perhaps 13?
Ping.
>
> -- >8 --
>
> invalid_tparm_referent_p was rejecting using the address of a class NTTP
> object as a
On Mon, Jan 8, 2024 at 1:40 PM Patrick Palka wrote:
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> OK for trunk/13/12?
Ping.
>
> -- >8 --
>
> The get_target_expr call added in r12-7069-g119cea98f66476 causes us
> for the below testcase to
On Sun, Jan 7, 2024 at 3:33 PM Patrick Palka wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
Ping.
>
> -- >8 --
>
> The recursively defined constraints on _Variadic_union's user-defined
> destructor (necessary for maintaining trivial destruc
Tested on x86_64-pc-linux-gnu, does this look OK for trunk/13?
libstdc++-v3/ChangeLog:
* include/bits/stl_iterator.h (const_iterator): Define
conversion operators as per P2836R1.
* include/bits/version.def (ranges_as_const): Update value.
* include/bits/version.h:
On Sat, 13 Jan 2024, Jonathan Wakely wrote:
> On Sat, 13 Jan 2024 at 00:06, Patrick Palka wrote:
> >
> > On Fri, 12 Jan 2024, Jonathan Wakely wrote:
> >
> > > On Fri, 12 Jan 2024 at 18:33, Patrick Palka wrote:
> > > >
> > > > On Fri, 12 Jan
On Fri, 12 Jan 2024, Jonathan Wakely wrote:
> On Fri, 12 Jan 2024 at 18:33, Patrick Palka wrote:
> >
> > On Fri, 12 Jan 2024, Jonathan Wakely wrote:
> >
> > > On Fri, 12 Jan 2024 at 17:55, Patrick Palka wrote:
> > > >
> > > > On Thu, 11
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
PR libstdc++/108827
PR libstdc++/111327
libstdc++-v3/ChangeLog:
* include/bits/version.def (bind_back): Define.
* include/bits/version.h: Regenerate.
* include/std/functional (_Bind_back): Define
This simplifies the operator() of _Bind_front using C++23 deducing
this, allowing us to condense multiple nearly identical operator()
overloads into one.
In passing I think we can remove _Bind_front's defaulted special member
declarations and just let the compiler implicitly generate them for us.
On Fri, 12 Jan 2024, Jonathan Wakely wrote:
> On Fri, 12 Jan 2024 at 17:55, Patrick Palka wrote:
> >
> > On Thu, 11 Jan 2024, Jonathan Wakely wrote:
> >
> > > I'd like to commit this to trunk for GCC 14. Please take a look.
> > >
> > > --
On Thu, 11 Jan 2024, Jonathan Wakely wrote:
> Tested x86_64-linux and aarch64-linux, with TBB 2020.3 only.
>
> Reviews requested.
>
> -- >8 --
>
> This is a step towards implementing the C++23 change P2408R5, "Ranges
> iterators as inputs to non-Ranges algorithms". C++20 random access
> iterato
On Thu, 11 Jan 2024, Jonathan Wakely wrote:
> I'd like to commit this to trunk for GCC 14. Please take a look.
>
> -- >8 --
>
> This is the last part of PR libstdc++/108822 implementing P2255R2, which
> makes it ill-formed to create a std::tuple that would bind a reference
> to a temporary.
>
>
On Thu, 11 Jan 2024, Jonathan Wakely wrote:
> On Wed, 10 Jan 2024 at 21:40, Patrick Palka wrote:
> >
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
> >
> > -- >8 --
> >
> > This avoids redundant moves when composing and partially applyi
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
-- >8 --
This simplifies the operator() of the _Pipe and _Partial range adaptor
closure objects using C++23 deducing this, allowing us to condense
multiple operator() overloads into one.
The new __like_t alias template is similar to the
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
-- >8 --
Since _Nth_type has a fallback native implementation, use
_GLIBCXX_USE_BUILTIN_TRAIT when deciding whether __type_pack_element
is available so that we can easily toggle which implementation
to use.
libstdc++-v3/ChangeLog:
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
-- >8 --
This avoids redundant moves when composing and partially applying range
adaptor objects.
Note that the new constraints on _Partial's constructor templates are
needed so that it's not inadvertently chosen over the copy construct
Congratulations on landing this impressive work in GCC 14!
On Sun, 7 Jan 2024, waffl3x wrote:
> Bootstrapped and tested on x86_64-linux with no regressions.
>
> I'm considering this finished, I have CWG2586 working but I have not
> included it in this version of the patch. I was not happy with t
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk/13/12?
-- >8 --
The get_target_expr call added in r12-7069-g119cea98f66476 causes us
for the below testcase to call build_vec_delete in a template context,
which builds a templated destructor call and checks expr_noexc
On Mon, 8 Jan 2024, Nathaniel Shead wrote:
> On Sat, Jan 06, 2024 at 05:32:37PM -0500, Nathan Sidwell wrote:
> > I;m not sure about this, there was clearly a reason I did it the way it is,
> > but perhaps that reasoning became obsolete -- something about an existing
> > declaration and reading in
On Mon, 8 Jan 2024, Nathaniel Shead wrote:
> On Thu, Jan 04, 2024 at 03:39:15PM -0500, Patrick Palka wrote:
> > On Sun, 3 Dec 2023, Nathaniel Shead wrote:
> >
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
> > >
> > > -- >8
On Sun, 7 Jan 2024, Patrick Palka wrote:
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
>
> -- >8 --
>
> The recursively defined constraints on _Variadic_union's user-defined
> destructor (necessary for maintaining trivial destructibility of th
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
-- >8 --
The recursively defined constraints on _Variadic_union's user-defined
destructor (necessary for maintaining trivial destructibility of the
variant iff all of its alternatives are) effectively require a template
instantiation dep
On Tue, 5 Dec 2023, Jonathan Wakely wrote:
> On Wed, 22 Nov 2023 at 14:50, Jonathan Wakely wrote:
> >
> > On Mon, 20 Nov 2023 at 02:56, Jason Merrill wrote:
> > >
> > > Tested x86_64-pc-linux-gnu. Are the library bits OK? Any comments
> > > before I
> > > push this?
> >
> > The library parts a
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
look OK for trunk?
-- >8 --
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
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk and perhaps 13?
-- >8 --
invalid_tparm_referent_p was rejecting using the address of a class NTTP
object as a template argument, but this should be fine.
PR c++/113242
gcc/cp/ChangeLog:
* pt.cc (inva
On Thu, 4 Jan 2024, Patrick Palka wrote:
> On Sat, 23 Dec 2023, Ken Matsui wrote:
>
> > This patch optimizes the compilation performance of std::is_pointer
> > by dispatching to the new __is_pointer built-in trait.
> >
> > libstdc++-v3/ChangeLog:
> >
>
On Sat, 23 Dec 2023, Ken Matsui wrote:
> This patch optimizes the compilation performance of std::is_pointer
> by dispatching to the new __is_pointer built-in trait.
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/cpp_type_traits.h (__is_pointer): Use
> __is_pointer built-in trait. O
raits in the type_traits header through
> _GLIBCXX_DO_NOT_USE_BUILTIN_TRAITS macro, without needing to modify the
> source code.
LGTM, thanks!
>
> libstdc++-v3/ChangeLog:
>
> * include/std/type_traits: Use _GLIBCXX_USE_BUILTIN_TRAIT.
>
> Signed-off-by: Ken Matsui
> Revie
On Sun, 3 Dec 2023, Nathaniel Shead wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
>
> -- >8 --
>
> The TYPE_DECL_SUPPRESS_DEBUG and DECL_EXTERNAL flags use the same
> underlying bit. This is causing confusion when attempting to determine
> the interface for a streamed
On Wed, 3 Jan 2024, Nathaniel Shead wrote:
> Linaro CI tells me that this patch caused regressions on ARM. I don't
> have an ARM machine available to test on, but it appears to have been
> caused by attempting to stream vtables as static data members, and ARM
> having different behaviour with rega
On Wed, 3 Jan 2024, Nathaniel Shead wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
>
> -- >8 --
>
> The attached testcase Patrick found in PR c++/112899 ICEs because it is
> attempting to write a variable initializer that is no longer in the
> static_aggregates map.
>
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
-- >8 --
Since partial template specializations can't be named directly, access
control (when declared at class scope) doesn't apply to them, so we
shouldn't have to set their TREE_PRIVATE / TREE_PROTECTED. This code
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk and perhaps 13?
-- >8 --
Here we neglect to emit the definitions of A::f2 and A::f4
despite the explicit instantiations ultimately because TREE_PUBLIC isn't
set on the corresponding partial specializations, the declara
Tested on x86_64-pc-linux-gnu, does this look OK for trunk and release
branches (r14-205 was backported everywhere)?
-- >8 --
The adjustment to max_size_type.cc in r14-205-g83470a5cd4c3d2
inadvertently increased the execution time of the test by over 5x due to
enabling the two main loops to actua
On Sat, 16 Sep 2023, Jason Merrill wrote:
> On 9/15/23 12:03, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> > trunk?
>
> OK.
Thanks a lot. Testing on cmcstl2 revealed that we don't maintain
visibility flags on ali
On Thu, Dec 21, 2023 at 8:29 AM Patrick Palka wrote:
>
> On Wed, 20 Dec 2023, Ken Matsui wrote:
>
> > This patch removes the testsuite_tr1.h dependency from g++.dg/ext/is_*.C
> > tests since the header is supposed to be used only by libstdc++, not
> > front-end. T
On Wed, 20 Dec 2023, Ken Matsui wrote:
> This patch removes the testsuite_tr1.h dependency from g++.dg/ext/is_*.C
> tests since the header is supposed to be used only by libstdc++, not
> front-end. This also includes test code consistency fixes.
LGTM
>
> gcc/testsuite/ChangeLog:
>
> * g
On Wed, 20 Dec 2023, Jason Merrill wrote:
> On 12/20/23 17:54, Patrick Palka wrote:
> > On Wed, 20 Dec 2023, Jason Merrill wrote:
> >
> > > On 12/20/23 17:07, Patrick Palka wrote:
> > > > Bootstrap and regtesting in progress on x86_64-pc-linux-gnu, do
On Wed, 20 Dec 2023, Jason Merrill wrote:
> On 12/20/23 17:07, Patrick Palka wrote:
> > Bootstrap and regtesting in progress on x86_64-pc-linux-gnu, does this
> > look OK for trunk if successful?
> >
> > -- >8 --
> >
> > Since r14-4977-g0f2e2080685e75
Bootstrap and regtesting in progress on x86_64-pc-linux-gnu, does this
look OK for trunk if successful?
-- >8 --
Since r14-4977-g0f2e2080685e75 the -Wparentheses warning now undesirably
warns on the idiom
Wparentheses-34.C:9:14: warning: suggest parentheses around assignment used as
truth value
On Fri, 1 Apr 2022, Jason Merrill wrote:
> On 4/1/22 11:17, Patrick Palka wrote:
> > An implicit guide already inherits the (rewritten) constraints of the
> > constructor. Thus it seems natural that the guide must also inherit
> > the constraints of the class template,
On Tue, 19 Dec 2023, Sandra Loosemore wrote:
> On 12/6/23 22:11, Ken Matsui wrote:
> > This patch series optimizes type traits compilation performance by
> > implementing built-in type traits and using them in libstdc++.
>
> I'm finding that all the new g++.dg/ext/is_*.C testcases added by this p
On Mon, 1 May 2023, Jason Merrill wrote:
> Tested x86_64-pc-linux-gnu, applying to trunk.
>
> Patrick, can you verify that this resolves 109506 and add whatever testcase(s)
> seem appropriate from that PR?
>
> -- 8< --
>
> Here it turns out I also needed to adjust cfun when stepping out of the
This also happens to fix composition of these closure objects.
PR libstdc++/112802
PR libstdc++/113068
libstdc++-v3/ChangeLog:
* include/std/ranges (__detail::_To::operator()): Add constraints.
(__detail::_To2::operator()): Likewise.
* testsuite/std/ranges
Bootstrappde and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
When computing a direct conversion to reference type fails and yields a
bad conversion, reference_binding incorrectly commits to that conversion
rather than attempting a conversion via a temporary. This lead
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
Here we first use and therefore synthesize the local class operator<=>
from an unevaluated context, which inadvertently affects synthesization
by causing functions used within the definition (such as the copy
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
-- >8 --
The deprecated and unavailable attributes weren't working when used on
a template redeclaration ultimately because the corresponding tree flags
on the underlying decls weren't being merged across redeclaratio
On Sat, 16 Dec 2023, Jonathan Wakely wrote:
> On Sat, 16 Dec 2023 at 09:14, Jonathan Wakely wrote:
> >
> > On Sat, 16 Dec 2023 at 00:27, Patrick Palka wrote:
> > >
> > > On Wed, 6 Dec 2023, Jonathan Wakely wrote:
> > >
> > > >
On Wed, 6 Dec 2023, Jonathan Wakely wrote:
> Any comments on this approach?
>
> -- >8 --
>
> This makes constexpr std::vector (mostly) work in Debug Mode. All safe
> iterator instrumentation and checking is disabled during constant
> evaluation, because it requires mutex locks and calls to non-i
On Thu, 1 Jun 2023, Patrick Palka wrote:
> During partial ordering, we want to look through dependent alias
> template specializations within template arguments and otherwise
> treat them as opaque in other contexts (see e.g. r7-7116-g0c942f3edab108
> and r11-7011-g6e0a231a4aa240).
On Mon, 11 Sep 2023, Patrick Palka wrote:
> On Thu, 1 Jun 2023, Patrick Palka wrote:
>
> > For a complex alias template-id, dependent_alias_template_spec_p returns
> > true if any template argument of the template-id is dependent. This
> > predicate indicates that substi
On Thu, 14 Dec 2023, Jason Merrill wrote:
> On 12/14/23 16:08, Patrick Palka wrote:
> > On Thu, 14 Dec 2023, Jason Merrill wrote:
> >
> > > On 12/14/23 14:17, Patrick Palka wrote:
> > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
On Thu, 14 Dec 2023, Jason Merrill wrote:
> On 12/14/23 14:17, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> > trunk? Do we want to condition this on abi_check (19)?
>
> I think we do, sadly.
Sounds good, like so? Boo
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
The section attribute currently has no effect on templates because the
call to set_decl_section_name only happens at parse time and not also at
instantiation time. This patch fixes this by propagating the se
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk? Do we want to condition this on abi_check (19)?
-- >8 --
As with other declaration attributes, we need to look through
TEMPLATE_DECL when looking up the abi_tag attribute.
PR c++/109715
gcc/cp/ChangeLog:
On Wed, 13 Dec 2023, Jason Merrill wrote:
> Tested x86_64-pc-linux-gnu, applying to trunk.
>
> -- 8< --
>
> When building an AGGR_INIT_EXPR from a CALL_EXPR, we shouldn't lose location
> information.
>
> gcc/cp/ChangeLog:
>
> * tree.cc (build_aggr_init_expr): Copy EXPR_LOCATION.
I made
On Tue, 12 Dec 2023, Patrick Palka wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
> for trunk?
>
> -- >8 --
>
> When unifying constants we need to generally treat constants of
> different types but same value as different, in light of au
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk?
-- >8 --
When unifying constants we need to generally treat constants of
different types but same value as different, in light of auto template
parameters. This patch fixes this in a minimal way; it seems we could
ge
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk? I considered removing the is_overloaded_fn test now as
well, but it could in theory be hit (and not subsumed by the
type_unknown_p test) for e.g. OVERLOAD of a single FUNCTION_DECL. I
wonder if that's something we'd s
We accept this testcase since r12-4453-g79802c5dcc043a.
PR c++/63378
gcc/testsuite/ChangeLog:
* g++.dg/template/fnspec3.C: New test.
---
gcc/testsuite/g++.dg/template/fnspec3.C | 20
1 file changed, 20 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/t
On Fri, 1 Dec 2023, Jason Merrill wrote:
> On 12/1/23 12:32, Patrick Palka wrote:
> > On Tue, 14 Nov 2023, Jason Merrill wrote:
> >
> > > On 11/14/23 11:10, Patrick Palka wrote:
> > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
&
On Thu, 30 Nov 2023, Jason Merrill wrote:
> Tested x86_64-pc-linux-gnu, applying to trunk.
>
> -- 8< --
>
> In review of the deducing 'this' patch it came up that LAMBDA_EXPR_MUTABLE_P
> doesn't make sense for a lambda with an explicit object parameter. And it
> was never necessary, so let's re
On Tue, 14 Nov 2023, Jason Merrill wrote:
> On 11/14/23 11:10, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> > trunk?
> >
> > -- >8 --
> >
> > For decltype((x)) within a lambda where x is not c
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
-- >8 --
Use the existing _Partial range adaptor closure object in the
definition of ranges::to instead of essentially open coding it.
libstdc++-v3/ChangeLog:
* include/std/ranges (__detail::_ToClosure): Replace with ...
301 - 400 of 1319 matches
Mail list logo