[{"id":3684112,"web_url":"http://patchwork.ozlabs.org/comment/3684112/","msgid":"","list_archive_url":null,"date":"2026-04-29T14:48:20","subject":"Re: [PATCH] Changes to gcc-16/porting_to","submitter":{"id":48004,"url":"http://patchwork.ozlabs.org/api/people/48004/","name":"Jonathan Wakely","email":"jwakely@redhat.com"},"content":"On Tue, 28 Apr 2026 at 18:19 -0400, Nathan Myers wrote:\n>gcc-wwwdocs/Changelog:\n>\n>\t* htdocs/gcc-16/porting_to.html: Numerous edits.\n>\n>---\n>\n> - Demote \"C and C++\" build errors to

, matching C++\n> - Promote 'uninitialized-variable', 'missing-header-includes'\n> common build failures from C++ to \"C and C++'.\n> - Clarify comments on unused-but-set increment examples, and\n> note that just silencing the warning is not necessarily the\n> right action.\n> - Add 'capture-this-deprecated' build failure in C++.\n> (From package builds, it showed up only in jemalloc.)\n> - Mention autoconf-2.73 change to AC_PROG_CXX under\n> 'wrong-standard', and suggest upgrading autoconf or removing\n> AC_PROG_CXX.\n> - Note that names removed from C++20 may still be seen in GCC-16\n> headers when building with -std=c++20.\n> - Note the -std=c++17 alternative to immediately renaming all\n> 'concept' and 'requires' identifiers.\n> - Change 'error:' to 'warning:' in sample diagnostics for uses\n> where the default is only a warning.\n> - Indent example diagnostic messages.\n> - Eliminate the 'specified bound 18446744073709551608' build\n> failure example as too obscure. (It only showed up in jemalloc\n> builds.)\n> - Trivial wording improvements.\n>\n>(patch attached, page as patched may be viewed at\n>.)\n\n>diff --git a/htdocs/gcc-16/porting_to.html b/htdocs/gcc-16/porting_to.html\n>index 2ab0df6f..3011261f 100644\n>--- a/htdocs/gcc-16/porting_to.html\n>+++ b/htdocs/gcc-16/porting_to.html\n>@@ -21,12 +21,18 @@ facilitate compilation or run-time performance.\n>

\n> Some of these changes are user visible and can cause grief when\n> porting to GCC 16. This document is an effort to identify common issues\n>-and provide solutions. Let us know if you have suggestions for improvements!\n>+and suggest solutions. Let us know if you have suggestions for improvements!\n\nThis intro paragraph comes from the template used for every release,\nlet's not change it.\n\n>

\n> \n>-

Common C and C++ language issues

\n>+

C and C++ language issues

\n\nI think this is \"common\" as in common to both C and C++, not common as\nin frequently encountered. So I think it should stay.\n\n> \n>-

Changes to -Wunused-but-set-* warnings

\n>+

Common C and C++ build failures

\n>+

\n>+Failures encountered when using Gcc-16 to rebuild numerous open-source\n>+C and C++ packages included the following:\n\nI'd prefer to just list the problems and give solutions, without this\npart. It doesn't really add value.\n\n(But it should be \"GCC 16\" though, not \"Gcc-16\")\n\n>+

\n>+\n>+

Changes to -Wunused-but-set-* warnings

\n> \n> \n> \n>@@ -59,10 +65,10 @@ void foo (void) {\n> int f = 0; // No warning, f used\n> int g = f = 5;\n> (void) g;\n>- int h = 0; // No warning, preincrement used\n>+ int h = 0; // No warning, preincrement result used\n> int i = ++h;\n> (void) i;\n>- int j = 0; // No warning, postdecrement used\n>+ int j = 0; // No warning, postdecrement result used\n\nIf I understand correctly, this does match the intended meaning\nbetter, but I'd like to hear from Jakub who added this example.\n\n> int k = j--;\n> (void) k;\n> int l = 0; // No warning, l used\n>@@ -75,20 +81,49 @@ void foo (void) {\n> In order to avoid the warnings, one can either remove newly diagnosed\n> variables or parameters which aren't used except in pre/post inc/decrements\n> or compound assignments, make them used in some way, e.g. just\n>-casting to (void), or lowering the level of the warning. See\n>+casting to (void), or lowering the level of the warning.\n>+But note that an unused variable may indicate a coding error, where\n>+some other object was mistakenly used in its place, or a larger change\n>+was begun but left incomplete.\n\nAgain, I'll leave Jakub to review this.\n\n>+See\n> \n> -Wunused-but-set-* documentation for more details.\n>

\n> \n>+

Uninitialized-variable warnings

\n>+\n>+

\n>+The compiler has similarly become better at identifying and warning about\n>+cases where a variable may be getting used without initialization, resulting\n>+in undefined behavior, and messages like:\n>+

 warning: ‘buffer’ may be used uninitialized\n\nPlease use plain ' quotes not ‘ and ’\n(the former is wht you get printed with LANG=C and the latter are\nlocale-specific).\n\n>+

These can often be fixed just by initializing the variable\n>+to a default value, but they might indicate a deeper problem that such a\n>+change would only mask.\n>+

\n\nThe warning isn't new though, and every release can change when/where\nyou get these warnings. I'm not sure we need to document it here.\n\n>+\n>+

Missing header includes

\n>+\n>+

\n>+Programs sometimes use names without having properly #included the header\n>+that declares them, relying instead on the name having being declared\n>+incidentally via some other header; until it no longer does, resulting in\n>+errors like:\n>+

 error: ‘uint64_t’ was not declared in this scope
\n>+

These are fixed by identifying which header declares the name, and\n>+including that. The compiler may suggest the header to include.\n>+

\n\nThis should be under the C++ issues, where I originally added it. What\nchanged in GCC 16 is the removal of some transitive includes in\nlibstdc++, so this doesn't affect C programs. We don't need a generic\ntutorial on include-what-you-use for C and C++, we just need to say\nthat is less widely used within libstdc++.\n\n>+\n>+\n>

C++ language issues

\n> \n>

\n>-Note that all GCC releases make +All GCC releases make >improvements to conformance which may reject non-conforming, legacy\n> codebases.\n> Other issues arise from C++20 becoming the default choice of published\n> Standard to follow (as might have been overridden with, e.g.,\n>--std=c++20), and changes in C++20 from previous Standards.\n>+'-std=c++20)', and changes in C++20 from previous Standards.\n\nWe don't usually quote options when referred to anywhere in our docs.\nThe code font already makes it stand out.\n\n>

\n> \n>

Deprecated features removed in C++20

\n>@@ -99,43 +134,52 @@ been deprecated have been removed from the Standard. These are\n> summarized at the top of\n> >Changes between C++17 and C++20 DIS [\"Draft International Standard\"].\n>+Note that names removed from C++20 may still appear in headers when\n>+building under '-std=c++20', and only provoke 'deprecated'\n\nNo quotes around the -std option.\n\n>+warnings.\n\nSo then we shouldn't say they've been removed. This is supposed to be\nabout porting to GCC 16, so if the names are still present in GCC 16\nthen we shouldn't talk about them being removed.\n\nDid we actually remove anything? I don't think we did. I don't even\nremember if we added deprecated attributes. ... git diff shows that I\ndeprecated std::fabs(const complex&) which was never in the\nstandard in the first place (see PR120235). I doubt anybody is using\nthat function, and we didn't remove anything except std::allocator\nmembers which are covered separately below. So I don't think we should\ndocument any removals/deprecations here.\n\n>

\n> \n>-

Common build failures

\n>+

Common C++ build failures

\n>

\n> Failures encountered when using Gcc-16 to rebuild numerous open-source\n>-packages included the following:\n>+C++ packages included the following:\n\nAgain, I don't think this adds value.\n\n>

\n> \n>-

Library uses features from a newer Standard

\n>+

Program uses features from a newer Standard

\n> \n>

\n>-Many failures are caused by using a build option like '-std=c++11\n>-where the code turns out to depend on features from a later Standard, such as when\n>-building with a new version of a library that has begun using such features.\n>-

error: 'make_unique' is not a member of 'std'\n>-

Just removing that option from the command line may suffice, although\n>-you might then need to update other code reliant on features that have\n>-been removed from the later Standard.

\n>+Many failures are caused by using a build option like '-std=c++11'\n\nI don't think Autoconf ever added -std=c++11, only -std=gnu++11, so\nthis is inaccurate.\n\n>+where the code turns out to depend on features from a later Standard:\n>+

 error: 'make_unique' is not a member of 'std'\n>+

Just removing that option from the command line may suffice,\n>+as GCC-16 now defaults to providing C++20. Note that autoconf\n\n\"GCC 16\" not \"GCC-16\"\n\n>+prior to release 2.73, if told 'AC_PROG_CXX' (meaning, verify the\n>+compiler supports C++11 features), upon checking GCC-16 incorrectly\n>+concludes it must add '-std=gnu++11' to the makefile.\n>+You can upgrade autoconf, or simply remove\n>+'AC_PROG_CXX' from the program's configure.ac file,\n>+and then reconstruct your project build scripts.\n\nI think this item buries the lede. The problem is the Autoconf bug,\nand nobody will be trying to use e.g. make_unique with -std=c++11 in\nexisting code that already compiles with GCC 15 and earlier. It's only\na problem when switching to GCC 16 *and* using a configure script\ngenerated by the buggy Autoconf 2.72 AC_PROG_CXX macro.\n\nSo maybe start by saying something about unexpected -std=gnu++11\noptions being added to makefiles and causing build failures, then\nexplain that it's due to Autoconf and then give your recommendation\nfor fixing it.\n\n> \n>

Expected identifier before

\n> \n>

\n> C++20 defines new keywords such as 'concept' and 'requires',\n> which can no longer be used as identifiers:\n>-

error: expected identifier before ‘concept’\n>-

The only solution is to change the name of the identifier.\n>+

 error: expected identifier before ‘concept’\n\nPlain '' quotes not ‘’\n\n>+

The only solutions are to change the name of the identifier,\n>+or build to an older standard, like '-std=c++17'.\n>

\n> \n>-

Uninitialized-variable warnings

\n>+

Implicit lambda capture of 'this'

\n> \n>

\n>-The compiler is now better at identifying and warning about cases\n>-where a variable may be getting used without initialization, resulting\n>-in undefined behavior, and errors like:\n>-

error: ‘buffer’ may be used uninitialized [-Werror=maybe-uninitialized]\n>-

These can often be fixed by just initializing the variable to a default\n>-value, but they may indicate a deeper problem that this would only mask.\n>+C++-20 deprecates implicitly capturing the value of the meta-variable\n>+'this' in saved lambda state, provoking warnings if member\n>+names from the surrounding context are used in the lambda body:\n>+

 warning: implicit capture of ‘this’ via ‘[=]’ is deprecated in C++20\n>+

\n>+These can be resolved by adding 'this' or '*this',\n>+as appropriate, to the capture list, such as by '[=,this]'.\n>

\n> \n>

Changes to character literals

\n>@@ -143,7 +187,7 @@ value, but they may indicate a deeper problem that this would only mask.\n>

\n> In C++20, u8\"str\" and u8'c' literals changed\n> from type char to type char8_t, leading to errors like:\n\n tags around char and char8_t\n\n>-

error: invalid conversion from 'const char8_t*' to 'const char*' [-fpermissive]\n>+

 error: invalid conversion from 'const char8_t*' to 'const char*' [-fpermissive]\n>

The fix is most commonly a cast from the u8 literal to plain char\n> or char const*.\n>

\n>@@ -155,7 +199,7 @@ In C++20, the operator>> overload for reading from an\n> istream into a char* was removed because it\n> offers no way to prevent buffer overrun when reading into a buffer of\n> unspecified size. This results in errors like:\n>-

error: no match for ‘operator>>’ (operand types are ‘std::istream’ {aka ‘std::basic_istream<char>’} and ‘char*’)\n>+

 error: no match for ‘operator>>’ (operand types are ‘std::istream’ {aka ‘std::basic_istream<char>’} and ‘char*’)\n\nPlain '' quotes not ‘’\n\n>

\n> A fix is to read into a native array, which uses the bound to prevent\n> overrun and leaves any extra characters unread, or to read into an\n>@@ -171,7 +215,7 @@ cause ambiguities if the type also defines its own operator!=\n> with an unconventional signature, such as only supporting comparisons\n> of non-const types (often a mistake, because comparison typically does\n> not require altering its arguments). This provokes errors like:\n>-

error: ambiguous overload for ‘operator!=’ (operand types are ‘daeStringRef’ and ‘long int’)\n>+

 error: ambiguous overload for ‘operator!=’ (operand types are ‘daeStringRef’ and ‘long int’)\n\nI think this item about default comparisons should be first. I expect\nit to be one of the most common problems when switching to C++20.\n\n>

Fixing argument-type signatures is often the simplest fix, but more\n> complicated cases may require adding or removing overloads.\n>

\n>@@ -179,8 +223,8 @@ complicated cases may require adding or removing overloads.\n>

Has no member named destroy

\n> \n>

\n>-In C++20, some of what had been deprecated member functions and member\n>-typedefs of std::allocator were removed, moving them into\n>+In C++20, many deprecated member functions and member typedefs of\n>+std::allocator were removed, moving them into\n> std::allocator_traits, causing complaints about\n\nThey weren't moved into allocator_traits in C++20, they were there\nsince C++11. Maybe something like:\n\nIn C++20, many deprecated member functions and member typedefs of\nstd::allocator were removed because\nstd::allocator_traits provides defaults for those\nmembers and those should be used instead.\n\n> lack of these names:\n> pointer,\n>@@ -195,23 +239,8 @@ lack of these names:\n>

\n> \n>

\n>-The solution in most cases is to use the corresponding member of\n>-std::allocator_traits as instantiated on the allocator\n>-type, instead. Note that explicitly specializing\n>-std::allocator_traits on a custom allocator type, though\n>-now undefined behavior, is not warned about.\n>-

\n>-\n>-

Missing header includes

\n>-\n>-

\n>-Programs sometimes use names without having properly #included the header\n>-that declares them, relying instead on the name having being declared\n>-accidently via some other header; until it no longer does, resulting in\n>-errors like:\n>-

error: ‘uint64_t’ was not declared in this scope
\n>-

Determine the correct header that declares the name, and #include\n>-it. The compiler may suggest a header to include.\n>+The solution is to use the corresponding member of std::allocator_traits\n>+as instantiated on the allocator type, instead.\n\nI think something like \"using allocator_traits::foo instead of\nA::foo\" would be clearer than \"as instead on the allocator type\".\n\n>

\n> \n>

unary_function is not defined

\n>@@ -242,17 +271,10 @@ All of\n> unary_negate,\n> binary_negate,\n> not1, and not2\n>-have been deprecated and then eliminated from C++20 or earlier Standards,\n>+have been deprecated in earlier Standards and then eliminated from C++20,\n> supplanted by (a much smaller number of) modern alternatives found in\n>-<functional>.\n>-

\n>-\n>-

specified bound 18446744073709551608 exceeds maximum

\n>-\n>-

\n>-GCC has become better at recognizing when a value passed to an allocator could potentially\n>-exceed the maximum permitted, 0x7ff...ff, such as by rounding a passed-in size up to the\n>-usual alignment without capping the result.\n>+<functional>. GCC-16 thus far only deprecates these names,\n>+but does not actually remove them.\n\nstd::unary_function and friends were given the deprecated attribute in\n2022 for GCC 12 so I don't think this needs to be documented here.\n\n>

\n> \n>

Operating Systems

","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","gcc-patches@gcc.gnu.org"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","gcc-patches@gcc.gnu.org"],"Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256\n header.s=mimecast20190719 header.b=EEKGqrP1;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org\n (client-ip=38.145.34.32; helo=vm01.sourceware.org;\n envelope-from=gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org;\n receiver=patchwork.ozlabs.org)","sourceware.org;\n\tdkim=pass (1024-bit key,\n unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256\n header.s=mimecast20190719 header.b=EEKGqrP1","sourceware.org; dmarc=pass (p=quarantine dis=none)\n header.from=redhat.com","sourceware.org; spf=pass smtp.mailfrom=redhat.com","server2.sourceware.org;\n arc=none smtp.remote-ip=170.10.133.124"],"Received":["from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g5Kv45wBwz1yHX\n\tfor ; Thu, 30 Apr 2026 00:49:03 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id B613F4BB3B83\n\tfor ; Wed, 29 Apr 2026 14:49:01 +0000 (GMT)","from us-smtp-delivery-124.mimecast.com\n (us-smtp-delivery-124.mimecast.com [170.10.133.124])\n by sourceware.org (Postfix) with ESMTP id A3D144B99F54\n for ; Wed, 29 Apr 2026 14:48:28 +0000 (GMT)","from mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com\n (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by\n relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,\n cipher=TLS_AES_256_GCM_SHA384) id us-mta-246-bU5-vW7YPaqKm9hH9E_LdQ-1; Wed,\n 29 Apr 2026 10:48:24 -0400","from mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com\n (mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.93])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest\n SHA256)\n (No client certificate requested)\n by mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS\n id B2CE21800DB4; Wed, 29 Apr 2026 14:48:22 +0000 (UTC)","from localhost (unknown [10.44.34.137])\n by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP\n id E6AF81800480; Wed, 29 Apr 2026 14:48:21 +0000 (UTC)"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org B613F4BB3B83","OpenDKIM Filter v2.11.0 sourceware.org A3D144B99F54"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org A3D144B99F54","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org A3D144B99F54","ARC-Seal":"i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1777474108; cv=none;\n b=iixeFjQ6ZznJfzSPcne3YRq6f8MWxUBh9CtwBIntViGLmATGF1dNjTxR1F05b6sicAk7AumomrgKVTPHr1dNte4hHACwOI0zwJ2XPFZZrXdP4k44rHtW2uPeYf63CLmxvHCgFzNX4VruKYTB09zATKWi5jreNR1ID/ehwaUUem8=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=sourceware.org; s=key;\n t=1777474108; c=relaxed/simple;\n bh=e0QMEq44Hjj47A+sCwmCIWrp06X6GraqXaDrY/OIO4g=;\n h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version;\n b=O9oq6z0kjFqwBfEHG3lC41T9nsbuCK6GlZrCxXl23op8yUsAH4TDqlJVnysuhjSjRyZYPGjEULzrmVuu4azajJ6e+1gErOkIcPFqb0sjOFw0GRWmcJ6rTCBavH9/120Bp4Ibau83CE7NxCU6WnVXDl1flxBpwgxjICChO5uHxFQ=","ARC-Authentication-Results":"i=1; server2.sourceware.org","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;\n s=mimecast20190719; t=1777474108;\n h=from:from:reply-to:subject:subject:date:date:message-id:message-id:\n to:to:cc:cc:mime-version:mime-version:content-type:content-type:\n content-transfer-encoding:content-transfer-encoding:\n in-reply-to:in-reply-to:references:references;\n bh=WFy36B2FWUWV6L5SElpd8W7xhm/fiSOtsU5GZDxQGy4=;\n b=EEKGqrP1S5jEZjBcvxc0qGQWbPUS+jGgAaVxfIgQPKSTEr19dQP4CuTPs5BMHeu7ZQM9ej\n +Ki5dDswh4XvgwBCVs461h0vnKTvsjP82Jmw0jf6D+MdLMAuyWUlhgsRuPWhBXkV0JrnGE\n plX4usvjhA0TssQ4q8I/zZcZ2Zy7Z8k=","X-MC-Unique":"bU5-vW7YPaqKm9hH9E_LdQ-1","X-Mimecast-MFC-AGG-ID":"bU5-vW7YPaqKm9hH9E_LdQ_1777474103","Date":"Wed, 29 Apr 2026 15:48:20 +0100","From":"Jonathan Wakely ","To":"Nathan Myers ","Cc":"gcc-patches@gcc.gnu.org, libstdc++@gcc.gnu.org,\n Jakub Jelinek ","Subject":"Re: [PATCH] Changes to gcc-16/porting_to","Message-ID":"","References":"<95c4cf6c-9e9f-47b3-8a93-5e5fefdf9d04@cantrip.org>","MIME-Version":"1.0","In-Reply-To":"<95c4cf6c-9e9f-47b3-8a93-5e5fefdf9d04@cantrip.org>","X-Clacks-Overhead":"GNU Terry Pratchett","X-Scanned-By":"MIMEDefang 3.4.1 on 10.30.177.93","X-Mimecast-Spam-Score":"0","X-Mimecast-MFC-PROC-ID":"TVLaUcVPvrE-yhXO8Q2VGjGB-EX6OCyXH7oHLOSWAkg_1777474103","X-Mimecast-Originator":"redhat.com","Content-Type":"text/plain; charset=utf-8; format=flowed","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","X-BeenThere":"gcc-patches@gcc.gnu.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"Gcc-patches mailing list ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org"}},{"id":3684117,"web_url":"http://patchwork.ozlabs.org/comment/3684117/","msgid":"","list_archive_url":null,"date":"2026-04-29T14:55:49","subject":"Re: [PATCH] Changes to gcc-16/porting_to","submitter":{"id":671,"url":"http://patchwork.ozlabs.org/api/people/671/","name":"Jakub Jelinek","email":"jakub@redhat.com"},"content":"On Wed, Apr 29, 2026 at 03:48:20PM +0100, Jonathan Wakely wrote:\n> > @@ -59,10 +65,10 @@ void foo (void) {\n> > int f = 0; // No warning, f used\n> > int g = f = 5;\n> > (void) g;\n> > - int h = 0; // No warning, preincrement used\n> > + int h = 0; // No warning, preincrement result used\n> > int i = ++h;\n> > (void) i;\n> > - int j = 0; // No warning, postdecrement used\n> > + int j = 0; // No warning, postdecrement result used\n> \n> If I understand correctly, this does match the intended meaning\n> better, but I'd like to hear from Jakub who added this example.\n\nI agree, but this comes straight from gcc/doc/invoke.texi, so\nif it is changed, it should be changed in there as well.\n\n> > int k = j--;\n> > (void) k;\n> > int l = 0; // No warning, l used\n> > @@ -75,20 +81,49 @@ void foo (void) {\n> > In order to avoid the warnings, one can either remove newly diagnosed\n> > variables or parameters which aren't used except in pre/post inc/decrements\n> > or compound assignments, make them used in some way, e.g. just\n> > -casting to (void), or lowering the level of the warning. See\n> > +casting to (void), or lowering the level of the warning.\n> > +But note that an unused variable may indicate a coding error, where\n> > +some other object was mistakenly used in its place, or a larger change\n> > +was begun but left incomplete.\n> \n> Again, I'll leave Jakub to review this.\n\nI think the change is fine.\n\n\tJakub","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","gcc-patches@gcc.gnu.org"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","gcc-patches@gcc.gnu.org"],"Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256\n header.s=mimecast20190719 header.b=INEsZiZJ;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org\n (client-ip=2620:52:6:3111::32; helo=vm01.sourceware.org;\n envelope-from=gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org;\n receiver=patchwork.ozlabs.org)","sourceware.org;\n\tdkim=pass (1024-bit key,\n unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256\n header.s=mimecast20190719 header.b=INEsZiZJ","sourceware.org; dmarc=pass (p=quarantine dis=none)\n header.from=redhat.com","sourceware.org; spf=pass smtp.mailfrom=redhat.com","server2.sourceware.org;\n arc=none smtp.remote-ip=170.10.133.124"],"Received":["from vm01.sourceware.org (vm01.sourceware.org\n [IPv6:2620:52:6:3111::32])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g5L3l1qdlz1yHZ\n\tfor ; Thu, 30 Apr 2026 00:56:33 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id 14BD14BBC0C4\n\tfor ; Wed, 29 Apr 2026 14:56:32 +0000 (GMT)","from us-smtp-delivery-124.mimecast.com\n (us-smtp-delivery-124.mimecast.com [170.10.133.124])\n by sourceware.org (Postfix) with ESMTP id 2487C4BA23D1\n for ; Wed, 29 Apr 2026 14:56:05 +0000 (GMT)","from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com\n (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by\n relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,\n cipher=TLS_AES_256_GCM_SHA384) id us-mta-590-lnwpsEuxO_mc9yd79O-sgQ-1; Wed,\n 29 Apr 2026 10:56:03 -0400","from mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com\n (mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.12])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest\n SHA256)\n (No client certificate requested)\n by mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS\n id 7077D1953941; Wed, 29 Apr 2026 14:55:54 +0000 (UTC)","from tucnak.zalov.cz (unknown [10.44.34.21])\n by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with\n ESMTPS\n id A704C19560B6; Wed, 29 Apr 2026 14:55:53 +0000 (UTC)","from tucnak.zalov.cz (localhost [127.0.0.1])\n by tucnak.zalov.cz (8.18.1/8.18.1) with ESMTPS id 63TEtoSU403752\n (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT);\n Wed, 29 Apr 2026 16:55:50 +0200","(from jakub@localhost)\n by tucnak.zalov.cz (8.18.1/8.18.1/Submit) id 63TEtnXA403751;\n Wed, 29 Apr 2026 16:55:49 +0200"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org 14BD14BBC0C4","OpenDKIM Filter v2.11.0 sourceware.org 2487C4BA23D1"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org 2487C4BA23D1","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org 2487C4BA23D1","ARC-Seal":"i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1777474565; cv=none;\n b=VAm3eaxD1YMwXxyxgAR51R6D0ScGQnaKVr5c40Aypj4RD2nk9kxBUj7WYnB17Oer4JJNoEM3Pfwx5kWIZ7x+gGTO6OisAQnNnXa9oVB6vC02tPw7K637GsgUKvVL06imJs/Zkn6WlNFlvmKukDQN3VGie2E1pOcTedLrpNiy+eA=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=sourceware.org; s=key;\n t=1777474565; c=relaxed/simple;\n bh=+rSeCB+A1vaBvQsvWuotrKyVjXE4gMYcyi5TwRvBLL8=;\n h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version;\n b=x3Xxj2rD3bXej5l4VWNpyjNqrfeUj0ZtX+VvIEkOWz9RXvloKi/o52/XlZ1pf0lLhmSE0MLOFetBG1iyV8U9UMOsn8O8d/2/4/bqA5I76cSAbTHyYRaLa8VVgd+PT2a/UZLzFdMhWAnzJHO0hZDDxtDAT7JaOJwKq6gHUUUcc7A=","ARC-Authentication-Results":"i=1; server2.sourceware.org","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;\n s=mimecast20190719; t=1777474564;\n h=from:from:reply-to:reply-to:subject:subject:date:date:\n message-id:message-id:to:to:cc:cc:mime-version:mime-version:\n content-type:content-type:in-reply-to:in-reply-to: references:references;\n bh=g/5JQ9fjygTLtty7XdzuqsClepcDnbNyZiq9qe4zgHM=;\n b=INEsZiZJK7uZVbtlLvEkN4MppE0a2/R6uvgopFstF569UaBdHDMldfQ8CK3SHjqW4M8kgb\n 9nDi7OrK7x3OIN4VGEW0nBQ2qPMkIbrcyaiHRSSyl7IBHh9O3sCFpS7X2fKUT2YM5+2+4A\n kUhdlGlSKCpgoQ6hzIAT9+Mi0Ly3yjU=","X-MC-Unique":"lnwpsEuxO_mc9yd79O-sgQ-1","X-Mimecast-MFC-AGG-ID":"lnwpsEuxO_mc9yd79O-sgQ_1777474562","Date":"Wed, 29 Apr 2026 16:55:49 +0200","From":"Jakub Jelinek ","To":"Jonathan Wakely ","Cc":"Nathan Myers , gcc-patches@gcc.gnu.org,\n libstdc++@gcc.gnu.org","Subject":"Re: [PATCH] Changes to gcc-16/porting_to","Message-ID":"","References":"<95c4cf6c-9e9f-47b3-8a93-5e5fefdf9d04@cantrip.org>\n ","MIME-Version":"1.0","In-Reply-To":"","X-Scanned-By":"MIMEDefang 3.0 on 10.30.177.12","X-Mimecast-Spam-Score":"0","X-Mimecast-MFC-PROC-ID":"jflhO19uM2TblxPxAXRXb0zMfRe2sNc-zu0ncJJN1-o_1777474562","X-Mimecast-Originator":"redhat.com","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","X-BeenThere":"gcc-patches@gcc.gnu.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"Gcc-patches mailing list ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Reply-To":"Jakub Jelinek ","Errors-To":"gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org"}}]