From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) by sourceware.org (Postfix) with ESMTPS id 227A03858C27; Wed, 19 Jan 2022 16:45:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 227A03858C27 Received: by mail-wm1-x32b.google.com with SMTP id l35-20020a05600c1d2300b0034d477271c1so6683306wms.3; Wed, 19 Jan 2022 08:45:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TbJnFhHpdk4fzZWlykC6vChHNduFZqGIlEw4Rf+6wKw=; b=40GGHK7wz07rgiAVW4djI3NVX2Omq0PA0wDeu0nOn8mEAgDg/MIUM33foaoN/rIDf6 rOwJlIRkI8XX2CWN3xwQP25NlUKdvm9hwhKHILEeMitIyuZ5GAVU2lZ86gpGsCdfJd0x TNflQJaIsjW55H0+gPdLB6hTEiGZgTNbSTBQ4m75g+RRgFXE6EOQHehTOy2220YFB25e vuD/mdCctdv+Vt4dvG5s6dQfHP/mdxemezt3CPWusdnVC+82BxxqmOviqvC2iyttsWqu jdAeONNYHpA3JNFJtesqVMQSUXKEsVXKhkTy+NtZR40qzHkK7oV80k8OTDDfkNH/+2rD 0Www== X-Gm-Message-State: AOAM531aJDgRfpxtpKmU7Tj3YJIbcVtBYZza1bZi0e1H45AyZVKgMkq0 TQFLGArJie4NI7y9Uq/LppI+hr/sRvljRarZnUE= X-Google-Smtp-Source: ABdhPJwHNdJs1gDRBqUIL/6lmfA67o3OPiY+Brd9or2X1llx6KkqJrn+DZP64TDHg/wAuCyP90Dirpo2m4M0UH1Owlw= X-Received: by 2002:a7b:c310:: with SMTP id k16mr4406266wmj.169.1642610750020; Wed, 19 Jan 2022 08:45:50 -0800 (PST) MIME-Version: 1.0 References: <2169197.iZASKD2KPV@minbar> <8881104.CDJkKcVGEf@minbar> <1901173.usQuhbGJ8B@minbar> In-Reply-To: <1901173.usQuhbGJ8B@minbar> From: Jonathan Wakely Date: Wed, 19 Jan 2022 16:45:38 +0000 Message-ID: Subject: Re: [PATCH] libstdc++: Fix for non-constexpr math_errhandling To: Matthias Kretz Cc: gcc-patches , "libstdc++" Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libstdc++@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libstdc++ mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2022 16:45:52 -0000 On Wed, 19 Jan 2022 at 15:46, Matthias Kretz wrote: > > On Wednesday, 19 January 2022 16:21:15 CET Jonathan Wakely wrote: > > On Wed, 19 Jan 2022, 12:45 Matthias Kretz, wrote: > > > On Wednesday, 19 January 2022 13:07:26 CET Jonathan Wakely wrote: > > > > So is it a macro or not? > > > > > > I agree the quote I used is unclear. The complete paragraph: > > > > > > The macros > > > > > > MATH_ERRNO > > > MATH_ERREXCEPT > > > > > > expand to the integer constants 1 and 2, respectively; the macro > > > > > > math_errhandling > > > > > > expands to an expression that has type int and the value MATH_ERRNO, > > > MATH_ERREXCEPT, or the bitwise OR of both. The value of math_errhandling > > > is > > > constant for the duration of the program. It is unspecified whether > > > math_errhandling is a macro or an identifier with external linkage. If a > > > macro > > > definition is suppressed or a program defines an identifier with the name > > > math_errhandling, the behavior is undefined. If the expression > > > math_errhandling & MATH_ERREXCEPT can be nonzero, the implementation shall > > > define the macros FE_DIVBYZERO, FE_INVALID, and FE_OVERFLOW in > > > . > > > > But that still says "the macro math_errhandling" and then says it might not > > be a macro. > > There's also [cmath.syn] https://eel.is/c++draft/cmath.syn which says: > > #define math_errhandling see below > > So, FWIW, libstdc++ is required to define math_errhandling as a macro in > . Thus, the original error (that math_errhandling wasn't defined even > after was included) really needs a fix in . :-P No, because we get it from libc: #include_next