From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 43E643858C41 for ; Thu, 4 Jan 2024 16:37:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 43E643858C41 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=foss.arm.com Authentication-Results: sourceware.org; spf=none smtp.mailfrom=foss.arm.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 43E643858C41 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=217.140.110.172 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704386233; cv=none; b=KLHRuUavMMcDy6mZSJasZlCpJEH+Pgo9AnuzG6B0mufJOv0nUfPtnN4anY2USPTRiE2Lc6wgia4+ah/bwiER7yqRVm7cUoBcYh726hvE2gauTLNUAuRs5OK8inWjilcqyZMYGb8HWmNWnmxU6cdSxDRKEABKVr7QbdCXV5g08RQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704386233; c=relaxed/simple; bh=B20IYqdIJfvNV+WBki5vg0NMaGFQrKCgRYQWUpJYBPU=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=se0fCCOxbYPW0gbSf/UsG4+0pnAath+SNIYtx4xCuHEriiZJ5nmNsJp/qGYmhO20I9i3w5VxL+2/0mt0/ognLf8P4REI+wgCxQJtwznuMS4Cxw0+iRjZDB/xJ/P6ZPTYsH5vqc3RnV+Kwv3OZ5mPH8Yf0u6iqLxk3piWTL9E+XU= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 99C8FC15; Thu, 4 Jan 2024 08:37:57 -0800 (PST) Received: from [10.57.45.9] (unknown [10.57.45.9]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 393D63F5A1; Thu, 4 Jan 2024 08:37:11 -0800 (PST) Message-ID: Date: Thu, 4 Jan 2024 16:37:09 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: pragma GCC optimize prevents inlining To: David Brown , gcc-help@gcc.gnu.org References: <20240104150325.GA19790@gate.crashing.org> Content-Language: en-GB From: Richard Earnshaw In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3487.5 required=5.0 tests=BAYES_00,BODY_8BITS,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 04/01/2024 15:24, David Brown via Gcc-help wrote: > On 04/01/2024 16:03, Segher Boessenkool wrote: >> On Thu, Jan 04, 2024 at 03:51:23PM +0100, David Brown via Gcc-help wrote: >>> This is a general limitation in GCC, as far as I know.  I have come >>> across it myself (in my case it was the "-fwrapv" flag).  As far as I >>> remember from a previous discussion long ago, there is no easy >>> workaround. >> >> What are the expected semantics?  That depends on the use case, so on >> what the user expects.  If the compiler inlines the function and picks >> either set of options, it may do something the user wanted to avoid. >> Not good. >> > > Yes, I realise that's a key problem. > > What I wanted in my own case was that this function: > > #pragma GCC push_options > #pragma GCC optimize("-fwrapv") > inline int32_t add(int32_t x, int32_t y) { >     return x + y; > } > #pragma GCC pop_options > > would work exactly as though I had : > > inline int32_t add(int32_t x, int32_t y) { >     return (int32_t) ((uint32_t) x + (uint32_t) y); > } > >> The user can always write exactly what the user wants, instead :-) > > In my case, I wrote it in that second version!  But had "-fwrapv" worked > through inlining, it would have been convenient and neat, especially as > I had several related functions (for a wrapping-integer class). > > > More generally, I think the expected semantics are that the additional > options apply to code inside the function, and at the boundary you don't > care which set of options apply.  So if you have normal floating point > code that sets "x", and then call an inline function with -ffast-math > using "x" as a parameter and returning "y", then the inlined could can > assume "x" is finite and not a NaN, and the later code can assume the > returned value "y" is similarly finite.  If the calculations for "x" > produce a NaN, then the code will be UB - that's the programmer's fault. > >> >> Maybe we could have an option -fallow-inlining-that-changes-semantics? >> Not sure if people will actually find that useful, but at least they >> cannot say they weren't warned if they use that ;-) >> >> >> Segher >> > > The general problem here is that the AST does not carry enough information to handle all these cases within a single function. To merge wrap/no-wrap code, for example, we'd need separate codes for ADD, SUBTRACT, MULTIPLY, etc. At present that 'state' is carried globally, which makes merging impossible without losing the state information.