On 8/4/25 11:11 AM, Jakub Jelinek wrote:
Hi!
Another easy part from the paper.
Part of the CWG2579 has been already done in an earlier paper (with
test commits by Marek) and the remaining part is implemented correctly,
we diagnose as error when token pasting doesn't form a valid token.
Except
On 8/1/25 8:30 AM, Jakub Jelinek wrote:
Hi!
Contrary to what the paper says, I think for #line directives we diagnose
everything we should (sure, some diagnostics are pedwarns).
Tested on x86_64-linux, ok for trunk?
OK.
2025-08-01 Jakub Jelinek
PR preprocessor/120778
* g
On 8/1/25 4:12 PM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk and 15 after 15.2 is released?
OK.
-- >8 --
The below testcases started to get rejected due to overload resolution
ambiguity after r15-3740 which corrected our inheritedness
On 8/2/25 3:35 AM, Jakub Jelinek wrote:
Hi!
This is another case which changed from compile time undefined behavior
to ill-formed, diagnostic required. Now, we warn on this, so pedantically
that is good enough, maybe all we need is a testcase, but the following
patch changes it to a pedwarn for
On 8/3/25 12:23 PM, Patrick Palka wrote:
On Sun, 3 Aug 2025, Jason Merrill wrote:
On 8/1/25 11:16 AM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk and 15/14 after 15.2 is released?
-- >8 --
r13-3299 changed our internal declaration
On 8/1/25 12:52 PM, Jakub Jelinek wrote:
Hi!
The CWG1709 just codifies existing GCC (and clang) behavior, so this
just adds a testcase for that.
Tested on x86_64-linux, ok for trunk?
OK.
2025-08-01 Jakub Jelinek
PR preprocessor/120778
* g++.dg/DRs/dr1709.C: New test.
--
On 7/31/25 1:58 PM, Jakub Jelinek wrote:
On Thu, Jul 31, 2025 at 11:04:56AM -0400, Jason Merrill wrote:
If the current backup handling is doing the wrong thing in this case, it
seems better to fix it rather than add more earlier in the function. Would
it be enough to move the existing
On 8/1/25 11:16 AM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk and 15/14 after 15.2 is released?
-- >8 --
r13-3299 changed our internal declaration of __dynamic_cast to reside
inside the abi / __cxxabiv1 namespace instead of the global na
Tested x86_64-pc-linux-gnu, applying to trunk and 15.
-- 8< --
Here cxx_eval_vec_init_1 wants to recreate the default constructor call that
we previously built and threw away in build_vec_init_elt, but we aren't in
the same access context at this point. Since we already checked access,
let's jus
On 6/27/25 5:54 PM, Jakub Jelinek wrote:
Hi!
My changes for "Module Declarations Shouldn’t be Macros" paper broke
the following testcase. The backup handling intentionally tries to
drop CPP_PRAGMA_EOL token if things go wrong, which is desirable for the
case where we haven't committed to the mo
On 7/30/25 5:48 PM, Patrick Palka wrote:
On Wed, 30 Jul 2025, Patrick Palka wrote:
On Wed, 30 Jul 2025, Patrick Palka wrote:
On Wed, 30 Jul 2025, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
-- >8 --
Here the result of A::make(0, 0,
On 7/30/25 7:37 PM, Patrick Palka wrote:
On Thu, 31 Jul 2025, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
And maybe 15?
Good catch re the invisiref handling! This LGTM, Jason what do you
think?
OK for trunk and 15.
-- >8 --
When we merge a fu
On 7/31/25 10:34 AM, Jason Merrill wrote:
On 7/29/25 8:10 AM, Nathaniel Shead wrote:
Thoughts? Another suggestion raised on the PR was to just make this a
warning or some other non-fatal diagnostic (I suppose not attached to
any particular warning option?) and continue translation; I'
On 7/29/25 8:10 AM, Nathaniel Shead wrote:
Thoughts? Another suggestion raised on the PR was to just make this a
warning or some other non-fatal diagnostic (I suppose not attached to
any particular warning option?) and continue translation; I'm not
particularly fussed either way.
An unconditio
On 7/31/25 7:12 AM, Marek Polacek wrote:
On Thu, Jul 31, 2025 at 11:43:17AM +0200, Richard Biener wrote:
On Sat, Jun 28, 2025 at 12:31 AM Jason Merrill wrote:
On 6/26/25 4:12 PM, Marek Polacek wrote:
On Wed, Jun 25, 2025 at 03:13:25PM -0400, Jason Merrill wrote:
On 6/25/25 1:28 PM, Marek
On 7/30/25 7:03 PM, Marek Polacek wrote:
On Wed, Jul 30, 2025 at 03:30:06PM -0400, Jason Merrill wrote:
On 7/25/25 3:59 PM, Marek Polacek wrote:
On Tue, Jul 22, 2025 at 04:52:53PM -0400, Jason Merrill wrote:
On 7/21/25 6:28 PM, Marek Polacek wrote:
On Mon, Jul 21, 2025 at 11:26:08AM -0400
On 7/25/25 4:55 PM, Marek Polacek wrote:
On Thu, Jul 17, 2025 at 05:20:31PM -0400, Jason Merrill wrote:
On 7/16/25 5:59 PM, Marek Polacek wrote:
On Mon, Jul 14, 2025 at 12:52:41PM -0400, Jason Merrill wrote:
On 7/11/25 5:49 PM, Marek Polacek wrote:
On Thu, Jul 10, 2025 at 02:13:06PM -0400
On 7/25/25 3:59 PM, Marek Polacek wrote:
On Tue, Jul 22, 2025 at 04:52:53PM -0400, Jason Merrill wrote:
On 7/21/25 6:28 PM, Marek Polacek wrote:
On Mon, Jul 21, 2025 at 11:26:08AM -0400, Jason Merrill wrote:
On 7/18/25 5:11 PM, Marek Polacek wrote:
On Thu, Jul 17, 2025 at 06:44:08PM -0400
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
A conversation today pointed out that the current diagnostic for this case
doesn't mention the constant evaluation failure, it just says e.g.
"'p' is not a valid template argument for 'int*' because it is not the
address of a variable"
Thi
On 7/29/25 3:20 AM, Jakub Jelinek wrote:
Hi!
The PR13358 r0-92909 change changed the diagnostics on long long
in C++ (either with -std=c++98 or -Wlong-long), but unlike the
C FE we unfortunately warn even in the
__extension__ long long a;
etc. cases. The C FE in that case in
disable_extension_d
On 7/29/25 3:45 AM, Jakub Jelinek wrote:
Hi!
The P2843R3 Preprocessing is never undefined paper contains comments
that various compilers handle comma operators in preprocessor expressions
incorrectly and I think they are right.
In both C and C++ the grammar uses constant-expression non-terminal
On 7/24/25 10:07 PM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu. Also verified that
it fixes the regression on an mcore-elf cross. OK for trunk?
OK.
-- >8 --
The assertion failure on ASM_OUTPUT_WEAKREF targets since my r16-1738
was caused because the 'TREE_CHA
On 7/24/25 5:20 PM, Patrick Palka wrote:
On Thu, 24 Jul 2025, Jason Merrill wrote:
On 7/23/25 8:29 PM, Patrick Palka wrote:
On Wed, 23 Jul 2025, Jason Merrill wrote:
On 7/23/25 3:46 PM, Patrick Palka wrote:
As a follow-up to r16-2448-g7590c14b53a762, this patch attempts to teach
On 7/23/25 8:29 PM, Patrick Palka wrote:
On Wed, 23 Jul 2025, Jason Merrill wrote:
On 7/23/25 3:46 PM, Patrick Palka wrote:
As a follow-up to r16-2448-g7590c14b53a762, this patch attempts to teach
build_min_non_dep_op_overload how to rebuild all rewritten comparison
operators, not just
On 7/24/25 2:43 PM, Patrick Palka wrote:
On Thu, 24 Jul 2025, Jason Merrill wrote:
The lambda conversion was ICEing for two C++23 features, static op() and
explicit object parameters. The issue with the former seems like a more
general issue: tsubst_function_decl recursing to substitute the
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
The lambda conversion was ICEing for two C++23 features, static op() and
explicit object parameters. The issue with the former seems like a more
general issue: tsubst_function_decl recursing to substitute the parameters
was affected by cp_u
On 7/24/25 8:40 AM, Nathaniel Shead wrote:
On Thu, Jul 24, 2025 at 09:02:24PM +1000, Nathaniel Shead wrote:
On Tue, Jul 08, 2025 at 12:51:37PM -0400, Jason Merrill wrote:
I'm resistant to moving functions around unnecessarily, as it makes git
change tracking a lot harder. Especially wh
On 7/24/25 12:39 PM, Iain Sandoe wrote:
On 24 Jul 2025, at 17:31, Jason Merrill wrote:
On 7/24/25 10:24 AM, Iain Sandoe wrote:
We should check (gcc_checking_assert?) that NRVO works in the case where we
expect it to, rather than let NRVO failures show up as wrong-code.
This seems a
On 7/24/25 10:24 AM, Iain Sandoe wrote:
We should check (gcc_checking_assert?) that NRVO works in the case where we
expect it to, rather than let NRVO failures show up as wrong-code.
This seems a simple request - but it seems quite involved to implement;
the conditions that have to be met are n
On 7/24/25 6:59 AM, Iain Sandoe wrote:
return machinery to return the g_r_o_o_a_f.
I think it should be simpler/cleaner to move the grooaf case to the 'else'
rather than the 'then', to accommodate the NRVO limitation described in
check_return_expr:
Done.
same type.
We should check
On 7/23/25 3:46 PM, Patrick Palka wrote:
As a follow-up to r16-2448-g7590c14b53a762, this patch attempts to teach
build_min_non_dep_op_overload how to rebuild all rewritten comparison
operators, not just != -> == ones, so that we don't incorrectly repeat
the unqualified name lookup at instantiati
On 7/23/25 11:45 AM, Iain Sandoe wrote:
This is needed to be able to back-port the rest of the CWG2563 work to
GCC-15.2, so I've prioritised it. So far, tested on x86_64 darwin, OK
for trunk (and backport) if it passes wider testing?
thanks
Iain
--- 8< ---
The current implementation was returni
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
The note and example in [class.union] p6 think that placement new can be
used to change the active member of a union, but we didn't support that for
array members in constant-evaluation even after implementing P1330 and
P2747.
First I tried
On 7/22/25 4:18 PM, Patrick Palka wrote:
Bootstrapped and rgetested on x86_64-pc-linux-gnu, does this look OK for
trunk?
In order to properly handle all rewritten operator expressions, I
suppose we could teach build_min_non_dep_op_overload to carefully look
through 'non_dep' and note when argume
On 7/21/25 6:28 PM, Marek Polacek wrote:
On Mon, Jul 21, 2025 at 11:26:08AM -0400, Jason Merrill wrote:
On 7/18/25 5:11 PM, Marek Polacek wrote:
On Thu, Jul 17, 2025 at 06:44:08PM -0400, Jason Merrill wrote:
On 7/17/25 6:25 PM, Jakub Jelinek wrote:
On Thu, Jul 17, 2025 at 05:31:27PM -0400
On 7/22/25 4:18 PM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk?
OK, and I think go ahead and apply it to the 15 branch as well.
-- >8 --
Our implementation of the INVOKE spec ([func.require]) was incorrectly
treating reference_wrapper:
On 7/18/25 5:17 PM, Marek Polacek wrote:
On Thu, Jul 17, 2025 at 05:20:31PM -0400, Jason Merrill wrote:
On 7/16/25 5:59 PM, Marek Polacek wrote:
On Mon, Jul 14, 2025 at 12:52:41PM -0400, Jason Merrill wrote:
On 7/11/25 5:49 PM, Marek Polacek wrote:
On Thu, Jul 10, 2025 at 02:13:06PM -0400
On 7/18/25 5:11 PM, Marek Polacek wrote:
On Thu, Jul 17, 2025 at 06:44:08PM -0400, Jason Merrill wrote:
On 7/17/25 6:25 PM, Jakub Jelinek wrote:
On Thu, Jul 17, 2025 at 05:31:27PM -0400, Jason Merrill wrote:
On 7/16/25 10:49 AM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux
On 7/17/25 6:25 PM, Jakub Jelinek wrote:
On Thu, Jul 17, 2025 at 05:31:27PM -0400, Jason Merrill wrote:
On 7/16/25 10:49 AM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
This patch implements consteval blocks, as specified by P2996.
They are
On 7/14/25 8:33 PM, Jeremy Rifkin wrote:
Hi Jason,
Thank you so much for taking a look!
This is OK, but I wonder about making do_warn_unused_result ignore empty
types in general; if there's no data in the type, what does it matter if
we ignore the empty box?
I'm not strongly opinionated and I
On 7/16/25 10:49 AM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
This patch implements consteval blocks, as specified by P2996.
They aren't very useful without define_aggregate, but having
a reviewed implementation on trunk would be great.
consteva
On 7/16/25 5:59 PM, Marek Polacek wrote:
On Mon, Jul 14, 2025 at 12:52:41PM -0400, Jason Merrill wrote:
On 7/11/25 5:49 PM, Marek Polacek wrote:
On Thu, Jul 10, 2025 at 02:13:06PM -0400, Jason Merrill wrote:
On 7/9/25 4:27 PM, Marek Polacek wrote:
On Tue, Jul 08, 2025 at 12:15:03PM -0400
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
In Jakub's patch for PR44677 he added code to prevent mark_exp_read on
e.g. (void)++i from marking i as read, but it seems to me that we can
generalize that to avoid looking any farther into any void expression;
you can't read a void value,
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
This was failing for two reasons:
1) We were wrongly treating the basic_string constructor as
zero-initializing the object, which it doesn't.
2) Given that, when we went to look for a value for the anonymous union,
we concluded that it was
On 7/15/25 9:04 AM, Jakub Jelinek wrote:
On Tue, Jul 15, 2025 at 08:21:50AM -0400, Jason Merrill wrote:
Given the above that seems rather unlikely, but I suppose it's fine if you
want to do it that way. The patch is OK either way.
Committed just the v2 patch. I can test your patch next
On 7/15/25 7:49 AM, Jonathan Wakely wrote:
On Thu, 10 Jul 2025 at 09:06, Jakub Jelinek wrote:
On Wed, Jul 09, 2025 at 06:45:41PM -0400, Jason Merrill wrote:
+ && reduced_constant_expression_p (val))
And a value doesn't need to be constant to be printable, we should be abl
On 7/15/25 5:26 AM, Jakub Jelinek wrote:
On Mon, Jul 14, 2025 at 11:58:32PM -0400, Jason Merrill wrote:
Coming back to this comment, it still seems to me that we can generalize
this and ignore anything cast to void here, as in the below; after something
has been cast to void, it can no longer
On 7/11/25 9:09 AM, Jakub Jelinek wrote:
On Thu, Jul 10, 2025 at 04:35:49PM -0400, Jason Merrill wrote:
@@ -211,8 +211,27 @@ mark_use (tree expr, bool rvalue_p, bool
}
return expr;
}
- gcc_fallthrough();
+ gcc_fallthrough ();
CASE_CONVERT
On 7/11/25 5:49 PM, Marek Polacek wrote:
On Thu, Jul 10, 2025 at 02:13:06PM -0400, Jason Merrill wrote:
On 7/9/25 4:27 PM, Marek Polacek wrote:
On Tue, Jul 08, 2025 at 12:15:03PM -0400, Jason Merrill wrote:
On 7/7/25 4:52 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu
On 7/11/25 3:00 PM, Jakub Jelinek wrote:
On Fri, Jul 11, 2025 at 02:34:24PM -0400, Jason Merrill wrote:
But by the time we get to cp_fold, DECL_READ_P should have already been set
appropriately when we built the thing we're now folding. And calling
Clearly it hasn't been, otherwis
On 7/11/25 2:17 PM, Jakub Jelinek wrote:
On Fri, Jul 11, 2025 at 12:26:54PM -0400, Jason Merrill wrote:
On 7/11/25 9:09 AM, Jakub Jelinek wrote:
On Thu, Jul 10, 2025 at 04:35:49PM -0400, Jason Merrill wrote:
--- gcc/cp/cp-gimplify.cc.jj2025-04-12 21:41:42.660924514 +0200
+++ gcc/cp/cp
On 7/10/25 4:41 PM, Nicolas Werner wrote:
Users might be using a space in their build directory path. To allow
specifying such a root for the module mapper started by GCC, we need the
command to allow quotes. Previously quoting a path passed to the module
mapper was not possible, so replace the c
On 7/11/25 9:09 AM, Jakub Jelinek wrote:
On Thu, Jul 10, 2025 at 04:35:49PM -0400, Jason Merrill wrote:
--- gcc/cp/cp-gimplify.cc.jj2025-04-12 21:41:42.660924514 +0200
+++ gcc/cp/cp-gimplify.cc 2025-04-23 21:33:19.050931604 +0200
@@ -3200,7 +3200,23 @@ cp_fold (tree x, fold_flags_t
On 7/10/25 6:34 PM, Jakub Jelinek wrote:
On Thu, Jul 10, 2025 at 05:46:06PM -0400, Jason Merrill wrote:
+ bool trivially_relocatable_if_eligible : 1;
+ bool replaceable_if_eligible : 1;
+
+ bool trivially_relocatable : 1;
+ bool trivially_relocatable_computed : 1;
+ bool replaceable : 1
On 6/9/25 1:30 PM, Jakub Jelinek wrote:
Hi!
The following patch implements the
/* FIXME reuse another field? */
comment on the lambda_expr member.
I think (and asserts in the patch seem to confirm) CLASSTYPE_KEY_METHOD
is only ever non-NULL for TYE_POLYMORPHIC_P and on the other side
CLASSTYPE_
On 6/17/25 2:25 AM, Jakub Jelinek wrote:
Hi!
When writing the libstdc++ patch, I've noticed I've missed adding any
testsuite coverage for __builtin_is_nothrow_relocatable trait.
And got wrong the implementation as well, I thought type2 in that
case should be the rvalue reference type to type1,
On 6/12/25 3:11 AM, Jakub Jelinek wrote:
Hi!
The following patch is on top of the
https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686210.html
patch which stopped treating override as conditional keyword in
class properties.
This PR mentions another problem; we emit a bogus warning on code li
On 6/9/25 1:19 PM, Jakub Jelinek wrote:
On Mon, Jun 09, 2025 at 12:17:12PM -0400, Jason Merrill wrote:
While the
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p2786r13.html#c03-compatibility-changes-for-annex-c-diff.cpp03.dcl.dcl
hunk dropped because
struct C {}; struct C {} final
On 4/24/25 3:50 AM, Jakub Jelinek wrote:
Hi!
The -Wunused-but-set-* warnings work by using 2 bits on VAR_DECLs &
PARM_DECLs, TREE_USED and DECL_READ_P. If neither is set, we typically
emit -Wunused-variable or -Wunused-parameter warning, that is for variables
which are just declared (including
On 7/9/25 4:27 PM, Marek Polacek wrote:
On Tue, Jul 08, 2025 at 12:15:03PM -0400, Jason Merrill wrote:
On 7/7/25 4:52 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
This patch is an attempt to implement P2036R3 along with P2579R0, fixing
bu
On 7/10/25 4:05 AM, Jakub Jelinek wrote:
On Wed, Jul 09, 2025 at 06:45:41PM -0400, Jason Merrill wrote:
+ && reduced_constant_expression_p (val))
And a value doesn't need to be constant to be printable, we should be able
to print it unconditionally.
Sure, the question i
On 7/9/25 2:36 PM, Jakub Jelinek wrote:
On Wed, Jul 09, 2025 at 10:26:51AM -0400, Jason Merrill wrote:
I don't understand this comment, at least in connection with the above
snippet, that just handles the magic calls.
Sorry I wasn't clear, the comment was about the existing code th
On 5/29/25 8:52 AM, Alfie Richards wrote:
Adds the target_version and target_clones attributes to diagnostic messages
for target_version semantics.
This is because the target_version/target_clones attributes affect the identity
of the decls, so need to be represented in diagnostics for them.
Af
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
These pass now; the first was fixed by r16-1507.
PR c++/120243
gcc/testsuite/ChangeLog:
* g++.dg/coroutines/torture/pr120243-unhandled-1.C: New test.
* g++.dg/coroutines/torture/pr120243-unhandled-2.C: New test.
--
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
My r16-2065 adding missed errors for auto in a template arg in a lambda
parameter also introduced a bogus error on this testcase, where the auto is
both in a lambda parameter and in a template arg, but in the other order,
which is OK. So we
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
In r16-970 I changed finish_this_expr to look at current_class_type rather
than current_class_ptr to accommodate explicit object lambdas. But here in
a lambda in the noexcept-spec, the closure type doesn't yet have the
function as its conte
On 7/8/25 4:22 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
Found while working on Reflection where we currently reject:
constexpr auto r = ^^::template C::type;
which should work, because "::template C::" should match the
nested-name-sp
On 7/9/25 9:30 AM, Jakub Jelinek wrote:
On Tue, Jul 08, 2025 at 09:43:20PM -0400, Jason Merrill wrote:
@@ -3066,7 +3810,12 @@ cxx_eval_call_expression (const constexp
return arg1;
}
else if (cxx_dynamic_cast_fn_p (fun))
- return cxx_eval_dynamic_cast_fn (ctx, t
On 7/9/25 7:34 AM, Jakub Jelinek wrote:
On Tue, Jul 08, 2025 at 09:43:20PM -0400, Jason Merrill wrote:
Thanks for the review.
Working on the rest (most of it already have in my working copy).
case CLEANUP_POINT_EXPR:
{
- auto_vec cleanups;
+ auto_vec cleanups
On 6/6/25 9:17 AM, Jakub Jelinek wrote:
On Wed, Jun 04, 2025 at 02:03:17PM +0200, Jakub Jelinek wrote:
You mean also check TREE_NOTHROW (fndecl) which we currently propagate
conservatively (if we can prove something never throws, we set it)
or something else?
If TREE_NOTHROW, that would be twice
On 6/19/25 8:13 AM, Jakub Jelinek wrote:
Hi!
The following patch implements the constexpr structured bindings part of
the P2686R4 paper, so the [dcl.pre], [dcl.struct.bind], [dcl.constinit]
and first hunk in [dcl.constexpr] changes.
The paper doesn't have a feature test macro and the constexpr s
On 5/30/25 11:22 PM, Nathaniel Shead wrote:
On Fri, May 30, 2025 at 11:10:08AM -0400, Patrick Palka wrote:
On Fri, 30 May 2025, Patrick Palka wrote:
On Fri, 30 May 2025, Nathaniel Shead wrote:
On Wed, May 28, 2025 at 02:14:06PM -0400, Patrick Palka wrote:
On Tue, 27 May 2025, Nathaniel Shea
On 5/23/25 9:00 PM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk/15?
-- >8 --
When emitting a primary module interface, we must re-stream any TU-local
entities that we saw in a partition. This patch adds the missing
members from core_vals.
As a drive-
On 6/9/25 9:00 PM, Jeremy Rifkin wrote:
Hi,
This fixes PR c/82134 which concerns gcc emitting an incorrect unused
result diagnostic for empty types. This diagnostic is emitted from
tree-cfg.cc because of a couple code paths which attempt to avoid
copying empty types, resulting in GIMPLE that isn'
On 7/8/25 11:32 AM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
While working on Reflection I noticed that we reject:
union U { int i; };
constexpr auto r = ^^typename ::U;
which is due to PR83469. Andrew P. posted a patch in 2021:
https://
On 7/7/25 4:52 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
This patch is an attempt to implement P2036R3 along with P2579R0, fixing
build breakages caused by P2036R3.
The simplest example is:
auto counter1 = [j=0]() mutable -> decltype(j) {
On 7/8/25 9:44 AM, Richard Biener wrote:
On Tue, Jul 8, 2025 at 3:25 PM Jason Merrill wrote:
On 7/8/25 4:35 AM, Richard Biener wrote:
On Mon, Jul 7, 2025 at 11:33 PM H.J. Lu wrote:
On Tue, Jul 8, 2025 at 5:02 AM H.J. Lu wrote:
On Mon, Jul 7, 2025 at 11:08 PM Jason Merrill wrote:
On
On 7/8/25 4:35 AM, Richard Biener wrote:
On Mon, Jul 7, 2025 at 11:33 PM H.J. Lu wrote:
On Tue, Jul 8, 2025 at 5:02 AM H.J. Lu wrote:
On Mon, Jul 7, 2025 at 11:08 PM Jason Merrill wrote:
On 7/1/25 5:36 PM, H.J. Lu wrote:
On Tue, Jul 1, 2025 at 9:37 PM Jason Merrill wrote:
On 6/30/25
On 7/3/25 9:46 AM, Jakub Jelinek wrote:
On Thu, Jul 03, 2025 at 09:35:49AM -0400, Jason Merrill wrote:
On 7/2/25 7:58 PM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk?
-- >8 --
Here the flag -fno-delete-null-pointer-checks causes
On 7/2/25 7:58 AM, Alfie Richards wrote:
Hi Jason,
Thanks for the feedback, see below an updated patch.
OK.
Again reg-tested on Aarch64 and x86.
Thanks,
Alfie
-- >8 --
Add logic for the case of two FMV annotated functions with identical
signature other than the return type.
Previously th
On 7/1/25 5:36 PM, H.J. Lu wrote:
On Tue, Jul 1, 2025 at 9:37 PM Jason Merrill wrote:
On 6/30/25 7:03 PM, H.J. Lu wrote:
On Mon, Jun 30, 2025 at 10:36 PM Jason Merrill wrote:
On 6/28/25 7:00 AM, H.J. Lu wrote:
Since a backend may ignore user type alignment for arguments passed on
stack
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
In r14-1659 I added a missing error for a Concepts TS feature that we were
failing to diagnose, but this PR requests a way to disable that error for
code written thinking it was valid. Which seems reasonable, since it
doesn't require any wo
On 7/5/25 1:05 PM, Jakub Jelinek wrote:
On Sat, Jul 05, 2025 at 08:46:31AM -0400, Jason Merrill wrote:
I think we want these diagnostics enabled by default; I don't feel strongly
about unconditional pedwarn vs. permerror.
So like this then?
OK.
2025-07-05 Jakub Jelinek
On 7/3/25 10:43 AM, Patrick Palka wrote:
On Thu, 3 Jul 2025, Jason Merrill wrote:
On 7/2/25 7:58 PM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk?
-- >8 --
Here the flag -fno-delete-null-pointer-checks causes the trivial addr
On 7/5/25 2:20 AM, Jakub Jelinek wrote:
Hi!
https://eel.is/c++draft/stmt.ranged#2
says that in for-range-declaration only type-specifier or constexpr
can appear. As the following testcases show, we've emitted some
diagnostics in most cases, but not for static/thread_local (the patch
handles __t
Tested x86_64-pc-linux-gnu, applying to trunk and 15.
-- 8< --
Here we were asserting non-zero errorcount, which is not the case if the
parse error was reduced to a warning (or silenced) in a template body. So
check seen_error instead.
PR c++/120575
PR c++/116064
gcc/cp/ChangeL
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
In this testcase there is nothing in the lambda except a static_assert which
mentions a variable from the enclosing scope but does not odr-use it, so we
want prune_lambda_captures to remove its capture. Since the lambda is so
empty, there's
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
This testcase was crashing from infinite recursion in the diagnostic
machinery, trying to print the lambda signature, which referred to the
__this capture field in the lambda, which wanted to print the lambda again.
But we don't want the si
On 7/2/25 7:58 PM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk?
-- >8 --
Here the flag -fno-delete-null-pointer-checks causes the trivial address
comparison in
inline int a, b;
static_assert(&a != &b);
to be rejected as non-constan
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
In r15-7532 for PR118856 I introduced a TARGET_EXPR with a
TARGET_EXPR_INITIAL of void_node to express that no initialization is done.
And indeed evaluating that doesn't store a value for the TARGET_EXPR_SLOT
variable.
But then at the end o
On 6/26/25 6:33 AM, Jakub Jelinek wrote:
On Wed, Jun 25, 2025 at 10:58:59PM +0200, Maciej Cencora wrote:
update of std module is missing.
Here is an updated patch which adds the std module part and while I was
changing the patch, I've also added value_type/type and the 2 operators
to std::type
On 6/30/25 4:25 AM, Alfie Richards wrote:
Hi Jeff,
Yes agreed, I've respun this to be standalone and moved the relevant test
from another patch to this.
Sending again for reapproval in an abbundance of caution.
Regr tested on Aarch64 and x86.
Thanks,
Alfie
-- >8 --
Add logic for the case of
On 7/1/25 10:57 AM, Florian Weimer wrote:
* Jason Merrill:
On 6/30/25 5:22 PM, Florian Weimer wrote:
* Jason Merrill:
On 6/28/25 3:17 PM, Florian Weimer wrote:
* Jason Merrill:
Since r10-6069[1] we control the call to __cxa_finalize with
DEFAULT_USE_CXA_ATEXIT, so there's no need to
On 6/30/25 5:22 PM, Florian Weimer wrote:
* Jason Merrill:
On 6/28/25 3:17 PM, Florian Weimer wrote:
* Jason Merrill:
Since r10-6069[1] we control the call to __cxa_finalize with
DEFAULT_USE_CXA_ATEXIT, so there's no need to also declare it as a weak
reference; if the targe
On 6/30/25 7:03 PM, H.J. Lu wrote:
On Mon, Jun 30, 2025 at 10:36 PM Jason Merrill wrote:
On 6/28/25 7:00 AM, H.J. Lu wrote:
Since a backend may ignore user type alignment for arguments passed on
stack, check backend for argument alignment on stack when evaluating
__alignof.
I assume that&#
On 7/1/25 3:10 AM, Jakub Jelinek wrote:
On Mon, Jun 30, 2025 at 04:56:47PM -0400, Jason Merrill wrote:
On 6/30/25 4:24 PM, Jakub Jelinek wrote:
On Mon, Jun 30, 2025 at 03:55:46PM -0400, Jason Merrill wrote:
Might go with my earlier !TREE_SIDE_EFFECTS && tree_invariant_p suggestion?
On 6/30/25 4:24 PM, Jakub Jelinek wrote:
On Mon, Jun 30, 2025 at 03:55:46PM -0400, Jason Merrill wrote:
Might go with my earlier !TREE_SIDE_EFFECTS && tree_invariant_p suggestion?
If you mean the following, it passes the 2 testcases and I can surely
bootstrap/regtest it tonight.
Yes
On 6/30/25 1:06 PM, Jakub Jelinek wrote:
On Mon, Jun 30, 2025 at 05:14:06PM +0200, Jakub Jelinek wrote:
1) for idx being INTEGER_CST (case for which I believe the change has been
added) it keeps doing what it did
2) if both op1 and op2 are arrays with invariant address or pointers to
som
On 6/29/25 2:19 PM, Jason Merrill wrote:
On 6/28/25 3:08 AM, Jakub Jelinek wrote:
On Fri, Jun 27, 2025 at 06:49:12PM -0400, Jason Merrill wrote:
On 6/27/25 5:58 PM, Jakub Jelinek wrote:
The following testcase is miscompiled since the introduction of UBSan,
cp_build_array_ref COND_EXPR
On 6/28/25 7:00 AM, H.J. Lu wrote:
Since a backend may ignore user type alignment for arguments passed on
stack, check backend for argument alignment on stack when evaluating
__alignof.
I assume that's reflected in DECL_ALIGN, so could we just add PARM_DECL to
else if (VAR_OR_FUNCTION_DECL_
1 - 100 of 2280 matches
Mail list logo
