From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 090C1385781A; Tue, 8 Mar 2022 23:17:21 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 090C1385781A From: "vincent-gcc at vinc17 dot net" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/26374] Compile failure on long double Date: Tue, 08 Mar 2022 23:17:21 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Version: 4.1.0 X-Bugzilla-Keywords: rejects-valid X-Bugzilla-Severity: normal X-Bugzilla-Who: vincent-gcc at vinc17 dot net X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2022 23:17:22 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D26374 --- Comment #21 from Vincent Lef=C3=A8vre -= -- (In reply to Jakub Jelinek from comment #16) > As for constant folding, even with double double gcc is able to fold some > constant arithmetics in that format, but because the emulation is only > approximate (it pretends it is 106-bit precision format while in reality = it > is variable precision up to some thousands depending on the exact values). > As has been said elsewhere, the emulation would be implementable if gcc > handled double double in all the arithmetics as a pair of doubles with all > the rules for it. But e.g. mpfr/libmpc isn't able to do something like > that, so we'd need to compute everything with much bigger precision etc. Well, the C standard does not require correct rounding, and while correct rounding is important for the IEEE formats, it is rather useless for the double-double format, whose goal was just to provide more precision than double, but still be rather fast (compared to quad emulation). The main drawback would be that results could be different whether a FP expression is evaluated at run time or at compile time, but unless users seek to control everything (e.g. with IEEE formats), they should get use to that (FYI, you = can have the same kind of issues with the contraction of FP expressions, such as FMA generation from mul-add, which GCC enable by default). So, in short, do= ing the compile-time evaluation at a 106-bit precision or more would be accepta= ble IMHO, at least better than a compiler error. Note: Even though double-double can be very interesting as a compromise bet= ween performance and accuracy, there exist various algorithms and which algorithm should be chosen depends on the context, which only the author of the progr= am can know in general. Thus it was a bad idea to implement double-double as a native FP type (here, long double); instead, the selection of the algorithms should be left to the developer. So the switch to IEEE quad is a good thing. But for how long will old ABIs be around?=