[{"id":3684926,"web_url":"http://patchwork.ozlabs.org/comment/3684926/","msgid":"","list_archive_url":null,"date":"2026-04-30T20:08:29","subject":"Re: [PATCH v2] 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 Thu, 30 Apr 2026 at 11:43 -0400, Nathan Myers wrote:\n>gcc-wwwdocs/Changelog:\n>\n>\t* htdocs/gcc-16/porting_to.html: Numerous edits.\n>\n>---\n> Changes in v2:\n>\n> - Remove s/provide/suggest/ change from template boilerplate text.\n> - Use \"Common\" only to indicate \"both C and C++\".\n> - Remove introductory paragraphs about origin in package builds.\n> - Call it \"GCC 16\" throughout, with NBSP where it might make\n> a difference.\n> - Reproduce compiler message texts using ASCII quote marks.\n> - Move case of transient includes from Common to C++ section.\n> - Remove quote marks from annotations.\n> - Remove case of function-object names not in C++20 but still\n> supported in GCC 16.\n> - Remove case about more \"uninitialized variable\" warnings.\n> - Rewrite the case for spurious \"-std=gnu++11\" build option\n> generated by pre-2.73 autoconf.\n> - Add missing tags.\n> - Put \"operator!=\" case first in the C++ list.\n> - Rewrite suggestion for fix for use of removed allocator members.\n>\n> Changes in v1:\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..69de6da8 100644\n>--- a/htdocs/gcc-16/porting_to.html\n>+++ b/htdocs/gcc-16/porting_to.html\n>@@ -20,13 +20,13 @@ facilitate compilation or run-time performance.\n> \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>+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>

\n> \n>

Common C and C++ language issues

\n> \n>-

Changes to -Wunused-but-set-* warnings

\n>+

Changes to -Wunused-but-set-* warnings

\n> \n> \n> \n>@@ -59,10 +59,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> int k = j--;\n> (void) k;\n> int l = 0; // No warning, l used\n>@@ -75,7 +75,11 @@ 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>+See\n> \n> -Wunused-but-set-* documentation for more details.\n>

\n>@@ -83,7 +87,7 @@ casting to (void), or lowering the level of the warning. See\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>@@ -99,53 +103,25 @@ 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>+warnings.\n>

\n> \n>-

Common build failures

\n>-

\n>-Failures encountered when using Gcc-16 to rebuild numerous open-source\n>-packages included the following:\n>-

\n>-\n>-

Library 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>+

C++ build failures

\n\nThe '+' character has special meaning in URLs so should not be used in\nan HTML anchor. Please use cpp-failures instead, so that it doesn't\nget URL-escaped as c%2b%2b.\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>-

\n>-\n>-

Uninitialized-variable warnings

\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>-

\n>-\n>-

Changes to character literals

\n>+

Ambiguous overload for operator!=

\n> \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>-

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>+In C++20, a type that defines operator== gets an\n>+operator!= provided implicitly by the compiler. This can\n>+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>+

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

\n> \n>

No match for operator>>

\n>@@ -155,51 +131,57 @@ 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>

\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> std::string, which grows as needed.\n>

\n> \n>-

Ambiguous overload for operator!=

\n>+

Program uses features from a newer Standard

\n> \n>

\n>-In C++20, a type that defines operator== gets an\n>-operator!= provided implicitly by the compiler. This can\n>-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>-

Fixing argument-type signatures is often the simplest fix, but more\n>-complicated cases may require adding or removing overloads.\n>+Many failures are caused by a spurious build option -std=gnu++11:\n>+

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

\n>+This is usually a consequence of a bug in Autoconf prior to release 2.73\n>+that adds this option to Makefiles when, acting on a directive\n>+AC_PROG_CXX, it tries but fails to verify that GCC 16's\n>+compiler supports C++11 language features by default. To work around that,\n>+remove the AC_PROG_CXX directive from the program's\n>+configure.ac file and regenerate the makefiles.\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 solutions are to change the name of the identifier,\n>+or build to an older standard with (e.g.) -std=c++17.\n>

\n> \n>-

Has no member named destroy

\n>+

Implicit lambda capture of 'this'

\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>-std::allocator_traits, causing complaints about\n>-lack of these names:\n>-pointer,\n>-const_pointer,\n>-reference,\n>-const_reference,\n>-construct,\n>-destroy,\n>-rebind,\n>-is_always_equal, and\n>-max_size.\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>+\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>+In C++20, u8\"str\" and u8'c' literals changed\n>+from type char to type char8_t, leading to\n>+errors like:\n>+

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

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

\n> \n>

Missing header includes

\n>@@ -207,52 +189,34 @@ now undefined behavior, is not warned about.\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>+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>-

Determine the correct header that declares the name, and #include\n>-it. The compiler may suggest a header to include.\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> \n>-

unary_function is not defined

\n>+

Has no member named destroy

\n> \n>

\n>-Standard library function objects have evolved, and have left early experiments behind.\n>-All of\n>-unary_function,\n>-binary_function,\n>-pointer_to_unary_function,\n>-pointer_to_binary_function,\n>-ptr_fun,\n>-binder1st,\n>-binder2nd,\n>-bind1st,\n>-bind2nd,\n>-binary_function,\n>-mem_fun,\n>-mem_fun_t,\n>-mem_fun1_t,\n>-const_mem_fun_ref_t,\n>-const_mem_fun1_ref_t,\n>-mem_fun_ref,\n>-mem_fun_ref_t,\n>-mem_fun1_ref_t,\n>-const_mem_fun_ref_t,\n>-const_mem_fun1_ref_t,\n>-unary_negate,\n>-binary_negate,\n>-not1, and not2\n>-have been deprecated and then eliminated from C++20 or earlier Standards,\n>-supplanted by (a much smaller number of) modern alternatives found in\n>-<functional>.\n>+In C++20, many deprecated member functions and member typedefs of\n>+std::allocator were removed because\n>+std::allocator_traits has since C++11 provided better\n>+defaults for those members that should be used instead. This applies\n>+to former members\n>+pointer,\n>+const_pointer,\n>+reference,\n>+const_reference,\n>+construct,\n>+destroy,\n>+rebind,\n>+is_always_equal, and\n>+max_size.\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>+The solution is to use (e.g.) std::allocator_traits::destroy\n\nThis needs to be <A> instead of \n\nOK for wwwdocs with those two changes.\n\n>+in place of A::destroy.\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=Jt3dt4vk;\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=Jt3dt4vk","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 4g64y61sbXz1yHZ\n\tfor ; Fri, 01 May 2026 06:09:16 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id 22D9C4099F87\n\tfor ; Thu, 30 Apr 2026 20:09:14 +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 1C97D4310D5B\n for ; Thu, 30 Apr 2026 20:08:37 +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-624-3iZyisEWPXSx-VmGqVI31g-1; Thu,\n 30 Apr 2026 16:08:32 -0400","from mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com\n (mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.17])\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 B73D618004A9; Thu, 30 Apr 2026 20:08:31 +0000 (UTC)","from localhost (unknown [10.44.50.237])\n by mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP\n id E32C11955D84; Thu, 30 Apr 2026 20:08:30 +0000 (UTC)"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org 22D9C4099F87","OpenDKIM Filter v2.11.0 sourceware.org 1C97D4310D5B"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org 1C97D4310D5B","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org 1C97D4310D5B","ARC-Seal":"i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1777579717; cv=none;\n b=NzLdpjwqVkGiT5R6sZr/1reriFD0tFJp6iQ3hEF37J5R+BSUZVSV2CsjHMG7hIxgYbs7nM03Ch7pMdMIDy6pNz+55cFhvS9wND/jDoSw8d3gNTlSYzakxViJfoR5NNFteCceH80UjF5Kzh93rxb5ruob83kb5LTTsFwhzhjnpmc=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=sourceware.org; s=key;\n t=1777579717; c=relaxed/simple;\n bh=L9SGYoBhhivphUlM/8T1GNBFqvBgdMGqDLmFA/F+X3I=;\n h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version;\n b=QNoN6y86DGwmXtw3pBueE3m7ZXF0v2IQy7AxcE44PrfdAlfSsU2U7GUZk9O3tGd22mvcKpHOF7RSFia7B/RJ012KsG5Fpw7S78+Q+ZlzHC1j+RfcOm1AjF6S2lBzKT8lSHqmD+uP3Hkoh5+gfJdKSAb+JEk9XIR7/4ZSmmJKF04=","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=1777579716;\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=9PE9tNa3EzYPjY6bLlJDqXNv72Qtfu4C3N5q8TH5+vs=;\n b=Jt3dt4vkMsUQaXXp2njgsm3atu1ygTnMa8ihxLqvTvZDIw+zU2yy7LJfDupcZ8Gr3qu1pm\n gqVNdKeYd9xq2izXHdjhc03dIhSI0uSIXZZMpaud1OuARedHx2Xc44aKL7wziTnl8IDNFI\n l/pz5Z7Mw2ZbpA2ngCoW922tv9d36qE=","X-MC-Unique":"3iZyisEWPXSx-VmGqVI31g-1","X-Mimecast-MFC-AGG-ID":"3iZyisEWPXSx-VmGqVI31g_1777579712","Date":"Thu, 30 Apr 2026 21:08:29 +0100","From":"Jonathan Wakely ","To":"Nathan Myers ","Cc":"gcc-patches ,\n\tlibstdc++ ","Subject":"Re: [PATCH v2] 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-Clacks-Overhead":"GNU Terry Pratchett","X-Scanned-By":"MIMEDefang 3.0 on 10.30.177.17","X-Mimecast-Spam-Score":"0","X-Mimecast-MFC-PROC-ID":"Kr-EQhi4gDnbVSoV98oSiCSNdR1CiQyY1t5HPOCLtJk_1777579712","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"}}]