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 ...
On Fri, 27 Oct 2023, Patrick Palka wrote:
> On Fri, 27 Oct 2023, Jason Merrill wrote:
>
> > On 10/27/23 15:55, Patrick Palka wrote:
> > > With the previous two patches in place, we can now extend our
> > > deletedness diagnostic to note the ot
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, we do so in
> > > the context of the template, not the specialized ty
Bootstrapped and regtested on x86_64-pc-linu-xgnu, does this look OK for
trunk?
-- >8 --
We need to consistently look through implicit INDIRECT_REF when
setting/checking for -Wparentheses warning suppression. In passing
use STRIP_REFERENCE_REF consistently as well.
PR c++/112765
gcc/cp
On Wed, 29 Nov 2023, Marek Polacek wrote:
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
>
> Now that I'm posting this patch, I think you'll probably want me to use
> ba_any unconditionally. That works too; g++.dg/tc1/dr52.C just needs
> a trivial testsuite tweak:
> 'C' is not
On Thu, 23 Nov 2023, Jonathan Wakely wrote:
> Here's the finished version of the std::ranges::to patch, which I've
> pushed to trunk.
>
> Tested x86_64-linux.
>
> -- >8 --
>
> This adds the std::ranges::to functions for C++23. The rest of P1206R7
> is not yet implemented, i.e. the new construct
This adds a sanity check to cp_parser_expression_statement similar to
the one in finish_expr_stmt added by r6-6795-g0fd9d4921f7ba2, which
effectively downgrades accepts-invalid/wrong-code bugs like this one
into ice-on-invalid/ice-on-valid ones.
PR c++/112658
gcc/cp/ChangeLog:
*
Bootstrapped and regtested on x86-64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
Here we deem the array-to-pointer conversions in both calls as invalid,
but we fail to issue a diagnostic for the second call, ultimately because
cp_build_c_cast doesn't replay errors from build_const_cast_1.
On Fri, 24 Nov 2023, Patrick Palka wrote:
> On Wed, 22 Nov 2023, Patrick Palka wrote:
>
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> > trunk?
> >
> > -- >8 --
> >
> > This patch implements C++23 class template argum
On Wed, 22 Nov 2023, Patrick Palka wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> trunk?
>
> -- >8 --
>
> This patch implements C++23 class template argument deduction from
> inherited constructors, which is specified in terms of C++
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
A rewritten guide for alias CTAD isn't really a specialization of the
original guide, so we shouldn't register it as such. This avoids an ICE
in the below modules testcase which otherwise tries to inspect th
On Thu, 23 Nov 2023, Nathaniel Shead wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu. I don't have write
> access.
>
> -- >8 --
>
> Otherwise attempting to get the originating module declaration ICEs
> because the DECL_CHAIN of an instantiated friend template is no longer
> its contex
301 - 400 of 1308 matches
Mail list logo
