From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id BF8C03861013; Thu, 20 Aug 2020 15:39:14 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BF8C03861013 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1597937954; bh=8J+dHOw8mP9A+Cn1Xxr2BNNUFk4m/HnVoK8t1bsr4fA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=tTir7XRYsVvQPm6H/3bbd9e30T3dDVUbH1DX4MWtDjPw9lmVIzWMulEBge/VUiiJl M/m5sVt0scDW6nT3uyLOyQHTEbpUrkVSeLB73z/YFD/iWSxml2fnyo7Y3/s5PZ6WOt +Y72RiMKhP7fh1+8QZaw6D8sBVKaUT+TMPgzm6UA= From: "sgk at troutmask dot apl.washington.edu" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/96711] Internal Compiler Error on NINT() Function Date: Thu, 20 Aug 2020 15:39:14 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 9.3.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: sgk at troutmask dot apl.washington.edu 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: Thu, 20 Aug 2020 15:39:14 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D96711 --- Comment #11 from Steve Kargl = --- On Thu, Aug 20, 2020 at 01:47:58PM +0000, bre08 at eggen dot co.uk wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D96711 >=20 > --- Comment #10 from B Eggen --- > I've been experimenting with the suggested work-around >=20 > m =3D anint(y) >=20 > This works for larger numbers, even in quad precision, however, it breaks= down > a long way before the integer*16 range is exhausted, consider the code be= low, > which starts with 2^113 and tries to double it, minus 1. The minus 1 is = not > taking effect: >=20 Of course, that is going to fail if you want an exact result. REAL(16) is a floating point format, which has 113 digits of precision. This means that integers less than 2**113 are exactly representable as REAL(16) floating point numbers. When you double (2._16)**113 to (2._16)**114, that is a prefectly fine REAL(16) floating point number. Subtracting 1._16 from (2._16)**114 is a valid floating point operation. Your problem lies in that result is rounded, and 1._16 is less than epsilon(1._16) in comparison to (2._16)**114. > I guess at some point NINT() will be fixed, can anyone suggest a robust > workaround that is valid until 2^127-1 ? If you're trying to use floating point arithmetic in computations and you need exact integral values up to 2**127-1, then there isn't a REAL type that works.=20=20 If you're looking for arbitrary precision arithmetic and you want to use Fortran, I suggest that you google "David Bailey arithmetic".=