From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id 2F2723858CD1 for ; Thu, 4 Jan 2024 16:56:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2F2723858CD1 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kernel.crashing.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 2F2723858CD1 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=63.228.1.57 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704387381; cv=none; b=VHpI+IKzxnoifpl9KaKcYAOSHN/HIGg5wFbWEpg4MDiAwAg9zgjfUbsdK2fMuFRvJNI1lGgawJ7FlDVSHIqPNM14iuDeogGPo+Z8O1P12o2Apt9IDh/bjgKxXK+1QNbiRspzkI2+KwWIgOwsKy+5JAOf8XFL0IQOKYM7Z23guQI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704387381; c=relaxed/simple; bh=L23mUqzRoDTojSeeRFAFN8WRbucUQVApmvrR/xKTGXo=; h=Date:From:To:Subject:Message-ID:Mime-Version; b=DVVE0deYQTGo3fl39Bh3+DXT2BEJv/8QIYJk2dH8WD9ttrd0IESkTRcPQp2pljl/p3b3ZwmNSBaj5ogDRWvhN9xWyD7cOl7JLf0XzLIWsFGrw9IN6DArBxYMwckUs9xb6tzvGJXJV9ZpFg1RbQKmWmLN+n4FSDgs0yq2Rx2I5UY= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 404GtIS1001921; Thu, 4 Jan 2024 10:55:18 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 404GtIB8001920; Thu, 4 Jan 2024 10:55:18 -0600 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Thu, 4 Jan 2024 10:55:17 -0600 From: Segher Boessenkool To: David Brown Cc: gcc-help@gcc.gnu.org Subject: Re: pragma GCC optimize prevents inlining Message-ID: <20240104165517.GB19790@gate.crashing.org> References: <20240104150325.GA19790@gate.crashing.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,SPF_HELO_PASS,SPF_PASS,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 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. 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). You would not typically want random nearby code to use -fwrapv as well, for example. Segher