From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa2.mentor.iphmx.com (esa2.mentor.iphmx.com [68.232.141.98]) by sourceware.org (Postfix) with ESMTPS id A7F683944810 for ; Wed, 4 Nov 2020 21:20:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org A7F683944810 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=joseph_myers@mentor.com IronPort-SDR: hSIX/0xbMfZuIH2XqeVACu1qTLVqqLt1VJRm6rrgqhq8K6LG0xkSKPG3MuB/RefVNTdXx8pabJ 754//QWVusXDszP30tHlrWAsPCEy6r1CznTwaOUyZW5G8cR1JKmNwgPsvoo7ZYKwQkQRQhL7M0 diJqAmYjP26gBHcBnxx3eFvAubVEiDxGFkUO0tDoTzUbgOBc1J3XSs231NhUA+Axie+z4dVo5/ YfcVGPdNdRKAALerrQ6mdkww53SVA57WA5oVT/Cbfsa5WkS/UqHZE9F1k+Vbep3ugTgS2lFLxW 6JQ= X-IronPort-AV: E=Sophos;i="5.77,451,1596528000"; d="scan'208";a="54754972" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa2.mentor.iphmx.com with ESMTP; 04 Nov 2020 13:20:28 -0800 IronPort-SDR: jpgGbo5C87P+olPZIsNUNHcmfxcVIq82e9tLwolQGB6nv9QrOHqGPs1T0+C6Yo1LLdn83v2zYj 7IDuCOeDxG0xxO0wV2GnG8zBIUfKnF2hiTp9rjJktAzIZEs1oGhJz+NNhcrlSoDoaxQ95FmXBk 8B0bfyB8+b1Fsw8+Awv9qgxBVbk9IahzrntFXaHn3cvp6vBZPC0OuLoJsgB6uFXVvPBTkKK+uz mJ/EyvgBAwmKErYcakWF48N/fti6fOM0ce2VfGfEuSD3urY7CDUYeLxPAd9C/BCrtYCL6FeGDw 3s8= Date: Wed, 4 Nov 2020 21:20:22 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: Richard Biener CC: Raoni Fassina Firmino , , , Subject: Re: [PATCH v5] rtl: builtins: (not just) rs6000: Add builtins for fegetround, feclearexcept and feraiseexcept [PR94193] In-Reply-To: Message-ID: References: <20201103231150.zlqccshb3qw63bdv@work-tp> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-05.mgc.mentorg.com (139.181.222.5) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-3126.0 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, RCVD_IN_DNSWL_LOW, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2020 21:20:31 -0000 On Wed, 4 Nov 2020, Richard Biener wrote: > AFAICS you do nothing to marshall with the actually used libc > implementation which AFAIU can choose arbitrary values for > the FE_* macros. I'm not sure we require the compiler to be > configured for one specific C library and for example require > matching FE_* macro definitions for all uses of the built > compiler. The compiler is definitely expected to match a given C library. This applies for and other typedefs, for example (various of which are used for printf format checking). It also applies to FE_* in some cases where relevant for __atomic_feraiseexcept for floating-point atomic compound assignment. > Now, I wonder whether _GCC_ should provide the FE_* macros, thus > move (parts of) fenv.h to GCC like we do for stdint.h? I think that would be a bad idea. fenv.h involves library functionality that can sometimes need to do things beyond simply modifying hardware registers. Consider e.g. the TLS exception and rounding mode state for soft-float powerpc-linux-gnu. Or the TLS decimal rounding mode in libdfp. Or how exception enabling can involve a prctl call on powerpc. Getting libgcc involved in storing such TLS state seems problematic. And whether an FE_* macro should be defined may depend on whether the library supports the underlying functionality (consider the case of FE_TONEARESTFROMZERO for RISC-V, where defining it should mean library code actually works in that rounding mode, not just that hardware supports it). The natural way to handle the rule in C2x that "The strictly conforming programs that shall be accepted by a conforming freestanding implementation that defines __STDC_IEC_60559_BFP__ or __STDC_IEC_60559_DFP__ may also use features in the contents of the standard headers and and the numeric conversion functions (7.22.1) of the standard header ." would be to say that GCC provides the compiler pieces of a freestanding implementation, not necessarily the whole freestanding implementation. (Those macros would only be defined via implicit preinclusion of stdc-predef.h anyway.) -- Joseph S. Myers joseph@codesourcery.com