From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id AB09938708FF; Sat, 13 Jun 2020 16:19:33 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AB09938708FF DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1592065173; bh=k6pMK6fjXk9jcJ7V9mJhYepNc1uXZ67Ec8lIVD9/j24=; h=From:To:Subject:Date:In-Reply-To:References:From; b=rs9nOAWeogVaOHLGoK5ShKzyXWkoKaOPZxlAcIr1diAi3wMTVhAQ7jPBoAsrvNVp6 dDuyz3O/zctsF67mZCl2ZbETeQk+t8i0rHLzOV1M+xrRgrQVLEdMHLQV9rEWjC7I+H Sl3SQslg6Fg5NfaRi1APCKznEvFi4CHQiXR4F/T0= From: "sgk at troutmask dot apl.washington.edu" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/95640] gfortran ieee_selected_real_kind returns 10 Date: Sat, 13 Jun 2020 16:19:33 +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: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: sgk at troutmask dot apl.washington.edu X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P4 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: Sat, 13 Jun 2020 16:19:33 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D95640 --- Comment #18 from Steve Kargl = --- On Sat, Jun 13, 2020 at 10:14:43AM +0000, pinskia at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D95640 >=20 > --- Comment #17 from Andrew Pinski --- > (In reply to Steve Kargl from comment #13) > > With a bit of work, someone could do > >=20 > > Index: gcc/fortran/trans-types.c > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > --- gcc/fortran/trans-types.c (revision 280157) > > +++ gcc/fortran/trans-types.c (working copy) > > @@ -451,7 +451,7 @@ gfc_init_kinds (void) > > continue; > > if (mode !=3D TYPE_MODE (float_type_node) > > && (mode !=3D TYPE_MODE (double_type_node)) > > - && (mode !=3D TYPE_MODE (long_double_type_node)) > > + && (!flag_disable_real10 || mode !=3D TYPE_MODE > > (long_double_type_node)) > > #if defined(HAVE_TFmode) && defined(ENABLE_LIBQUADMATH_SUPPORT) > > && (mode !=3D TFmode) > > #endif >=20 >=20 > It needs to be more complex than that as long double on most > targets is NOT the 80bit (96bit or 128bit storage) IEEE FP type. Of course, this was just a test to see if it would work. It does not.=20=20 As gfortran's behavior conforms with the Fortran standard, I'm inclined to close the bug report with INVALID. But, I'm leaving it open as someone else might find value in disabling REAL(10). Now, if someone else closes the bug, I won't object.=