From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ciao.gmane.io (ciao.gmane.io [116.202.254.214]) by sourceware.org (Postfix) with ESMTPS id 4A0B13858D1E for ; Fri, 5 Jan 2024 14:24:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4A0B13858D1E Authentication-Results: sourceware.org; dmarc=fail (p=quarantine dis=none) header.from=westcontrol.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=m.gmane-mx.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 4A0B13858D1E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=116.202.254.214 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704464696; cv=none; b=JYAtV+0jx0L7ttk4xz/OcMEuAPwhw1T4cCuvRzN5c3C3vtv91UmvbTLf+e6cIPFJc+8dkByGm+1OcQwJeGIXewG+BsClO7RwXF6KfqZxYmxzU71VYMBDs4E+rsczObv3w54SGH4irD1HVWUl7AA4uRpiZCwwO9x64odHu33uRQc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704464696; c=relaxed/simple; bh=daKzDdKOPDDnJjEzS15Zo44ngBVHLqLQDX99DJFqdoU=; h=To:From:Subject:Date:Message-ID:Mime-Version; b=E4FnZBvWy2RktlfVMpb4tAhuDA9d1xhDSHdA8GztSa8Sfi7BfBCB9x/jIWA/AEaVZf3B1WCdMAocQH7Xaq89BGJ0S0psSYvrdvFYZBk133gQGnBDvPJSVru2ZKhsPMjbWqcHV7Kw+DpiEc7Ff5YAnzeFTRcayNXxX1un9nH5J/s= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1rLl81-0001By-7J for gcc-help@gcc.gnu.org; Fri, 05 Jan 2024 15:24:53 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gcc-help@gcc.gnu.org From: David Brown Subject: Re: pragma GCC optimize prevents inlining Date: Fri, 5 Jan 2024 15:24:48 +0100 Message-ID: References: <20240104150325.GA19790@gate.crashing.org> <20240104165517.GB19790@gate.crashing.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Content-Language: en-GB In-Reply-To: <20240104165517.GB19790@gate.crashing.org> X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham 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 17:55, Segher Boessenkool wrote: > On Thu, Jan 04, 2024 at 04:24:20PM +0100, David Brown via Gcc-help wrote: >> 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). > > Most things work on function basis; almost nothing works per RTL > instruction. There is no per-instruction representation for -fwrapv > in the RTL stream. > Yes, I appreciate that. And I can also imagine that carrying such option information in the AST to make this possible would be a significant burden, and very rarely of benefit - so unless there is some other important use-case then it is not a good trade-off. > Things are even worse for -O2 vs. -O3 etc. > >> 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. > > Yes, but that is only true for -ffast-math (which means "the user does > not care about correct results" anyway). (Getting a little off-topic... Um, that's not what "-ffast-math" means. It means "the user is using floating point as a close approximation to real number arithmetic, and promises to stick to numerically stable calculations". All my uses of floating point are done with "-ffast-math", and I /do/ care that the results are correct. But the definition of "correct" for my work is "as close to the theoretical real number result as you can get with a limited accuracy format, plus or minus small rounding errors". For other people, full IEEE compliance, support for NaNs, and bit-perfect repeatable results regardless of optimisations and target details, are important for correctness. And that's fine, and it's great that gcc supports both kinds of code - though I believe that "-ffast-math" would actually be more appropriate for a large proportion of programs.) > > You would not typically want random nearby code to use -fwrapv as well, > for example. > No, not normally. (Some people would like C to work that way, but not me!) > > Segher >