In my initial implementation of alias CTAD, I described a couple of
differences from the specification that I thought would not have a practical
effect; this testcase demonstrates that I was wrong. One difference is
resolved by the CPTK_IS_DEDUCIBLE commit; the other (adding too many of the
alias
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 internal-only for GCC 13 at least by adding a space in the name, b
The standard was unclear what happens with the transformation of a deduction
guide if the initial template argument deduction fails for a reason other
than not deducing all the arguments; my implementation assumed that the
right thing was to give up on the deduction guide. But in consideration of
Tested x86_64-pc-linux-gnu. This isn't really a regression fix, but it's very
safe, and fixes a longstanding annoyance, so I'm leaning toward putting it into
GCC 13. Thoughts?
-- 8< --
For a long time, people have expected to be able to write
static_assert (false) in a template and only have it
On 2/17/23 23:02, Alexandre Oliva wrote:
cp_build_binary_op, that issues -Waddress warnings, issues an extra
warning on arm targets, that g++.dg/warn/Waddress-5.C does not expect
when comparing a pointer-to-member-function literal with null.
The reason for the extra warning is that, on arm targ
On 2/17/23 23:04, Alexandre Oliva wrote:
We used to define WINT_TYPE to WCHAR_TYPE, so that both wint_t and
wchar_t mapped to the same underlying type, but this caused a glitch
in Wstringop-overflow-6.C: on vxworks, wint_t is typedef'ed to
wchar_t
And fixing that isn't an option? Do the integ
On 2/9/23 09:39, Marek Polacek wrote:
In constexpr-nsdmi3.C, with -fno-elide-constructors, we don't elide
the Y::Y(const Y&) call used to initialize o.c. So store_init_value
-> cxx_constant_init must constexpr-evaluate the call to Y::Y(const Y&)
in cxx_eval_call_expression. It's a trivial funct
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.gnu.org/pipermail/gcc-patches/2022-November/607443.html ]
This patch factors out the TYPENAME_TYPE case of tsubst into a sep
On 9/26/22 15:27, Lewis Hyatt wrote:
On Wed, Jun 15, 2022 at 03:06:16PM -0400, Lewis Hyatt wrote:
On Tue, Jun 14, 2022 at 05:26:49PM -0400, Lewis Hyatt wrote:
Hello-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103902
The attached patch resolves PR preprocessor/103902 as described in the patc
On 2/15/23 05:37, Jonathan Wakely wrote:
OK for trunk?
OK.
-- >8 --
Users are confused about what this warning means, so add a suggested
solution to the documentation.
gcc/ChangeLog:
* doc/invoke.texi (C++ Dialect Options): Suggest adding a
using-declaration to unhide funct
On 2/9/23 10:22, Patrick Palka wrote:
On Thu, 9 Feb 2023, Patrick Palka wrote:
When substituting into sizeof(expr), tsubst_copy_and_build elides
substitution into the operand if args is NULL_TREE, and instead
considers the TREE_TYPE of the operand. But here the (templated)
operand is a TEMPLAT
On 2/10/23 08:51, Patrick Palka wrote:
On Fri, 10 Feb 2023, Patrick Palka wrote:
On Thu, 9 Feb 2023, Patrick Palka wrote:
On Thu, 9 Feb 2023, Jason Merrill wrote:
On 2/9/23 09:36, Patrick Palka wrote:
On Sun, 5 Feb 2023, Jason Merrill wrote:
On 2/3/23 15:51, Patrick Palka wrote:
On Mon,
On 2/14/23 14:15, 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 into a separate
function tsubst_typename_type. It als
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 ]
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.
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 into a separate
function tsubst_typename_type. It also factors out the two tsubst flags
contr
On 2/14/23 03:33, Jakub Jelinek wrote:
On Tue, Feb 14, 2023 at 12:22:33PM +0100, Jakub Jelinek via Gcc-patches wrote:
2023-02-14 Jakub Jelinek
* g++.dg/DRs/dr2691.C: New test.
Actually, this one isn't a DR, so maybe it should go into:
* gcc/testsuite/c-c++-common/cpp/delimi
On 2/13/23 09:06, Marek Polacek wrote:
joust_maybe_elide_copy checks that the last conversion in the ICS for
the first argument is ck_ref_bind, which is reasonable, because we've
checked that we're dealing with a copy/move constructor. But it can
also happen that we couldn't figure out which con
On 1/25/23 13:06, Ben Boeckel wrote:
This patch implements support for [P1689R5][] to communicate to a build
system the C++20 module dependencies to build systems so that they may
build `.gcm` files in the proper order.
Thanks again.
Support is communicated through the following three new fla
On 1/25/23 13:06, Ben Boeckel wrote:
They affect the build, so report them via `-MF` mechanisms.
gcc/cp/
* module.cc (do_import): Report imported CMI files as
dependencies.
Both this and the mapper dependency patch seem to cause most of the
modules testcases to crash; please
On 1/25/23 13:06, Ben Boeckel wrote:
Unicode does not support such values because they are unrepresentable in
UTF-16.
libcpp/
* charset.cc: Reject encodings of codepoints above 0x10.
UTF-16 does not support such codepoints and therefore all
Unicode rejects such value
On 2/8/23 18:15, Marek Polacek wrote:
On Wed, Feb 08, 2023 at 04:00:25PM -0800, Jason Merrill wrote:
On 2/8/23 13:01, Marek Polacek wrote:
(This may not be a complete fix but I got stuck so I'm posting what
I have, which at least fixes the ICE.)
We ICE on the simple:
struct X { const X* x
On 2/9/23 09:36, Patrick Palka wrote:
On Sun, 5 Feb 2023, Jason Merrill wrote:
On 2/3/23 15:51, Patrick Palka wrote:
On Mon, 30 Jan 2023, Jason Merrill wrote:
On 1/27/23 17:02, Patrick Palka wrote:
This PR illustrates that __builtin_is_constant_evaluated currently acts
as an optimization ba
On 2/8/23 13:01, Marek Polacek wrote:
(This may not be a complete fix but I got stuck so I'm posting what
I have, which at least fixes the ICE.)
We ICE on the simple:
struct X { const X* x = this; };
constexpr const X& x = X{};
where store_init_value initializes 'x' with
&TARGET_EXPR
On 2/8/23 00:59, Jakub Jelinek wrote:
Hi!
For standard excess precision, like the C FE we parse floating
point constants as EXCESS_PRECISION_EXPR of promoted REAL_CST
rather than the nominal REAL_CST, and as the following testcase
shows the constants might need mangling.
The following patch man
On 1/24/23 17:49, Marek Polacek wrote:
On Fri, Jan 20, 2023 at 03:19:54PM -0500, Jason Merrill wrote:
On 1/19/23 21:03, Marek Polacek wrote:
On Thu, Jan 19, 2023 at 01:02:02PM -0500, Jason Merrill wrote:
On 1/18/23 20:13, Marek Polacek wrote:
On Wed, Jan 18, 2023 at 04:07:59PM -0500, Jason Me
On 2/3/23 15:51, Patrick Palka wrote:
On Mon, 30 Jan 2023, Jason Merrill wrote:
On 1/27/23 17:02, Patrick Palka wrote:
This PR illustrates that __builtin_is_constant_evaluated currently acts
as an optimization barrier for our speculative constexpr evaluation,
since we don't want to prematurely
On 2/5/23 09:57, Patrick Palka wrote:
On Sat, 4 Feb 2023, Jason Merrill wrote:
On 2/4/23 20:41, Jason Merrill wrote:
On 2/4/23 20:08, Patrick Palka wrote:
On Sat, 4 Feb 2023, Jason Merrill wrote:
On 2/4/23 15:31, Patrick Palka wrote:
After r13-5684-g59e0376f607805 the (pruned) callee of a
On 2/4/23 20:41, Jason Merrill wrote:
On 2/4/23 20:08, Patrick Palka wrote:
On Sat, 4 Feb 2023, Jason Merrill wrote:
On 2/4/23 15:31, Patrick Palka wrote:
After r13-5684-g59e0376f607805 the (pruned) callee of a non-dependent
CALL_EXPR is a bare FUNCTION_DECL rather than ADDR_EXPR of
FUNCTION
On 2/4/23 20:08, Patrick Palka wrote:
On Sat, 4 Feb 2023, Jason Merrill wrote:
On 2/4/23 15:31, Patrick Palka wrote:
After r13-5684-g59e0376f607805 the (pruned) callee of a non-dependent
CALL_EXPR is a bare FUNCTION_DECL rather than ADDR_EXPR of FUNCTION_DECL.
This innocent change revealed tha
On 2/4/23 15:31, Patrick Palka wrote:
After r13-5684-g59e0376f607805 the (pruned) callee of a non-dependent
CALL_EXPR is a bare FUNCTION_DECL rather than ADDR_EXPR of FUNCTION_DECL.
This innocent change revealed that cp_tree_equal doesn't first check
dependentness of a CALL_EXPR before treating t
On 2/3/23 13:08, Marek Polacek wrote:
On Thu, Feb 02, 2023 at 05:29:44PM -0500, Jason Merrill wrote:
On 1/30/23 21:35, Marek Polacek wrote:
In this test case, we find ourselves evaluating 't' which is
((const struct carray *) this)->data_[VIEW_CONVERT_EXPR(index)]
in cxx_eval_array_reference.
On 1/30/23 14:10, Patrick Palka wrote:
In check_methods we're unnecessarily checking satisfaction for all
constructors and assignment operators, even those that don't look like
copy/move special members. In the testcase below this manifests as an
unstable satisfaction error because the satisfact
On 1/30/23 16:36, Patrick Palka wrote:
Here we're crashing from check_bases_and_members due to
CLASSTYPE_DESTRUCTOR being an OVERLOAD which, due to the pruning
performed by add_method, should only happen if there is no viable
destructor or the destructor is ambiguous.
This patch fixes this by ma
On 1/30/23 21:35, Marek Polacek wrote:
In this test case, we find ourselves evaluating 't' which is
((const struct carray *) this)->data_[VIEW_CONVERT_EXPR(index)]
in cxx_eval_array_reference. ctx->object is non-null, a RESULT_DECL, so
we replace it with 't':
new_ctx.object = t; // result_de
On 2/2/23 13:09, Patrick Palka wrote:
Here the ahead-of-time overload set pruning in finish_call_expr is
unintentionally returning a CALL_EXPR whose pruned callee is wrapped in
an ADDR_EXPR, despite the original callee not being wrapped in an
ADDR_EXPR. This ends up causing a bogus declaration m
Tested x86_64-pc-linux-gnu, applying to trunk.
This isn't exactly a regression fix, but it is in response to new build
failures and safe.
-- 8< --
In recent years this error has been coming up more because other compilers
don't diagnose it as consistently. So let's add a flag for it, and be mor
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
We also need to split up a CONSTRUCTOR in cp_genericize_init if we need to
add extra copy constructor calls to deal with CWG2403.
PR c++/108559
gcc/cp/ChangeLog:
* cp-gimplify.cc (any_non_eliding_target_exprs): New.
On 1/31/23 15:41, Marek Polacek wrote:
Here we crash in the middle end because warn_logical_operator calls
build_range_check which calls various fold_* functions and those
don't work too well when we're still processing template trees. For
instance here we crash because we're converting a RECORD
On 1/30/23 21:34, Marek Polacek wrote:
On Mon, Jan 30, 2023 at 01:12:00PM -0500, Jason Merrill wrote:
On 1/30/23 11:00, Marek Polacek wrote:
On Fri, Jan 27, 2023 at 06:17:00PM -0500, Patrick Palka wrote:
On Fri, 27 Jan 2023, Marek Polacek wrote:
On Fri, Jan 27, 2023 at 05:15:00PM -0500, Patr
On 1/27/23 17:02, Patrick Palka wrote:
This PR illustrates that __builtin_is_constant_evaluated currently acts
as an optimization barrier for our speculative constexpr evaluation,
since we don't want to prematurely fold the builtin to false if the
expression in question would be later manifestly
On 1/27/23 17:02, Patrick Palka wrote:
This patch turns the manifestly_const_eval flag used by the constexpr
machinery into a tri-state enum so that we're able to express wanting
to fold __builtin_is_constant_evaluated to false via late speculative
constexpr evaluation. Of all the entry points t
On 1/30/23 11:00, Marek Polacek wrote:
On Fri, Jan 27, 2023 at 06:17:00PM -0500, Patrick Palka wrote:
On Fri, 27 Jan 2023, Marek Polacek wrote:
On Fri, Jan 27, 2023 at 05:15:00PM -0500, Patrick Palka wrote:
On Thu, 26 Jan 2023, Marek Polacek via Gcc-patches wrote:
Here we crash because a CA
On 1/27/23 17:15, Patrick Palka wrote:
On Thu, 26 Jan 2023, Marek Polacek via Gcc-patches wrote:
Here we crash because a CAST_EXPR, representing T(), doesn't have
its operand, and operand_equal_p's STRIP_ANY_LOCATION_WRAPPER doesn't
expect that. (o_e_p is called from warn_duplicated_cond_add_o
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 Palka wrote:
On Thu, 7 Jul 2022, Jonathan Wakely via Gcc-patches wrote:
This adds a
On 1/13/23 18:22, Marek Polacek wrote:
On Sat, Dec 03, 2022 at 02:58:16PM -0500, Jason Merrill wrote:
On 12/2/22 18:58, Marek Polacek wrote:
On Fri, Nov 18, 2022 at 08:39:10PM -0500, Jason Merrill wrote:
On 11/18/22 18:52, Marek Polacek wrote:
+/* Parse a string literal or user defined string
On 1/24/23 18:16, Jakub Jelinek wrote:
On Mon, Jan 23, 2023 at 10:26:14PM -0500, Jason Merrill via Gcc-patches wrote:
* g++.dg/init/new51.C: New test.
The test fails on targets where size_t is not unsigned long
due to extra diagnostics.
As the testcase is tested in C++98 too, I'
On 1/24/23 18:19, Jakub Jelinek wrote:
Hi!
Before the P1169R4 changes, operator () of a lambda was
always a method, so it was fine to pass method_p = 1 unconditionally,
but it isn't always the case, so this patch adds a check for whether
it is a method or nor.
Bootstrapped/regtested on x86_64-l
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Since r11-2095 we pass flags to cp_lexer_get_preprocessor_token, and
cp_lexer_new_main passes C_LEX_STRING_NO_JOIN when lexing most of the
translation unit, but doesn't do that for the very first token; as a
result, if the first token is a s
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
tsubst_lambda_expr uses build_memfn_type to build a METHOD_TYPE for the new
lamba op(). This is not what we want for a C++23 static op(), but since we
also use that METHOD_TYPE to communicate the closure type down to
tsubst_function_decl, l
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
In r13-2978 I tried to eliminate TARGET_EXPR around TARGET_EXPR by
discarding the outer one, but as in this testcase that breaks if the
TARGET_EXPR_SLOT of the outer one is used elsewhere. But it should always
be safe to strip the inner one
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
With -ffold-simple-inlines, we turn calls to std::move into the static_cast
equivalent. In this testcase, this exposes the FindResult temporary to copy
elision which is not specified by the standard, through an optimization in
gimplify_modi
On 1/23/23 16:28, Marek Polacek wrote:
On Fri, Jan 20, 2023 at 02:37:19PM -0500, Jason Merrill wrote:
On 1/19/23 21:03, Marek Polacek wrote:
We shouldn't emit "right operand of comma operator has no effect"
when that comma operator was created by the compiler for "new int{}".
convert_to_void/CO
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
The transformation done by r13-4564 to use the iterator constructor instead
of the initializer-list constructor breaks if the iterator pointers are
themselves treated as elements of an initializer-list, so check for that.
PR c++/108
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
In r13-4469 we started to build the RESULT_DECL in grokdeclarator, while we
still know the location of the return type. But in this testcase, we hit
that code again when parsing the explicit instantiation, and clobber the
DECL_RESULT that w
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
This PR points out a case where we are not extending the lifetime of a
temporary when the subobject is denoted by a pointer-to-member operation.
These rules were clarified in C++20 by CWG1299.
There are other cases that also need to be hand
On 1/22/23 15:50, Jakub Jelinek wrote:
On Sun, Jan 22, 2023 at 03:40:26PM -0500, Jason Merrill wrote:
2023-01-21 Jakub Jelinek
PR c++/108474
* cp-gimplify.cc (cp_fold_r): Handle structured bindings
vars like anon union artificial vars.
* g++.dg/cpp1z/decomp57
On 1/21/23 04:59, Jakub Jelinek wrote:
Hi!
As reported by Andrew Pinski, structured bindings (with the exception
of the ones using std::tuple_{size,element} and get which are really
standalone variables in addition to the binding one) also use
DECL_VALUE_EXPR and needs the same treatment in stat
On 1/19/23 21:03, Marek Polacek wrote:
On Thu, Jan 19, 2023 at 01:02:02PM -0500, Jason Merrill wrote:
On 1/18/23 20:13, Marek Polacek wrote:
On Wed, Jan 18, 2023 at 04:07:59PM -0500, Jason Merrill wrote:
On 1/18/23 12:52, Marek Polacek wrote:
Here, -Wdangling-reference triggers where it proba
On 1/19/23 21:03, Marek Polacek wrote:
We shouldn't emit "right operand of comma operator has no effect"
when that comma operator was created by the compiler for "new int{}".
convert_to_void/COMPOUND_EXPR already checks warning_suppressed_p so
we can just suppress -Wunused-value.
Bootstrapped/re
On Thu, Jan 19, 2023 at 11:26 PM Bernhard Reutner-Fischer
wrote:
>
> On 19 January 2023 20:39:08 CET, Jason Merrill wrote:
> >On Sat, Nov 12, 2022 at 4:24 PM Harald Anlauf via Gcc-patches
> > wrote:
> >>
> >> Am 12.11.22 um 22:05 schrieb Bernhard Reutner-Fischer via Gcc-patches:
> >> > This funct
On 1/18/23 03:06, Richard Biener wrote:
On Tue, 17 Jan 2023, Jason Merrill wrote:
On 12/7/22 06:25, Richard Biener wrote:
The following avoids a bogus -Wstringop-overflow diagnostic by
properly recognizing that &d->m_mutex cannot be nullptr in C++
even if m_mutex is at offset zero. The fronte
On 1/19/23 15:13, Jakub Jelinek wrote:
Hi!
For anonymous union members we create artificial VAR_DECLs which
have DECL_VALUE_EXPR for the actual COMPONENT_REF. That works
just fine inside of functions (including global dynamic constructors),
because during gimplification such VAR_DECLs are gimpl
On Sat, Nov 12, 2022 at 4:24 PM Harald Anlauf via Gcc-patches
wrote:
>
> Am 12.11.22 um 22:05 schrieb Bernhard Reutner-Fischer via Gcc-patches:
> > This function definition was removed years ago, remove it's prototype.
> >
> > gcc/fortran/ChangeLog:
> >
> > * gfortran.h (gfc_check_include):
On 1/19/23 03:52, Jakub Jelinek wrote:
Hi!
As the following testcases shows, when adding static operator[]
support I've missed that the 2 build_min_non_dep_op_overload functions
need to be adjusted. The first one we only use for the single index
case, but as cp_tree_code_length (ARRAY_REF) is 2
On 1/18/23 20:13, Marek Polacek wrote:
On Wed, Jan 18, 2023 at 04:07:59PM -0500, Jason Merrill wrote:
On 1/18/23 12:52, Marek Polacek wrote:
Here, -Wdangling-reference triggers where it probably shouldn't, causing
some grief. The code in question uses a reference wrapper with a member
function
On 1/18/23 12:52, Marek Polacek wrote:
Here, -Wdangling-reference triggers where it probably shouldn't, causing
some grief. The code in question uses a reference wrapper with a member
function returning a reference to a subobject of a non-temporary object:
const Plane & meta = fm.planes().in
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 Palka wrote:
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 s
On 12/7/22 06:25, Richard Biener wrote:
The following avoids a bogus -Wstringop-overflow diagnostic by
properly recognizing that &d->m_mutex cannot be nullptr in C++
even if m_mutex is at offset zero. The frontend already diagnoses
a &d->m_mutex != nullptr comparison and the following transfers
On 1/13/23 12:45, Jakub Jelinek wrote:
On Fri, Jan 13, 2023 at 11:58:06AM -0500, Jason Merrill wrote:
LGTM, though we might put that condition in c-common somewhere?
So like this then? Just tested on the new testcases, full bootstrap/regtest
queued?
OK..
2023-01-13 Jakub Jelinek
On 1/11/23 04:52, Jakub Jelinek wrote:
Hi!
On the following testcase trunk emits a false positive warning on ia32.
convert_like_internal is there called with type of double and
expr EXCESS_PRECISION_EXPR with float type with long double operand
2.L * (long double) x.
Now, for the code generation
On 1/12/23 15:31, Jakub Jelinek wrote:
On Thu, Jan 12, 2023 at 08:55:32PM +0100, Jakub Jelinek via Gcc-patches wrote:
So, the following patch for the NOP_EXPR cases checks just in case that
it is from integral type and more importantly checks it is a widening
conversion, and then next to it also
On 1/12/23 19:32, Jakub Jelinek wrote:
Hi!
As mentioned in the PR, various x86 intrinsics need to return
an uninitialized vector. Currently they use self initialization
to avoid -Wuninitialized warnings, which works fine in C, but
doesn't work in C++ where -Winit-self is enabled in -Wall.
We do
On 1/11/23 12:58, Jakub Jelinek wrote:
Hi!
The following testcase is miscompiled, because we shorten the division
in a case where it should not be shortened.
Divisions (and modulos) can be shortened if it is unsigned division/modulo,
or if it is signed division/modulo where we can prove the divi
On 12/6/22 09:47, Gaius Mulley via Gcc-patches wrote:
Here are the dejagnu expect library scripts for the gm2
testsuite.
A couple of weeks ago I noticed on a testrun that the modula tests
didn't seem to be timing out properly, so I made this change. It looks
like they didn't run at all in th
On 1/9/23 05:19, Jakub Jelinek wrote:
Hi!
The last testcase in this patch ICEs, because
maybe_init_list_as_range -> maybe_init_list_as_array
calls maybe_constant_init in:
/* Don't do this if the conversion would be constant. */
first = maybe_constant_init (first);
if (TREE_CONSTANT (fi
On 1/5/23 12:20, Patrick Palka wrote:
When tentatively parsing what is really an elaborated-type-specifier
first as a class-specifier, we may form a CPP_TEMPLATE_ID token that
later gets reused in the fallback parse if the tentative parse fails.
These special tokens also capture the access checks
On 1/4/23 11:37, Patrick Palka wrote:
We typically ignore mark_used failure when in a non-SFINAE context for
sake of better error recovery. But in mark_single_function we're
instead ignoring mark_used failure in a SFINAE context, which ends up
causing the second static_assert here to incorrectly
On 1/4/23 10:30, Iain Sandoe wrote:
On 4 Jan 2023, at 15:03, Jason Merrill wrote:
On 1/3/23 18:17, Iain Sandoe wrote:
On 3 Jan 2023, at 22:22, Jason Merrill wrote:
On 12/7/22 10:39, Iain Sandoe wrote:
This has been tested on x86_64 and arm64 Darwin and on x86_64 linux gnu.
The basic
On 1/4/23 04:32, Jakub Jelinek wrote:
Hi!
We ICE on the following testcase during error recovery, both new_parm
and old_parm are error_mark_node, the ICE is on
error ("redefinition of default argument for %q+#D", new_parm);
inform (DECL_SOURCE_LOCATION (old_parm),
On 1/3/23 18:17, Iain Sandoe wrote:
On 3 Jan 2023, at 22:22, Jason Merrill wrote:
On 12/7/22 10:39, Iain Sandoe wrote:
This has been tested on x86_64 and arm64 Darwin and on x86_64 linux gnu.
The basic patch is live in the homebrew macOS support and so has had quite
wide coverage on n
On 12/7/22 10:39, Iain Sandoe wrote:
This has been tested on x86_64 and arm64 Darwin and on x86_64 linux gnu.
The basic patch is live in the homebrew macOS support and so has had quite
wide coverage on non-trivial codebases.
OK for master?
Iain
Since this actually fixes wrong c
On 12/23/22 10:48, Patrick Palka wrote:
On Thu, 22 Dec 2022, Patrick Palka wrote:
On Thu, 22 Dec 2022, Jason Merrill wrote:
On 12/22/22 16:41, Patrick Palka wrote:
On Thu, 22 Dec 2022, Jason Merrill wrote:
On 12/22/22 11:31, Patrick Palka wrote:
On Wed, 21 Dec 2022, Jason Merrill wrote:
mingw stdio.h plays horrible games with extern "C++", but it also seems
sloppy for coro.h to declare printf in testcases that will also include
standard headers.
gcc/testsuite/ChangeLog:
* g++.dg/coroutines/coro.h: #include instead of
declaring puts/printf.
* g++.dg/corou
On 12/22/22 16:56, Arsen Arsenović wrote:
Hi,
Jason Merrill writes:
+# Newlines should be more tolerant.
+s/\n$/(\\n|\\r\\n|\\r)*/;
Isn't specifically handling \\r\\n redundant with the * operator?
To the extent of my knowledge, yes; I left that in since the original
tests I was re
On 12/22/22 16:41, Patrick Palka wrote:
On Thu, 22 Dec 2022, Jason Merrill wrote:
On 12/22/22 11:31, Patrick Palka wrote:
On Wed, 21 Dec 2022, Jason Merrill wrote:
On 12/21/22 09:52, Patrick Palka wrote:
Here during ahead of time checking of C{}, we indirectly call get_nsdmi
for C::m from f
On 12/22/22 05:32, Jakub Jelinek wrote:
Hi!
On the following testcase, we warn with -Wunused-value twice, once
in the FEs and later on cgraphunit again with slightly different
wording.
The following patch fixes that by registering a warning suppression in the
FEs when we warn and not warning in
On 12/22/22 06:03, Arsen Arsenović wrote:
This script is a helper used to generate dg-output lines from an existing
program output conveniently. It takes care of escaping Tcl and ARE stuff.
contrib/ChangeLog:
* dg-out-generator.pl: New file.
---
I updated this file to include the prope
On 12/22/22 06:03, Arsen Arsenović wrote:
From: Jonathan Wakely
Make the output more readable. Don't output anything unless verbose
termination is enabled at configure-time.
LGTM if Jonathan agrees. The testsuite changes should be applied in the
same commit.
libstdc++-v3/ChangeLog:
On 12/22/22 11:31, Patrick Palka wrote:
On Wed, 21 Dec 2022, Jason Merrill wrote:
On 12/21/22 09:52, Patrick Palka wrote:
Here during ahead of time checking of C{}, we indirectly call get_nsdmi
for C::m from finish_compound_literal, which in turn calls
break_out_target_exprs for C::m's (non-te
On 12/4/22 11:30, Iain Sandoe wrote:
This fixes a long-standing problem on Darwin where we cannot independently set
-static-libstdc++ because the flag gets stripped by the g++ driver.
This patch is essentially the same as the one used for the 'D' driver and has
been in local use for some time.
On 12/22/22 12:34, Patrick Palka wrote:
On Thu, 15 Dec 2022, Jason Merrill wrote:
On 12/15/22 14:31, Patrick Palka wrote:
On Thu, 15 Dec 2022, Patrick Palka wrote:
On Thu, 15 Dec 2022, Jason Merrill wrote:
On 12/12/22 12:20, Patrick Palka wrote:
When instantiating a constrained hidden tem
On 12/21/22 09:52, Patrick Palka wrote:
Here during ahead of time checking of C{}, we indirectly call get_nsdmi
for C::m from finish_compound_literal, which in turn calls
break_out_target_exprs for C::m's (non-templated) initializer, during
which we end up building a call to A::~A and checking ex
On 12/20/22 14:39, Richard Biener wrote:
Am 20.12.2022 um 18:38 schrieb Jason Merrill :
On 12/20/22 07:07, Richard Biener wrote:
On Fri, Dec 2, 2022 at 4:46 PM Jason Merrill via Gcc-patches
wrote:
Tested x86_64-pc-linux-gnu, OK for trunk?
-- 8< --
If the DECL_VALUE_EXPR of a VAR_D
On 12/20/22 10:30, Patrick Palka wrote:
Unfortunately the extract_autos_r fix in r13-4799-ga7c8036b26082d is
derailed by the fact that walk_tree_1 currently walks the elements of a
TREE_VEC in reverse, which means for A in the below testcase
extract_autos_r ends up adjusting the TEMPLATE_TYPE_IDX
On 12/20/22 07:07, Richard Biener wrote:
On Fri, Dec 2, 2022 at 4:46 PM Jason Merrill via Gcc-patches
wrote:
Tested x86_64-pc-linux-gnu, OK for trunk?
-- 8< --
If the DECL_VALUE_EXPR of a VAR_DECL has EXPR_LOCATION set, then any use of
that variable looks like it has that location, wh
On 12/20/22 05:49, Arsen Arsenović wrote:
From: Jonathan Wakely
Make the output more readable. Don't output anything unless verbose
termination is enabled at configure-time.
libstdc++-v3/ChangeLog:
PR libstdc++/107792
PR libstdc++/107778
* src/experimental/contract.cc
On 12/15/22 12:39, Arsen Arsenović wrote:
Hi,
Jason Merrill writes:
The lowercase constants are more consistent with the standard, and it is
unlikely that the uppercase versions would've been accepted.
OK.
Thanks. Could you push this for me? I don't have write access.
Done.
Jason
On 12/16/22 19:52, Jeff Law wrote:
On 12/6/22 06:26, Jason Merrill via Gcc-patches wrote:
Tested x86_64-pc-linux-gnu, OK for trunk?
-- 8< --
The PR (which isn't resolved by this commit) pointed out to me that GCC
should build with -Wconditionally-supported to support bootstrapping
On 12/19/22 13:13, Patrick Palka wrote:
On Mon, 19 Dec 2022, Jason Merrill wrote:
On 12/6/22 13:35, 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
asser
On 12/7/22 15:18, Patrick Palka wrote:
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 typ
401 - 500 of 1486 matches
Mail list logo
