{"id":2229926,"url":"http://patchwork.ozlabs.org/api/1.1/patches/2229926/?format=json","web_url":"http://patchwork.ozlabs.org/project/gcc/patch/95c4cf6c-9e9f-47b3-8a93-5e5fefdf9d04@cantrip.org/","project":{"id":17,"url":"http://patchwork.ozlabs.org/api/1.1/projects/17/?format=json","name":"GNU Compiler Collection","link_name":"gcc","list_id":"gcc-patches.gcc.gnu.org","list_email":"gcc-patches@gcc.gnu.org","web_url":null,"scm_url":null,"webscm_url":null},"msgid":"<95c4cf6c-9e9f-47b3-8a93-5e5fefdf9d04@cantrip.org>","date":"2026-04-28T22:19:09","name":"Changes to gcc-16/porting_to","commit_ref":null,"pull_url":null,"state":"new","archived":false,"hash":"e0605796f4e5809e088ab93d1e22eef042c32ee4","submitter":{"id":90892,"url":"http://patchwork.ozlabs.org/api/1.1/people/90892/?format=json","name":"Nathan Myers","email":"ncm@cantrip.org"},"delegate":null,"mbox":"http://patchwork.ozlabs.org/project/gcc/patch/95c4cf6c-9e9f-47b3-8a93-5e5fefdf9d04@cantrip.org/mbox/","series":[{"id":501941,"url":"http://patchwork.ozlabs.org/api/1.1/series/501941/?format=json","web_url":"http://patchwork.ozlabs.org/project/gcc/list/?series=501941","date":"2026-04-28T22:19:09","name":"Changes to gcc-16/porting_to","version":1,"mbox":"http://patchwork.ozlabs.org/series/501941/mbox/"}],"comments":"http://patchwork.ozlabs.org/api/patches/2229926/comments/","check":"pending","checks":"http://patchwork.ozlabs.org/api/patches/2229926/checks/","tags":{},"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 (2048-bit key;\n unprotected) header.d=cantrip.org header.i=@cantrip.org header.a=rsa-sha256\n header.s=dreamhost header.b=h9FBBZKA;\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 (2048-bit key,\n unprotected) header.d=cantrip.org header.i=@cantrip.org header.a=rsa-sha256\n header.s=dreamhost header.b=h9FBBZKA","sourceware.org;\n dmarc=none (p=none dis=none) header.from=cantrip.org","sourceware.org; spf=pass smtp.mailfrom=cantrip.org","server2.sourceware.org;\n arc=pass smtp.remote-ip=23.83.209.51"],"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 4g4vyC0k4jz1xvV\n\tfor ; Wed, 29 Apr 2026 08:19:57 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id 820DC4BBC0DC\n\tfor ; Tue, 28 Apr 2026 22:19:55 +0000 (GMT)","from dragonfly.birch.relay.mailchannels.net\n (dragonfly.birch.relay.mailchannels.net [23.83.209.51])\n by sourceware.org (Postfix) with ESMTPS id 05FB84BB8F48;\n Tue, 28 Apr 2026 22:19:14 +0000 (GMT)","from relay.mailchannels.net (localhost [127.0.0.1])\n by relay.mailchannels.net (Postfix) with ESMTP id 7B0437A1FD5;\n Tue, 28 Apr 2026 22:19:13 +0000 (UTC)","from pdx1-sub0-mail-a240.dreamhost.com\n (100-97-140-132.trex-nlb.outbound.svc.cluster.local [100.97.140.132])\n (Authenticated sender: dreamhost)\n by relay.mailchannels.net (Postfix) with ESMTPA id 4C7DB7A1E8E;\n Tue, 28 Apr 2026 22:19:12 +0000 (UTC)","from pdx1-sub0-mail-a240.dreamhost.com (pop.dreamhost.com\n [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384)\n by 100.97.140.132 (trex/7.1.5); Tue, 28 Apr 2026 22:19:13 +0000","from [10.137.0.15] (unknown [65.192.71.68])\n (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)\n key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest\n SHA256)\n (No client certificate requested)\n (Authenticated sender: ncm@cantrip.org)\n by pdx1-sub0-mail-a240.dreamhost.com (Postfix) with ESMTPSA id\n 4g4vwv5pYtzyr9;\n Tue, 28 Apr 2026 15:19:11 -0700 (PDT)"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org 820DC4BBC0DC","OpenDKIM Filter v2.11.0 sourceware.org 05FB84BB8F48"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org 05FB84BB8F48","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org 05FB84BB8F48","ARC-Seal":["i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1777414755; cv=pass;\n b=ndHBpMIPjosS98ngMs98DAul3Fl6WgznY4bcZEu8qj9sBrM7xwHG0dOdh7xQKkrWZLkfqgO0c6aziwUPAqryutx//msTaiNIXtXeD2M57E2fNMzSoR0AfDVa6pGKHze7AfSkHPuOiIZlvfcBEVgZzKS8CKR5UQkdb7x2bLf+SSI=","i=1; a=rsa-sha256; d=mailchannels.net; s=arc-2022; cv=none;\n t=1777414752;\n b=KyJwxQM1lr5WAD1rMJr4/WvJTQn9Ni6qAgcfE0mneDz6YqVvwxJdtUfVt0FSXUJub5sONR\n q9vhHGlTUHRNKTLxxqdX2xj9XAk3fFiYfzxckP+Mg01+/ZuwqKmmSr8tWogen1jUxv29ja\n mNnQezy8utXZLiATXp4ggpNCpes0PeUJNuV2wnjo/SmV3ZDz7bt00GI3ZSrKYPzw64DM9i\n zIxgCjPI9A4il1Egfj4U1QFTuHSLZkk3jNUxdMhaDn2/PgPfR0EX7MHOc5VdyPQyio2LVU\n B6O7vX/EsJ9qKyyRSOsoeGhZ20QTfQEOdpNrB++gJccnSlc1yuhPvu7dCV9MUA=="],"ARC-Message-Signature":["i=2; a=rsa-sha256; d=sourceware.org; s=key;\n t=1777414755; c=relaxed/simple;\n bh=v0feG7L8Xwq7SfbkdMxBk9LnbvKWr93h+GObS9Vcqig=;\n h=DKIM-Signature:Message-ID:Date:MIME-Version:To:From:Subject;\n b=fIgc7kFHigaLcuCy0alfiaLVr5TBMpDMHISHz93bTIJDdrhhzmxkKT/oOCJwni+l2IWiqS3phLjJn4DEqIEGIU3MnTJHX5XWQB7Zvb1CW3+8svBDG2XQLakHS3pkpH8w4OMsuyOfoz7LJw3uJQfPw/Ho1iaOcfBCm/plAxriPj0=","i=1; a=rsa-sha256; c=relaxed/relaxed;\n d=mailchannels.net; s=arc-2022; t=1777414752;\n h=from:from:reply-to:subject:subject:date:date:message-id:message-id:\n to:to:cc:mime-version:mime-version:content-type:content-type:\n dkim-signature; bh=/cHl5nMH9f3xNeKuOmg0V/qJ1zSlkW61Mtft+kRq6iE=;\n b=Ubob3fcvT6bF7qeoKlyQbMSFkO+/O/mcPhTwwyz9KQzUzNkFshUCv9vJQmxBsjFKbGPZB1\n nf3UV0FRhFsuOFtCNg1VQOfKHueAcaKIPw67Fq658fQo2yvAX+M2iTdR8STnRPZK3iyBqD\n uXM9b1Cauf6DDmqyHbGsqMBPgrpznElwCTP2wOc9hTbNsiX3hUy3cO661+trd82QNytNiE\n JLpslGICsHly9f27ax3mki8jwaKVmru/WxOv1RLK1T4xdssb70YHEFxTGkh/SG5ywC2fqz\n 2r1mtiarf+VAG2rTcNd/+roF2E0ph7o4Gw63fhzT+CI+RoOSG5qSlzd1P+nHmA=="],"ARC-Authentication-Results":["i=2; server2.sourceware.org","i=1; rspamd-55bb47d7db-b8ldg;\n auth=pass smtp.auth=dreamhost smtp.mailfrom=ncm@cantrip.org"],"X-Sender-Id":["dreamhost|x-authsender|ncm@cantrip.org","dreamhost|x-authsender|ncm@cantrip.org"],"X-MC-Relay":"Neutral","X-MailChannels-SenderId":"dreamhost|x-authsender|ncm@cantrip.org","X-MailChannels-Auth-Id":"dreamhost","X-Drop-Scare":"251f279a7d735610_1777414753378_1758034172","X-MC-Loop-Signature":"1777414753378:1561039274","X-MC-Ingress-Time":"1777414753377","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=cantrip.org;\n s=dreamhost; t=1777414752;\n bh=/cHl5nMH9f3xNeKuOmg0V/qJ1zSlkW61Mtft+kRq6iE=;\n h=Content-Type:Date:To:From:Subject;\n b=h9FBBZKAUL7ZBAWD8xgAlQ18iw5ypYsVRP4OwM9EQ5AmXIC7uFZunA1qClF7nQuab\n HO35tut7FarFNCGXENzrR/KCgHvpHTXdveBw/IERaF98+S955RbF+i2KD/p+rwurtz\n fs8o+kMYSfVmp3uPzkoIbqimNW+gUAo+m7wh5WiTuolx8gG30ifIGoCzPX9nPjtSRy\n LhYVmjAnGE2EBZlIwQBHWoX2ydPp/FMMNHmINNbUVWG4R/fTKlD09FMd8n5tncyA+8\n zUkcyL507Lr3AuR9V3KL9JLxuSHSNn8SICVzkBFKGwlt2SHqjkbuoxOtzw9+Z9mIKG\n h+WWeos52ba9A==","Content-Type":"multipart/mixed; boundary=\"------------0VH8ZEerPfJjBxEUB0X0uW02\"","Message-ID":"<95c4cf6c-9e9f-47b3-8a93-5e5fefdf9d04@cantrip.org>","Date":"Tue, 28 Apr 2026 18:19:09 -0400","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","To":"gcc-patches@gcc.gnu.org, libstdc++@gcc.gnu.org","Content-Language":"en-US","From":"Nathan Myers ","Subject":"[PATCH] Changes to gcc-16/porting_to","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"},"content":"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.)","diff":"diff --git a/htdocs/gcc-16/porting_to.html b/htdocs/gcc-16/porting_to.html\nindex 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

\n \n-

Common C and C++ language issues

\n+

C and C++ language issues

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

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

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

C++ language issues

\n \n

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

\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+warnings.\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

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

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-

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

\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

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

\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

\n \n

Operating Systems

\n","prefixes":[]}