https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640
--- Comment #18 from Steve Kargl <sgk at troutmask dot apl.washington.edu> --- 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=95640 > > --- Comment #17 from Andrew Pinski <pinskia at gcc dot gnu.org> --- > (In reply to Steve Kargl from comment #13) > > With a bit of work, someone could do > > > > Index: gcc/fortran/trans-types.c > > =================================================================== > > --- 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 != TYPE_MODE (float_type_node) > > && (mode != TYPE_MODE (double_type_node)) > > - && (mode != TYPE_MODE (long_double_type_node)) > > + && (!flag_disable_real10 || mode != TYPE_MODE > > (long_double_type_node)) > > #if defined(HAVE_TFmode) && defined(ENABLE_LIBQUADMATH_SUPPORT) > > && (mode != TFmode) > > #endif > > > 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. 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.
