On Thu, 15 Dec 2022, Jason Merrill wrote:
> On 12/12/22 12:20, Patrick Palka wrote:
> > When instantiating a constrained hidden template friend, we need to
> > substitute into its constraints for sake of declaration matching.
>
> Hmm, we shouldn't need to do declaration matching when there's
There's a curious corner case with variadic member using-decls: the
terminal name can also contain a parameter pack, and only through naming
a conversion function, e.g.
using A::operator Ts...;
We currently only handle parameter packs appearing in the qualifying
scope of a variadic using-decl;
Here we're triggering an overzealous assert in unify during partial
ordering since the member function pointer constants are represented as
ordinary CONSTRUCTORs (with TYPE_PTRMEMFUNC_P TREE_TYPE) but the assert
expects only COMPOUND_LITERAL_P constructors.
Bootstrapped and regtested on
We substitute the qualifying scope of a TYPENAME_TYPE directly using
tsubst_aggr_type (so that we can pass entering_scope=true) instead of
going through tsubst, which means we don't properly reuse typedefs
during this substitution. This ends up causing us to reject the below
testcase because we
When instantiating a constrained hidden template friend, we need to
substitute into its constraints for sake of declaration matching. For
this substitution we use a full argument vector whose outer levels
correspond to the class's arguments and innermost level corresponds to
the template's
Here during partial instantiation of the constexpr if, extra_local_specs
walks the statement looking for local specializations within to save and
possibly capture. However, we're thwarted by the fact that 'ts' first
appears inside an unevaluated context, and so the calls to
process_outer_var_ref
Here when parsing the class-scope auto constrained by a qualified
concept-id, we first tentatively parse the overall member-declaration as
a deprecated access-declaration, during which we parse C as a
standalone TEMPLATE_ID_EXPR (not part of the auto) and end up emitting
the bogus error
We currently declare __builtin_source_location with a const void* return
type instead of the true type (const std::source_location::__impl*), and
later when folding this builtin we just obtain the true type via name
lookup.
But the below testcase demonstrates this name lookup approach seems to
In extract_autos_r, we need to reset TYPE_CANONICAL for the template
type parameter after adjusting its index, otherwise we end up with a
comptypes ICE for the below testcase. Note that such in-place type
adjustment isn't generallly safe to do since the type could be the
TYPE_CANONICAL of another
On Tue, 6 Dec 2022, Patrick Palka wrote:
> This patch fixes some issues with substitution into a C++20 template
> parameter object wrapper:
>
> * The first testcase demonstrates a situation where the same_type_p
> assert in relevant case of tsubst_copy doesn't hold, because (partial)
>
This patch fixes some issues with substitution into a C++20 template
parameter object wrapper:
* The first testcase demonstrates a situation where the same_type_p
assert in relevant case of tsubst_copy doesn't hold, because (partial)
substitution of {int,} into the VIEW_CONVERT_EXPR wrapper
On Mon, 5 Dec 2022, Prathamesh Kulkarni wrote:
> On Mon, 5 Dec 2022 at 09:51, Patrick Palka via Gcc-patches
> wrote:
> >
> > These functions currently repeatedly dereference tp during the subtree
> > walk, dereferences which the compiler can't CSE because it can't
> &
These functions currently repeatedly dereference tp during the subtree
walk, dereferences which the compiler can't CSE because it can't
guarantee that the subtree walking doesn't modify *tp.
But we already implicitly require that TREE_CODE (*tp) remains the same
throughout the subtree walks, so
The functions strip_array_types, is_typedef_decl, typedef_variant_p,
cp_type_quals and cp_expr_location are used throughout the C++ frontend
including in some fairly hot parts (e.g. in the tsubst routines and
cp_walk_subtree) and they're small enough that the overhead of calling
them out-of-line
Here find_parameter_packs_r isn't recognizing the unexpanded pack T
inside the requires-expr's parameter list ultimately because
cp_walk_trees avoids walking the parameters, for good reason: in
requires (Ts... ts) { }
walking 'ts' would trigger a false positive in the unexpanded pack
checker
We implement using enum at class scope by injecting clones of the enum's
CONST_DECLs as fields of the class, for which CONST_DECL_USING_P is
true, so that qualified lookup naturally finds the enumerators.
Substitution into such a CONST_DECL currently ICEs however, because we
assume the
On Thu, 1 Dec 2022, Jason Merrill wrote:
> On 12/1/22 14:51, Patrick Palka wrote:
> > 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
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 corresponding TEMPLATE_DECL are
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 members.
>
> This patch
[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 iostream when
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 Libstdc++
> > > wrote:
> > > >
> > > > Tested
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/ranges_algo.h (__contains_fn, contains): Define.
> >
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 casts to a
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 implement the recommended practice of:
> >
> >
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
> > the init_priority attribute.
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++/2022-October/054849.html
> > > > adds
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-integer-like type that
>
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 good. Could you add a comment about why you need to
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
r 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
> > > &g
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 has_definition for
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_cluster has no effect,
>
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 a FIELD_DECL). But for a class
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_fns and end up
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.
>
> > variant<_PatternIter, _InnerIter> in the
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 (as can
> > > > be seen in
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 code in one of
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 them to various switch
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 exact switch
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 support would be useful for
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:
> > > > > On 9/23/22 09:32, Patrick Palka wrote:
> > > > >
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 part of
> > > > maybe_register_incomplete_var,
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, ISTM the code
> > > is really only
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
301 - 400 of 1377 matches
Mail list logo
