On Mon, Sep 18, 2023 at 9:36 AM Jason Merrill wrote:
>
> On 9/18/23 08:58, Patrick Palka wrote:
> > On Sun, 17 Sep 2023, Jason Merrill wrote:
> >
> >> On 9/17/23 15:13, Patrick Palka wrote:
> >>> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> >>> trunk?
> >>>
> >>> --
On Mon, 18 Sep 2023, Patrick Palka wrote:
> Jason pointed out that even implicit loads of volatile references need
> to undergo lvalue-to-rvalue conversion, but we currently emit a warning
> in this case and discard the load. This patch changes this behavior so
> that we don't issue a warning,
On Mon, 18 Sep 2023, Patrick Palka wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> trunk?
>
> -- >8 --
>
> Here convert_to_void always completes the type of an indirection or
> id-expression, but according to [expr.context] an lvalue-to-rvalue
> conversion is
Jason pointed out that even implicit loads of volatile references need
to undergo lvalue-to-rvalue conversion, but we currently emit a warning
in this case and discard the load. This patch changes this behavior so
that we don't issue a warning, and preserve the load.
gcc/cp/ChangeLog:
*
On Mon, 18 Sep 2023, Patrick Palka wrote:
> On Sun, 17 Sep 2023, Jason Merrill wrote:
>
> > On 9/16/23 17:41, Patrick Palka wrote:
> > > 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,
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
Here convert_to_void always completes the type of an indirection or
id-expression, but according to [expr.context] an lvalue-to-rvalue
conversion is applied to a discarded-value expression only if "the
On Sun, 17 Sep 2023, Jason Merrill wrote:
> On 9/16/23 17:41, Patrick Palka wrote:
> > 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?
> > > >
> > > > -- >8
On Sun, 17 Sep 2023, Jason Merrill wrote:
> On 9/17/23 14:51, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> > trunk? Patch generatde with -w to avoid noisy whitespace changes.
> >
> > -- >8 --
> >
> > This patch makes us recognize and check
On Sun, 17 Sep 2023, Jason Merrill wrote:
> On 9/17/23 15:13, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> > trunk?
> >
> > -- >8 --
> >
> > r14-2655-g92d1425ca78040 made instantiate_template avoid redundantly
> > performing a
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
r14-2655-g92d1425ca78040 made instantiate_template avoid redundantly
performing a specialization lookup when instantiating a function or
alias template. This patch applies the same optimization to
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk? Patch generatde with -w to avoid noisy whitespace changes.
-- >8 --
This patch makes us recognize and check non-dependent simple assigments
ahead of time, like we already do for compound assignments. This means
the
On Sat, 16 Sep 2023, Jason Merrill wrote:
> On 9/15/23 13:55, Patrick Palka wrote:
> > This corrects decltype of a (class) NTTP object as per
> > [dcl.type.decltype]/1.2 and [temp.param]/6 in the type-dependent case.
> > In the non-dependent case (nontype-class8.C) we resolve the decltype
> >
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?
> >
> > -- >8 --
> >
> > Here convert_to_void always completes the type of an INDIRECT_REF or
> > VAR_DECL expression, but
bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk/13?
-- >8 --
This corrects decltype of a (class) NTTP object as per
[dcl.type.decltype]/1.2 and [temp.param]/6 in the type-dependent case.
In the non-dependent case (nontype-class8.C) we resolve the decltype
ahead of
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
When constraining the visibility of an instantiation, we weren't
properly considering the visibility of PTRMEM_CST and TEMPLATE_DECL
template arguments.
PR c++/70413
gcc/cp/ChangeLog:
*
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
Here convert_to_void always completes the type of an INDIRECT_REF or
VAR_DECL expression, but according to [expr.context] an lvalue-to-rvalue
conversion is applied to a discarded-value expression only if
On Thu, 14 Sep 2023, Jonathan Wakely wrote:
> On Thu, 14 Sept 2023 at 15:13, Patrick Palka via Libstdc++
> wrote:
> >
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
> >
> > -- >8 --
> >
> > By now it's probably safe to assume supported compilers have full
> > concepts support in
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
-- >8 --
By now it's probably safe to assume supported compilers have full
concepts support in C++20 mode. And using a requires-clase instead
enable_if_t inside the return type greatly reduces the sizes of the
corresponding symbol
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
-- >8 --
For std::to_chars:
The constrained alias __integer_to_chars_result_type seems unnecessary
ever since r10-3080-g28f0075742ed58 got rid of the only public overload
which used it. Now only non-public overloads are constrained by
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
Since the LHS of a qualified-id is a non-deduced context, it effectively
means we can't deduce from outer template arguments of a class template
specialization. And checking for equality between the
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
-- >8 --
Here more_specialized_partial_spec considers the two partial
specializations to be unordered ultimately because unify for identical
parm=arg=A::C returns failure due to C being dependent.
This patch fixes
Bootstrpaped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
This simple patch extends the r12-3271-gf1e73199569287 optimization
to apply to deduction without explicit template arguments as well.
The motivation for this is to accept testcases such as conv20.C and
On Mon, 11 Sep 2023, Patrick Palka wrote:
> This specialization for the case of no bound args, added by
> r13-4214-gcbd05ca5ab1231, seems to be mostly obsoleted by
> r13-5033-ge2eab3c4edb6aa which added [[no_unique_address]] to the
> main template's data members. And the compile time advantage
The previous patch fixed perfect forwarding for std::bind_front.
This patch fixes the same issue for std::not_fn.
Tested on x86_64-pc-linux-gnu, does this look OK for trunk and
perhaps 13?
PR libstdc++/111327
libstdc++-v3/ChangeLog:
* include/std/functional
In order to properly implement a perfect forwarding call wrapper
(before 'deducing this' at least) we need a total of 8 operator()
overloads, 4 main ones and 4 deleted ones for each const/ref qual pair,
as described in section 5.5 of P0847R6. Otherwise the wrapper may
not perfectly forward
This specialization for the case of no bound args, added by
r13-4214-gcbd05ca5ab1231, seems to be mostly obsoleted by
r13-5033-ge2eab3c4edb6aa which added [[no_unique_address]] to the
main template's data members. And the compile time advantage of
avoiding an empty tuple and index_sequence seems
On Mon, 11 Sep 2023, Ken Matsui via Gcc-patches wrote:
> This patch uses _GLIBCXX_USE_BUILTIN_TRAIT macro instead of __has_builtin in
> the type_traits header for traits that have a corresponding fallback
> non-built-in implementation. This macro supports to toggle the use of built-in
> traits in
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). To that end
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 substitution into the template-id may behave
> differently with respect to SFINAE
On Thu, 7 Sep 2023, Jason Merrill wrote:
> On 9/6/23 18:07, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> > trunk? This cache apparently has a 98% hit rate for TYPE_HAS_CONVERSION
> > types on some test files.
>
> Does it make a measurable
On Mon, 28 Aug 2023, Jason Merrill wrote:
> On 8/24/23 09:31, Patrick Palka wrote:
> > On Wed, 23 Aug 2023, Jason Merrill wrote:
> >
> > > On 8/21/23 21:51, Patrick Palka wrote:
> > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look like
> > > > a reasonable approach? I
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk? This cache apparently has a 98% hit rate for TYPE_HAS_CONVERSION
types on some test files.
-- >8 --
gcc/cp/ChangeLog:
* config-lang.in (gtfiles): Add search.cc.
* search.cc
On Mon, 28 Aug 2023, Jason Merrill wrote:
> On 8/24/23 09:31, Patrick Palka wrote:
> > On Wed, 23 Aug 2023, Jason Merrill wrote:
> >
> > > On 8/21/23 21:51, Patrick Palka wrote:
> > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look like
> > > > a reasonable approach? I
On Fri, 25 Aug 2023, Marek Polacek via Gcc-patches wrote:
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
LGTM
>
> -- >8 --
>
> This CWG clarifies that designated initializer support direct-initialization.
> Just be careful what Note 2 in [dcl.init.aggr]/4.2 says: "If the
>
Tested on x86_64-pc-linux-gnu, does this look OK for trunk? This
reduces calls to is_rvalue_constant_expression from
cp_parser_constant_expression by 10% for stdc++.h.
-- >8 --
As a follow-up to Marek's r14-3088-ga263152643bbec, this patch makes
us avoid passing an effectively dummy
Boostrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
This replaces manual memory management via conversion_obstack_alloc(0)
and obstack_free with the recently added conversion_obstack_sentinel,
and also uses the latter in build_user_type_conversion and
On Fri, 25 Aug 2023, Richard Biener via Gcc-patches wrote:
>
> The following adds the capability to have fold-const.cc matched
> patterns visible in -folding dumps. There's two choices,
> a portable one replacing return stmts like
>
> - return fold_build1 (tcode, ctype, fold_convert
On Wed, 23 Aug 2023, Jason Merrill wrote:
> On 8/21/23 21:51, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look like
> > a reasonable approach? I didn't observe any compile time/memory impact
> > of this change.
> >
> > -- >8 --
> >
> > As described in
On Wed, 12 Jul 2023, Ken Matsui via Libstdc++ wrote:
> This patch implements built-in trait for std::is_function.
>
> gcc/cp/ChangeLog:
>
> * cp-trait.def: Define __is_function.
> * constraint.cc (diagnose_trait_expr): Handle CPTK_IS_FUNCTION.
> * semantics.cc
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look like
a reasonable approach? I didn't observe any compile time/memory impact
of this change.
-- >8 --
As described in detail in the PR, CWG 2369 has the surprising
consequence of introducing constraint recursion in seemingly valid
On Mon, Apr 24, 2023 at 12:23 PM Patrick Palka wrote:
>
> This patch makes these integer-class type structural types by changing
> their private data members into public ones, which allows them to be
> used as NTTP types. I'm not sure if this is required by the standard
> but it seems handy.
>
>
On Sun, Apr 16, 2023 at 11:24 PM Patrick Palka wrote:
>
> On Fri, 14 Apr 2023, Patrick Palka wrote:
>
> > Using the CRTP idiom for this base class avoids bloating the size of a
> > pipeline when adding distinct empty range adaptor closure objects to it,
> > as detailed in section 4.1 of P2387R3.
On Mon, Apr 17, 2023 at 9:39 AM Patrick Palka wrote:
>
> This C++23 paper fixes a bug in these views when adapting a certain kind
> of non-forward range, and we treat it as a DR against C++20.
>
> Tested on x86_64-pc-linux-gnu, does this look OK for GCC 13? This
> is an ABI change for join_view
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
-- >8 --
This makes the generic pretty printer print braces around a TREE_VEC
like we do for CONSTRUCTOR. This should improve readability of nested
TREE_VECs in particular.
gcc/ChangeLog:
* tree-pretty-print.cc
On Thu, 10 Aug 2023, Jason Merrill wrote:
> On 8/10/23 16:40, Patrick Palka wrote:
> > On Thu, 10 Aug 2023, Jason Merrill wrote:
> >
> > > On 8/10/23 12:09, Patrick Palka wrote:
> > > > Booststrapped and regtested on x86_64-pc-linux-gnu, does this look OK
> > > > for
> > > > trunk and perhaps
On Tue, 8 Aug 2023, Jason Merrill wrote:
> On 7/31/23 20:34, Patrick Palka wrote:
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
> >
> > -- >8 --
> >
> > gcc/cp/ChangeLog:
> >
> > * ptree.cc (cxx_print_decl): Check for DECL_LANG_SPECIFIC and
> > TS_DECL_COMMON only
On Thu, 10 Aug 2023, Jason Merrill wrote:
> On 8/10/23 12:09, Patrick Palka wrote:
> > Booststrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> > trunk and perhaps 13?
> >
> > -- >8 --
> >
> > We shouldn't issue a "declared static but never defined" warning
> > for a
Booststrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk and perhaps 13?
-- >8 --
We shouldn't issue a "declared static but never defined" warning
for a deduction guide (declared in an anonymous namespace).
PR c++/106604
gcc/cp/ChangeLog:
* decl.cc
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk?
-- >8 --
This makes us recognize variable template partial specializations
defined directly inside the class body. It seems to suffice to call
check_explicit_specialization when we see a static TEMPLATE_ID_EXPR data
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk and perhaps 13?
-- >8 --
Here we're incorrectly rejecting the first type-requirement at parse
time with
concepts-requires35.C:14:56: error: ‘typename A::B’ is not a template
[-fpermissive]
We also incorrectly
On Thu, Jun 1, 2023 at 2:11 PM Bernhard Reutner-Fischer
wrote:
>
> Hi David, Patrick,
>
> On Thu, 1 Jun 2023 18:33:46 +0200
> Bernhard Reutner-Fischer wrote:
>
> > On Thu, 1 Jun 2023 11:24:06 -0400
> > Patrick Palka wrote:
> >
> > > On Sat, May 13, 2023 at 7:26 PM Bernhard Reutner-Fischer via
>
On Thu, 27 Jul 2023, Ken Matsui via Gcc-patches wrote:
> This patch uses _GLIBCXX_HAS_BUILTIN_TRAIT macro instead of
> __has_builtin in the type_traits header. This macro supports to toggle
> the use of built-in traits in the type_traits header through
> _GLIBCXX_NO_BUILTIN_TRAITS macro, without
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
-- >8 --
gcc/cp/ChangeLog:
* ptree.cc (cxx_print_decl): Check for DECL_LANG_SPECIFIC and
TS_DECL_COMMON only when necessary. Print DECL_TEMPLATE_INFO
for all decls that have it, not just VAR_DECL or
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
-- >8 --
In the C++ front end, a COMPONENT_REF's second operand isn't always a
decl (at least at template parse time). This patch makes the generic
pretty printer not ICE when printing such a COMPONENT_REF.
gcc/ChangeLog:
*
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk/13 (later)?
-- >8 --
Now that init_subob_ctx no longer sets new_ctx.ctor for a subobject of
empty type, it seems we need to ensure its callers cxx_eval_bare_aggregate
and cxx_eval_vec_init_1 consistently omit entries
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk/13 (after the branch is unfrozen)?
-- >8 --
This teaches unify how to compare two REAL_CSTs.
PR c++/110809
gcc/cp/ChangeLog:
* pt.cc (unify) : Generalize to handle
REAL_CST as well.
On Fri, 21 Jul 2023, Jason Merrill wrote:
> On 7/21/23 14:34, Patrick Palka wrote:
> > (This is a follow-up of
> > https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624951.html)
> >
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, how does this look?
> >
> > -- >8 --
> >
> > The
On Fri, Jul 21, 2023 at 5:29 PM Thiago Jung Bauermann
wrote:
>
> Commit 92d1425ca780 "c++: redundant targ coercion for var/alias tmpls"
> changed the compiler error message in this testcase from
>
> : In instantiation of 'void foo() [with T = int]':
> :14:11: required from here
> :8:22: error:
(This is a follow-up of
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624951.html)
Bootstrapped and regtested on x86_64-pc-linux-gnu, how does this look?
-- >8 --
The previous fix doesn't work for partially instantiated ttps primarily
because most_general_template doesn't work for them.
On Wed, Jul 19, 2023 at 3:33 PM Ken Matsui via Gcc-patches
wrote:
>
> This patch defines _GLIBCXX_HAS_BUILTIN_TRAIT macro, which will be used
> as a flag to toggle the use of built-in traits in the type_traits header
> through _GLIBCXX_NO_BUILTIN_TRAITS macro, without needing to modify the
>
On Wed, 19 Jul 2023, Jason Merrill wrote:
> On 7/19/23 14:05, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> > trunk/13?
> >
> > -- >8 --
> >
> > Since the arguments 'pargs' passed to the coerce_template_parms from
> >
On Tue, 18 Jul 2023, Ken Matsui via Libstdc++ wrote:
> This patch defines _GLIBCXX_HAS_BUILTIN_TRAIT, which will be used as a
> flag to toggle built-in traits in the type_traits header. Through this
> macro function and _GLIBCXX_NO_BUILTIN_TRAITS macro, we can switch the
> use of built-in traits
On Wed, 19 Jul 2023, Marek Polacek wrote:
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
LGTM. It might be preferable to check COMPLETE_TYPE_P in the caller
instead, so that we avoid inspecting CLASSTYPE_NON_AGGREGATE on an
incomplete class type, and so that the caller doesn't
On Wed, Jul 19, 2023 at 2:05 PM Patrick Palka wrote:
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> trunk/13?
>
> -- >8 --
>
> Since the arguments 'pargs' passed to the coerce_template_parms from
> coerce_template_template_parms are always a full set, we need to
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk/13?
-- >8 --
Since the arguments 'pargs' passed to the coerce_template_parms from
coerce_template_template_parms are always a full set, we need to make sure
we always pass the parameters of the most general template
On Tue, 18 Jul 2023, Marek Polacek via Gcc-patches wrote:
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk and branches?
Looks reasonable to me.
Though I wonder if we could also fix this by not checking potentiality
at all in this case? The problematic call to
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk? Also verified by way of gcc_assert that we never see
TEMPLATE_PARM_INDEX here.
-- >8 --
Within a template parameter list, a non-type template parameter pack is
represented as a PARM_DECL. But in a couple of spots
On Fri, 14 Jul 2023, Jason Merrill wrote:
> On 7/14/23 14:07, Patrick Palka wrote:
> > On Thu, 13 Jul 2023, Jason Merrill wrote:
> >
> > > On 7/13/23 11:48, Patrick Palka wrote:
> > > > On Wed, 28 Jun 2023, Patrick Palka wrote:
> > > >
> > > > > On Wed, Jun 28, 2023 at 11:50 AM Jason Merrill
>
On Thu, 13 Jul 2023, Jason Merrill wrote:
> On 7/13/23 11:48, Patrick Palka wrote:
> > On Wed, 28 Jun 2023, Patrick Palka wrote:
> >
> > > On Wed, Jun 28, 2023 at 11:50 AM Jason Merrill wrote:
> > > >
> > > > On 6/23/23 12:23, Patrick Palka wrote:
> > > > > On Fri, 23 Jun 2023, Jason Merrill
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
Here the call A().f() is represented as a COMPOUND_EXPR whose first
operand is the otherwise unused object argument A() and second operand
is the call result (both are TARGET_EXPRs). Within the return
On Wed, 28 Jun 2023, Patrick Palka wrote:
> On Wed, Jun 28, 2023 at 11:50 AM Jason Merrill wrote:
> >
> > On 6/23/23 12:23, Patrick Palka wrote:
> > > On Fri, 23 Jun 2023, Jason Merrill wrote:
> > >
> > >> On 6/21/23 13:19, Patrick Palka wrote:
> > >>> When stepping through the variable/alias
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk and perhaps 13?
-- >8 --
This fixes a crash when mangling an ADL-enabled call to a template-id
naming an unknown template (as per P0846R0).
PR c++/110524
gcc/cp/ChangeLog:
* mangle.cc
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk? There might be an existing PR for this issue but Bugzilla search
seems to be timing out for me currently.
-- >8 --
I noticed we were accidentally preventing ourselves from considering
a pointer/reference-to-function
On Wed, 12 Jul 2023, Patrick Palka wrote:
> We're not checking constraints of pointer/reference-to-function conversion
> functions during overload resolution, which causes us to ICE on the first
> testcase and incorrectly reject the second testcase.
Er, I noticed [over.call.object] doesn't
We're not checking constraints of pointer/reference-to-function conversion
functions during overload resolution, which causes us to ICE on the first
testcase and incorrectly reject the second testcase.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk/13?
PR
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk?
-- >8 --
Here during ahead of time coercion of the variable template-id v1,
since we pass only the innermost arguments to coerce_template_parms (and
outer arguments are still dependent at this point), substitution of
On Sat, 1 Jul 2023, Nathaniel Shead wrote:
> This is an update of the patch series at
> https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614811.html
>
> Changes since v2:
>
> - Use a separate 'hash_set' to track expired variables instead of
> adding a flag to 'lang_decl_base'.
> - Use
Tested on x86_64-pc-linux-gnu, pushed to trunk as obvious.
-- >8 --
Now that we cache level-lowered ttps we can end up processing the same
ttp multiple times via (multiple calls to) redeclare_class_template, so
we can't assume a ttp's DECL_CONTEXT is initially empty.
PR c++/110523
On Fri, 30 Jun 2023, Jonathan Wakely wrote:
> Tested x86_64-linux. Patrick, PTAL.
>
> -- >8 --
>
> The __has_attribute(init_priority) check in is true for Clang
> on darwin, which means that user code including thinks the
> library will initialize the global streams. However, when libstdc++
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk/13?
-- >8 --
cp_fold is neglecting to propagate CONSTRUCTOR_MUTABLE_POISON when folding
a CONSTRUCTOR initializer, which for the below testcase causes us to fail
to reject a mutable member access of a constexpr
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk/13/12?
-- >8 --
Here we find ourselves instantiating the NSDMI for A<1>::m when
computing argument conversions during overload resolution, and
thus tf_conv is set. This causes mark_used for the constructor
used in
On Wed, Jun 28, 2023 at 11:50 AM Jason Merrill wrote:
>
> On 6/23/23 12:23, Patrick Palka wrote:
> > On Fri, 23 Jun 2023, Jason Merrill wrote:
> >
> >> On 6/21/23 13:19, Patrick Palka wrote:
> >>> When stepping through the variable/alias template specialization code
> >>> paths, I noticed we
On Sat, Jun 24, 2023 at 9:24 AM Nathaniel Shead
wrote:
>
> On Fri, Jun 23, 2023 at 11:59:51AM -0400, Patrick Palka wrote:
> > Hi,
> >
> > On Sat, 22 Apr 2023, Nathaniel Shead via Gcc-patches wrote:
> >
> > > Bootstrapped and tested on x86_64-pc-linux-gnu.
> > >
> > > -- 8< --
> > >
> > > This
There's currently no cheap way to obtain the partial template
specialization (and arguments relative to it) that was selected for a
class or variable template specialization. Our only option is to
compute the result from scratch via most_specialized_partial_spec.
For class templates this isn't
On Sun, 25 Jun 2023, Nathaniel Shead wrote:
> On Fri, Jun 23, 2023 at 12:43:21PM -0400, Patrick Palka wrote:
> > On Wed, 29 Mar 2023, Nathaniel Shead via Gcc-patches wrote:
> >
> > > This adds rudimentary lifetime tracking in C++ constexpr contexts,
> > > allowing the compiler to report errors
On Wed, 29 Mar 2023, Nathaniel Shead via Gcc-patches wrote:
> This patch caches the current expression's location information in the
> constexpr_global_ctx struct, which allows subexpressions that have lost
> location information to still provide accurate diagnostics. Also
> rewrites a number of
On Wed, 29 Mar 2023, Nathaniel Shead via Gcc-patches wrote:
> Currently, when typeck discovers that a return statement will refer to a
> local variable it rewrites to return a null pointer. This causes the
> error messages for using the return value in a constant expression to be
> unhelpful,
On Wed, 29 Mar 2023, Nathaniel Shead via Gcc-patches wrote:
> This adds rudimentary lifetime tracking in C++ constexpr contexts,
> allowing the compiler to report errors with using values after their
> backing has gone out of scope. We don't yet handle other ways of ending
> lifetimes (e.g.
On Fri, 23 Jun 2023, Jason Merrill wrote:
> On 6/21/23 13:19, Patrick Palka wrote:
> > When stepping through the variable/alias template specialization code
> > paths, I noticed we perform template argument coercion twice: first from
> > instantiate_alias_template / finish_template_variable and
On Sun, 30 Apr 2023, Nathaniel Shead via Gcc-patches wrote:
> This patch ensures that any errors raised by finish_id_expression when
> parsing a decltype expression are properly reported, rather than
> potentially going ignored and causing invalid code to be accepted.
>
> We can also now remove
Hi,
On Sat, 22 Apr 2023, Nathaniel Shead via Gcc-patches wrote:
> Bootstrapped and tested on x86_64-pc-linux-gnu.
>
> -- 8< --
>
> This patch raises an error early when the decltype(auto) specifier is
> used as a parameter of a function. This prevents any issues with an
> unexpected tree type
When stepping through the variable/alias template specialization code
paths, I noticed we perform template argument coercion twice: first from
instantiate_alias_template / finish_template_variable and again from
tsubst_decl (during instantiate_template). It should suffice to perform
coercion
On Tue, 21 Mar 2023, Ken Matsui wrote:
> This patch lets libstdc++ use new built-in trait __is_const.
>
> libstdc++-v3/ChangeLog:
>
> * include/std/type_traits (is_const): Use __is_const built-in trait.
We should also use it in is_const_v (likewise for the __is_array and
__is_volatile
On Mon, 12 Jun 2023, Ken Matsui via Libstdc++ wrote:
> This patch gets std::is_reference to dispatch to new built-in trait
> __is_reference.
>
> libstdc++-v3/ChangeLog:
>
> * include/std/type_traits (is_reference): Use __is_reference built-in
> trait.
> (is_reference_v):
On Mon, 12 Jun 2023, Ken Matsui via Libstdc++ wrote:
> This patch implements built-in trait for std::is_reference.
>
> gcc/cp/ChangeLog:
>
> * cp-trait.def: Define __is_reference.
> * constraint.cc (diagnose_trait_expr): Handle CPTK_IS_REFERENCE.
> * semantics.cc
On Mon, 12 Jun 2023, Ken Matsui via Gcc-patches wrote:
> This patch implements built-in trait for std::is_function.
>
> gcc/cp/ChangeLog:
>
> * cp-trait.def: Define __is_function.
> * constraint.cc (diagnose_trait_expr): Handle CPTK_IS_FUNCTION.
> * semantics.cc
On Mon, 12 Jun 2023, Ken Matsui via Libstdc++ wrote:
> This patch gets std::is_function to dispatch to new built-in trait
> __is_function.
>
> libstdc++-v3/ChangeLog:
>
> * include/std/type_traits (is_function): Use __is_function built-in
> trait.
> (is_function_v): Likewise.
On Mon, 12 Jun 2023, Ken Matsui via Libstdc++ wrote:
> This patch implements built-in trait for std::is_void. Since the new built-in
> name is __is_void, to avoid unintentional macro replacement, this patch also
> involves the removal of the existing __is_void in helper_functions.h and
>
On Thu, 15 Jun 2023, Ken Matsui via Libstdc++ wrote:
> Hi,
>
> For those curious about the performance improvements of this patch, I
> conducted a benchmark that instantiates 256k specializations of
> is_object_v based on Patrick's code. You can find the benchmark code
> at this link:
>
>
On Sat, 17 Jun 2023, Ken Matsui via Gcc-patches wrote:
> Hi,
>
> I conducted a benchmark for remove_pointer as well as is_object. Just
> like the is_object benchmark, here is the benchmark code:
>
> https://github.com/ken-matsui/gcc-benches/blob/main/remove_pointer_benchmark.cc
>
> On my
1 - 100 of 1377 matches
Mail list logo
