Here the two BOUND_TEMPLATE_TEMPLATE_PARMs written as C end
up having the same TYPE_CANONICAL since the ctp_table (which interns the
canonical form of a template type parameter) doesn't set the
comparing_specializations flag which controls how PARM_DECLs from
different DECL_CONTEXTs compare equal.
On Thu, 1 Dec 2022, Jason Merrill wrote:
> On 12/1/22 11:37, Patrick Palka wrote:
> > When defining a explicit specialization of a constrained member template
> > (of a class template) such as f and g in the below testcase, the
> > DECL_TEMPLATE_PARMS of the corres
When defining a explicit specialization of a constrained member template
(of a class template) such as f and g in the below testcase, the
DECL_TEMPLATE_PARMS of the corresponding TEMPLATE_DECL are partially
instantiated, whereas its associated constraints are carried over
from the original
In a SFINAE context composite_pointer_type returns error_mark_node if
the given pointer types are incompatible, but the SPACESHIP_EXPR case of
cp_build_binary_op wasn't prepared to handle error_mark_node, which led
to an ICE (from spaceship_comp_cat) for the below testcase where we form
a <=> with
On Mon, 28 Nov 2022, Patrick Palka wrote:
> [temp.res.general]/3 says, in a note, "the usual qualified name lookup
> ([basic.lookup.qual]) applies even in the presence of typename". Thus
> when resolving a TYPENAME_TYPE, it seems we shouldn't be looking past
> non-type me
[temp.res.general]/3 says, in a note, "the usual qualified name lookup
([basic.lookup.qual]) applies even in the presence of typename". Thus
when resolving a TYPENAME_TYPE, it seems we shouldn't be looking past
non-type members.
This patch fixes this by passing want_type=false instead of =true
Here we're crashing when using an explicit specialization of a function
template with trailing requirements ultimately because decls_match
(called indirectly from register_specialization) returns false since the
template has trailing requirements whereas the specialization doesn't.
In
IIUC the only practical difference between coerce_innermost_template_parms
and the main function coerce_template_parms is that the former takes
a multi-level template parameter list and returns a template argument
vector of the same depth, whereas the latter takes a single-level
template parameter
We already cache the overall normal form of a declaration's constraints
under the assumption that it can't change over the translation unit.
But if we have two constrained declarations such as
template void f() requires expensive && A;
template void g() requires expensive && B;
then despite
On Tue, 15 Nov 2022, Patrick Palka wrote:
> When linking with a static library, the linker seems to exclude a
> constituent .o object (including its global initializers) if nothing
> from it is referenced by the program (unless e.g. --whole-archive is
> used). This behavior breaks i
When linking with a static library, the linker seems to exclude a
constituent .o object (including its global initializers) if nothing
from it is referenced by the program (unless e.g. --whole-archive is
used). This behavior breaks iostream when linking with static libstdc++.a
(on systems that
On Mon, 14 Nov 2022, Jonathan Wakely wrote:
> On Mon, 14 Nov 2022 at 10:17, Daniel Krügler
> wrote:
> >
> > Am Mo., 14. Nov. 2022 um 11:09 Uhr schrieb Jonathan Wakely via
> > Libstdc++ :
> > >
> > > On Mon, 14 Nov 2022 at 04:52, Patrick Palka via Libs
On Mon, 14 Nov 2022, Jonathan Wakely wrote:
> On Mon, 14 Nov 2022 at 04:51, Patrick Palka via Libstdc++
> wrote:
> >
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
> >
> > libstdc++-v3/ChangeLog:
> >
> > * include/bits/range
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
libstdc++-v3/ChangeLog:
* include/bits/ranges_algo.h (__find_last_fn, find_last):
Define.
(__find_last_if_fn, find_last_if): Define.
(__find_last_if_not_fn, find_last_if_not): Define.
*
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
libstdc++-v3/ChangeLog:
* include/bits/ranges_algo.h (out_value_result): Define.
(iota_result): Define.
(__iota_fn, iota): Define.
* testsuite/25_algorithms/iota/1.cc: New test.
---
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
libstdc++-v3/ChangeLog:
* include/bits/ranges_algo.h (__contains_fn, contains): Define.
(__contains_subrange_fn, contains_subrange): Define.
* testsuite/25_algorithms/contains/1.cc: New test.
*
The commit r13-3706-gd0a492faa6478c for correcting the result of
__has_attribute(init_priority) causes a bootstrap failure on hppa64-hpux
because it assumes SUPPORTS_INIT_PRIORITY expands to a simple constant,
but on this target SUPPORTS_INIT_PRIORITY is defined as
#define
On Fri, 11 Nov 2022, Jonathan Wakely via Libstdc++ wrote:
> On Fri, 11 Nov 2022 at 11:23, Nathaniel Shead via Libstdc++
> wrote:
> >
> > Hi,
> >
> > Below is a patch to fix std::string in constexpr contexts on Clang. This
> > was originally fixed in the commits attached to PR103295, but a later
On Thu, 10 Nov 2022, Patrick Palka wrote:
> AFAICT the only purpose of tsubst_copy_and_build's
> integral_constant_expression_p boolean parameter is to diagnose certain
> constructs that aren't allowed to appear in a C++98 integral constant
> expression context, specifically ca
AFAICT the only purpose of tsubst_copy_and_build's
integral_constant_expression_p boolean parameter is to diagnose certain
constructs that aren't allowed to appear in a C++98 integral constant
expression context, specifically casts to a non-integral type (diagnosed
from the *_CAST_EXPR case of
The function_p parameter of tsubst_copy_and_build (added in r69316) is
inspected only in its IDENTIFIER_NODE case, where it controls whether we
diagnose unqualified name lookup failure for the given identifier. But
I think ever since r173965, we never substitute an IDENTIFIER_NODE with
On Thu, 27 Oct 2022, Patrick Palka wrote:
> On Thu, 27 Oct 2022, Patrick Palka wrote:
>
> > This also implements the proposed resolutions of the tentatively ready
> > LWG issues 3760 and 3761.
> >
> > I'm not sure how/if we should impl
On Fri, 4 Nov 2022, Florian Weimer wrote:
> * Patrick Palka via Gcc-patches:
>
> > This patch moves the global object for constructing the standard streams
> > out from and into the compiled library on targets that support
> > the init_priority attribute. Th
On Fri, 4 Nov 2022, Jonathan Wakely wrote:
> On Fri, 4 Nov 2022 at 15:08, Patrick Palka via Libstdc++
> wrote:
> >
> > This patch moves the global object for constructing the standard streams
> > out from and into the compiled library on targets that support
> &g
This patch moves the global object for constructing the standard streams
out from and into the compiled library on targets that support
the init_priority attribute. This means that no longer
introduces a separate global constructor in each TU that includes it.
We can do this only if the
Currently __has_attribute(init_priority) always returns true, even on
targets that don't actually support init priorities, and when using
the attribute on such targets, we issue a hard error that init
priorities are unsupported. This makes it impossible to conditionally
use the attribute by
Like during satisfaction, we need to check access immediately during
substitution of a requires-expr since the outcome of an access check can
determine the value of the requires-expr. And otherwise, in contexts
where access checking is deferred (such as during substitution into a
base-clause), a
We're rejecting the below testcase with
error: 'virtual constexpr Base::~Base()' used before its definition
error: 'virtual constexpr Derived::~Derived()' used before its definition
due to an early exit added to mark_used by r181272 to defer synthesis of
virtual destructors until EOF where
IIUC such variables should be declared inline to avoid potential ODR
violations since they're otherwise considered to be distinct (internal
linkage) entities across TUs.
The changes inside the regex_constants and execution namespace seem to
be unimplemented parts of P0607R0; the rest of the
The fallback implementation of floating-point std::from_chars for e.g.
float80 just calls the C library's strtod family of functions. In case
of overflow of the parsed result, the behavior of these functions is
rigidly specified:
If the correct value overflows and default rounding is in
On Tue, 1 Nov 2022, Jonathan Wakely wrote:
> On Tue, 1 Nov 2022 at 12:18, Jakub Jelinek wrote:
> >
> > On Fri, Oct 28, 2022 at 12:52:44PM -0400, Patrick Palka wrote:
> > > > The following patch on top of
> > > > https://gcc.gnu.org/pipermail/libstdc++/20
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
libstdc++-v3/ChangeLog:
* include/std/ranges (as_rvalue_view): Define.
(enable_borrowed_range): Define.
(views::__detail::__can_as_rvalue_view): Define.
(views::_AsRvalue, views::as_rvalue): Define.
On Thu, 27 Oct 2022, Jakub Jelinek wrote:
> Hi!
>
> The following patch on top of
> https://gcc.gnu.org/pipermail/libstdc++/2022-October/054849.html
> adds std::{,b}float16_t support for std::to_chars.
> When precision is specified (or for std::bfloat16_t for hex mode even if not),
> I believe
On Thu, 27 Oct 2022, Patrick Palka wrote:
> This also implements the proposed resolutions of the tentatively ready
> LWG issues 3760 and 3761.
>
> I'm not sure how/if we should implement the recommended practice of:
>
> difference_type should be the smallest signed
This also implements the proposed resolutions of the tentatively ready
LWG issues 3760 and 3761.
I'm not sure how/if we should implement the recommended practice of:
difference_type should be the smallest signed-integer-like type that
is sufficiently wide to store the product of the maximum
On Mon, 24 Oct 2022, Nathan Sidwell wrote:
> On 10/21/22 09:11, Patrick Palka wrote:
> > On Fri, 21 Oct 2022, Nathan Sidwell wrote:
>
> > >
> > > Thanks for the explanation, it's a situation I didn;t anticipate and your
> > > fix
> > > is g
It looks like the parameter use_default_args introduced in r110693 is
effectively unused ever since r7-5536-g3c75aaa3d884ef removed the last
(and probably only) 'coerce_template_parms (..., true, false)' call, so
this patch gets rid of it.
In passing, I noticed we currently define wrapper
On Fri, 21 Oct 2022, Nathan Sidwell wrote:
> On 10/19/22 09:55, Patrick Palka wrote:
> > On Wed, 19 Oct 2022, Richard Biener wrote:
> >
> > > On Tue, Oct 18, 2022 at 8:26 PM Patrick Palka wrote:
> > > >
> > > > On Fri, 14 Oct 2022, Richard Biene
Here node_template_info is overlooking that CONCEPT_DECL has TEMPLATE_INFO
too, which makes get_originating_module_decl for the CONCEPT_DECL fail to
return the corresponding TEMPLATE_DECL, which leads to an ICE from
import_entity_index while pretty printing the CONCEPT_DECL's module
suffix as part
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
libstdc++-v3/ChangeLog:
* include/std/ranges (views::__detail::__is_repeat_view): Define
and later define a partial specialization.
(views::__detail::__take_of_repeat_view): Declare and later define.
PR libstdc++/107313
libstdc++-v3/ChangeLog:
* include/std/ranges (stride_view::_Iterator::operator-): Fix typo.
* testsuite/std/ranges/adaptors/stride/1.cc (test03): New test.
---
libstdc++-v3/include/std/ranges | 2 +-
On Wed, 19 Oct 2022, Richard Biener wrote:
> On Tue, Oct 18, 2022 at 8:26 PM Patrick Palka wrote:
> >
> > On Fri, 14 Oct 2022, Richard Biener wrote:
> >
> > > On Thu, Oct 13, 2022 at 5:40 PM Patrick Palka via Gcc-patches
> > > wrote:
> > >
On Tue, 18 Oct 2022, Patrick Palka wrote:
> For an enum declaration, has_definition returns true iff its TYPE_VALUES
> field is non-empty. But this will wrongly return false for an enum that's
> defined to have no enumerators as in the below testcase.
>
> This patch fixes
On Fri, 14 Oct 2022, Richard Biener wrote:
> On Thu, Oct 13, 2022 at 5:40 PM Patrick Palka via Gcc-patches
> wrote:
> >
> > Here during stream in we end up having created a type variant for the enum
> > before we read the enum's definition, and thus the variant inherit
For an enum declaration, has_definition returns true iff its TYPE_VALUES
field is non-empty. But this will wrongly return false for an enum that's
defined to have no enumerators as in the below testcase.
This patch fixes has_definition for such enums by checking OPAQUE_ENUM_P
instead, which
We currently stream TYPE_MIN/MAX_VALUE of an enum only if the enum is
defined rather than just declared. But that seems inconsistent with
what start_enum does, which always sets TYPE_MIN/MAX_VALUE on the
ENUMERAL_TYPE (via copy_type_enum) even for an opaque enum that lacks a
definition.
This
This fixes the below testcase in which we neglect to stream the default
argument for T only because the subsequent parameter U doesn't also have
a default argument.
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
PR c++/105045
gcc/cp/ChangeLog:
* module.cc
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
libstdc++-v3/ChangeLog:
* include/std/ranges (stride_view): Define.
(stride_view::_Iterator): Define.
(views::__detail::__can_stride_view): Define.
(views::_Stride, views::stride): Define.
*
It looks like the constexpr commit r13-3313-g378a0f1840e694
caused some modules regressions:
FAIL: g++.dg/modules/xtreme-header-4_b.C -std=c++2b (test for excess errors)
FAIL: g++.dg/modules/xtreme-header_b.C -std=c++2b (test for excess errors)
Like PR105297, the problem seems to be the
IIUC we currently avoid streaming the RESULT_DECL and PARM_DECLs
of a constexpr_fundef entry under the assumption that they're just
copies of the DECL_RESULT and DECL_ARGUMENTS of the FUNCTION_DECL.
Thus we can just make new copies of DECL_RESULT and DECL_ARGUMENTs
on stream in rather than
The FUNCTION_DECL we build for __dynamic_cast has an empty DECL_CONTEXT,
but trees_out::tree_node expects all FUNCTION_DECLs to have non-empty
DECL_CONTEXT thus we crash when streaming out the dynamic_cast in the
below testcase.
This patch naively fixes this by setting DECL_CONTEXT for
Here during stream in we end up having created a type variant for the enum
before we read the enum's definition, and thus the variant inherited stale
TYPE_VALUES and TYPE_MIN/MAX_VALUES, which leads to an ICE (with -g). The
stale variant got created from set_underlying_type during earlier stream
IIUC the function depset::hash::add_binding_entity has an assert
verifying that if a namespace contains an exported entity, then
the namespace must have been opened in the module purview:
if (data->hash->add_namespace_entities (decl, data->partitions))
{
/* It contains an exported
On Mon, 10 Oct 2022, Nathan Sidwell wrote:
> On 10/4/22 13:36, 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_
Tested on x86_64-pc-linux-gnu, does this look OK for trunk? (The paper
also makes changes to views::take and views::drop, which will be
implemented separately.)
libstdc++-v3/ChangeLog:
* include/std/ranges (repeat_view): Define.
(repeat_view::_Iterator): Define.
On Mon, 10 Oct 2022, Jonathan Wakely via Libstdc++ wrote:
> Tested powerpc64le-linux. Pushed to trunk.
>
> -- >8 --
>
> Currently we only reject std::make_signed_t but not cv bool.
> Similarly for std::make_unsigned_t.
>
> As well as making those ill-formed, this adds a requires-clause to the
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 contain
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
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
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
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.
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
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, 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.
>
> >
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:
*
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/
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
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 trait
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
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
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 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
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, 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
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
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 su
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
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
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
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
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, 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
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
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)
> > {
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
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
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:
*
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
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_ARGS,
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
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
>
atic_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
> dependently scop
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 issu
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 the
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,
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
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
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.
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 ++--
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
>
701 - 800 of 2194 matches
Mail list logo
