From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id A3887384DED1; Mon, 19 Feb 2024 10:33:00 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A3887384DED1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1708338780; bh=Zj0bLr1jQbKZqxbINZCejuo/r9TeuyCjiQFdFa3X8FQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Jpt+3oYyvBW2VzO3MuO4H5wp+QXpT7xUQmmUbFbrCN6zc+YMG06MfYaFaGHfEWlWo CE8gyAgoYht90hUaDLZadIYtgrJtAx4/PXJrgKJZtTAXtTGQJvmi9cTf8cM58L40rK o6rSMooWn+8fIujV+/yx5v22jaTbLWinGfs6b9Gw= From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/19779] IBM 128bit long double format is not constant folded. Date: Mon, 19 Feb 2024 10:32:59 +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.0.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: enhancement X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D19779 --- Comment #10 from Jakub Jelinek --- (In reply to Iain Sandoe from comment #9) > (In reply to Andrew Pinski from comment #8) > > (In reply to Sergey Fedorov from comment #6) > > > (In reply to Andrew Pinski from comment #0) > > > > This is the new bug for PR 19405. Keeping track of that we no longer > > > > constant fold long doubles in the=20 > > > > IBM 128bit long double format. > > >=20 > > > What is the current status of the issue? > >=20 > > Nothing has changed here that much. Though powerpc64 le is heading towa= rds > > doing IEEE 128bit FP by default so this might be much much less of an i= ssue > > for most people which means this is more likely never get fixed. >=20 > it occasionally causes grief, but so far there's been a work-around; I gu= ess > if someone really wanted to make a patch - they'd have to use MPFR et. al. > to do the work. MPFR won't really help, after all, it doesn't have any double double arithm= etic support at all. The problem is that real.cc pretends that IBM double double is a sane float= ing point format with 106bit precision, which is not the case. In GCC, basic floating point operations are performed by performing stuff in the GCC internal format, which is something with sufficient precision and exponent range to cover all the sane supported formats including some extra precision bits and then converting that to the appropriate mode. That doesn't work for double double, which has precision between 53 to some thousands bits of precision, so in order to emulate in the compiler basic floating point, it would need to be handled like it is actually at runtime, which is hold the REAL_CST/CONST_DOUBLE double double values as a pair of DFmode values rather than a single real_internal_format value (because the latter can't express all the double double values), perform whatever __gcc_qadd/__gcc_qsub/__gcc_qmul/__gcc_qdiv etc. perform at runtime on the DFmode values, etc. And then there is a question what to do about emulatio= n of libm functions - how to map that e.g. to mpfr operations, because what libm actually does for those is sometimes quite weird and hard to define.=