[{"id":3676592,"web_url":"http://patchwork.ozlabs.org/comment/3676592/","msgid":"","list_archive_url":null,"date":"2026-04-13T09:25:39","subject":"Re: [PATCH] libstdc++: follow std in numeric_limits::traps","submitter":{"id":48004,"url":"http://patchwork.ozlabs.org/api/people/48004/","name":"Jonathan Wakely","email":"jwakely@redhat.com"},"content":"On Fri, 10 Apr 2026 at 13:02, Alexandre Oliva wrote:\n>\n>\n> There's a comment from 2002 suggesting that\n> numeric_limits::traps was in a DR, but C++ standards including\n> 11, 17 and 23 explicitly set it to false. I suppose whatever DR that\n> comment referred to must have long been resolved in favor of what's in\n> these much newer releases of the standard. So align it with the\n> standards, and drop the comment.\n\nhttps://cplusplus.github.io/LWG/issue497 (opened by Martin in 2005)\nonly covers floating-point types.\n\nThe comment probably refers to\nhttps://cplusplus.github.io/LWG/issue184 which added the\nnumeric_limits specialization.\n\nIn 2006 Howard opened https://cplusplus.github.io/LWG/issue554 to\nquestion the meaning of numeric_limits::traps but that was\nclosed as Not A Defect. I think that resolution casts doubt on how we\ndefine traps for all integral types. We use:\n\n// GCC only intrinsically supports modulo integral types. The only remaining\n// integral exceptional values is division by zero. Only targets that do not\n// signal division by zero in some \"hard to ignore\" way should use false.\n#ifndef __glibcxx_integral_traps\n# define __glibcxx_integral_traps true\n#endif\n\nThis seems to suggest that we make it true because division by zero\nmight trap, but the resolution of 554 says that's an incorrect\ninterpretation. GCC has no integer values that can trap. I think this\nis the case even for integer types with padding like __int20, because\nthose types have no valid values that can trap when used. The padding\nbits do not participate in the value.\n\nSo I think the correct fix is to just get rid of\n__glibcxx_integral_traps and set numeric_limits::traps to false for\nall integral types. But that's definitely stage 1 material.\n\n\n>\n> Regstrapped on x86_64-linux-gnu. Ok to install? Not a regression\n> AFAICT; perhaps for stage1?\n>\n>\n> for libstdc++-v3/ChangeLog\n>\n> * include/std/limits (numeric_limits::traps): Set to\n> false.\n> ---\n> libstdc++-v3/include/std/limits | 5 +----\n> 1 file changed, 1 insertion(+), 4 deletions(-)\n>\n> diff --git a/libstdc++-v3/include/std/limits b/libstdc++-v3/include/std/limits\n> index f0ba2851a0a2e..c160503e0a826 100644\n> --- a/libstdc++-v3/include/std/limits\n> +++ b/libstdc++-v3/include/std/limits\n> @@ -446,10 +446,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION\n> static _GLIBCXX_USE_CONSTEXPR bool is_bounded = true;\n> static _GLIBCXX_USE_CONSTEXPR bool is_modulo = false;\n>\n> - // It is not clear what it means for a boolean type to trap.\n> - // This is a DR on the LWG issue list. Here, I use integer\n> - // promotion semantics.\n> - static _GLIBCXX_USE_CONSTEXPR bool traps = __glibcxx_integral_traps;\n> + static _GLIBCXX_USE_CONSTEXPR bool traps = false;\n> static _GLIBCXX_USE_CONSTEXPR bool tinyness_before = false;\n> static _GLIBCXX_USE_CONSTEXPR float_round_style round_style\n> = round_toward_zero;\n>\n> --\n> Alexandre Oliva, happy hacker https://blog.lx.oliva.nom.br/\n> Free Software Activist FSFLA co-founder GNU Toolchain Engineer\n> More tolerance and less prejudice are key for inclusion and diversity.\n> Excluding neuro-others for not behaving \"\"normal\"\" is *not* inclusive!\n>","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=CdCxufba;\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=CdCxufba","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 4fvMVR5C7Qz1y2d\n\tfor ; Mon, 13 Apr 2026 19:26:39 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id 6F6784BA2E15\n\tfor ; Mon, 13 Apr 2026 09:26:37 +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 160F94BA2E0A\n for ; Mon, 13 Apr 2026 09:25:59 +0000 (GMT)","from mail-yx1-f71.google.com (mail-yx1-f71.google.com\n [74.125.224.71]) by relay.mimecast.com with ESMTP with STARTTLS\n (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id\n us-mta-376-5B-Rdw6DOtuEWFfETOYToQ-1; Mon, 13 Apr 2026 05:25:57 -0400","by mail-yx1-f71.google.com with SMTP id\n 956f58d0204a3-651bd07888eso1931483d50.2\n for ; Mon, 13 Apr 2026 02:25:57 -0700 (PDT)"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org 6F6784BA2E15","OpenDKIM Filter v2.11.0 sourceware.org 160F94BA2E0A"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org 160F94BA2E0A","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org 160F94BA2E0A","ARC-Seal":"i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1776072360; cv=none;\n b=LpjS8D/c9OGIfAn4w8zTnLFFvRh63V0PUUgrD6DDGL6aytjN3nFfF+7pD+TmVNdFW4WEybFEA5DxQ4OnmCNzx5+3ZI8/x7dQLS7fD6vx52PbJDW8txUMrIZVlWPhnSMI54dI++4vmTzdyZXTM4J52Kpmr5IzRRlktLtz0v85Xkw=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=sourceware.org; s=key;\n t=1776072360; c=relaxed/simple;\n bh=TSgFMeUQaD97v2pQhRB7YIUMFCpn7PXGxASGXEubpk8=;\n h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To;\n b=Wuv+jaFW1q7FLXd3dhHLc21yqEH2tEJftdMVgCKZNn36DmMQHRk/+cZke6G1UGUL24OZmD3lyG/gEOdw6ss6rNXyCZpPSPKRknWXc3fcArAEP0zRuqMFTrVuXpuzUoYxblaHEjtn/89PzfXIiYiSXxibxyMCoMG2/lja+XbU/3Q=","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=1776072359;\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 in-reply-to:in-reply-to:references:references;\n bh=9wyrYVjdn4xidVwT/JenbQ2x0/pQQeVp/1D28aZFw4A=;\n b=CdCxufbaultFhb3nYnufUVlT6eYEukjxnVMfEAmcI/FtE9+oKJQPdOHuemaUzzyxMyiuel\n GrwwTw2vl4EDgRU7gZFWI0zbnZdmJ4xQMWs2x9PSfwE+kgwntfx6lDLyJXW8vSmTEhsEOk\n bo/KeYVyAkZ8HeoT2DkT0BlGLYQCS2s=","X-MC-Unique":"5B-Rdw6DOtuEWFfETOYToQ-1","X-Mimecast-MFC-AGG-ID":"5B-Rdw6DOtuEWFfETOYToQ_1776072357","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1776072357; x=1776677157;\n h=cc:to:subject:message-id:date:from:in-reply-to:references\n :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date\n :message-id:reply-to;\n bh=9wyrYVjdn4xidVwT/JenbQ2x0/pQQeVp/1D28aZFw4A=;\n b=mIsER5+dURaS4RT+nbT1669GBPZ3/Ko21Xc8FOg0l0e6atI8MUVhhD9t8Ci8ystNIq\n 4jkPGIkMsGOUmWOZ3YKLyzU7UUOiqTkZWfL2LJJahHk6JwVQe+wEgXxwnKJUemgjBCSR\n RnYTvu38gUhSkT3TjuoF1NAPSmBVBVQmP1bgUjBzzxyL261/LN1D/fvWw7BC6jmzy0A/\n hXxpR632ll3wsX1C4rM7CQWgjxY7RQAuBCPm10bY+TywijB9RM5HU8yKaZqCLl1OsdhF\n yfE2z90gr6WuzyWaH9YEhd36aGPrpke4VOPkx4Y8y3kjk2tAhOdFCv/l1cZydKem+Ryi\n xkYA==","X-Gm-Message-State":"AOJu0Yxt9SrgTD3T/Kdh2TnkE3PD2un3LoydPZiF0l02ak/KDH2ylWLc\n MV68TIk0sbaoqXqL9eyT6l9nBXQQgEBJ0Yx0NIq6dp9KDufE5BncX5SrSkOZXoNs0i6vaCt3+Pr\n Otz6VmluHxexvedgbRQz1yAgi/sV722soIit5aUXvrsjsYUuEhhx7oDisFoGpUPwdZjOcDfWpEA\n 3ZH+T75/xXqZCSrZ6rQ1jjPAvRThOtUaIvOclxIPS3UVaB","X-Gm-Gg":"AeBDievgoo1iXiR5OU5teMJZL7ud88j46PGmgtmo8sws07WFLiuNLi20x8y7pNtKdRq\n DPPlQ9AXNexrq/8A21i6S4iRCZvnggCEDw7Us+GY8nu8QykYNgO6oq0xvnPyAqrxDLxp21YGVwN\n i0qA9pCnuGsv5EC+XpQlcoBaLuWoikWbeB3qudv/I9OLGgtyrI/Lq0DZXvCwZ1x2dVRjZAY78GI\n gzOOpXfh6FD/w/QjMqlFg5+fLmmuNSyHzjs3WjiAjqaONFXZhz0Yy8aNMun5vfZcIM=","X-Received":["by 2002:a05:690e:b48:b0:651:c3d3:a441 with SMTP id\n 956f58d0204a3-651c3d3a777mr3764210d50.46.1776072357038;\n Mon, 13 Apr 2026 02:25:57 -0700 (PDT)","by 2002:a05:690e:b48:b0:651:c3d3:a441 with SMTP id\n 956f58d0204a3-651c3d3a777mr3764200d50.46.1776072356612; Mon, 13 Apr 2026\n 02:25:56 -0700 (PDT)"],"MIME-Version":"1.0","References":"","In-Reply-To":"","From":"Jonathan Wakely ","Date":"Mon, 13 Apr 2026 10:25:39 +0100","X-Gm-Features":"AQROBzA_ZrF4H8fBQViuAncxoButzJOkDaRDnDV1yOzMGqzIiEz11PkVHGP7_pU","Message-ID":"\n ","Subject":"Re: [PATCH] libstdc++: follow std in numeric_limits::traps","To":"Alexandre Oliva ","Cc":"gcc-patches@gcc.gnu.org, libstdc++@gcc.gnu.org","X-Mimecast-Spam-Score":"0","X-Mimecast-MFC-PROC-ID":"Wd24-zpMamQDJ5OcIb6tmwuCK2rn2h0NhCupYcXQ6dk_1776072357","X-Mimecast-Originator":"redhat.com","Content-Type":"text/plain; charset=\"UTF-8\"","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"}}]