Patch Detail
get:
Show a patch.
patch:
Update a patch.
put:
Update a patch.
GET /api/patches/2218889/?format=api
{ "id": 2218889, "url": "http://patchwork.ozlabs.org/api/patches/2218889/?format=api", "web_url": "http://patchwork.ozlabs.org/project/gcc/patch/20260402012517.545633-1-sloosemore@baylibre.com/", "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": "<20260402012517.545633-1-sloosemore@baylibre.com>", "list_archive_url": null, "date": "2026-04-02T01:25:16", "name": "[RFC] doc, libitm: Fix some issues with transactional memory documentation", "commit_ref": null, "pull_url": null, "state": "new", "archived": false, "hash": "c517bb86db206490a1ece3c7a5633db52bc44683", "submitter": { "id": 87955, "url": "http://patchwork.ozlabs.org/api/people/87955/?format=api", "name": "Sandra Loosemore", "email": "sloosemore@baylibre.com" }, "delegate": null, "mbox": "http://patchwork.ozlabs.org/project/gcc/patch/20260402012517.545633-1-sloosemore@baylibre.com/mbox/", "series": [ { "id": 498415, "url": "http://patchwork.ozlabs.org/api/series/498415/?format=api", "web_url": "http://patchwork.ozlabs.org/project/gcc/list/?series=498415", "date": "2026-04-02T01:25:16", "name": "[RFC] doc, libitm: Fix some issues with transactional memory documentation", "version": 1, "mbox": "http://patchwork.ozlabs.org/series/498415/mbox/" } ], "comments": "http://patchwork.ozlabs.org/api/patches/2218889/comments/", "check": "pending", "checks": "http://patchwork.ozlabs.org/api/patches/2218889/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=baylibre-com.20230601.gappssmtp.com\n header.i=@baylibre-com.20230601.gappssmtp.com header.a=rsa-sha256\n header.s=20230601 header.b=0LeckfB2;\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=baylibre-com.20230601.gappssmtp.com\n header.i=@baylibre-com.20230601.gappssmtp.com header.a=rsa-sha256\n header.s=20230601 header.b=0LeckfB2", "sourceware.org;\n dmarc=none (p=none dis=none) header.from=baylibre.com", "sourceware.org; spf=pass smtp.mailfrom=baylibre.com", "server2.sourceware.org;\n arc=none smtp.remote-ip=209.85.210.43" ], "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 4fmPMG53Rzz1yCs\n\tfor <incoming@patchwork.ozlabs.org>; Thu, 02 Apr 2026 12:25:57 +1100 (AEDT)", "from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id 2599F4BA23C5\n\tfor <incoming@patchwork.ozlabs.org>; Thu, 2 Apr 2026 01:25:54 +0000 (GMT)", "from mail-ot1-f43.google.com (mail-ot1-f43.google.com\n [209.85.210.43])\n by sourceware.org (Postfix) with ESMTPS id B152A4BA2E31\n for <gcc-patches@gcc.gnu.org>; Thu, 2 Apr 2026 01:25:23 +0000 (GMT)", "by mail-ot1-f43.google.com with SMTP id\n 46e09a7af769-7d9c98e437cso360301a34.0\n for <gcc-patches@gcc.gnu.org>; Wed, 01 Apr 2026 18:25:23 -0700 (PDT)", "from nenufar.hsd1.co.comcast.net ([2601:281:d901:97c0::9a27])\n by smtp.gmail.com with ESMTPSA id\n 46e09a7af769-7dba72fd3fesm1078381a34.14.2026.04.01.18.25.20\n (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);\n Wed, 01 Apr 2026 18:25:21 -0700 (PDT)" ], "DKIM-Filter": [ "OpenDKIM Filter v2.11.0 sourceware.org 2599F4BA23C5", "OpenDKIM Filter v2.11.0 sourceware.org B152A4BA2E31" ], "DMARC-Filter": "OpenDMARC Filter v1.4.2 sourceware.org B152A4BA2E31", "ARC-Filter": "OpenARC Filter v1.0.0 sourceware.org B152A4BA2E31", "ARC-Seal": "i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1775093123; cv=none;\n b=cAl1NBSk9lPAVykz6VhhHBO0fpssJeJR6ui5qQn+DfgV39+89GGFwwkAJ/uxZODUr8jxCi8aw+nI6kMpq8fcbKWfa4/IFS3c+V5O2MUlMwQRVmwKDC+fdCthXP9KUifh0BL9FFK/yMZ7Dp4WMUf/tVQQdUdJpIMV53qlDmmv1Lo=", "ARC-Message-Signature": "i=1; a=rsa-sha256; d=sourceware.org; s=key;\n t=1775093123; c=relaxed/simple;\n bh=E0MRc3lxH+wgm3nq2LHh1wBNfdpQGbPvYqP/iXHW73k=;\n h=DKIM-Signature:From:To:Subject:Date:Message-Id:MIME-Version;\n b=bhPdh7G0l4nOKTYR8lpdi6/voVDFesmENkLJ0fcpiydG7f+tKAxNqGkzt6zPDb3JBByKYXYjDY5+BcLCluWmzm+XHOC6owz6DwJGqXdONnvA5saszd1uF752okcy3RhykzcgNAI1lz6Q8FiT335c3Ja02L3rYA7oNauPSKFMqCA=", "ARC-Authentication-Results": "i=1; server2.sourceware.org", "DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=baylibre-com.20230601.gappssmtp.com; s=20230601; t=1775093123;\n x=1775697923;\n darn=gcc.gnu.org;\n h=content-transfer-encoding:mime-version:message-id:date:subject:to\n :from:from:to:cc:subject:date:message-id:reply-to;\n bh=fvdmaRo8rcs0xS39CXzKN3toOJJIpM9lEmHxnlYLdOM=;\n b=0LeckfB2cxzBofpfz05oQn0PLp0X2ezNBcYOcIXKHD9UVduZNmwJqRqC4et8Alog8t\n NfW+yllXT3fLk9Y6pUQ8bglGq/gAgMSjTTsxmK31nviQ5SVtgREIWxl6X8lJM4meREjZ\n REtZoURN7wjBsLMrq4mUcsmGOJQ10NxLqmMAne58g/ywZkdkOGgm+RUq7T5OCieRdoi4\n f2OB446K/W3wUgHcDvxbNeusiFv25S8m+w+UKKFLjuHma/u0Kng58Ma4GwHOzEOQZNbW\n t0vADcZVlOmK/9HGqXBj0JXTtSHU9dM0pYrhuT+71syju5O66+0QDlidUgPI7A8I6L7v\n cKxQ==", "X-Google-DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1775093123; x=1775697923;\n h=content-transfer-encoding:mime-version:message-id:date:subject:to\n :from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id\n :reply-to;\n bh=fvdmaRo8rcs0xS39CXzKN3toOJJIpM9lEmHxnlYLdOM=;\n b=gG5Vt1IWDweYkL8tZboTX3dKU4fUpem6VaTR8eNbR031XDn5irNJFpogW6rYswPGRN\n krRWJO1U637tcKNAlNBaPZgvyJz0BbrVNw/0p/dmB8B2s95SkYG9S4en6LyfB3QA9s5g\n 56mIeTY3aP6g29Q4A9YAOMdNyZAKxyxglrLS35fNmJpE0Ifqp0nM/vpX+cKYAnsCOI7z\n 6nuRre9SNuktU/MdugKsG7BnvV26c/zhXmFW0/7WG1rrTWpoBzMqIbybBtQ/zb/FbA5z\n aP0M9zUS7lbEHESPuPxwIwdtkqXcEvg/x/1CdI5Y0620sZyxgbP6nZAyLv7pN3A1E36J\n GZnQ==", "X-Gm-Message-State": "AOJu0Yxz9iGHQYSnEW9xIRiOq7MXPEbFbvoYT42aZ3LmD09OLWVku4FR\n H2/tQ27j+7WDW+ckB7nQacelmE1QIfXia14hdP20pJ8i2kcqDKnzuOpvlAnxfcTXMNfVqmVS7bK\n MgQBL", "X-Gm-Gg": "ATEYQzywYBlHiiRSmE2TWFey365WfaFuZjmY3uYd7Bvk8aoe0/8jD689Roi4/WhkAxp\n q2xB9SXQAILwon0X0FG2RLW6o8l0V76LHSW5O/1CTLySSU/F7XZcV9wlkRR9rVV1p47rtImsHBR\n D9Rh1oNCxw3Ry14ywEIb5M2p8EtpdYhST8Drje/iAakfdNtaEvyhEM4b0sQkRZaPcq3M3F94duO\n 34nxpA/c2/i7W0bxDmA5T5LNKREjva8aMZqh73yxtZ7YqLjydai21sldRPDHPQt/ZdwaS/+4pTg\n OKOy3m4KlW4Wfu/fHkTuYGhbgFijHbULPNSXDZSdb1nQgwJgTwLbXpRYGrTuNoyZlRbvdLBmIAr\n NNlJ3yDaTfb1rsgHN2FVqwhAQWV5KaD4DBWJtbRn1PbrvYVWy1RBdQSIxzK6tgIypa7e+y3UIx5\n RRqVXGbGpfxF8qa54Or0qGUo9WRxlFynEW", "X-Received": "by 2002:a05:6830:3bc5:b0:7d7:faa4:6c2b with SMTP id\n 46e09a7af769-7db9923ed37mr3792142a34.9.1775093122569;\n Wed, 01 Apr 2026 18:25:22 -0700 (PDT)", "From": "Sandra Loosemore <sloosemore@baylibre.com>", "To": "gcc-patches@gcc.gnu.org", "Subject": "[RFC] doc,\n libitm: Fix some issues with transactional memory documentation", "Date": "Wed, 1 Apr 2026 19:25:16 -0600", "Message-Id": "<20260402012517.545633-1-sloosemore@baylibre.com>", "X-Mailer": "git-send-email 2.34.1", "MIME-Version": "1.0", "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 <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": "I was looking at PR94108 (\"transaction memory attributes not\ndocumented\") and found that the link to the spec that defines these\nattributes was (a) to the internal API document rather than the C++\ninterface document and (b) dead. From discussion on IRC and in the\nmail archives it appears that the transactional memory feature is not\nreally usable but there is resistance to deprecating and/or removing\nit. I've settled on just warning readers that it is obsolete and not\nreally usable, as well as digging up working links to both documents.\nThis patch doesn't address PR94108 as there seems to be little value\nin telling readers about features that are not really useful.\n\ngcc/ChangeLog\n\t* doc/invoke.texi (C Dialect Options) <-fgnu-tm>: Do not describe\n\tthe 2009 document as \"current\". Warn readers this is an experimental\n\tand unmaintained feature. Update pointer to libitm documentation.\n\nlibitm/ChangeLog\n\t* libitm.texi (Implementation Status): New section, consolidating\n\tbits of information formerly found elsewhere including...\n\t(Enabling libitm): ...here.\n\t(The libitm ABI): Do not describe the 2009 document as \"current\".\n---\n gcc/doc/invoke.texi | 20 +++++++++-----------\n libitm/libitm.texi | 30 ++++++++++++++++++++++++------\n 2 files changed, 33 insertions(+), 17 deletions(-)", "diff": "diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi\nindex 00f470a0d5d..56de3bc79ee 100644\n--- a/gcc/doc/invoke.texi\n+++ b/gcc/doc/invoke.texi\n@@ -2757,18 +2757,16 @@ passes.\n @opindex fno-gnu-tm\n @item -fgnu-tm\n When the option @option{-fgnu-tm} is specified, the compiler\n-generates code for the Linux variant of Intel's current Transactional\n-Memory ABI specification document (Revision 1.1, May 6 2009). This is\n-an experimental feature whose interface may change in future versions\n-of GCC, as the official specification changes. Please note that not\n-all architectures are supported for this feature.\n+generates code for the Linux variant of Intel's Transactional\n+Memory ABI specification document (draft Revision 1.1, May 6 2009). This is\n+an experimental feature and has not been maintained for some time; newer\n+proposals for transactional memory in the C++ language are substantially\n+different.\n \n-For more information on GCC's support for transactional memory,\n-@xref{Enabling libitm,,The GNU Transactional Memory Library,libitm,GNU\n-Transactional Memory Library}.\n-\n-Note that the transactional memory feature is not supported with\n-non-call exceptions (@option{-fnon-call-exceptions}).\n+For more information on GCC's support for transactional memory and limitations\n+of the current implementation,\n+@xref{Implementation Status,Implementation Status,Implementation Status,\n+libitm,The GNU Transactional Memory Library}.\n \n @opindex fgnu89-inline\n @opindex fno-gnu89-inline\ndiff --git a/libitm/libitm.texi b/libitm/libitm.texi\nindex d7c5626a4be..f43297b52e4 100644\n--- a/libitm/libitm.texi\n+++ b/libitm/libitm.texi\n@@ -54,13 +54,13 @@ Memory Library. It provides transaction support for accesses to a process'\n memory, enabling easy-to-use synchronization of accesses to shared memory by\n several threads.\n \n-\n @comment\n @comment When you add a new menu item, please keep the right hand\n @comment aligned to the same column. Do not use tabs. This provides\n @comment better formatting.\n @comment\n @menu\n+* Implementation Status:: Transactional Memory is experimental.\n * Enabling libitm:: How to enable libitm for your applications.\n * C/C++ Language Constructs for TM::\n Notes on the language-level interface supported\n@@ -72,6 +72,28 @@ several threads.\n * Library Index:: Index of this documentation.\n @end menu\n \n+@node Implementation Status\n+@chapter Implementation Status\n+\n+GCC follows the\n+@uref{https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1613.pdf,\n+Draft Specification of Transactional Language Constructs for C++},\n+version 1.1 dated February 3, 2011, and the\n+@uref{https://gcc.gnu.org/wiki/TransactionalMemory,\n+Intel Transactional Memory Compiler and Runtime Application Binary Interface}\n+document identified as revision 1.1 (Draft) and dated May 6, 2009,\n+in its implementation of transactional memory.\n+\n+Be aware that GCC's support for transactional memory is an\n+experimental feature and has not been maintained for some time; newer\n+proposals for transactional memory in the C++ language are\n+substantially different.\n+\n+Please note that not all architectures are supported for this feature\n+and additional limitations and caveats appear throughout this document.\n+Transactional memory is also known to conflict with link-time optimization\n+(@option{-flto}) and non-call exceptions (@option{-fnon-call-exceptions}).\n+\n \n @c ---------------------------------------------------------------------\n @c Enabling libitm\n@@ -110,10 +132,6 @@ atomics):\n __transaction_atomic @{ if (a > b) b++; @}\n @end example\n \n-GCC follows the @uref{https://sites.google.com/site/tmforcplusplus/, Draft\n-Specification of Transactional Language Constructs for C++ (v1.1)} in its\n-implementation of transactions.\n-\n The precise semantics of transactions are defined in terms of the C++11/C11\n memory model (see the specification). Roughly, transactions provide\n synchronization guarantees that are similar to what would be guaranteed when\n@@ -130,7 +148,7 @@ with a transactional read to the same memory location is a data race).\n @chapter The libitm ABI\n \n The ABI provided by libitm is basically equal to the Linux variant of Intel's\n-current TM ABI specification document (Revision 1.1, May 6 2009) but with the\n+TM ABI specification document (Revision 1.1, May 6 2009) but with the\n differences listed in this chapter. It would be good if these changes would\n eventually be merged into a future version of this specification. To ease\n look-up, the following subsections mirror the structure of this specification.\n", "prefixes": [ "RFC" ] }