On Thu, 4 Mar 2021, Patrick Palka wrote:
> My recent r11-7454 changed the way do_auto_deduction handles constrained
> placeholders during template argument deduction (context == adc_unify)
> when processing_template_decl != 0.
>
> Before the patch, when processing_template_dec
On Thu, 4 Mar 2021, Jason Merrill wrote:
> On 3/4/21 11:32 AM, Patrick Palka wrote:
> > On Thu, 4 Mar 2021, Patrick Palka wrote:
> >
> > > My recent r11-7454 changed the way do_auto_deduction handles constrained
> > > placeholders during template argumen
On Thu, 4 Mar 2021, Patrick Palka wrote:
> On Thu, 4 Mar 2021, Jason Merrill wrote:
>
> > On 3/4/21 11:32 AM, Patrick Palka wrote:
> > > On Thu, 4 Mar 2021, Patrick Palka wrote:
> > >
> > > > My recent r11-7454 changed the way do_auto_deduction handl
On Thu, 4 Mar 2021, Patrick Palka wrote:
> On Thu, 4 Mar 2021, Patrick Palka wrote:
>
> > On Thu, 4 Mar 2021, Jason Merrill wrote:
> >
> > > On 3/4/21 11:32 AM, Patrick Palka wrote:
> > > > On Thu, 4 Mar 2021, Patrick Palka wrote:
> > >
This makes tsubst_copy appropriately handle a variable template-id, which
in turn fixes tsubsting a COMPONENT_REF whose member operand is known at
parse time to be a variable template-id, as in the initialization of 'x'
in the first testcase. Previously, we rejected this testcase with the
error "f
Here, during cxx_eval_increment_expression (with lval=false) of
++__first where __first is &"mystr"[0], we correctly update __first
to &"mystr"[1] but we end up returning &"mystr"[0] + 1 instead of
&"mystr"[1]. This unreduced return value inhibits other pointer
arithmetic folding during later cons
On Fri, 5 Mar 2021, Jason Merrill wrote:
> On 3/4/21 9:55 PM, Patrick Palka wrote:
> > On Thu, 4 Mar 2021, Patrick Palka wrote:
> >
> > > On Thu, 4 Mar 2021, Patrick Palka wrote:
> > >
> > > > On Thu, 4 Mar 2021, Jason Merrill wrote:
> > >
On Fri, 5 Mar 2021, Jason Merrill wrote:
> On 3/5/21 1:05 PM, Patrick Palka wrote:
> > Here, during cxx_eval_increment_expression (with lval=false) of
> > ++__first where __first is &"mystr"[0], we correctly update __first
> > to &"mystr"[1] b
Here during constexpr evaluation of
std::construct_at(&a._M_value)
we find ourselves in cxx_eval_store_expression where the target object
is 'a._M_value' and the initializer is {}. Since _M_value is an empty
[[no_unique_address]] member we don't create a sub-CONSTRUCTOR for it,
so we end up in
Here we're rejecting the default template argument
requires (T t) { x(t); }
because we consider the 't' in the requirement to be a local variable
(according to local_variable_p), and we generally forbid local variables
from appearing inside template arguments. We can perhaps fix this by
giving
Here grokdeclarator is emitting the error
error: class template placeholder ‘Foo’ not permitted in this context
during the tentative (and ultimately futile) parse of 'x' as a function
declaration. This happens because when parsing 'Foo{1}',
cp_parser_parameter_declaration yields an parameter d
It looks like we still don't recognize class-scope non-template
deduction guides even after r12-2260. This is because deduction guides
are handled in cp_parser_init_declarator after calling
cp_parser_declarator, but in the class-scope non-template case we call
cp_parser_declarator directly from c
On Wed, Jul 28, 2021 at 4:42 PM Jason Merrill wrote:
>
> On 7/19/21 6:05 PM, Patrick Palka wrote:
> > Constraint subsumption is implemented in two steps. The first step
> > computes the disjunctive (or conjunctive) normal form of one of the
> > constraints, and the second
On Wed, 11 Aug 2021, Jason Merrill wrote:
> On 8/9/21 5:07 PM, Patrick Palka wrote:
> > On Wed, Jul 28, 2021 at 4:42 PM Jason Merrill wrote:
> > >
> > > On 7/19/21 6:05 PM, Patrick Palka wrote:
> > > > Constraint subsumption is implemented in two step
On Wed, 11 Aug 2021, Jason Merrill wrote:
> On 8/9/21 1:16 PM, Patrick Palka wrote:
> > It looks like we still don't recognize class-scope non-template
> > deduction guides even after r12-2260. This is because deduction guides
> > are handled in cp_parser_ini
During aggregate CTAD, collect_ctor_idx_types always recurses into a
sub-CONSTRUCTOR, regardless of whether the corresponding pair of braces
was elided in the original initializer. This causes us to reject some
completely-braced forms of aggregate CTAD as in the first testcase
below, because colle
Since (template) argument passing is a copy-initialization context,
we mustn't consider explicit deduction guides when deducing a CTAD
placeholder type of an NTTP.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk/11?
PR c++/101883
gcc/cp/ChangeLog:
On Mon, 16 Aug 2021, Marek Polacek wrote:
> On Mon, Aug 16, 2021 at 03:06:08PM -0400, Patrick Palka via Gcc-patches wrote:
> > During aggregate CTAD, collect_ctor_idx_types always recurses into a
> > sub-CONSTRUCTOR, regardless of whether the corresponding pair of braces
> &
During overload resolution, when the arity of a function template
clearly disagrees with the arity of the call, no specialization of the
function template could yield a viable candidate. The deduction routine
type_unification_real already notices this situation, but not before
it substitutes expli
In the context of overload resolution we have the notion of a "bad"
argument conversion, which is a conversion that "would be a permitted
with a bending of the language standards", and we handle such bad
conversions specially. In particular, we rank a bad conversion as
better than no conversion bu
Here when partially substituting into the pack expansion, substitution
into the constexpr if yields a still-dependent tree, so tsubst_expr
returns an IF_STMT with an unsubstituted IF_COND and with
IF_STMT_EXTRA_ARGS added to. Hence after partial substitution
the pack expansion pattern still refers
On Thu, 13 Aug 2020, Jason Merrill wrote:
> On 8/13/20 11:21 AM, Patrick Palka wrote:
> > On Mon, 10 Aug 2020, Jason Merrill wrote:
> >
> > > On 8/10/20 2:18 PM, Patrick Palka wrote:
> > > > On Mon, 10 Aug 2020, Patrick Palka wrote:
> > > >
>
On Wed, 16 Sep 2020, Jason Merrill wrote:
> On 9/16/20 1:34 PM, Patrick Palka wrote:
> > On Thu, 13 Aug 2020, Jason Merrill wrote:
> >
> > > On 8/13/20 11:21 AM, Patrick Palka wrote:
> > > > On Mon, 10 Aug 2020, Jason Merrill wrote:
> > > >
&
According to [expr.const]/14, the result of substitution into an atomic
constraint is manifestly constant-evaluated; this patch adjusts the call
to maybe_constant_value in satisfy_atom to that effect.
Tested on x86_64-pc-linux-gnu, and also tested on the cmcstl2 and
range-v3 libraries. Does this
On Thu, 10 Sep 2020, Patrick Palka wrote:
> On Thu, 10 Sep 2020, David Malcolm wrote:
>
> > On Tue, 2020-07-28 at 20:22 -0400, Patrick Palka wrote:
> > > On Tue, 28 Jul 2020, David Malcolm wrote:
> > >
> > > > On Tue, 2020-07-28 at 15:50 -0400, Pa
With r10-8077 we stopped passing the argified current_template_parms to
normalize_constraint_expression from finish_nested_requirement, and
instead tweaked map_arguments to perform a self-mapping of parameters
when args is NULL. We're currently not handling parameter packs and
BOUND_TEMPLATE_TEMPL
On Fri, 18 Sep 2020, Jason Merrill wrote:
> On 9/18/20 4:07 PM, Patrick Palka wrote:
> > With r10-8077 we stopped passing the argified current_template_parms to
> > normalize_constraint_expression from finish_nested_requirement, and
> > instead tweaked map_arguments to perf
On Fri, 18 Sep 2020, Patrick Palka wrote:
> On Fri, 18 Sep 2020, Jason Merrill wrote:
>
> > On 9/18/20 4:07 PM, Patrick Palka wrote:
> > > With r10-8077 we stopped passing the argified current_template_parms to
> > > normalize_constraint_expression from
This fixes a division by zero in the selection-sampling std::__search
overload when the input range is empty (and hence __unsampled_sz is 0).
Tested on x86_64-pc-linux-gnu.
libstdc++-v3/ChangeLog:
* include/bits/stl_algo.h (__sample): Exit early when the
input range is empty.
As per P0202.
Tested on x86_64-pc-linux-gnu.
libstdc++-v3/ChangeLog:
* include/bits/stl_algo.h (for_each_n): Mark constexpr for C++20.
(search): Likewise for the overload that takes a searcher.
* testsuite/25_algorithms/for_each/constexpr.cc: Test constexpr
std::f
In the testcase below, the dependent specializations iter_reference_t
and iter_reference_t share the same tree due to specialization
caching. So when find_template_parameters walks through the
requires-expression (as part of normalization), it sees and includes the
out-of-scope template parameter
On Fri, 18 Sep 2020, Patrick Palka wrote:
> This fixes a division by zero in the selection-sampling std::__search
Whoops, this line say std::__sample, not std::__search.
> overload when the input range is empty (and hence __unsampled_sz is 0).
>
> Tested on x86_64-pc-linux-gnu.
For a span with empty static extent, we currently model the
preconditions of front(), back(), and operator[] as if they were
mandates, by using a static_assert to verify that extent != 0. This
causes us to incorrectly reject valid programs that instantiate these
member functions but never call the
On Mon, 21 Sep 2020, Patrick Palka wrote:
> For a span with empty static extent, we currently model the
> preconditions of front(), back(), and operator[] as if they were
> mandates, by using a static_assert to verify that extent != 0. This
> causes us to incorrectly reject valid p
On Mon, 21 Sep 2020, Jason Merrill wrote:
> On 9/19/20 3:49 PM, Patrick Palka wrote:
> > In the testcase below, the dependent specializations iter_reference_t
> > and iter_reference_t share the same tree due to specialization
> > caching. So when find_template_paramet
On Tue, 22 Sep 2020, Patrick Palka wrote:
> On Mon, 21 Sep 2020, Jason Merrill wrote:
>
> > On 9/19/20 3:49 PM, Patrick Palka wrote:
> > > In the testcase below, the dependent specializations iter_reference_t
> > > and iter_reference_t share the same tree due to spe
Fixed by r11-3361.
gcc/testsuite/ChangeLog:
PR c++/96652
* g++.dg/cpp0x/decltype-96652.C: New test.
---
gcc/testsuite/g++.dg/cpp0x/decltype-96652.C | 14 ++
1 file changed, 14 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/decltype-96652.C
diff --git a/
The class template semiregular-box defined in [range.semi.wrap] is
used by a number of views to accomodate non-semiregular subobjects
while ensuring that the overall view remains semiregular. It provides
a stand-in default constructor, copy assignment operator and move
assignment operator whenever
In the testcase concepts7.C below, we currently reject the call to f1
but we accept the call to f2, even though their associated constraints
are functionally equivalent.
The reason satisfaction differs for (!!C is due to normalization: the former is already an
atom, and the latter is not. Normali
libstdc++-v3/ChangeLog:
* include/bits/ranges_util.h (subrange::_M_end): Give it
[[no_unique_adcress]].
* testsuite/std/ranges/subrange/sizeof.cc: New test.
---
libstdc++-v3/include/bits/ranges_util.h | 2 +-
.../testsuite/std/ranges/subrange/sizeof.cc | 28 ++
libstdc++-v3/ChangeLog:
* include/std/ranges (iota_view::_M_bound): Give it
[[no_unique_address]].
* testsuite/std/ranges/iota/iota_view.cc: Check that an
unbounded iota_view has minimal size.
---
libstdc++-v3/include/std/ranges | 2 +-
libstdc+
libstdc++-v3/ChangeLog:
* testsuite/std/ranges/adaptors/sizeof.cc: New test.
---
.../testsuite/std/ranges/adaptors/sizeof.cc | 49 +++
1 file changed, 49 insertions(+)
create mode 100644 libstdc++-v3/testsuite/std/ranges/adaptors/sizeof.cc
diff --git a/libstdc++-v3/tes
Since the standard range adaptors are specified to derive from the empty
class view_base, making their first data member store the underlying
view is suboptimal, for if the underlying view also derives from
view_base then the two view_base subobjects will be adjacent, thus
preventing the compiler f
On Mon, 28 Sep 2020, Jonathan Wakely wrote:
> On 28/09/20 00:48 -0400, Patrick Palka via Libstdc++ wrote:
> > Since the standard range adaptors are specified to derive from the empty
> > class view_base, making their first data member store the underlying
> > view is s
On Mon, 28 Sep 2020, Jason Merrill wrote:
> On 9/25/20 4:44 PM, Patrick Palka wrote:
> > In the testcase concepts7.C below, we currently reject the call to f1
> > but we accept the call to f2, even though their associated constraints
> > are functionally equivalent.
>
&g
In the testcase below, during processing (at parse time) of Y's base
class X, convert_template_argument calls is_compatible_template_arg
to check if the template argument Y is no more constrained than the
parameter P. But at this point we haven't yet set Y's constraints, so
get_normalized_constrai
This patch fixes an "unguarded" call to coerce_template_parms in
build_standard_check: processing_template_decl could be zero if we
we get here during processing of the first 'auto' parameter of an
abbreviated function template. In the testcase below, this leads to an
ICE when coerce_template_parm
This rewrites ranges::construct_at in terms of std::construct_at so
that we can piggy back on the compiler's existing support for
recognizing placement new within std::construct_at during constexpr
evaluation instead of having to additionally teach the compiler about
ranges::construct_at.
While we
I noticed that the following changes from this paper were not yet
implemented.
OK to commit after testing on x86_64-pc-linux-gnu finishes successfully?
libstdc++-v3/ChangeLog:
* include/bits/stl_iterator.h (reverse_iterator::iter_move):
Define for C++20 as per P0896.
(rev
cp_tree_equal currently considers alignof the same as __alignof__, but
these operators are semantically different ever since r8-7957. In the
testcase below, this causes the second static_assert to fail on targets
where alignof(double) != __alignof__(double) because the specialization
cache (which
On Wed, 30 Sep 2020, Jason Merrill wrote:
> On 9/29/20 5:01 PM, Patrick Palka wrote:
> > This patch fixes an "unguarded" call to coerce_template_parms in
> > build_standard_check: processing_template_decl could be zero if we
> > we get here during processing of t
On Tue, 6 Oct 2020, Jason Merrill wrote:
> On 10/5/20 4:30 PM, Patrick Palka wrote:
> > On Wed, 30 Sep 2020, Jason Merrill wrote:
> >
> > > On 9/29/20 5:01 PM, Patrick Palka wrote:
> > > > This patch fixes an "unguarded" call to coerce_
On Tue, 29 Sep 2020, Patrick Palka wrote:
> In the testcase below, during processing (at parse time) of Y's base
> class X, convert_template_argument calls is_compatible_template_arg
> to check if the template argument Y is no more constrained than the
> parameter P. But at this
On Wed, 30 Sep 2020, Patrick Palka wrote:
> This rewrites ranges::construct_at in terms of std::construct_at so
> that we can piggy back on the compiler's existing support for
> recognizing placement new within std::construct_at during constexpr
> evaluation instead of havin
In the testcase below, we're ICEing during constexpr evaluation of the
CONSTRUCTOR {.data={{}, [1 ... 7]={}}} of type 'vector'. The apparently
unique thing about this CONSTRUCTOR is that it has a RANGE_EXPR index
whose corresponding sub-aggregate initializer doesn't satisfy
reduced_constant_expres
It looks like we aren't respecting SFINAE for:
* an invalid/non-constant conditional explicit-specifier
* a non-constant conditional noexcept-specifier
* a non-constant argument to __integer_pack
This patch fixes these issues in the usual way, by passing complain
and propagating error_mark_
On Tue, 13 Sep 2022, Jason Merrill wrote:
> On 9/13/22 07:45, Patrick Palka wrote:
> > It looks like we aren't respecting SFINAE for:
> >
> >* an invalid/non-constant conditional explicit-specifier
> >* a non-constant conditional noexcept-specifier
>
Tested on x86_64-pc-linux-gnu, committed to trunk as obvious.
gcc/cp/ChangeLog:
* cp-tree.h (mark_used): Remove single-parameter overload. Add
default argument to the two-parameter overload.
* decl2.cc (mark_used): Likewise.
---
gcc/cp/cp-tree.h | 4 ++--
gcc/cp/decl2.cc
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
libstdc++-v3/ChangeLog:
* include/bits/ranges_algo.h (__adjacent_find_fn, adjacent_find):
Move to ...
* include/bits/ranges_util.h: ... here.
* include/std/ranges (chunk_by_view): Define.
(chunk_by
Here we're crashing during constraint matching for the instantiated
hidden friends due to two issues with dependent substitution into a
TEMPLATE_ID_EXPR naming a template from the current instantiation
(as performed from maybe_substitute_reqs_for for C<3> with T=T):
* tsubst_copy substitutes int
This patch permits accessing 'mutable' members of local objects during
constexpr evaluation (which other compilers seem to accept in C++14
mode, while we reject), while continuing to reject it for global objects
(as in the last line of cpp0x/constexpr-mutable1.C, which other
compilers also reject).
A couple of xtreme-header-* modules tests began ICEing in C++23 mode
ever since r13-2650-g5d84a4418aa962 introduced into the
dependently scoped friend declaration
friend /* typename */ _OuterIter::value_type;
ultimately because the streaming code assumes a TYPE_P friend must
be a class type, b
On Fri, 16 Sep 2022, Jason Merrill wrote:
> On 9/15/22 11:58, Patrick Palka wrote:
> > Here we're crashing during constraint matching for the instantiated
> > hidden friends due to two issues with dependent substitution into a
> > TEMPLATE_ID_EXPR naming a template from
On Fri, 16 Sep 2022, Patrick Palka wrote:
> On Fri, 16 Sep 2022, Jason Merrill wrote:
>
> > On 9/15/22 11:58, Patrick Palka wrote:
> > > Here we're crashing during constraint matching for the instantiated
> > > hidden friends due to two issues
uct C { static_assert(A::value == 42); };
--
2.38.0.rc0
>
> nathan
>
> On Thu, Sep 15, 2022, 22:16 Patrick Palka wrote:
> A couple of xtreme-header-* modules tests began ICEing in C++23 mode
> ever since r13-2650-g5d84a4418aa962 introduced into the
> depend
On Sat, 17 Sep 2022, Jason Merrill wrote:
> On 9/16/22 10:59, Patrick Palka wrote:
> > On Fri, 16 Sep 2022, Jason Merrill wrote:
> >
> > > On 9/15/22 11:58, Patrick Palka wrote:
> > > > Here we're crashing during constraint matching for the instantiated
It looks like some xtreme-header-* tests are failing after the libstdc++
change r13-2158-g02f6b405f0e9dc ultimately because we're neglecting
to stream PACK_EXPANSION_EXTRA_ARGS, which leads to false equivalences
of different partial instantiations of _TupleConstraints::__constructible.
Tested on x
On Tue, 20 Sep 2022, Nathan Sidwell wrote:
> On 9/19/22 09:52, Patrick Palka wrote:
> > It looks like some xtreme-header-* tests are failing after the libstdc++
> > change r13-2158-g02f6b405f0e9dc ultimately because we're neglecting
> > to stream PACK_EXPANSION_EXTRA_
The modules streaming code seems to rely on the invariant that a
TEMPLATE_DECL and its DECL_TEMPLATE_RESULT have the same TREE_TYPE.
But for a templated VAR_DECL with deduced non-dependent type, the two
TREE_TYPEs end up diverging: cp_finish_decl deduces the type of the
initializer ahead of time an
This adds some recently implemented C++20/23 library headers to the
xtreme-header tests as appropriate. Also, it looks like we can safely
re-add and remove the NO_ASSOCIATED_LAMBDA workaround.
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
gcc/testsuite/ChangeLog:
* g++.dg
With partial variable template specializations, it looks like we
stream the VAR_DECL (i.e. the DECL_TEMPLATE_RESULT of the corresponding
TEMPLATE_DECL) since process_partial_specialization adds it to the
specializations table, but end up never streaming the corresponding
TEMPLATE_DECL itself that a
When streaming in the artificial VAR_DECL synthesized for a class NTTP
argument, we end up crashing from complete_vars because the call to
maybe_register_incomplete_var from add_module_namespace_decl for this
VAR_DECL pushes an unexpected NULL_TREE type onto the incomplete_vars
vector.
This patch
On Thu, 22 Sep 2022, Nathan Sidwell wrote:
> On 9/22/22 14:25, Patrick Palka wrote:
>
> > index 80467c19254..722b64793ed 100644
> > --- a/gcc/cp/decl.cc
> > +++ b/gcc/cp/decl.cc
> > @@ -18235,9 +18235,11 @@ maybe_register_incomplete_var (tree var)
> > {
In r13-2775-g32d8123cd6ce87 I overlooked that we need to adjust the
call to add_mergeable_specialization in the MK_partial case to correctly
handle variable template partial specializations (it currently assumes
we're always dealing with one for a class template). This fixes an ICE
when converting
On Mon, 26 Sep 2022, Marek Polacek via Gcc-patches wrote:
> Jon reported that evaluating __is_convertible in this test leads to
> instantiating char_traits::eq, which is invalid (because we
> are trying to call a member function on a char) and so we fail to
> compile the test. __is_convertible do
On Mon, 26 Sep 2022, Nathan Sidwell wrote:
> On 9/26/22 10:08, Nathan Sidwell wrote:
> > On 9/23/22 09:32, Patrick Palka wrote:
> >
> > > Judging by the two commits that introduced/modified this part of
> > > maybe_register_incomplete_var, r196852 and r214333, I
On Mon, 26 Sep 2022, Patrick Palka wrote:
> On Mon, 26 Sep 2022, Nathan Sidwell wrote:
>
> > On 9/26/22 10:08, Nathan Sidwell wrote:
> > > On 9/23/22 09:32, Patrick Palka wrote:
> > >
> > > > Judging by the two commits that introduced/modified this par
We already have generic support for predicate-like traits that yield a
boolean via TRAIT_EXPR, but we lack the same support for transform-like
traits that yield a type. Such support would be useful for implementing
efficient built-ins for std::decay and std::remove_cvref and other
conceptually sim
This uses TRAIT_TYPE from the previous patch to implement efficient
built-ins for std::remove_cv, std::remove_reference and std::remove_cvref.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk?
gcc/c-family/ChangeLog:
* c-common.cc (c_common_reswords): Add __
On Tue, 27 Sep 2022, Nathan Sidwell wrote:
> On 9/26/22 15:05, Patrick Palka wrote:
> > On Mon, 26 Sep 2022, Patrick Palka wrote:
> >
> > > On Mon, 26 Sep 2022, Nathan Sidwell wrote:
> > >
> > > > On 9/26/22 10:08, Nathan Sidwell wrote:
&g
On Tue, 27 Sep 2022, Jason Merrill wrote:
> On 9/27/22 15:50, Patrick Palka wrote:
> > We already have generic support for predicate-like traits that yield a
> > boolean via TRAIT_EXPR, but we lack the same support for transform-like
> > traits that yield a type. Such suppor
Adding a new builtin trait currently involves some boilerplate (as can
be seen in r13-2956-g9ca147154074a0) of defining corresponding RID_ and
CPTK_ enumerators and adding them to various switch statements across
many files. The exact switch statements we need to change is determined
by whether th
On Thu, 29 Sep 2022, Patrick Palka wrote:
> Adding a new builtin trait currently involves some boilerplate (as can
> be seen in r13-2956-g9ca147154074a0) of defining corresponding RID_ and
> CPTK_ enumerators and adding them to various switch statements across
> many files. The
On Thu, 29 Sep 2022, Marek Polacek wrote:
> On Thu, Sep 29, 2022 at 11:05:04AM -0400, Patrick Palka via Gcc-patches wrote:
> > Adding a new builtin trait currently involves some boilerplate (as can
> > be seen in r13-2956-g9ca147154074a0) of defining corresponding RID_ and
> &
On Thu, 29 Sep 2022, Nathan Sidwell wrote:
>
> This adds smarts to the module machinery to handle NTTP object
> VAR_DECLs. Like typeinfo objects, these must be ignored in the symbol
> table, streamed specially and recreated on stream in.
>
> Patrick, thanks for the testcase, I don't know how to
On Thu, 29 Sep 2022, Jason Merrill wrote:
> On 9/29/22 11:05, Patrick Palka wrote:
> > Adding a new builtin trait currently involves some boilerplate (as can
> > be seen in r13-2956-g9ca147154074a0) of defining corresponding RID_ and
> > CPTK_ enumerators and adding t
On Fri, 30 Sep 2022, Nathan Sidwell wrote:
> Hi,
> I've discovered some mangling problems with lambdas. (a) divergence from
> clang and (b) manglings that incorrectly demangle. With #a I'm not yet sure
> who is correct. for #b g++ is definitely wrong.
>
> From the docs, it doesn't appear to ha
This replaces the unreachable default case in some cp_trait_kind
switches with an exhaustive listing of the _unexpected_ trait codes,
so that when adding a new trait we'll get a -Wswitch diagnostic if we
forget to handle the trait code in one of these switches.
Bootstrappend and regtested on x86_6
On Fri, 30 Sep 2022, Patrick Palka wrote:
> This replaces the unreachable default case in some cp_trait_kind
> switches with an exhaustive listing of the _unexpected_ trait codes,
> so that when adding a new trait we'll get a -Wswitch diagnostic if we
> forget to handle the tra
On Fri, 30 Sep 2022, Jason Merrill wrote:
> On 9/30/22 11:14, Patrick Palka wrote:
> > On Thu, 29 Sep 2022, Jason Merrill wrote:
> >
> > > On 9/29/22 11:05, Patrick Palka wrote:
> > > > Adding a new builtin trait currently involves some boilerplate
This is apparently needed since we include cp-trait.def from cp-tree.h
(in order to define the cp_trait_kind enum), as with operators.def.
Tested on x86_64-pc-linux-gnu by doing make install and verifying
cp-trait.def appears in
$prefix/lib/gcc/x86_64-pc-linux-gnu/13.0.0/plugin/include/cp/
Doe
Tested on x86_64-pc-linux-gnu, does this look OK for trunk? FWIW using
variant<_PatternIter, _InnerIter> in the implementation means we need to
include from , which increases the preprocessed size
of by 3% (51.5k vs 53k). I suppose that's an acceptable cost?
libstdc++-v3/ChangeLog:
*
On Tue, 4 Oct 2022, Jonathan Wakely wrote:
> On Tue, 4 Oct 2022 at 02:11, Patrick Palka via Libstdc++
> wrote:
> >
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk? FWIW using
>
> OK, thanks.
Thanks a lot, patch committed.
>
> > variant
Here when lazily loading the binding for f at parse time from the
template g, processing_template_decl is set and thus the call to
note_vague_linkage_fn from module_state::read_cluster has no effect,
and we never push f onto deferred_fns and end up never emitting its
definition.
ISTM the behavior
On Tue, 4 Oct 2022, Patrick Palka wrote:
> Here when lazily loading the binding for f at parse time from the
> template g, processing_template_decl is set and thus the call to
> note_vague_linkage_fn from module_state::read_cluster has no effect,
> and we never push f onto deferred_fn
On Thu, 7 Jul 2022, Jonathan Wakely via Gcc-patches wrote:
> This adds a new built-in to replace the recursive class template
> instantiations done by traits such as std::tuple_element and
> std::variant_alternative. The purpose is to select the Nth type from a
> list of types, e.g. __builtin_type
Roughly speaking, optimize_specialization_lookup_p returns true
for a non-template member function of a class template, e.g.
template struct A { int f(); };
The idea behind the optimization in question seems to be that if we want
to look up the specialization A::f [with T=int], then we can just
The below testcase fails to link with the error
undefined reference to `f()::y'
ultimately because during stream out for the static VAR_DECL y we
override DECL_EXTERNAL to true, which later during IPA confuses
symbol_table::remove_unreachable_nodes into thinking it's safe
to not emit the symbol
According to grokbitfield, DECL_BITFIELD_REPRESENTATIVE may "temporarily"
contain the width of the bitfield until we layout the class type (after
which it'll contain a FIELD_DECL). But for a class template, it'll always
be the width since we don't/can't layout dependent types.
Tested on x86_64-pc
On Fri, 7 Oct 2022, Nathan Sidwell wrote:
> On 10/7/22 11:09, Patrick Palka wrote:
> > According to grokbitfield, DECL_BITFIELD_REPRESENTATIVE may "temporarily"
> > contain the width of the bitfield until we layout the class type (after
> > which it'll con
1401 - 1500 of 2590 matches
Mail list logo
