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 i
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.gn
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 shou
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:
> > >
> > &
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
We should also fold the overall initializer passed to cp_fully_fold_init
with mce_false, which enables folding of the copy-initialization of
'a1' in the below testcase (the initializer here is an AGGR_INIT_EXPR).
Unfortunately this doesn't help with direct- or default-initialization
because we don
On Mon, 20 Feb 2023, Patrick Palka wrote:
> 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.
>
On Sun, 19 Feb 2023, Jason Merrill wrote:
> On 2/15/23 12:11, Patrick Palka wrote:
> > 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:
> > > >
Here we're mishandling the unevaluated array new-expressions due to a
supposed non-constant array size ever since r12-5253-g4df7f8c79835d569,
made us no longer perform constant evaluation of non-manifestly-constant
expressions within unevaluated contexts. This shouldn't make a
difference here sinc
On Wed, 22 Feb 2023, Marek Polacek wrote:
> In this test, we get a bogus error because we failed to deduce the auto in
> constexpr auto is_pointer_v = is_pointer::value;
> to bool. Then ensure_literal_type_for_constexpr_object thinks the object
> isn't literal and an error is reported.
>
> This
Here we're incorrectly treating the non-dependent variable template-id
tag as dependent ever since r226642 gave variable TEMPLATE_ID_EXPR
an empty type which causes the call to finish_template_variable from
finish_id_expression_1 to be dead code at template parse time. Thus
we're led into treating
On Thu, 16 Feb 2023, Patrick Palka wrote:
> 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_p
On Mon, 27 Feb 2023, Jason Merrill wrote:
> On 2/22/23 14:45, Patrick Palka wrote:
> > Here we're mishandling the unevaluated array new-expressions due to a
> > supposed non-constant array size ever since r12-5253-g4df7f8c79835d569,
> > made us no longer perform
On Wed, 1 Mar 2023, Jason Merrill wrote:
> On 3/1/23 10:32, Patrick Palka wrote:
> > On Mon, 27 Feb 2023, Jason Merrill wrote:
> >
> > > On 2/22/23 14:45, Patrick Palka wrote:
> > > > Here we're mishandling the unevaluated array new-expressions due to a
On Wed, 1 Mar 2023, Jason Merrill wrote:
> On 3/1/23 12:20, Patrick Palka wrote:
> > On Wed, 1 Mar 2023, Jason Merrill wrote:
> >
> > > On 3/1/23 10:32, Patrick Palka wrote:
> > > > On Mon, 27 Feb 2023, Jason Merrill wrote:
> > > >
In order to fix PR100295, r13-4730-g18499b9f848707 attempted to make
extract_local_specs walk the given pattern twice, ignoring unevaluated
operands the first time around so that we prefer to process a local
specialization in an evaluated context if it appears in one (we process
a local specializat
ranges::begin() isn't guaranteed to be equality-preserving for
non-forward ranges, so in cartesian_product_view::end we need to be
careful about calling begin() on the first range (which could be
non-forward) in the (non-degenerate) case where __empty_tail is false.
Since we're already using a var
On Tue, 7 Mar 2023, Patrick Palka wrote:
> ranges::begin() isn't guaranteed to be equality-preserving for
> non-forward ranges, so in cartesian_product_view::end we need to be
> careful about calling begin() on the first range (which could be
> non-forward) in the (non-degen
Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps 12?
PR libstdc++/108362
libstdc++-v3/ChangeLog:
* include/std/ranges (__detail::__can_single_view): New concept.
(_Single::operator()): Constrain it. Move [[nodiscard]] to the
end of the funct
The LWG 3820 testcase revealed a bug in _M_advance, which this patch
also fixes.
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
libstdc++-v3/ChangeLog:
* include/std/ranges
(cartesian_product_view::_Iterator::_Iterator): Remove
constraint on default construct
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
libstdc++-v3/ChangeLog:
* include/bits/ranges_util.h (view_interface::empty): Add
preferred overloads that use ranges::size when the range is
sized as per LWG 3715.
* testsuite/std/ranges/adaptors/lwg3715.
Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps
backports?
libstdc++-v3/ChangeLog:
* include/bits/stl_iterator.h (move_iterator::_S_iter_concept):
Define.
(__cpp_lib_move_iterator_concept): Define for C++20.
(move_iterator::iterator_concept):
On Mon, 6 Mar 2023, Marek Polacek via Gcc-patches wrote:
> When processing a noexcept, constructors aren't elided: build_over_call
> has
>/* It's unsafe to elide the constructor when handling
> a noexcept-expression, it may evaluate to the wrong
> value (c++/53025). */
When redeclaring a member of a constrained class template, we need to
repeat the class's constraints, but it turns out we don't verify
anywhere that the repeated constraints match the class's constraints.
A safe place to do so seems to be in push_template_decl, nearby a
similar consistency check fo
Here when instantiating a constrained template friend naming an already
declared class template, we erroneously pass the existing template's
constraints instead of the friend declaration's constraints to
redeclare_class_template, which causes the constraint comparison check
therein to always be vac
Tested on x86_64-pc-linux-gnu, pushed to trunk as obvious.
-- >8 --
PR libstdc++/109111
libstdc++-v3/ChangeLog:
* include/std/ranges (repeat_view): Remove redundant parentheses
in requires-clause.
(repeat_view::_Iterator): Correct the requires-clause.
---
libstd
On Thu, 9 Mar 2023, Jason Merrill wrote:
> On 3/9/23 14:32, Patrick Palka wrote:
> > On Mon, 6 Mar 2023, Marek Polacek via Gcc-patches wrote:
> >
> > > When processing a noexcept, constructors aren't elided: build_over_call
> > > has
> > >/* It&
r8-1253-g3d2e25a240c711 removed the template argument linkage requirement
in convert_nontype_argument for C++17, but we need to also remove the one
in convert_nontype_argument_function for sake of the first and third test
case which we incorrectly reject (in C++17/20 mode).
And in invalid_tparm_re
On Wed, 10 May 2023, Jason Merrill wrote:
> On 5/10/23 11:36, Patrick Palka wrote:
> > r8-1253-g3d2e25a240c711 removed the template argument linkage requirement
> > in convert_nontype_argument for C++17, but we need to also remove the one
> > in convert_nontype_argument_fun
We accept this testcase since r13-806-g221acd67ca50f8.
PR c++/103807
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/lambda-targ1.C: New test.
---
gcc/testsuite/g++.dg/cpp2a/lambda-targ1.C | 11 +++
1 file changed, 11 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/cpp2a/
On Fri, 5 May 2023, Jonathan Wakely wrote:
>
>
> On Fri, 5 May 2023 at 10:43, Florian Weimer wrote:
> * Jonathan Wakely via Libstdc:
>
> > We could use strtod for a single-threaded target (i.e.
> > !defined(_GLIBCXX_HAS_GTHREADS) by changing the global locale using
> > s
r13-2701-g7107ea6fb933f1 made us correctly accept 'mutable' member
accesses during constexpr evaluation of objects constructed during that
evaluation, while continuing to reject such accesses for constexpr
objects constructed outside of that evaluation, by considering the
CONSTRUCTOR_MUTABLE_POISON
On Thu, 11 May 2023, Patrick Palka wrote:
> r13-2701-g7107ea6fb933f1 made us correctly accept 'mutable' member
> accesses during constexpr evaluation of objects constructed during that
> evaluation, while continuing to reject such accesses for constexpr
> objects const
I noticed only after the fact that the new testcase template/function2.C
(from r14-708-gc3afdb8ba8f183) is just a subset of ext/visibility/anon8.C,
so let's get rid of it.
PR c++/83258
gcc/testsuite/ChangeLog:
* g++.dg/ext/visibility/anon8.C: Mention PR83258.
* g++.dg/tem
This rewrites the testcase for PR109752 to make it simpler and more
robust (i.e. no longer dependent on r13-4035-gc41bbfcaf9d6ef).
PR c++/109752
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-pr109752.C: Rename to ...
* g++.dg/cpp2a/concepts-complete4.C: ... this. Rewr
Hi Martin,
On Fri, May 12, 2023 at 12:13 PM Martin Jambor wrote:
>
> Hello Patrick,
>
> On Wed, May 03 2023, Patrick Palka via Gcc-patches wrote:
> >
> [...]
> >
> > Subject: [PATCH] c++: potentiality of templated memfn call [PR109480]
> >
> > Here
On Wed, 3 May 2023, Jason Merrill via Gcc-patches wrote:
> Tested x86_64-pc-linux-gnu, applying to trunk.
>
> -- 8< --
>
> We try to cache the result of reduce_template_parm_level so that when we
> reduce the same parm multiple times we get the same result, but this wasn't
> working for template
This adds the feature-test macro for PR0849R8, as per
https://github.com/cplusplus/CWG/issues/281.
Tested on x86_64-pc-linux-gnu, does this look OK for trunk/13?
gcc/c-family/ChangeLog:
* c-cppbuiltin.cc (c_cpp_builtins): Predefine __cpp_auto_cast
for C++23.
gcc/testsuite/Change
On Mon, May 15, 2023 at 11:43 AM Jakub Jelinek wrote:
>
> On Mon, May 15, 2023 at 11:41:46AM -0400, Jason Merrill via Gcc-patches wrote:
> > On 5/15/23 11:24, Patrick Palka wrote:
> > > This adds the feature-test macro for PR0849R8, as per
> > > https://githu
add_list_candidates has logic to reject designated initialization of a
non-aggregate type, but this is inadvertendly being suppressed if the type
has a list constructor due to the order of case analysis, which in the
below testcase leads to us incorrectly treating the list initializer as
an ordinar
On Fri, 12 May 2023, Ken Matsui via Libstdc++ wrote:
> It appears that GCC 13 has been released, but I am wondering if there
> are any issues preventing this patch from being merged yet. Can you
> provide any information on this?
Thanks for the reminder, I pushed this to trunk just now
(r14-940-g
lookup_and_finish_template_variable calls convert_from_reference, which
means for a variable template-id of reference type the function returns
an INDIRECT_REF instead of the bare VAR_DECL. But the downstream logic
of two callers, tsubst_qualified_id and finish_class_member_access_expr,
expect a D
Avoid performing two norm_cache lookups during normalization of a
concept-id by allocating inserting a norm_entry* before rather than
after the fact, which is simpler and faster.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
gcc/cp/ChangeLog:
* constrain
This implements noexcept-expr mangling (and demangling) as per the
Itanium ABI.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
look OK for trunk?
PR c++/70790
gcc/cp/ChangeLog:
* mangle.cc (write_expression): Handle NOEXCEPT_EXPR.
libiberty/ChangeLog:
* c
On Fri, 19 May 2023, Patrick Palka wrote:
> This implements noexcept-expr mangling (and demangling) as per the
> Itanium ABI.
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
> look OK for trunk?
>
> PR c++/70790
>
> gcc/cp/Change
On Tue, May 23, 2023 at 3:42 PM Ken Matsui via Gcc-patches
wrote:
>
> Since the type_traits header is a C++11 header file, using can be used instead
> of typedef. This patch provides more readability, especially for long type
> names.
>
> libstdc++-v3/ChangeLog:
>
> * include/std/type_trai
Here at parse time finish_qualified_id_expr adds an implicit 'this->' to
the expression tmp::integral (because it's type-dependent, and also
current_class_ptr is set) within the trailing return type, and later
during substitution we can't resolve the 'this' since
tsubst_function_type does inject_th
On Thu, 21 Jan 2021, Patrick Palka wrote:
> Here at parse time finish_qualified_id_expr adds an implicit 'this->' to
> the expression tmp::integral (because it's type-dependent, and also
> current_class_ptr is set) within the trailing return type, and later
> during
On Thu, 21 Jan 2021, Marek Polacek wrote:
> On Thu, Jan 21, 2021 at 11:22:24AM -0500, Patrick Palka via Gcc-patches wrote:
> > Here at parse time finish_qualified_id_expr adds an implicit 'this->' to
> > the expression tmp::integral (because it's type-dependent,
On Thu, 21 Jan 2021, Jason Merrill wrote:
> On 1/21/21 11:22 AM, Patrick Palka wrote:
> > Here at parse time finish_qualified_id_expr adds an implicit 'this->' to
> > the expression tmp::integral (because it's type-dependent, and also
> > current_class_ptr
On Fri, 22 Jan 2021, Patrick Palka wrote:
> On Thu, 21 Jan 2021, Jason Merrill wrote:
>
> > On 1/21/21 11:22 AM, Patrick Palka wrote:
> > > Here at parse time finish_qualified_id_expr adds an implicit 'this->' to
> > > the expression tmp::inte
On Fri, 22 Jan 2021, Patrick Palka wrote:
> On Fri, 22 Jan 2021, Patrick Palka wrote:
>
> > On Thu, 21 Jan 2021, Jason Merrill wrote:
> >
> > > On 1/21/21 11:22 AM, Patrick Palka wrote:
> > > > Here at parse time finish_qualified_id_expr adds an implicit
On Fri, 22 Jan 2021, Jason Merrill wrote:
> On 1/22/21 12:59 PM, Patrick Palka wrote:
> > On Fri, 22 Jan 2021, Patrick Palka wrote:
> >
> > > On Fri, 22 Jan 2021, Patrick Palka wrote:
> > >
> > > > On Thu, 21 Jan 2021, Jason Merrill wrote:
> >
On Fri, 22 Jan 2021, Jason Merrill wrote:
> On 1/22/21 1:58 PM, Patrick Palka wrote:
> > On Fri, 22 Jan 2021, Jason Merrill wrote:
> >
> > > On 1/22/21 12:59 PM, Patrick Palka wrote:
> > > > On Fri, 22 Jan 2021, Patrick Palka wrote:
> > > >
&g
In this testcase we're crash during constexpr evaluation of the
ARRAY_REF b[0] as part of folding the lambda's by-copy capture of b
(which is encoded as a VEC_INIT_EXPR). Since A's default constructor
is not yet defined, b's initializer is not actually constant, but
because A is an empty type, eva
On Fri, 29 Jan 2021, Jason Merrill wrote:
> On 1/29/21 12:28 PM, Patrick Palka wrote:
> > In this testcase we're crash during constexpr evaluation of the
> > ARRAY_REF b[0] as part of folding the lambda's by-copy capture of b
> > (which is encoded as a VEC
We correctly accept this testcase ever since r10-5143.
gcc/testsuite/ChangeLog:
PR c++/84494
* g++.dg/cpp1y/constexpr-84494.C: New test.
---
gcc/testsuite/g++.dg/cpp1y/constexpr-84494.C | 11 +++
1 file changed, 11 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/cp
In this testcase, we're crashing because the lookup of operator+ from
within the generic lambda via lookup_name finds multiple bindings
(namely C1::operator+ and C2::operator+) and returns a TREE_LIST
thereof, something which maybe_save_operator_binding isn't prepared to
handle.
Since we already d
Since we no longer partially instantiate REQUIRES_EXPRs, we don't need
to rebuild its requirements during tsubst_requires_expr.
gcc/cp/ChangeLog:
* constraint.cc (tsubst_simple_requirement): Just return
boolean_true_node on success.
(tsubst_type_requirement): Likewise.
The subsequent patches revealed some latent type canonicalization
issues during normalization and satisfaction:
1. In tsubst_parameter_mapping, we're canonicalizing the arguments of a
TYPE_ARGUMENT_PACK only if 'arg' wasn't a TYPE_ARGUMENT_PACK to begin
with.
2. We currently set DECL_CONTEX
This sets up the functionality for controlling the initial set of
template parameters to pass to normalization when dealing with a
constraint-expression that is not associated with some constrained
declaration, for instance when normalizing a nested requirement of a
requires expression, or the cons
This fixes the way we check satisfaction of constraints on placeholder
types in various contexts, and in particular when the constraint is
dependent.
Firstly, when evaluating the return type requirement of a compound
requirement, we currently substitute the outer template arguments into
the constr
On Mon, 8 Feb 2021, Patrick Palka wrote:
> This fixes the way we check satisfaction of constraints on placeholder
> types in various contexts, and in particular when the constraint is
> dependent.
>
> Firstly, when evaluating the return type requirement of a compound
> require
When an abbreviated function template has a complex placeholder return
type such auto& or auto**, the level adjustment performed by
splice_late_return_type directly replaces the 'auto' inside the original
return type with the level-adjusted 'auto', but that breaks
TYPE_CANONICAL caching. Instead,
On Tue, 2 Feb 2021, Jason Merrill wrote:
> On 2/2/21 12:19 AM, Patrick Palka wrote:
> > In this testcase, we're crashing because the lookup of operator+ from
> > within the generic lambda via lookup_name finds multiple bindings
> > (namely C1::operator+ and C2::operator
On Tue, 9 Feb 2021, Jason Merrill wrote:
> On 2/8/21 2:03 PM, Patrick Palka wrote:
> > This sets up the functionality for controlling the initial set of
> > template parameters to pass to normalization when dealing with a
> > constraint-expression that is not associated
On Wed, 10 Feb 2021, Jason Merrill wrote:
> On 2/9/21 5:12 PM, Patrick Palka wrote:
> > On Tue, 2 Feb 2021, Jason Merrill wrote:
> >
> > > On 2/2/21 12:19 AM, Patrick Palka wrote:
> > > > In this testcase, we're crashing because the lookup of operator+ f
On Wed, 10 Feb 2021, Jason Merrill wrote:
> On 2/10/21 12:32 PM, Patrick Palka wrote:
> > On Wed, 10 Feb 2021, Jason Merrill wrote:
> >
> > > On 2/9/21 5:12 PM, Patrick Palka wrote:
> > > > On Tue, 2 Feb 2021, Jason Merrill wrote:
> > > >
&
On Thu, 11 Feb 2021, Jason Merrill wrote:
> On 2/8/21 2:03 PM, Patrick Palka wrote:
> > This fixes the way we check satisfaction of constraints on placeholder
> > types in various contexts, and in particular when the constraint is
> > dependent.
> >
> > Firstly
This makes instantiation_dependent_expression_p avoid checking
potential_constant_expression when processing_template_decl isn't set
(and hence when value_dependent_expression_p is definitely false).
gcc/cp/ChangeLog:
* pt.c (instantiation_dependent_expression_p): Check
processing
Here, the problem ultimately seems to be that tsubst_copy_and_build,
when called with empty args as we do during non-dependent expression
folding, doesn't touch BASELINKs at all: it delegates to tsubst_copy
which then immediately exits early due to the empty args. This means
that the CAST_EXPR int
On Fri, 12 Feb 2021, Patrick Palka wrote:
> Here, the problem ultimately seems to be that tsubst_copy_and_build,
> when called with empty args as we do during non-dependent expression
> folding, doesn't touch BASELINKs at all: it delegates to tsubst_copy
> which then immediatel
When determining whether to rule out initializer-list constructors
during CTAD with a single-element initializer list, the element type's
cv-qualifiers should be irrelevant. This patch fixes this by making
is_spec_or_derived strip cv-qualifiers from the supplied expression
type.
In passing, I not
My change in r10-7718 to make build_aggr_init_expr set EXPR_LOCATION
(mimicking build_target_expr) causes the debuginfo regression PR96997.
Given that this change is mostly independent of the rest of the commit,
and that the only fallout of reverting it is a less accurate error
message location in
The logic in std::to_chars for extracting the high- and low-order parts
of a IBM long double value does the right thing on powerpc64le, but not
on powerpc64be. This patch makes the extraction endian-agnostic, which
fixes the execution FAIL of to_chars/long_double.cc on powerpc64be.
Tested on powe
This makes the hexadecimal section of the long double std::to_chars
testcase more robust by avoiding false-negative FAILs due to printf
using a different leading hex digit than us, and by additionally
verifying the correctness of the hexadecimal form via round-tripping
through std::from_chars.
Tes
On Mon, 22 Feb 2021, Patrick Palka wrote:
> This makes the hexadecimal section of the long double std::to_chars
> testcase more robust by avoiding false-negative FAILs due to printf
> using a different leading hex digit than us, and by additionally
> verifying the correctness of the
On Wed, 24 Feb 2021, Jonathan Wakely wrote:
> On 23/02/21 11:30 -0500, Patrick Palka via Libstdc++ wrote:
> > On Mon, 22 Feb 2021, Patrick Palka wrote:
> >
> > > This makes the hexadecimal section of the long double std::to_chars
> > > testcase more robust by avo
The code path in __floating_to_chars_precision for handling long double
by going through printf now also handles __float128, so the condition
that guards this code path needs to be updated accordingly.
Tested on x86_64-pc-linux-gnu (i.e. it compiles :)), does this look OK
for trunk?
libstdc++-v3/
My r10-7705 patch for PR94521 made us set TFF_NO_FUNCTION_ARGUMENTS when
pretty printing the function scope of a local class type in order to
eliminate infinite recursion with a function signature that contains
decltype([]{}). But due to the way dump_function_decl works, this
change regressed our
In the three-parameter version of satisfy_declaration_constraints, when
't' isn't the most general template, then 't' doesn't correspond with
the augmented template arguments 'args', and so the instantiation
context that we push via push_tinst_level isn't quite correct. This
manifests as misleadin
On Thu, 25 Feb 2021, Jason Merrill wrote:
> On 2/25/21 1:37 AM, Patrick Palka wrote:
> > In-Reply-To: <20210225063712.3725111-1-ppa...@redhat.com>
>
> BTW, This patch doesn't seem in any way a reply to your previous patch, so
> it's confusing for the mail heade
On Tue, 9 Feb 2021, Patrick Palka wrote:
> When an abbreviated function template has a complex placeholder return
> type such auto& or auto**, the level adjustment performed by
> splice_late_return_type directly replaces the 'auto' inside the original
> return type wit
On Fri, 12 Feb 2021, Jason Merrill wrote:
> On 2/10/21 9:41 AM, Patrick Palka wrote:
> > On Tue, 9 Feb 2021, Jason Merrill wrote:
> >
> > > On 2/8/21 2:03 PM, Patrick Palka wrote:
> > > > This sets up the functionality for controlling the initial set of
&g
On Fri, 12 Feb 2021, Jason Merrill wrote:
> On 2/11/21 5:14 PM, Patrick Palka wrote:
> > On Thu, 11 Feb 2021, Jason Merrill wrote:
> >
> > > On 2/8/21 2:03 PM, Patrick Palka wrote:
> > > > This fixes the way we check satisfaction of constraints on placehold
This patch mostly performs some straightforward refactoring:
- Renamed satisfy_constraint to satisfy_normalized_constraints
- Renamed the three-parameter version of satisfy_constraint_expression
to satisfy_nondeclaration_constraints
- Removed normalize_(non)?template_requirements
- Rem
This folds the diagnose_requires_expr routines into the corresponding
tsubst_requires_expr ones. This is achieved by making the latter
routines take a sat_info instead of a subst_info, and assigning the
appropriate meanings to the flags sat_info::noisy and
sat_info::diagnose_unsatisfaction_p durin
On Mon, 1 Mar 2021, Jason Merrill wrote:
> On 2/28/21 12:40 PM, Patrick Palka wrote:
> > On Fri, 12 Feb 2021, Jason Merrill wrote:
> >
> > > On 2/10/21 9:41 AM, Patrick Palka wrote:
> > > > On Tue, 9 Feb 2021, Jason Merrill wrote:
> > > >
On Mon, 1 Mar 2021, Jason Merrill wrote:
> On 2/28/21 12:58 PM, Patrick Palka wrote:
> > This patch mostly performs some straightforward refactoring:
> >
> >- Renamed satisfy_constraint to satisfy_normalized_constraints
> >- Renamed the
On Mon, 1 Mar 2021, Jason Merrill wrote:
> On 2/28/21 12:59 PM, Patrick Palka wrote:
> > This folds the diagnose_requires_expr routines into the corresponding
> > tsubst_requires_expr ones. This is achieved by making the latter
> > routines take a sat_info instead of a subs
On Tue, 2 Mar 2021, Jason Merrill wrote:
> On 3/2/21 11:45 AM, Patrick Palka wrote:
> > On Mon, 1 Mar 2021, Jason Merrill wrote:
> >
> > > On 2/28/21 12:59 PM, Patrick Palka wrote:
> > > > This folds the diagnose_requires_expr routines into the correspondi
On Wed, 3 Mar 2021, Moritz Sichert via Libstdc++ wrote:
> std::ranges::reverse_view uses make_reverse_iterator in its
> implementation as described in [range.reverse.view]. This accidentally
> allows ADL as an unqualified name is used in the call. According to
> [contents], however, this should be
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_decl != 0 we would just
ignore the constraints on the placeholder in this s
1301 - 1400 of 2590 matches
Mail list logo
