[{"id":3679747,"web_url":"http://patchwork.ozlabs.org/comment/3679747/","msgid":"","list_archive_url":null,"date":"2026-04-21T08:42:12","subject":"Re: [PATCH] libstdc++: follow std in numeric_limits::traps and\n integral traps","submitter":{"id":48004,"url":"http://patchwork.ozlabs.org/api/people/48004/","name":"Jonathan Wakely","email":"jwakely@redhat.com"},"content":"On Tue, 21 Apr 2026 at 05:52, Alexandre Oliva wrote:\n>\n> On Apr 13, 2026, Jonathan Wakely wrote:\n>\n> > So I think the correct fix is to just get rid of\n> > __glibcxx_integral_traps and set numeric_limits::traps to false for\n> > all integral types. But that's definitely stage 1 material.\n>\n> I couldn't get myself to pull the trigger :-) but I've tested this:\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, presumably in response to\n> issue 184.\n>\n> Issue 554 clarifies that traps is about values that may trap, rather\n> than operations that may trap, so we were wrong in the interpretation\n> about divide-by-zero operations' trapping on integral types that led\n> to __glibcxx_integral_traps's defaulting to true, and some of its\n> overrides.\n>\n> Align numeric_limits::traps with the standard, default\n> __glibcxx_integral_traps to false, drop the overriders based on the\n> incorrect interpretation, but keep __glibcxx_integral_traps for the\n> admittedly unlikely case of trapping integral values' existing on some\n> architecture.\n>\n>\n> Regstrapped on x86_64-linux-gnu. Also tested on arm-eabi and\n> riscv32-elf. Ok for stage1?\n\nThis is strictly speaking an ABI change for most targets, but I doubt\nanybody cares about numeric_limits::traps. I hope\nnobody is depending on it for anything.\n\nAnybody who needs the old behaviour can compile with\n-D__glibcxx_integral_traps=1 if they really need it, so I think this\nis OK to fix ion stage 1.\n\n> (should the otherwise-effectively-empty cpu_defines.h headers be deleted\n> altogether?)\n\nI had to look into that, but it looks like we don't bother having an\nempty cpu_defines.h, and just use the default generic/cpu_defines.h\nfile. So I think yes, they should be removed.\n\n>\n>\n> for libstdc++-v3/ChangeLog\n>\n> * include/std/limits (__glibcxx_integral_traps): Set to\n> false. Update comments.\n> (numeric_limits::traps): Likewise. Likewise.\n> * config/cpu/arm/cpu_defines.h (__glibcxx_integral_traps):\n> Drop overrider.\n> * config/cpu/powerpc/cpu_defines.h (__glibcxx_integral_traps):\n> Likewise.\n> ---\n> libstdc++-v3/config/cpu/arm/cpu_defines.h | 7 -------\n> libstdc++-v3/config/cpu/powerpc/cpu_defines.h | 3 ---\n> libstdc++-v3/include/std/limits | 16 +++++++++-------\n> 3 files changed, 9 insertions(+), 17 deletions(-)\n>\n> diff --git a/libstdc++-v3/config/cpu/arm/cpu_defines.h b/libstdc++-v3/config/cpu/arm/cpu_defines.h\n> index 57e4cbbe0136b..36d6ab25bdb90 100644\n> --- a/libstdc++-v3/config/cpu/arm/cpu_defines.h\n> +++ b/libstdc++-v3/config/cpu/arm/cpu_defines.h\n> @@ -30,11 +30,4 @@\n> #ifndef _GLIBCXX_CPU_DEFINES\n> #define _GLIBCXX_CPU_DEFINES 1\n>\n> -// Integer divide instructions don't trap on ARM.\n> -#ifdef __ARM_ARCH_EXT_IDIV__\n> -#define __glibcxx_integral_traps false\n> -#else\n> -#define __glibcxx_integral_traps true\n> -#endif\n> -\n> #endif\n> diff --git a/libstdc++-v3/config/cpu/powerpc/cpu_defines.h b/libstdc++-v3/config/cpu/powerpc/cpu_defines.h\n> index f4248e0f602a3..59a9b92098726 100644\n> --- a/libstdc++-v3/config/cpu/powerpc/cpu_defines.h\n> +++ b/libstdc++-v3/config/cpu/powerpc/cpu_defines.h\n> @@ -30,7 +30,4 @@\n> #ifndef _GLIBCXX_CPU_DEFINES\n> #define _GLIBCXX_CPU_DEFINES 1\n>\n> -// Integer divide instructions don't trap on PowerPC.\n> -#define __glibcxx_integral_traps false\n> -\n> #endif\n> diff --git a/libstdc++-v3/include/std/limits b/libstdc++-v3/include/std/limits\n> index f0ba2851a0a2e..cb775fbd438e5 100644\n> --- a/libstdc++-v3/include/std/limits\n> +++ b/libstdc++-v3/include/std/limits\n> @@ -81,10 +81,11 @@\n> // The default values are appropriate for many 32-bit targets.\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> +// integral exceptional values is division by zero, but that's an operation,\n> +// not a value, and traps is about values that trap (Issue554), so there aren't\n> +// any for integral types.\n> #ifndef __glibcxx_integral_traps\n> -# define __glibcxx_integral_traps true\n> +# define __glibcxx_integral_traps false\n> #endif\n>\n> // float\n> @@ -446,10 +447,11 @@ _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> + // The standard is explicit in that the bool specialization has it set to\n> + // false, whereas other integral types, for which no explicit\n> + // specialization is given in the standard, follow the general\n> + // specification.\n\nI don't think we need such a detailed comment here (especially not\nreferring to non-bool specializations).\n\nWe already have this comment above the whole explicit specialization,\nwhich justifies why it's there and what all its values are:\n\n // _GLIBCXX_RESOLVE_LIB_DEFECTS\n // 184. numeric_limits wording problems\n\nSo I would just remove the comment on traps entirely.\n\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;","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=Y6wb7oF8;\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=Y6wb7oF8","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 4g0G9B5Qg7z1yGs\n\tfor ; Tue, 21 Apr 2026 18:43:41 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id 9E6254B9DB44\n\tfor ; Tue, 21 Apr 2026 08:43:39 +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 B54944BA23FD\n for ; Tue, 21 Apr 2026 08:42:31 +0000 (GMT)","from mail-yw1-f199.google.com (mail-yw1-f199.google.com\n [209.85.128.199]) by relay.mimecast.com with ESMTP with STARTTLS\n (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id\n us-mta-682-WSuYIwiuMimpxn0UodOHkg-1; Tue, 21 Apr 2026 04:42:29 -0400","by mail-yw1-f199.google.com with SMTP id\n 00721157ae682-79064868702so84955457b3.3\n for ; Tue, 21 Apr 2026 01:42:29 -0700 (PDT)"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org 9E6254B9DB44","OpenDKIM Filter v2.11.0 sourceware.org B54944BA23FD"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org B54944BA23FD","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org B54944BA23FD","ARC-Seal":"i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1776760951; cv=none;\n b=cMod3PZIWC0+2eHRbJYUUPBFQLsz9vCYICc7/+3COTAdSsDCP9imIaszNRFYmjYZP5lqQOEfPsQlNzz4e1jNHKKzIE0sxlD8UxzbxFdlIIXTAhK0SMdmjuRKSgidYSKQJUJ0O23Aa4p6JhufQli8w19uwR26MoCiThZiDYAdFFQ=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=sourceware.org; s=key;\n t=1776760951; c=relaxed/simple;\n bh=hGY+IU/POMjB4j85pMATbYR2AqIJ2RBHK2o5SEJVxsw=;\n h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To;\n b=KWcYJhLCh8/gv3MIG5qD9Or6IRHsKMiWPp8xlu9XxiZ1KObP2QYR9Dns1mxOUKmgMoaZczUvBh+Y1nondF6iujt2CBZYnyFVnjNI4bgwnntUb8ea9278w7ZvF7aqLkQVHGjnXKWdMMpM1Ejvmi6Xa1ZBSxf7MgyAAh4gwIUsUYY=","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=1776760951;\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=Q2Z0igTItECsiDQmU18hUWe3WUjT+ck2APTU6ThA9Q4=;\n b=Y6wb7oF8PSvWfHzFBoKvzbG3e3YQ+tCuqKTWqC4ZfjB1RaGbNjjUIMjPsHLepgLoGTGLdC\n eqUSWQgubsCzTotxaw+wwhxI2XOVRnkPyQZt7S+/9N+wCs3eHDMcXxvoPyzr/qAuUQclN1\n PnWOaq8De4xA0K2ZS4DdGsQKTxsB8nA=","X-MC-Unique":"WSuYIwiuMimpxn0UodOHkg-1","X-Mimecast-MFC-AGG-ID":"WSuYIwiuMimpxn0UodOHkg_1776760949","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1776760949; x=1777365749;\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=Q2Z0igTItECsiDQmU18hUWe3WUjT+ck2APTU6ThA9Q4=;\n b=VGtxe3hsO/u87Oxz7lISX9Uh9UdlvTCHptCgUdK/Tn9D8PuVE/uZyqZr+hfRXnIGpe\n XIe8f0kWMyi8NejwssS5zYvRQKZA5z9TlLYdLHiQsvop4Q5GH6cHlYkQ49LpZglWp4/J\n vaaymt2xjCOEXFZSuwsTTcalbGLqXtFhQRT1inMpwAUH7XuqB/BT+BMB7S9oblgx1tEk\n UMdGpMcrgtpypWI+0xG6vYNu+VUINSV5fedI5Vcsm3E2cJ5biAPEpxNa2tSHkMBpBBbt\n meK3QdHGLuG4x4cv2p/bb8E2oxuVw3PPHL6aSKc9nf+j8ODuwUwT+1FUnb/z2FYB43Zr\n kMgg==","X-Gm-Message-State":"AOJu0Yy221LJUFd3Nfx9aeY/cFj7wrUPhjD0cFDAwOi3ReQVZ8NFlnfn\n MdQ2twwKL6ZOb6zfcX6C+Mo9S+Eob52P4OMGumbHcjFkH/kdN3V7+RQ4B8WoMMkeeTyHv/mHyuN\n Gj6kCR6kao+keH0IJieLyFRub7ur2eglLT6ZdVflQ5VY1qheemBKtcoZFBCufqg04jmsrVAGtdU\n CVISG4iBsaqGhR107eqAsIRTFXc+JeOmm0dw==","X-Gm-Gg":"AeBDieuEnDUWBHgYb4+YgdzWNNWC0ooVu9i7sE/cIUI086AMzJN1fqXK1W+By/7/mnt\n VN+tU3rCIHpL6NFDYkBPZsTh5ULb/2emvSeLB/AL934WVDt8gf7uEPm35xbQq5D5x67DwJL47bt\n MDgq0jWOwuLW1+KaQvcqRbcgnTx8jVXhYHTJSn9dvBTjg5pPKuY2FVfljFWr1bSYCC/K9IHiRnD\n IMscfCT/J2TRKJXMEPvY9CjbQxRslvxAfbT+Wxz7V8VoWPOvDGlftFnIiqcYM1hG4YitkC8TRlQ\n 6A==","X-Received":["by 2002:a05:690e:1441:b0:651:bca4:9b64 with SMTP id\n 956f58d0204a3-6531085ec41mr14811794d50.21.1776760949283;\n Tue, 21 Apr 2026 01:42:29 -0700 (PDT)","by 2002:a05:690e:1441:b0:651:bca4:9b64 with SMTP id\n 956f58d0204a3-6531085ec41mr14811777d50.21.1776760948737; Tue, 21 Apr 2026\n 01:42:28 -0700 (PDT)"],"MIME-Version":"1.0","References":"\n \n ","In-Reply-To":"","From":"Jonathan Wakely ","Date":"Tue, 21 Apr 2026 09:42:12 +0100","X-Gm-Features":"AQROBzDr-hX75PZ_PZxzsxJZRZV_9PgbHeUM99AXQt3NACYFARwemEo0XDaHCKM","Message-ID":"\n ","Subject":"Re: [PATCH] libstdc++: follow std in numeric_limits::traps and\n integral traps","To":"Alexandre Oliva ","Cc":"gcc-patches@gcc.gnu.org, libstdc++@gcc.gnu.org","X-Mimecast-Spam-Score":"0","X-Mimecast-MFC-PROC-ID":"UctyuCbDP8XcgsfLcWYTG32RCbjHGAO6PKjka-SmKYQ_1776760949","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"}}]