On 5/30/23 16:51, Jakub Jelinek wrote:
On Tue, May 30, 2023 at 04:36:34PM -0400, Jason Merrill wrote:
Note that it is fine to treat p->fld as invariant in C++ if fld is
TREE_READONLY and p is itself invariant. The implementation is allowed to
assume that other code didn't destroy *p and create
On 5/30/23 04:23, Jakub Jelinek wrote:
On Tue, May 30, 2023 at 10:03:05AM +0200, Eric Botcazou wrote:
We want to be able to treat such things as invariant somehow even if we
can't do that for references to user data that might be changed by
intervening code.
That is, indicate that we know that
On 5/13/23 06:58, Eric Botcazou wrote:
I think we really need Eric (as one who e.g. introduced the
DECL_INVARIANT_P apparently for this kind of stuff) to have a look at that
on the Ada side.
I have been investigating this for a few days and it's no small change for Ada
and probably for other la
On 5/19/23 15:10, Patrick Palka wrote:
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/ChangeLog:
* m
On 5/26/23 19:18, Marek Polacek wrote:
Since r8-509, we'll no longer create a static temporary var for
the initializer '{ 1, 2 }' for num in the attached test because
the code in finish_compound_literal is now guarded by
'&& fcl_context == fcl_c99' but it's fcl_functional here. This
causes us to
On Wed, May 24, 2023 at 5:00 AM Jonathan Wakely via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> On Wed, 24 May 2023 at 09:41, Xi Ruoyao wrote:
>
> > Wang Lei raised some concerns about Itanium C++ ABI, so let's ask a C++
> > expert here...
> >
> > Jonathan: AFAIK the standard and the Itanium
Middle-end folks: any thoughts about how best to make the change described in
the last paragraph below?
Library folks: any thoughts on the changes to __cxa_call_terminate?
-- 8< --
[except.handle]/7 says that when we enter std::terminate due to a throw,
that is considered an active handler. We
On 5/18/23 13:59, Patrick Palka wrote:
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 fi
On 5/18/23 14:01, Patrick Palka wrote:
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
On 5/16/23 15:34, Jakub Jelinek wrote:
Hi!
My GCC 12 change to avoid removing zero-sized bitfields as they are
important for ABI and are needed for layout compatibility traits
apparently causes zero sized bitfields to be initialized in the IL,
which at least in 13+ results in ICEs in the ranger
On 5/16/23 15:13, Marek Polacek wrote:
In check_return_expr, we suppress the -Wdangling-reference warning when
we're sure it would be a false positive. It wasn't working in a
template, though, because the suppress_warning call was never reached.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok
On 5/16/23 11:38, Patrick Palka wrote:
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 tr
On 5/15/23 11:24, Patrick Palka wrote:
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?
OK.
gcc/c-family/ChangeLog:
* c-cppbuiltin.cc (c_cpp_builtins): Predefine __cpp_au
On 5/15/23 03:32, Richard Biener wrote:
On Fri, May 12, 2023 at 10:54 PM Jason Merrill via Gcc-patches
wrote:
In the context of the recent discussion, it occurred to me that this semantic
would be useful, but currently there is no easy way to access it. Bikeshedding
welcome; the use of this
In the context of the recent discussion, it occurred to me that this semantic
would be useful, but currently there is no easy way to access it. Bikeshedding
welcome; the use of this flag is a bit odd, but it has the advantage of being
accepted without error going back at least to 4.3.
-- 8< --
C
On 5/12/23 13:02, Patrick Palka wrote:
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 we're incorrectly deeming th
On 5/9/23 08:07, Alex Coplan wrote:
This patch implements clang's __has_feature and __has_extension in GCC.
Thanks!
Currently the patch aims to implement all documented features (and some
undocumented ones) following the documentation at
https://clang.llvm.org/docs/LanguageExtensions.html wit
On 5/11/23 14:30, 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 constructed outside of that evaluation, by c
On 5/10/23 17:28, Marek Polacek wrote:
On Wed, May 03, 2023 at 03:37:03PM -0400, Jason Merrill wrote:
On 5/2/23 19:10, Marek Polacek wrote:
This PR points out that std::is_convertible has given the wrong answer
in
static_assert (!std::is_convertible_v , "");
since r13-2822 implemented __i
On 5/10/23 14:11, Patrick Palka wrote:
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_argumen
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
While looking at PR109247 I made this change to improve diagnostics. I
don't think I'm going ahead with that patch, but this still seems like a
worthy cleanup.
gcc/cp/ChangeLog:
* call.cc (convert_like_internal): Share ck_ref_bind
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_function for sake of the first and third test
case which we incorrectly reject (in
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
DR 2543 clarifies that constinit variables should follow the language, and
diagnose non-constant initializers (according to [expr.const]) even if they
can actually initialize the variables statically.
DR 2543
gcc/cp/ChangeLog:
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
The restriction on the "permitted result of a constant expression" to not
refer to an immediate function applies regardless of context. The previous
code tried to only check in cases where we wouldn't get the check in
cp_fold_r, but with th
On 5/9/23 15:23, Jakub Jelinek wrote:
On Tue, May 09, 2023 at 01:17:09PM -0400, Jason Merrill wrote:
How about changing cp_parser_std_attribute to set TREE_VALUE to
error_mark_node if it skips arguments?
In limited testing that seems to work (tried
GXX_TESTSUITE_STDS=98,11,14,17,20,2b make -j3
On 5/9/23 12:35, Patrick Palka wrote:
When processing a noexcept-spec from a nested class after completion of
the outer class (since a noexcept-spec is a complete-class context), we
pass to noexcept_override_late_checks the outer class type instead of
the nested class type, which leads to bogus e
On 5/9/23 12:35, Patrick Palka wrote:
After diagnosing and recovering from unstable satisfaction, it's
possible to evaluate an atom for the first time noisily rather than
quietly. The satisfaction cache tries to handle this situation
gracefully, but apparently not gracefully enough: we inserted
On 5/9/23 04:12, Jakub Jelinek wrote:
Hi!
The following testcase shows we silently accept (and ignore) attributes without
arguments used as pack expansions. This is because we call
make_pack_expansion and that starts with
if (!arg || arg == error_mark_node)
return arg;
Now, an attribute
On 5/9/23 04:22, Jakub Jelinek wrote:
Hi!
http://eel.is/c++draft/dcl.attr#grammar-4 says
"In an attribute-list, an ellipsis may appear only if that attribute's
specification permits it."
and doesn't explicitly permit it on any standard attribute.
The https://wg21.link/p1774r8 paper which introdu
On 5/5/23 13:36, Patrick Palka wrote:
This extends the PR93107 fix, which made us do resolve_nondeduced_context
on the elements of an initializer list during auto deduction, to happen
for CTAD as well.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
PR c+
On 5/5/23 14:30, Patrick Palka wrote:
On Fri, 5 May 2023, Patrick Palka wrote:
Here we're neglecting to propagate parenthesized-ness when the member
access expression (this->m) resolves to a static member (and thus
finish_class_member_access_expr yields a VAR_DECL instead of a
COMPONENT_REF).
On 5/5/23 13:36, Patrick Palka wrote:
It seems DR 2256 permitted goto to cross the initialization of a
trivially initialized object with a non-trivial destructor. We
already supported this as an -fpermissive extension, so this patch
just makes us unconditionally support this.
Bootstrapped and r
On 5/5/23 09:40, Jakub Jelinek wrote:
On Fri, May 05, 2023 at 07:38:45AM -0400, Jason Merrill wrote:
On 5/5/23 06:45, Jakub Jelinek wrote:
+ if (TREE_READONLY (t) && !TREE_SIDE_EFFECTS (t))
+{
+ /* Return true for const qualified vars, but for members or array
+elements withou
On 5/5/23 06:45, Jakub Jelinek wrote:
On Fri, May 05, 2023 at 11:55:41AM +0200, Jakub Jelinek via Gcc-patches wrote:
Looking at the Ada cases (I admit I don't really understand why it isn't
vectorized, the IL is so different from the start because of the extra
SAVE_EXPRs that it is very hard to
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
In the testcase the assert fails because we use one member function from
another while we're in the middle of instantiating them all, which is
perfectly fine. It seems complicated to detect this situation, so let's
remove the assert again.
On 5/4/23 09:59, Richard Biener wrote:
I've previously sent
https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608077.html
adding ADDR_EXPR_NONZERO and there were comments from Jason
where I just realized I ignored ARRAY_REF for the following.
Anyway, here's a more aggressive variant not go
On 4/28/23 08:54, Patrick Palka wrote:
On Thu, 27 Apr 2023, Patrick Palka wrote:
On Thu, Apr 27, 2023 at 4:46 PM Patrick Palka wrote:
Now that with r14-11-g2245459c85a3f4 made us coerce the template
arguments of a bound ttp again after level-lowering, this unfortunately
causes a crash from c
On 5/4/23 12:33, Patrick Palka wrote:
* Harden some tree accessor macros and fix some incorrect uses of
PLACEHOLDER_TYPE_CONSTRAINTS.
* Use strip_innermost_template_args in outer_template_args.
* Add !processing_template_decl early exit tests to some dependence
predicates.
OK.
gcc/cp/Ch
On 5/4/23 12:33, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
OK.
PR c++/85979
gcc/cp/ChangeLog:
* cxx-pretty-print.cc (cxx_pretty_printer::unary_expression)
: Consider ALIGNOF_EXPR_STD_P.
* error.cc (du
On 5/3/23 16:50, Patrick Palka wrote:
On Wed, 3 May 2023, Jason Merrill wrote:
On 5/2/23 15:53, Patrick Palka wrote:
on Tue, 2 May 2023, Patrick Palka wrote:
On Tue, 2 May 2023, Jason Merrill wrote:
On 5/1/23 15:59, Patrick Palka wrote:
Here we're incorrectly deeming the templated call a.
On 5/2/23 15:53, Patrick Palka wrote:
on Tue, 2 May 2023, Patrick Palka wrote:
On Tue, 2 May 2023, Jason Merrill wrote:
On 5/1/23 15:59, Patrick Palka wrote:
Here we're incorrectly deeming the templated call a.g() inside b's
initializer as potentially constant, despite g being non-constexpr,
On 5/2/23 17:13, Patrick Palka wrote:
constraints_satisfied_p already carefully checks dependence of template
arguments before proceeding with satisfaction, so the dependence check
in instantiate_alias_template is unnecessary and overly conservative.
Getting rid of it allows us to check satisfact
On 5/2/23 19:10, Marek Polacek wrote:
This PR points out that std::is_convertible has given the wrong answer
in
static_assert (!std::is_convertible_v , "");
since r13-2822 implemented __is_{,nothrow_}convertible.
std::is_convertible uses the imaginary
To test() { return std::declval();
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
A bug in the simplification I did around 91618; at this point X::f has
DECL_IMPLICIT_INSTANTIATION set, but we've already identified what template
it corresponds to, so we don't want to call check_explicit_specialization.
To distinguish thi
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 template parms because in that case TYPE is a
TEMPLATE_TEMPLATE_PARM, a
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
I noticed that for member class templates of a class template we were
unnecessarily substituting both the template and its type. Avoiding that
duplication speeds compilation of this silly testcase from ~12s to ~9s on my
laptop. It's unlike
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
In the testcase below, we push_to_top_level to instantiate f and g, and they
can both use the previous_class_level cache from instantiating A.
Wiping the cache in pop_from_top_level is not helpful; we'll do that in
pushclass if needed.
te
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
While looking at the empty base handling for 109678, it occurred to me that
we ought to be able to look for an empty base at a specific offset, not just
in general.
PR c++/109678
gcc/cp/ChangeLog:
* cp-tree.h (lookup_base)
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Here, when dealing with a class with a complex subobject structure, we would
try and fail to find the relevant FIELD_DECL for an empty base before giving
up. And we would do this at each level, in a combinatorially problematic
way. Instead
On 5/2/23 11:19, Jakub Jelinek wrote:
Hi!
During patch backporting, I've noticed that while most cp_walk_tree calls
with cp_fold_r callback callers were changed from &pset to cp_fold_data
&data, the VEC_INIT_EXPR gimplifications has not, so it still passes just
address of a hash_set and so if du
On 5/1/23 15:59, Patrick Palka wrote:
enforce_access currently inspects processing_template_decl to determine
whether to defer the given access check until instantiation time. But
using this flag is unreliable because it gets cleared during e.g.
non-dependent initializer folding, and can lead to
On 5/1/23 15:59, Patrick Palka wrote:
Here we're incorrectly deeming the templated call a.g() inside b's
initializer as potentially constant, despite g being non-constexpr,
which leads to us wastefully instantiating the initializer ahead of time
and triggering a bug in access checking deferral (w
On 5/1/23 19:54, Marek Polacek wrote:
Sadly, -Wdangling-reference generates false positives for std::span-like
user classes, and it seems imprudent to attempt to improve the heuristic
in GCC 13. Let's move the warning to -Wextra, that will hopefully
reduce the number of false positives the users
Tested x86_64-pc-linux-gnu, applying to trunk.
Patrick, can you verify that this resolves 109506 and add whatever testcase(s)
seem appropriate from that PR?
-- 8< --
Here it turns out I also needed to adjust cfun when stepping out of the
member function to instantiate the DMI. But instead of ad
On 4/28/23 15:40, Patrick Palka wrote:
On Fri, 28 Apr 2023, Patrick Palka wrote:
On Fri, 28 Apr 2023, Patrick Palka wrote:
After mechanically replacing RESULT_DECL within a constexpr call result
(for sake of RVO), we can in some cases simplify the call result
further.
In the below testcase t
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
In testcases like this one, the printing of candidates in a diagnostic has
been longer than necessary because it jumps back and forth between the call
site and the candidate site. So here, we first say at the call site that no
match was fou
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
For PR61445 I removed this assert, but PR108242 demonstrated why it's still
useful; to avoid regressing the former testcase I check pattern_defined
in the assert.
This reverts r212524.
PR c++/61445
gcc/cp/ChangeLog:
* pt.
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
It occurred to me that we have a perfectly good DECL_INITIAL field to put
the instantiated DMI into, we don't need a separate hash table.
gcc/cp/ChangeLog:
* init.cc (nsdmi_inst): Remove.
(maybe_instantiate_nsdmi_init): Use
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
The earlier fix for PR109241 avoided the crash by handling a type with no
TREE_BINFO. But we want to move toward doing the partial substitution of
classes in generic lambdas, so let's take a step in that direction.
PR c++/109241
g
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Normally we re-instantiate a function declaration when we start to
instantiate the body in case of multiple declarations. In this wacky
testcase, this causes a problem because the type of the w_counter parameter
depends on its declaration n
On 4/25/23 10:55, Patrick Palka wrote:
On Sat, 18 Mar 2023, Patrick Palka wrote:
On Fri, 17 Mar 2023, Jason Merrill via Gcc-patches wrote:
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
When a lambda refers to a constant local variable in the enclosing scope, we
tentativ
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
In the comments for PR108099 Jakub provided some testcases that demonstrated
that even before the regression noted in the patch we were getting the
semantics of this extension wrong: in the unsigned case we weren't producing
the correspondin
On 4/21/23 13:07, Patrick Palka wrote:
On Sun, 4 Dec 2022, Patrick Palka wrote:
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_wal
On 4/20/23 11:44, Patrick Palka wrote:
On Thu, 20 Apr 2023, Patrick Palka wrote:
1. Now that we no longer substitute the constraints of an auto, we can
get rid of the infinite recursion loop breaker during level lowering
of a constrained auto and we can also use the TEMPLATE_PARM_DESCEN
On 4/20/23 09:56, Patrick Palka wrote:
This patch makes us use a TREE_VEC instead of TREE_LIST to represent the
trailing arguments of a variadic built-in trait. These built-ins are
typically passed a simple pack expansion as the second argument, e.g.
__is_constructible(T, Ts...)
so the mai
On 4/20/23 09:56, Patrick Palka wrote:
If we have a TREE_VEC of types that we want to strip of typedefs, we
unintuitively need to call strip_typedefs_expr instead of strip_typedefs
since only strip_typedefs_expr handles TREE_VEC, and it also dispatches
to strip_typedefs when given a type. But th
On 4/19/23 12:05, Patrick Palka wrote:
On Wed, 19 Apr 2023, Patrick Palka wrote:
Aside from correcting how try_class_unification copies multi-dimensional
'targs', r13-377-g3e948d645bc908 also made it ggc_free this copy as an
optimization. But this is potentially wrong since the call to unify
w
On 4/19/23 11:26, Jakub Jelinek wrote:
On Wed, Apr 19, 2023 at 11:20:09AM -0400, Jason Merrill wrote:
When I was backporting the earlier 108099 patch I finally saw your comments on
the PR about the meaning of this pattern with the patch being wrong (and a
regression from 11). This fixes that re
When I was backporting the earlier 108099 patch I finally saw your comments on
the PR about the meaning of this pattern with the patch being wrong (and a
regression from 11). This fixes that regression; fixing the broader issues can
wait.
Tested x86_64-pc-linux-gnu, OK for 13.1 or wait for 13.2?
On 4/18/23 15:57, Jeff Law via Gcc-patches wrote:
On 11/20/22 09:54, Mark Harmstone wrote:
On 20/11/22 16:43, Jeff Law wrote:
On 10/26/22 21:38, Mark Harmstone wrote:
Changed to double dashes as per
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/604287.html.
What value is there in
On 4/11/23 10:21, Patrick Palka wrote:
On Thu, 26 Jan 2023, Jason Merrill wrote:
On 1/25/23 15:35, Patrick Palka wrote:
On Tue, 17 Jan 2023, Jason Merrill wrote:
On 1/9/23 14:25, Patrick Palka via Gcc-patches wrote:
On Mon, 9 Jan 2023, Patrick Palka wrote:
On Wed, 5 Oct 2022, Patrick Palk
On 4/17/23 14:44, Patrick Palka wrote:
Here when level lowering the bound ttp TT via the
substitution T=C, we're neglecting to canonicalize (and therefore strip
of simple typedefs) the resulting template arguments {A} before
determining its new canonical type via hash table lookup. This leads to
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
We were assuming that the result of evaluation of TARGET_EXPR_INITIAL would
always be the new value of the temporary, but that's not necessarily true
when the initializer is complex (i.e. target_expr_needs_replace). In that
case evaluating
On 4/14/23 21:22, Jeff Law wrote:
On 4/14/23 17:42, Jason Merrill via Gcc-patches wrote:
Tested x86_64-pc-linux-gnu, ok for trunk?
-- 8< --
Here we hit the MEM_REF case, with its arg an ADDR_EXPR, but had no
handling
for that and wrongly assumed it would be a reference to a local varia
Tested x86_64-pc-linux-gnu, ok for trunk?
-- 8< --
Here we hit the MEM_REF case, with its arg an ADDR_EXPR, but had no handling
for that and wrongly assumed it would be a reference to a local variable.
This patch overhauls the logic for deciding whether the target is something
to warn about so th
On 4/5/23 13:31, Patrick Palka wrote:
On Wed, 5 Apr 2023, Patrick Palka wrote:
r13-6098-g46711ff8e60d64 made make_typename_type no longer ignore
non-types during the lookup, unless the TYPENAME_TYPE in question was
followed by the :: scope resolution operator. But there is another
exception to
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
An incomplete type argument to several traits is specified to be undefined
behavior in the library; since it's a compile-time property, we diagnose
it. But apparently some code was relying on the previous behavior of not
diagnosing. So let
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Like other diagnostic functions that might be silenced by options, it should
return whether or not it actually emitted a diagnostic.
gcc/cp/ChangeLog:
* typeck2.cc (cxx_incomplete_type_diagnostic): Return bool.
* cp-tree.h
On 4/6/23 02:27, Iain Sandoe wrote:
I spotted this problem while trying to collate my WIP patches (sorry
for not spotting it when the original patch was discussed).
Although we do not yet have any regression filed against this (AFAIK),
it's only a matter of time - so I'd suggest that we should a
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Here friend matching tries to find a matching non-template friend and fails,
so we mark the friend as a template specialization to be determined later.
Then cplus_decl_attributes tries again to find a matching function and gets
confused by D
On 4/3/23 10:49, Patrick Palka wrote:
This testcase demonstrates we can legitimately enter satisfaction with
an ARGUMENT_PACK_SELECT argument, which is problematic because we can't
store such arguments in the satisfaction cache (or any other hash table).
Since this appears to be possible only du
On 4/3/23 12:28, Patrick Palka wrote:
On Wed, 29 Mar 2023, Jason Merrill wrote:
On 3/28/23 13:37, Patrick Palka wrote:
Now that we resolve non-dependent variable template-ids ahead of time,
cp_finish_decl needs to handle a new invalid situation: we can end up
trying to instantiate a variable t
On 3/31/23 15:06, Patrick Palka wrote:
On Fri, 31 Mar 2023, Jason Merrill wrote:
On 3/31/23 11:55, Patrick Palka wrote:
On Fri, 31 Mar 2023, Patrick Palka wrote:
On Thu, 30 Mar 2023, Jason Merrill wrote:
On 3/30/23 14:53, Patrick Palka wrote:
On Wed, 29 Mar 2023, Jason Merrill wrote:
On
On 3/30/23 09:51, Alexandre Oliva wrote:
On Mar 30, 2023, Alexandre Oliva wrote:
If we're dropping the renaming, I suppose we could also revert Jakub's
change. I suppose this patch will take care of it, pending testing...
Regstrapped on x86_64-linux-gnu and also tested on arm-vx7r2 (with
gc
On 3/31/23 11:55, Patrick Palka wrote:
On Fri, 31 Mar 2023, Patrick Palka wrote:
On Thu, 30 Mar 2023, Jason Merrill wrote:
On 3/30/23 14:53, Patrick Palka wrote:
On Wed, 29 Mar 2023, Jason Merrill wrote:
On 3/27/23 09:30, Patrick Palka wrote:
On Thu, 23 Mar 2023, Patrick Palka wrote:
r1
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
We weren't properly considering the function pointer conversions in
deduction between FUNCTION_TYPE; we just hardcoded the
UNIFY_ALLOW_MORE_CV_QUAL semantics, which are backwards when deducing for a
template conversion function like the one
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
While parsing the anonymous union, we don't yet know that it's an anonymous
union, so we build the reference to 'v' in the static_assert relative to the
union type. But at instantiation time we know it's an anonymous union, so
we need to av
On 3/30/23 08:15, Jonathan Wakely wrote:
Tested with various combinations of 'make clean all' etc.
OK for trunk?
And backport to gcc-12 and gcc-11 after some soak time on trunk?
OK.
-- >8 --
The c++tools makefile doesn't remove progressively more files in each of
mostlyclean, clean, and di
On 3/30/23 14:53, Patrick Palka wrote:
On Wed, 29 Mar 2023, Jason Merrill wrote:
On 3/27/23 09:30, Patrick Palka wrote:
On Thu, 23 Mar 2023, Patrick Palka wrote:
r13-995-g733a792a2b2e16 worked around the problem of FUNCTION_DECL
template arguments not always getting marked as odr-used by red
On 3/30/23 03:47, Jakub Jelinek wrote:
Hi!
The following testcase ICEs, because grok_array_decl during
processing_template_decl handling of a non-dependent subscript
emits a -Wcomma-subscript pedwarn, we decide to pass to the
single index argument the index expressions as if it was wrapped
with
On 3/30/23 03:53, Iain Sandoe wrote:
Hi Jason,
On 30 Mar 2023, at 00:53, Jason Merrill wrote:
On 3/26/23 12:54, Iain Sandoe wrote:
Tested on x86_64-darwin21, x86-64-linux-gnu
+/* This is used to make a stable, but unique-per-function, sequence number
for
+ each TARGET_EXPR slot varia
On 3/23/23 17:18, Patrick Palka wrote:
Here we're issuing a duplicate diagnostic for the use of the deleted
foo, first from the CALL_EXPR case of tsubst_copy_and_build (which
doesn't exit early upon failure), and again from from build_over_call
when rebuilding the substituted CALL_EXPR.
We can f
On 3/29/23 16:57, Jakub Jelinek wrote:
On Wed, Mar 29, 2023 at 04:35:15PM -0400, Jason Merrill wrote:
On the following testcase we emit notes in
maybe_inform_about_fndecl_for_bogus_argument_init
despite no warning/error being printed before it.
This is for the extended floating point type conver
On 3/27/23 09:30, Patrick Palka wrote:
On Thu, 23 Mar 2023, Patrick Palka wrote:
r13-995-g733a792a2b2e16 worked around the problem of FUNCTION_DECL
template arguments not always getting marked as odr-used by redundantly
calling mark_used on the substituted ADDR_EXPR callee of a CALL_EXPR.
This
On 3/25/23 06:08, Jakub Jelinek wrote:
Hi!
On the following testcase we emit notes in
maybe_inform_about_fndecl_for_bogus_argument_init
despite no warning/error being printed before it.
This is for the extended floating point type conversions where pedwarn
is used, and complained is used there f
On 3/17/23 11:26, Patrick Palka wrote:
Here we're crashing during satisfaction for the NTTP 'C auto' from
do_auto_deduction ultimately because convert_template_argument / unify
don't pass all outer template arguments to do_auto_deduction, and during
satisfaction we need to know all arguments. Wh
On 3/26/23 12:54, Iain Sandoe wrote:
Tested on x86_64-darwin21, x86-64-linux-gnu
OK for trunk?
Iain
When we need to 'promote' a value (i.e. store it in the coroutine frame) it
is given a frame entry name. This was based on the DECL_UID for slot vars.
However, when LTO is used, the names from mu
On 3/28/23 13:37, Patrick Palka wrote:
Now that we resolve non-dependent variable template-ids ahead of time,
cp_finish_decl needs to handle a new invalid situation: we can end up
trying to instantiate a variable template with deduced return type
before we fully parsed (and attached) its initiali
On 3/29/23 07:36, Benjamin Priour wrote:
Hi, below is my first patch ever. I ran the testsuites against trunk
20230322, everything seems OK to me, but as it is my first submission
I'd like to be sure of it.
Thanks a lot for the review !
Thanks!
Please see https://gcc.gnu.org/contribute.html#
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
The two hunks fix missing handling demonstrated by the two testcases: first,
if we omit one alias template parm but include another, we need to rewrite
the deduced template args to reflect the new position of the included parm.
Second, if we
201 - 300 of 1280 matches
Mail list logo
