Patch Detail
get:
Show a patch.
patch:
Update a patch.
put:
Update a patch.
GET /api/patches/2231321/?format=api
{ "id": 2231321, "url": "http://patchwork.ozlabs.org/api/patches/2231321/?format=api", "web_url": "http://patchwork.ozlabs.org/project/gcc/patch/acbb8dfa-f0f8-4bb6-bfba-91136517594a@cantrip.org/", "project": { "id": 17, "url": "http://patchwork.ozlabs.org/api/projects/17/?format=api", "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, "list_archive_url": "", "list_archive_url_format": "", "commit_url_format": "" }, "msgid": "<acbb8dfa-f0f8-4bb6-bfba-91136517594a@cantrip.org>", "list_archive_url": null, "date": "2026-04-30T15:43:04", "name": "[v2] Changes to gcc-16/porting_to", "commit_ref": null, "pull_url": null, "state": "new", "archived": false, "hash": "fb32dcd4d4bc4f2c6340f3f61df2dcb39ea0d742", "submitter": { "id": 90892, "url": "http://patchwork.ozlabs.org/api/people/90892/?format=api", "name": "Nathan Myers", "email": "ncm@cantrip.org" }, "delegate": null, "mbox": "http://patchwork.ozlabs.org/project/gcc/patch/acbb8dfa-f0f8-4bb6-bfba-91136517594a@cantrip.org/mbox/", "series": [ { "id": 502330, "url": "http://patchwork.ozlabs.org/api/series/502330/?format=api", "web_url": "http://patchwork.ozlabs.org/project/gcc/list/?series=502330", "date": "2026-04-30T15:43:04", "name": "[v2] Changes to gcc-16/porting_to", "version": 2, "mbox": "http://patchwork.ozlabs.org/series/502330/mbox/" } ], "comments": "http://patchwork.ozlabs.org/api/patches/2231321/comments/", "check": "pending", "checks": "http://patchwork.ozlabs.org/api/patches/2231321/checks/", "tags": {}, "related": [], "headers": { "Return-Path": "<gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org>", "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=UWCRDl/s;\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 (2048-bit key,\n unprotected) header.d=cantrip.org header.i=@cantrip.org header.a=rsa-sha256\n header.s=dreamhost header.b=UWCRDl/s", "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.82" ], "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 4g5z4D2Bwwz1yHZ\n\tfor <incoming@patchwork.ozlabs.org>; Fri, 01 May 2026 01:44:12 +1000 (AEST)", "from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id 5E2BC436A051\n\tfor <incoming@patchwork.ozlabs.org>; Thu, 30 Apr 2026 15:43:55 +0000 (GMT)", "from heron.birch.relay.mailchannels.net\n (heron.birch.relay.mailchannels.net [23.83.209.82])\n by sourceware.org (Postfix) with ESMTPS id E0280436F7D4;\n Thu, 30 Apr 2026 15:43:07 +0000 (GMT)", "from relay.mailchannels.net (localhost [127.0.0.1])\n by relay.mailchannels.net (Postfix) with ESMTP id D7C074C5150;\n Thu, 30 Apr 2026 15:43:06 +0000 (UTC)", "from pdx1-sub0-mail-a251.dreamhost.com\n (100-100-197-62.trex-nlb.outbound.svc.cluster.local [100.100.197.62])\n (Authenticated sender: dreamhost)\n by relay.mailchannels.net (Postfix) with ESMTPA id 7934E4C49BB;\n Thu, 30 Apr 2026 15:43:06 +0000 (UTC)", "from pdx1-sub0-mail-a251.dreamhost.com (pop.dreamhost.com\n [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384)\n by 100.100.197.62 (trex/7.1.5); Thu, 30 Apr 2026 15:43:06 +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-a251.dreamhost.com (Postfix) with ESMTPSA id\n 4g5z2x6RyZz1040;\n Thu, 30 Apr 2026 08:43:05 -0700 (PDT)" ], "DKIM-Filter": [ "OpenDKIM Filter v2.11.0 sourceware.org 5E2BC436A051", "OpenDKIM Filter v2.11.0 sourceware.org E0280436F7D4" ], "DMARC-Filter": "OpenDMARC Filter v1.4.2 sourceware.org E0280436F7D4", "ARC-Filter": "OpenARC Filter v1.0.0 sourceware.org E0280436F7D4", "ARC-Seal": [ "i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1777563788; cv=pass;\n b=E3cYXfM4yYzk4FEpdiMaVrYhKM6iFhmWHYCuI2BtbwbnRvQQLlOQv+Zdze2gglLC5OQ3Ft165cMoJHlE6I1nlW96gPkuJn3EfFlWhA6HENpRK8nYRGnYde53jAI6gJfI+BlsZRp28HgI/9cbvuNsPiyFFZfef92Ffz7KmsfYIDk=", "i=1; a=rsa-sha256; d=mailchannels.net; s=arc-2022; cv=none;\n t=1777563786;\n b=K6trrb6Si9BK5twBmjfgIR5Mb0KeB/jvDV9MPNgplGtLyzuUoIz4NFG+MsAlfJzD+Y729U\n HyKFgKJ2ISrQDXIAmUL4dJv1bQu8K9cenbpC6O9/Ck6EqfRVNUhkKpj23XaTImo4JDXL+N\n cH8CXTHvIkRfvVoVIzWDzYWtal6Dk4otRzIfKPHKIqrICD+1PCeanb7Pl+QSRvUt+PoQ8F\n EOead3qTDdc0UkDEvGCE7cLvP5WkRagMcEqWiJfVh1pX+JBXY0yPERfdfncjDiLDrYTgkd\n kzhBAs6k2tm0s+7hHI+ywmVM3FmwFMZby7q4jRqGFRY/hTpKyv0mav3SgBHl7g==" ], "ARC-Message-Signature": [ "i=2; a=rsa-sha256; d=sourceware.org; s=key;\n t=1777563788; c=relaxed/simple;\n bh=In07Ljlofe8fuDPrhhQ4hk1i6qgX4W9mqQka+e/9I0I=;\n h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From;\n b=R1MAQzv3y5sigLQJ8JznEAbZakMqkxOb3OZGWYmyPtfxEccj8dY/xh/A6hdtGL/L7XeDya5SBcc9Qrc4RwJ+9AdacwRHQhXyXAic5rIj9oq+GvQnS1HqdXAeOzt8fxnloI80j15Al1o+kwhp9E7tvZ2SDA96F7O25aOzM3f1qdE=", "i=1; a=rsa-sha256; c=relaxed/relaxed;\n d=mailchannels.net; s=arc-2022; t=1777563786;\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 in-reply-to:in-reply-to:references:references:dkim-signature;\n bh=zJxPBWjdh0VQ5UDN2N2B7MpG55JJg5ONK+rWX2bXYV8=;\n b=0cxpLOOyW9mXrOECyuUcHtzgzsox+/J72QZ2QtmoWtZXba/Dfq9Ft86sAyzScJY2rhd7kM\n iYh1So/i/JICtNsDzy7oLtQ2v5n4UjDwWR7wg6WXoVDlz0VLY4/I+sPXcCOBZBL0pzWNNi\n 8foWnjYD9xPVwxnj9vkcoXgTrZ248VtXlAVmnE5x61/Ocef/utAwCTb3930O4QTEcWX/Cb\n lJUHma6N57/vq/hIgzqxBiI/weALguoAJdeuEV/MjK9QExjYernLctVTJol3sTuJLmemaE\n eoOy7yqY94b+AOXWHVv7nbbCwPGZuzxwRtAKeTCU7YaO8sNeH6FBvt8dA6CV4g==" ], "ARC-Authentication-Results": [ "i=2; server2.sourceware.org", "i=1; rspamd-798d95666b-wdtgg;\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-Quick-Well-Made": "38e757096718f4ce_1777563786753_3947727576", "X-MC-Loop-Signature": "1777563786753:2368675650", "X-MC-Ingress-Time": "1777563786753", "DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed; d=cantrip.org;\n s=dreamhost; t=1777563786;\n bh=zJxPBWjdh0VQ5UDN2N2B7MpG55JJg5ONK+rWX2bXYV8=;\n h=Content-Type:Date:Subject:To:From;\n b=UWCRDl/sSFaDy26/AKxpJhU7LLR2iqXW0ftoESPpbTqbfzddFRuuJacB+wSMTy3yx\n 8RUgQA/IuSomnc4PSH/bb3fKChWgfXflCECzVzL/HhOeT1IB2Uppw44a+G0Lj/aUU+\n et9uWHUbNa7amIDWtt/lqwAHgQM5m4kTpMvFJ/BnR+XE5yoxhLiYpKiMS3veUkDszA\n Mtm7r4U1kz03AyyMJ1MI0pGFum8wIGH8LVgoVqEVV79qVqLnosC2vamk242tka7MAc\n 3PA8dZO2keP4ayN2wYFUKmpe1v8bHyvEM3DrhPwTkhCX1nzzfEvuTklGtbFUQNqBZZ\n MlF4fZSJZvlDA==", "Content-Type": "multipart/mixed; boundary=\"------------GsKwpbLv0xjS87qsY4P90O7l\"", "Message-ID": "<acbb8dfa-f0f8-4bb6-bfba-91136517594a@cantrip.org>", "Date": "Thu, 30 Apr 2026 11:43:04 -0400", "MIME-Version": "1.0", "User-Agent": "Mozilla Thunderbird", "Subject": "[PATCH v2] Changes to gcc-16/porting_to", "Content-Language": "en-US", "References": "<95c4cf6c-9e9f-47b3-8a93-5e5fefdf9d04@cantrip.org>", "To": "gcc-patches <gcc-patches@gcc.gnu.org>, libstdc++ <libstdc++@gcc.gnu.org>", "From": "Nathan Myers <ncm@cantrip.org>", "In-Reply-To": "<95c4cf6c-9e9f-47b3-8a93-5e5fefdf9d04@cantrip.org>", "X-Forwarded-Message-Id": "<95c4cf6c-9e9f-47b3-8a93-5e5fefdf9d04@cantrip.org>", "X-BeenThere": "gcc-patches@gcc.gnu.org", "X-Mailman-Version": "2.1.30", "Precedence": "list", "List-Id": "Gcc-patches mailing list <gcc-patches.gcc.gnu.org>", "List-Unsubscribe": "<https://gcc.gnu.org/mailman/options/gcc-patches>,\n <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe>", "List-Archive": "<https://gcc.gnu.org/pipermail/gcc-patches/>", "List-Post": "<mailto:gcc-patches@gcc.gnu.org>", "List-Help": "<mailto:gcc-patches-request@gcc.gnu.org?subject=help>", "List-Subscribe": "<https://gcc.gnu.org/mailman/listinfo/gcc-patches>,\n <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe>", "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 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 <code> 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 <code> 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 <h4>, 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<http://cantrip.org/porting_to.html>.)", "diff": "diff --git a/htdocs/gcc-16/porting_to.html b/htdocs/gcc-16/porting_to.html\nindex 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 <p>\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 </p>\n \n <h2 id=\"c-cpp\">Common C and C++ language issues</h2>\n \n-<h3 id=\"changes-to-wunused\">Changes to -Wunused-but-set-* warnings</h3>\n+<h4 id=\"changes-to-wunused\">Changes to -Wunused-but-set-* warnings</h4>\n \n <!-- introduced in 0eac9cfee8cb0b21de866a04d5d59685ab35208f -->\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 <code>(void)</code>, or lowering the level of the warning. See\n+casting to <code>(void)</code>, 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 <a href=\"https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wunused-but-set-variable_003d\">\n <code>-Wunused-but-set-*</code></a> documentation for more details.\n </p>\n@@ -83,7 +87,7 @@ casting to <code>(void)</code>, or lowering the level of the warning. See\n <h2 id=\"cpp\">C++ language issues</h2>\n \n <p>\n-Note that all GCC releases make <a href=\"https://gcc.gnu.org/bugs/#upgrading\"\n+All GCC releases make <a href=\"https://gcc.gnu.org/bugs/#upgrading\"\n >improvements to conformance</a> 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 <a href=\"https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2131r0.html\"\n >Changes between C++17 and C++20 DIS [\"Draft International Standard\"]</a>.\n+Note that names removed from C++20 may still appear in headers when\n+building under <code>-std=c++20</code>, and only provoke 'deprecated'\n+warnings.\n </p>\n \n-<h3 id=\"c++-common-failures\">Common build failures</h3>\n-<p>\n-Failures encountered when using Gcc-16 to rebuild numerous open-source\n-packages included the following:\n-</p>\n-\n-<h4 id=\"wrong-standard\">Library uses features from a newer Standard</h4>\n-\n-<p>\n-Many failures are caused by using a build option like '<code>-std=c++11</code>\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-</p><code>error: 'make_unique' is not a member of 'std'</code>\n-</p>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.</p>\n+<h3 id=\"c++-failures\">C++ build failures</h3>\n \n-<h4 id=\"expected-identifier-before\">Expected identifier before</h4>\n-\n-<p>\n-C++20 defines new keywords such as '<code>concept</code>' and '<code>requires</code>',\n-which can no longer be used as identifiers:\n-</p><p><code> error: expected identifier before ‘concept’\n-</code></p><p>The only solution is to change the name of the identifier.\n-</p>\n-\n-<h4 id=\"uninitialized-variable\">Uninitialized-variable warnings</h4>\n-\n-<p>\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-</p><p><code> error: ‘buffer’ may be used uninitialized [-Werror=maybe-uninitialized]\n-</code></p><p>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-</p>\n-\n-<h4 id=\"changes-to-str-literals\">Changes to character literals</h4>\n+<h4 id=\"ambiguous-overload-for-op-not-equal\">Ambiguous overload for <code>operator!=</code></h4>\n \n <p>\n-In C++20, <code>u8\"str\"</code> and <code>u8'c'</code> literals changed\n-from type char to type char8_t, leading to errors like:\n-</p><p><code> error: invalid conversion from 'const char8_t*' to 'const char*' [-fpermissive]\n-</code></p><p> The fix is most commonly a cast from the u8 literal to plain <code>char</code>\n-or <code>char const*</code>.\n+In C++20, a type that defines <code>operator==</code> gets an\n+<code>operator!=</code> provided implicitly by the compiler. This can\n+cause ambiguities if the type also defines its own <code>operator!=</code>\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+</p><p><code> error: ambiguous overload for 'operator!=' (operand types are 'daeStringRef' and 'long int')\n+</code></p><p>Fixing argument-type signatures is often the simplest fix, but more\n+complicated cases may require adding or removing overloads.\n </p>\n \n <h4 id=\"no-match-op-right-shift\">No match for <code>operator>></code></h4>\n@@ -155,51 +131,57 @@ In C++20, the <code>operator>></code> overload for reading from an\n <code>istream</code> into a <code>char*</code> 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-</p><p><code> error: no match for ‘operator>>’ (operand types are ‘std::istream’ {aka ‘std::basic_istream<char>’} and ‘char*’)\n+</p><p><code> error: no match for 'operator>>' (operand types are 'std::istream' {aka 'std::basic_istream<char>'} and 'char*')\n </code></p><p>\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 <code>std::string</code>, which grows as needed.\n </p>\n \n-<h4 id=\"ambiguous-overload-for-op-not-equal\">Ambiguous overload for <code>operator!=</code></h4>\n+<h4 id=\"wrong-standard\">Program uses features from a newer Standard</h4>\n \n <p>\n-In C++20, a type that defines <code>operator==</code> gets an\n-<code>operator!=</code> provided implicitly by the compiler. This can\n-cause ambiguities if the type also defines its own <code>operator!=</code>\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-</p><p><code> error: ambiguous overload for ‘operator!=’ (operand types are ‘daeStringRef’ and ‘long int’)\n-</code></p><p>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 <code>-std=gnu++11</code>:\n+</p><p><code> error: 'make_unique' is not a member of 'std'</code>\n+</p><p>\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+<code>AC_PROG_CXX</code>, 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 <code>AC_PROG_CXX</code> directive from the program's\n+<code>configure.ac</code> file and regenerate the makefiles.\n+\n+<h4 id=\"expected-identifier-before\">Expected identifier before</h4>\n+\n+<p>\n+C++20 defines new keywords such as <code>concept</code> and <code>requires</code>,\n+which can no longer be used as identifiers:\n+</p><p><code> error: expected identifier before 'concept'\n+</code></p><p>The only solutions are to change the name of the identifier,\n+or build to an older standard with (e.g.) <code>-std=c++17</code>.\n </p>\n \n-<h4 id=\"no-member-destroy\">Has no member named <code>destroy</code></h4>\n+<h4 id=\"capture-this\">Implicit lambda capture of '<code>this</code>'</h4>\n \n <p>\n-In C++20, some of what had been deprecated member functions and member\n-typedefs of <code>std::allocator</code> were removed, moving them into\n-<code>std::allocator_traits</code>, causing complaints about\n-lack of these names:\n-<code>pointer</code>,\n-<code>const_pointer</code>,\n-<code>reference</code>,\n-<code>const_reference</code>,\n-<code>construct</code>,\n-<code>destroy</code>,\n-<code>rebind</code>,\n-<code>is_always_equal</code>, and\n-<code>max_size</code>.\n+C++20 deprecates implicitly capturing the value of the meta-variable\n+<code>this</code> in saved lambda state, provoking warnings if member\n+names from the surrounding context are used in the lambda body:\n+</p><p><code> warning: implicit capture of 'this' via '[=]' is deprecated in C++20</code>\n+</p><p>\n+These can be resolved by adding <code>this</code> or <code>*this</code>,\n+as appropriate, to the capture list, such as by <code>[=,this]</code>.\n </p>\n \n+<h4 id=\"changes-to-str-literals\">Changes to character literals</h4>\n+\n <p>\n-The solution in most cases is to use the corresponding member of\n-<code>std::allocator_traits</code> as instantiated on the allocator\n-type, instead. Note that explicitly specializing\n-<code>std::allocator_traits</code> on a custom allocator type, though\n-now undefined behavior, is not warned about.\n+In C++20, <code>u8\"str\"</code> and <code>u8'c'</code> literals changed\n+from type <code>char</code> to type <code>char8_t</code>, leading to\n+errors like:\n+</p><p><code> error: invalid conversion from 'const char8_t*' to 'const char*' [-fpermissive]\n+</code></p><p> The fix is most commonly a cast from the <code>u8</code>\n+literal to plain <code>char</code> or <code>char const*</code>.\n </p>\n \n <h4 id=\"missing-header-includes\">Missing header includes</h4>\n@@ -207,52 +189,34 @@ now undefined behavior, is not warned about.\n <p>\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-</p><p><code> error: ‘uint64_t’ was not declared in this scope</code><br>\n-</p><p>Determine the correct header that declares the name, and <code>#include</code>\n-it. The compiler may suggest a header to include.\n+</p><p><code> error: 'uint64_t' was not declared in this scope</code><br>\n+</p><p>These are fixed by identifying which header declares the name, and\n+including that. The compiler may suggest the header to include.\n </p>\n \n-<h4 id=\"obsolete-function-objects\"><code>unary_function</code> is not defined</h4>\n+<h4 id=\"no-member-destroy\">Has no member named <code>destroy</code></h4>\n \n <p>\n-Standard library function objects have evolved, and have left early experiments behind.\n-All of\n-<code>unary_function</code>,\n-<code>binary_function</code>,\n-<code>pointer_to_unary_function</code>,\n-<code>pointer_to_binary_function</code>,\n-<code>ptr_fun</code>,\n-<code>binder1st</code>,\n-<code>binder2nd</code>,\n-<code>bind1st</code>,\n-<code>bind2nd</code>,\n-<code>binary_function</code>,\n-<code>mem_fun</code>,\n-<code>mem_fun_t</code>,\n-<code>mem_fun1_t</code>,\n-<code>const_mem_fun_ref_t</code>,\n-<code>const_mem_fun1_ref_t</code>,\n-<code>mem_fun_ref</code>,\n-<code>mem_fun_ref_t</code>,\n-<code>mem_fun1_ref_t</code>,\n-<code>const_mem_fun_ref_t</code>,\n-<code>const_mem_fun1_ref_t</code>,\n-<code>unary_negate</code>,\n-<code>binary_negate</code>,\n-<code>not1</code>, and <code>not2</code>\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-<code><functional></code>.\n+In C++20, many deprecated member functions and member typedefs of\n+<code>std::allocator</code> were removed because\n+<code>std::allocator_traits</code> has since C++11 provided better\n+defaults for those members that should be used instead. This applies\n+to former members\n+<code>pointer</code>,\n+<code>const_pointer</code>,\n+<code>reference</code>,\n+<code>const_reference</code>,\n+<code>construct</code>,\n+<code>destroy</code>,\n+<code>rebind</code>,\n+<code>is_always_equal</code>, and\n+<code>max_size</code>.\n </p>\n-\n-<h4 id=\"specified-bound-overflow\">specified bound 18446744073709551608 exceeds maximum</h4>\n-\n <p>\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.) <code>std::allocator_traits<A>::destroy</code>\n+in place of <code>A::destroy</code>.\n </p>\n \n <h2 id=\"os\">Operating Systems</h2>\n", "prefixes": [ "v2" ] }