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 9C5603858D20 for ; Fri, 5 Jan 2024 18:20:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9C5603858D20 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 9C5603858D20 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=1704478831; cv=none; b=hOgLfbhJg0UmdMUGfFmvZwYa6XezZ1Itms6kDqRF9cGLycrspn7UF43xO9/o9FGPFDu28a+sulwZke24oe62aSR6kYLrIWDOKn6K9Tv70VpKZe5Q7MjheE36d8t/p/W9yXfSG0TyRaVDveEsG3AS3p2BtxryU7GmtPxbOKY2VJQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704478831; c=relaxed/simple; bh=brziEcRaIUhMG0uklbA8TVr2TRU/f3HnvQ/2Hy6zTvk=; h=Date:From:To:Subject:Message-ID:Mime-Version; b=ehuYhmCdeCpG6hLTwLRa2ziQ9R7n102jcF2rWOX5j0l+PXHuPGqko4kYCkBZ9shr1i/jYIuuhW09CcVtQ1fBk0FIkwYdFZswSg8YxD55lCj9IeBA9U2JHOzX29BjSGa+uYZCQUEFwMq5LCnx4SDnOI4FLSexxeukxyEmbgK4Tc4= 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 405IJR13031395; Fri, 5 Jan 2024 12:19:27 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 405IJR2K031394; Fri, 5 Jan 2024 12:19:27 -0600 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Fri, 5 Jan 2024 12:19:26 -0600 From: Segher Boessenkool To: David Brown Cc: gcc-help@gcc.gnu.org Subject: Re: pragma GCC optimize prevents inlining Message-ID: <20240105181926.GD19790@gate.crashing.org> References: <20240104150325.GA19790@gate.crashing.org> <20240104165517.GB19790@gate.crashing.org> <20240105150051.GC19790@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 Fri, Jan 05, 2024 at 04:53:35PM +0100, David Brown via Gcc-help wrote: > >-ffast-math is allowed to introduce any rounding error it wants. Which > >can (in a loop for example) easily introduce unlimited rounding error, > >bigger than the actual result. And this is not just theoretical either. > > > > Normal maths mode can also lead to rounding errors that can build up - > the fact that rounding is carefully specified with IEEE does not mean > there are no errors (compared to the theoretical perfect real-number > calculation). That's not the point. A program can be perfectly fine, with bounded errors and all, and then -ffast-math will typically completely destroy all that, and replace all arithmetic by the equivalent of a dice roll. That has nothing to do with the fact that all floating point arithmetic is an approximation to real arithmetic (arithmetic on real numbers). The semantics of 754 (or any other standard followed) make it clear what the exact behaviour should be, and -ffast-math tells the compiler to ignore that and do whatever instead. You cannot have reasonable programs that way. > The rounding errors in -ffast-math will be very similar to those in IEEE > mode, for normal numbers. No, not at all. Look at what -fassociative-math does, for example. This can **and does** cause the loss of **all** bits of precision in certain programs. This is not theoretical. This is real. The -ffast-math flag can only reasonably be used with programs that did not want any specific results anyway. It would be even faster (and just as correct!) to always return 0. Segher