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 than substitution into the expanded
alias, and so th
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 template_args_equal was
given a partial_order flag t
On Sat, May 13, 2023 at 7:26 PM Bernhard Reutner-Fischer via
Gcc-patches wrote:
>
> From: Bernhard Reutner-Fischer
>
> gcc/cp/ChangeLog:
>
> * call.cc (promoted_arithmetic_type_p): Use _P defines from tree.h.
> (build_conditional_expr): Ditto.
> (convert_like_internal): Di
On Wed, May 3, 2023 at 9:50 AM Patrick Palka wrote:
>
> This patch makes us coerce the arguments of a variable template-id ahead
> of time, as we do for other template-ids, which allows us to immediately
> diagnose template parameter/argument kind mismatches and arity mismatches.
>
> Unfortunately
Due to level/depth mismatches between the template parameters of a level
lowered ttp and the original ttp, the ttp comparison check added by
r14-418-g0bc2a1dc327af9 never actually holds outside of erroneous cases.
Moreover, it'd be good to cache the overall TEMPLATE_TEMPLATE_PARM
instead of just th
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
The check for a non-template member function of a class template in
is_specialization_of_friend is overbroad, and accidentally holds for a
non-template hidden friend too, which causes the predicate to return
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk?
-- >8 --
r10-7815-gaa576f2a860c82 added special hashing for TEMPLATE_TEMPLATE_PARM
since non-lowered ttps had TYPE_CANONICAL but level lowered ttps did not.
But this is no longer the case ever since r13-737-gd0ef9e061
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk?
-- >8 --
All uses of in_template_function besides the one in cp_make_fname_decl
seem like they could be generalized to apply to all template contexts,
not just function templates. To that end this patch replaces the
Bootstrapped and regtested on x86_64-pc-linu-xgnu, does this look OK for trunk?
-- >8 --
Here we notice the 'this' conversion for the call f() is bad, so
we correctly defer instantiating it, but we end up never adding it to
'bad_fns' since missing_conversion_p for it returns false (its only
argum
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 th
Here when substituting the injected class name A during regeneration of
the lambda, we find ourselves in lookup_template_class for A with
V=_ZTAXtl3BarEE (i.e. the template parameter object for Foo{}). The
call to coerce_template_parms within then undesirably tries to make a copy
of this class NTT
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
In the second testcase of PR110122, during regeneration of the generic
lambda with V=Bar{}, substitution followed by coerce_template_parms for
A's template argument naturally yields a copy of V in terms of Ba
On Wed, 7 Jun 2023, Jason Merrill wrote:
> On 6/6/23 14:29, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> > trunk?
> >
> > -- >8 --
> >
> > In the second testcase of PR110122, during regeneration of the generic
> > lambda with V=Bar{}, substi
When defining a previously declared class template, we neglect to set
TPARMS_PRIMARY_TEMPLATE for the in-scope template parameters, which the
class members go on to inherit, and so the members' DECL_TEMPLATE_PARMS
will have empty TPARMS_PRIMARY_TEMPLATE at those levels as well. This
causes us to c
On Sun, 2 Apr 2023, Ken Matsui via Gcc-patches wrote:
> This patch gets std::is_function to dispatch to new built-in trait
> __is_function.
For std::is_function and other predicate-like type traits, I think we also
want to make the corresponding variable template is_function_v directly
use the bu
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 c
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 exactl
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
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 (write_expressi
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 tem
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 statem
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 wr
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
>
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 wh
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 is_rvalue_constant_ex
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 be
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 mak
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 "c
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 w
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
> > coerce_template_template
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
> sourc
(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. T
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: '
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 previou
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.
gcc/test
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 f
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:
* tr
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 FUNCTION_DEC
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 n
On Wed, Jun 1, 2022 at 3:21 PM Jason Merrill via Gcc-patches
wrote:
>
> This testcase demonstrates that the issue in PR105623 is not limited to
> templates, so we should do the marking in a less template-specific place.
>
> Tested x86_64-pc-linux-gnu, applying to trunk.
>
> PR c++/105779
>
On Fri, 1 Jul 2022, Jason Merrill wrote:
> On 6/29/22 13:42, Patrick Palka wrote:
> > In r13-1045-gcb7fd1ea85feea I assumed that substitution into generic
> > DECL_TI_ARGS corresponds to an identity mapping of the given arguments,
> > and hence its safe to always elide such substitution. But this
On Tue, 5 Jul 2022, Jason Merrill wrote:
> On 7/5/22 10:06, Patrick Palka wrote:
> > On Fri, 1 Jul 2022, Jason Merrill wrote:
> >
> > > On 6/29/22 13:42, Patrick Palka wrote:
> > > > In r13-1045-gcb7fd1ea85feea I assumed that substitution into generic
> > > > DECL_TI_ARGS corresponds to an identi
On Thu, 7 Jul 2022, Jason Merrill wrote:
> On 7/6/22 15:26, Patrick Palka wrote:
> > On Tue, 5 Jul 2022, Jason Merrill wrote:
> >
> > > On 7/5/22 10:06, Patrick Palka wrote:
> > > > On Fri, 1 Jul 2022, Jason Merrill wrote:
> > > >
> > > > > On 6/29/22 13:42, Patrick Palka wrote:
> > > > > > In r
On Thu, 7 Jul 2022, Patrick Palka wrote:
> On Thu, 7 Jul 2022, Jason Merrill wrote:
>
> > On 7/6/22 15:26, Patrick Palka wrote:
> > > On Tue, 5 Jul 2022, Jason Merrill wrote:
> > >
> > > > On 7/5/22 10:06, Patrick Palka wrote:
> > > > > On Fri, 1 Jul 2022, Jason Merrill wrote:
> > > > >
> > > >
Here we incorrectly deem the calls to func1, func2 and tmpl2 as
ambiguous ahead of time ultimately because we mishandle dependence
of a constrained member function from the current instantiation.
In type_dependent_expression_p, we consider the dependence of a
TEMPLATE_DECL's constraints (via uses_
Here we were crashing when substituting a non-dependent call to a
consteval operator, whose CALL_EXPR_OPERATOR_SYNTAX flag we try to
propagate to the result, but the result isn't a CALL_EXPR since the
called function is consteval. This patch fixes this by checking the
result of extract_call_expr a
In case of l/rvalue or cv-qual mismatch during reference binding, we try
to give more helpful diagnostics by attempting a bad conversion that
ignores the mismatch. But in doing so, we may end up instantiating an
ill-formed conversion function, something that would otherwise be
avoided if we didn't
On Mon, 18 Jul 2022, Jason Merrill wrote:
> On 7/18/22 12:59, Patrick Palka wrote:
> > In case of l/rvalue or cv-qual mismatch during reference binding, we try
> > to give more helpful diagnostics by attempting a bad conversion that
> > ignores the mismatch. But in doing so, we may end up instant
During CTAD, we currently perform the first phase of overload resolution
from [over.match.list] only if the class template has a list constructor.
But according to [over.match.class.deduct]/4 it should be enough to just
have a guide that looks like a list constructor (which is a more general
criter
On Thu, 21 Jul 2022, Patrick Palka wrote:
> During CTAD, we currently perform the first phase of overload resolution
> from [over.match.list] only if the class template has a list constructor.
> But according to [over.match.class.deduct]/4 it should be enough to just
> have a guide that looks like
The 11 and 10 partial backports of P2325R3, r11-9555-g92d6121eec and
r10-10808-g22b86cdc4d7fdd, unnecessarily preserved some changes from the
paper that made certain views no longer default constructible, changes
which aren't required to reap the overall benefits of the paper and
which conflict
On Fri, Jul 22, 2022 at 11:52 AM Patrick Palka wrote:
>
> The 11 and 10 partial backports of P2325R3, r11-9555-g92d6121eec and
> r10-10808-g22b86cdc4d7fdd, unnecessarily preserved some changes from the
> paper that made certain views no longer default constructible, changes
> which aren't requ
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
>
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 reje
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
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 (wrapu
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 deduction
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 when
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 13?
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 (dump_generic_n
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 s
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 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.
>
>
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 Fri, 9 Jun 2023, Jonathan Wakely via Libstdc++ wrote:
> Tested powerpc64le-linux. Pushed to trunk.
>
> This makes sense to backport after some soak time on trunk.
>
> -- >8 --
>
> As reported in PR libstdc++/110167, std::to_array compiles extremely
> slowly for very large arrays. It needs to
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 comput
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:
>
> https:
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
> cpp_type_
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 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 (trait_expr_val
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 (trait_expr_va
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): Likewi
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 pat
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 once.
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 l
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 t
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 ag
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. explic
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, espe
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 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 wi
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 re
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 patc
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 perfo
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 the
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 variabl
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++ is
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
gcc/c
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 'ilo
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
[N.B. this is a corrected version of
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607443.html ]
This patch factors out the TYPENAME_TYPE case of tsubst into a separate
function tsubst_typename_type. It also factors out the two tsubst flags
controlling TYPENAME_TYPE substitution, tf_kee
[N.B. this is a corrected version of
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607443.html ]
Currently when resolving a TYPENAME_TYPE for 'typename T::m' via
make_typename_type, we consider only type bindings of 'm' and ignore
non-type ones. But [temp.res.general]/3 says, in a note,
On Tue, 14 Feb 2023, Jason Merrill wrote:
> On 2/13/23 09:23, Patrick Palka wrote:
> > [N.B. this is a corrected version of
> > https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607443.html ]
> >
> > This patch factors out the TYPENAME_TYPE case of tsubst into a separate
> > function tsubst
On Wed, 15 Feb 2023, Jason Merrill wrote:
> On 2/15/23 09:21, Patrick Palka wrote:
> > On Tue, 14 Feb 2023, Jason Merrill wrote:
> >
> > > On 2/13/23 09:23, Patrick Palka wrote:
> > > > [N.B. this is a corrected version of
> > > > https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607443.htm
This fixes some header-defined functions that are undesirably declared
static and weren't caught by the "^static inline" pattern used in the
previous patch.
gcc/ChangeLog:
* hash-table.h (gt_pch_nx): Remove static.
* lra-int.h (lra_change_class): Likewise.
* recog.h (which
On Fri, 17 Feb 2023, Marek Polacek via Gcc-patches wrote:
> Here we crash in is_capture_proxy:
>
> /* Location wrappers should be stripped or otherwise handled by the
> caller before using this predicate. */
> gcc_checking_assert (!location_wrapper_p (decl));
>
> so fixed as the commen
On Fri, 17 Feb 2023, Marek Polacek wrote:
> On Fri, Feb 17, 2023 at 03:00:39PM -0500, Patrick Palka wrote:
> > On Fri, 17 Feb 2023, Marek Polacek via Gcc-patches wrote:
> >
> > > Here we crash in is_capture_proxy:
> > >
> > > /* Location wrappers should be stripped or otherwise handled by the
On Fri, 17 Feb 2023, Patrick Palka wrote:
> On Fri, 17 Feb 2023, Marek Polacek wrote:
>
> > On Fri, Feb 17, 2023 at 03:00:39PM -0500, Patrick Palka wrote:
> > > On Fri, 17 Feb 2023, Marek Polacek via Gcc-patches wrote:
> > >
> > > > Here we crash in is_capture_proxy:
> > > >
> > > > /* Locati
On Sat, 18 Feb 2023, Jason Merrill via Gcc-patches wrote:
> Tested x86_64-pc-linux-gnu. Since this is fixing experimental (C++20)
> functionality, I think it's reasonable to apply now; I'm interested in other
> opinions, and thoughts about the user-facing functionality. I'm thinking to
> make it
According to [basic.start.static]/2 and [expr.const]/2, a variable
with static storage duration initialized with a constant initializer
has constant initialization, and such an initializer is manifestly
constant-evaluated.
We're already getting this right with copy initialization because in
that c
1 - 100 of 1378 matches
Mail list logo
