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 03830385780A for ; Fri, 30 Jul 2021 20:51:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 03830385780A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com IronPort-SDR: h6etgWeJxOT6r0cqUue9p45Ivy3+7Gvi0D2Av46O5rNjT/FTY58bgGNfrVo/gekZmu/SAphCXW uSQna+PXMfKBktYU/cMrHP5Ac6uVbWolGSzTYBhXsTlBRWWFlF9NqJJzTo19N0qRFs8ZHvJg84 TtZzPadaI1XfNlUPfny0O0BzXgFRG+invdG02ReEbO/LtR3uEG+BwcK/fTGI9M/cFsBO+xmo3l W7xLPgHV+UWSGFblzHEhYmNGdMGStLtx9blN01D0ZOxjNaRdJ+UQxGLW0Zesdqp4ua4mNWUPzO kgSN8ZCf6+jkPw0rpGdNxMn3 X-IronPort-AV: E=Sophos;i="5.84,282,1620720000"; d="scan'208";a="64128248" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa2.mentor.iphmx.com with ESMTP; 30 Jul 2021 12:51:27 -0800 IronPort-SDR: AL6sQNU1tu2iusL2i2jVByt9e+fSdlcGFy0ozJF+YKr5Hs+pQ/9GWW+8wiYIY2v6gxwlEICwah Ynbq6gpD0V6mQF4kV2O+7WZLJ/09NVjNMgeY9nxLKmSPmpVStih/6f7Zl4xWpq0bwbjdbHv+tu McDmcrvwTY7jVObn0wAe+YqDIDcdEumB5bOMHfJPUVxqarMyZa6VF8n7pdwTWopMn/1ZIUb7FK bRVO4/zGmitYi0hvqkzj1wSrIIt/dTuqZ5r3o8GI4sEk8XdyTw5MbPvnKaDk2pceBpv66LvekA xhE= Date: Fri, 30 Jul 2021 20:51:21 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: Stefan Kanthak CC: Subject: Re: Are some builtin functions (for example log() vs. sqrt()) more equal than others? In-Reply-To: <8C3EADB2051345408B320575745C4E56@H270> Message-ID: References: <8C3EADB2051345408B320575745C4E56@H270> 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-09.mgc.mentorg.com (139.181.222.9) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-3119.5 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2021 20:51:30 -0000 On Fri, 30 Jul 2021, Stefan Kanthak wrote: > Joseph Myers wrote: > > > None of these are valid constant expressions as defined by the standard > > (constant expressions cannot involve evaluated function calls). > > That's why I ask specifically why GCC bugs on log(log(...)), but not on > log(sqrt(...) ...)! The log(log(1.0)) example you gave would raise divide-by-zero. > > Some might be accepted as an extension, but I expect that since the > > optimization for constant arguments is intended for valid calls that > > would otherwise be executed at runtime, not for static initializers, > > it's avoiding optimizations that would result in the loss of floating- > > point exception flag raising. > > That's no valid excuse: by the standard, the compiler is free to execute > static initializers during runtime, before calling the main() routine. The point of this extension isn't to accept as much as possible. Rather, it turned out when I implemented standard constant expression rules for GCC 4.5 that lots of existing code was using just about anything GCC could fold into a constant in just about any context requiring a constant expression. So for compatibility with existing, questionable, pre-GCC-4.5 code, we still allow "expressions that can be folded into a constant" in various such contexts, with a pedwarn-if-pedantic. But because this isn't a designed, documented extension or something it's actually considered good practice to use, the semantics remain "expressions that can be folded into a constant", with all the dependence that implies on the folding GCC does for optimization purposes - and that folding is designed for optimizing code outside of static initializers, not for use in this extension, with all the corresponding implications for its design. So if some expression doesn't get folded to a constant outside of static initializers (or for that matter, if it does get so folded, but previous GCC versions didn't accept it in static initializers, since this extension is about compatibility with existing code), it's not a bug for it not to be accepted in a static initializer. If, outside of static initializers, some of these expressions don't get folded to a constant *even with -fno-trapping-math*, that's a missed optimization and it would make sense to improve the compiler to fold them given -fno-trapping-math. Executing static initializers at runtime seems more like a C++ thing; it's not within the conventional concept of how C maps to object files. -- Joseph S. Myers joseph@codesourcery.com