[Patch, Fortran] PR 82143: add a -fdefault-real-16 flag

[Patch, Fortran] PR 82143: add a -fdefault-real-16 flag

[Janus Weil]

[-- Attachment #1: Type: text/plain, Size: 1748 bytes --]

Hi all,

attached is a (technically) simple patch that implements the compiler
flag "-fdefault-real-16" for gfortran.

I know that there is some opposition against this, but I am proposing
it anyway, because I do think it is useful after all. My reasoning is
as follows:

1) Despite tons of -freal-X-real-Y flags, there currently is no way to
only promote the default real kind to real(16).
2) Since a variable of default REAL kind does not specify a KIND value
explicitly, it is quite natural for a compiler to control this by
means of flags.
3) gfortran already has -fdefault-real-8 (which is used in lots of
real-world codes AFAIK) and does support quad-precision variables.
4) Other compilers do have flags for this as well (e.g. ifort's
"-real-size 128" etc).
5) I know that it is possible, any maybe cleaner, to declare variables
with explicit kinds instead of relying on compiler flags, but for
large and historically grown codes it is not always straightforward to
do this right away.
6) The patch does not modify the default behavior of gfortran.
7) No one who dislikes such compiler flags is forced to use them.
8) I don't see how this flag can cause any harm. It adds additional
possibilities of using the compiler and thus makes gfortran more
powerful (and more compatible with other compilers).

The patch regtests cleanly on x86_64-linux-gnu. Ok for trunk?

Cheers,
Janus


2017-09-17  Janus Weil  <janus@gcc.gnu.org>

    PR fortran/82143
    * lang.opt: Add the option -fdefault-real-16.
    * invoke.texi: Add documentation for -fdefault-real-16.
    * trans-types.c (gfc_init_kinds): Implement -fdefault-real-16.

2017-09-17  Janus Weil  <janus@gcc.gnu.org>

    PR fortran/82143
    * gfortran.dg/promotion_3.f90: New test case.

[-- Attachment #2: pr82143.diff --]
[-- Type: text/plain, Size: 2884 bytes --]

Index: gcc/fortran/invoke.texi
===================================================================
--- gcc/fortran/invoke.texi	(revision 252892)
+++ gcc/fortran/invoke.texi	(working copy)
@@ -120,7 +120,7 @@ by type.  Explanations are in the following sectio
 -fd-lines-as-comments @gol
 -fdec -fdec-structure -fdec-intrinsic-ints -fdec-static -fdec-math @gol
 -fdefault-double-8 -fdefault-integer-8 @gol
--fdefault-real-8 -fdollar-ok -ffixed-line-length-@var{n} @gol
+-fdefault-real-8 -fdefault-real-16 -fdollar-ok -ffixed-line-length-@var{n} @gol
 -ffixed-line-length-none -ffree-form -ffree-line-length-@var{n} @gol
 -ffree-line-length-none -fimplicit-none -finteger-4-integer-8 @gol
 -fmax-identifier-length -fmodule-private -ffixed-form -fno-range-check @gol
@@ -404,6 +404,14 @@ the default width of @code{DOUBLE PRECISION} to 16
 @code{-fdefault-double-8} is given, too. Unlike @option{-freal-4-real-8},
 it does not promote variables with explicit kind declaration.
 
+@item -fdefault-real-16
+@opindex @code{fdefault-real-16}
+Set the default real type to a 16 byte wide type. This option also affects
+the kind of non-double real constants like @code{1.0}, and does promote
+the default width of @code{DOUBLE PRECISION} to 16 bytes if possible, unless
+@code{-fdefault-double-8} is given. Unlike @option{-freal-4-real-16},
+it does not promote variables with explicit kind declaration.
+
 @item -fdefault-double-8
 @opindex @code{fdefault-double-8}
 Set the @code{DOUBLE PRECISION} type to an 8 byte wide type.  Do nothing if this
Index: gcc/fortran/lang.opt
===================================================================
--- gcc/fortran/lang.opt	(revision 252892)
+++ gcc/fortran/lang.opt	(working copy)
@@ -460,6 +460,10 @@ fdefault-real-8
 Fortran Var(flag_default_real)
 Set the default real kind to an 8 byte wide type.
 
+fdefault-real-16
+Fortran Var(flag_default_real_16)
+Set the default real kind to an 16 byte wide type.
+
 fdollar-ok
 Fortran Var(flag_dollar_ok)
 Allow dollar signs in entity names.
Index: gcc/fortran/trans-types.c
===================================================================
--- gcc/fortran/trans-types.c	(revision 252892)
+++ gcc/fortran/trans-types.c	(working copy)
@@ -538,6 +538,14 @@ gfc_init_kinds (void)
 
       gfc_default_real_kind = 8;
     }
+  else if (flag_default_real_16)
+  {
+    if (!saw_r16)
+      gfc_fatal_error ("REAL(KIND=16) is not available for "
+			"%<-fdefault-real-16%> option");
+
+    gfc_default_real_kind = 16;
+  }
   else if (flag_real4_kind == 8)
   {
     if (!saw_r8)
@@ -577,7 +585,7 @@ gfc_init_kinds (void)
 
   if (flag_default_real && flag_default_double && saw_r8)
     gfc_default_double_kind = 8;
-  else if (flag_default_real && saw_r16)
+  else if ((flag_default_real || flag_default_real_16) && saw_r16)
     gfc_default_double_kind = 16;
   else if (flag_real8_kind == 4)
     {

[-- Attachment #3: promotion_3.f90 --]
[-- Type: text/x-fortran, Size: 387 bytes --]

! { dg-do run }
! { dg-options "-fdefault-real-16" }
!
! PR 82143: add a -fdefault-real-16 flag
!
! Contributed by Janus Weil <janus@gcc.gnu.org>

real :: r
real(kind=4) :: r4
real(kind=8) :: r8
double precision :: d
print *, kind(r4), kind(r8), kind(r), kind(d)
if (kind(r4) /= 4) call abort
if (kind(r8) /= 8) call abort
if (kind(r) /= 16) call abort
if (kind(d) /= 16) call abort
end

Re: [Patch, Fortran] PR 82143: add a -fdefault-real-16 flag

[Steve Kargl]

On Sun, Sep 17, 2017 at 10:42:01PM +0200, Janus Weil wrote:
> 
> attached is a (technically) simple patch that implements the compiler
> flag "-fdefault-real-16" for gfortran.

What about -fdefault-real-10?  If you're going to add bloat to the
compiler, then you might as well to it right.

-- 
Steve
20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4
20161221 https://www.youtube.com/watch?v=IbCHE-hONow

Re: [Patch, Fortran] PR 82143: add a -fdefault-real-16 flag

[Janus Weil]

Hi Steve,

>> attached is a (technically) simple patch that implements the compiler
>> flag "-fdefault-real-16" for gfortran.
>
> What about -fdefault-real-10?  If you're going to add bloat to the
> compiler, then you might as well to it right.

well, yeah. If my only aim was to add bloat to the compiler out of
plain boredom and nastiness, then I might as well add
-fdefault-real-37. But I don't think that would be very useful.

Regarding -fdefault-real-16, in contrast: Yes, I think it's useful. My
motivation for adding it is to enable Real People(tm) in the Real
World(tm) to do Real Work(tm).

To give a few data points that document the need for such a flag
(brought up by a quick web search):
* https://gcc.gnu.org/ml/fortran/2012-01/msg00148.html
* https://glennklockwood.blogspot.de/2014/02/linux-perf-libquadmath-and-gfortrans.html
* https://ndclx4.bnl.gov/gf/project/empire/mailman/?_forum_action=ForumMessageBrowse&thread_id=1318&action=ListThreads&mailman_id=11
* plus my own usage scenarios for this flag

If nothing else, this flag is supposed to make gfortran compile code
that is built with "ifort -real-size 132". Or make it possible to try
quad-precision for codes that use -fdefault-real-8 (of which I think
there are quite a lot out there, whether you like it or not).

Why all the grumpiness, anyway?

Cheers,
Janus

Re: [Patch, Fortran] PR 82143: add a -fdefault-real-16 flag

[Steve Kargl]

On Mon, Sep 18, 2017 at 09:02:22AM +0200, Janus Weil wrote:
> Hi Steve,
> 
> >> attached is a (technically) simple patch that implements the compiler
> >> flag "-fdefault-real-16" for gfortran.
> >
> > What about -fdefault-real-10?  If you're going to add bloat to the
> > compiler, then you might as well to it right.
> 
> well, yeah. If my only aim was to add bloat to the compiler out of
> plain boredom and nastiness, then I might as well add
> -fdefault-real-37. But I don't think that would be very useful.

Why?  One gets 11-bits of additional precision (on most platforms)
and a significant increase in the exponent range (+- ~1024 to
+- ~16384).  REAL(10) maps to hardware floating point, which is
faster than software quad precision.

-- 
Steve
20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4
20161221 https://www.youtube.com/watch?v=IbCHE-hONow

Re: [Patch, Fortran] PR 82143: add a -fdefault-real-16 flag

[Janus Weil]

2017-09-18 16:08 GMT+02:00 Steve Kargl <sgk@troutmask.apl.washington.edu>:
> On Mon, Sep 18, 2017 at 09:02:22AM +0200, Janus Weil wrote:
>> Hi Steve,
>>
>> >> attached is a (technically) simple patch that implements the compiler
>> >> flag "-fdefault-real-16" for gfortran.
>> >
>> > What about -fdefault-real-10?  If you're going to add bloat to the
>> > compiler, then you might as well to it right.
>>
>> well, yeah. If my only aim was to add bloat to the compiler out of
>> plain boredom and nastiness, then I might as well add
>> -fdefault-real-37. But I don't think that would be very useful.
>
> Why?  One gets 11-bits of additional precision (on most platforms)
> and a significant increase in the exponent range (+- ~1024 to
> +- ~16384).  REAL(10) maps to hardware floating point, which is
> faster than software quad precision.

Well, ok. If adding -fdefault-real-10 was a serious suggestion from
your side (which was not so easy to tell through all the sarcasm), I
can surely add that as well.

Cheers,
Janus

Re: [Patch, Fortran] PR 82143: add a -fdefault-real-16 flag

[Janus Weil]

[-- Attachment #1: Type: text/plain, Size: 1641 bytes --]

Attached is an updated patch, where I'm adding -fdefault-real-10
according to Steve's suggestion. As with -fdefault-real-8 and
-fdefault-real-16, I'm choosing to set the double kind to 16 in this
case. Also I'm renaming flag_default_real to flag_default_real_8 (for
symmetry reasons and to make the code more readable). Finally I'm
removing the restriction that -fdefault-double-8 must occur together
with -fdefault-real-8. It may be useful on its own and should be
combinable with the new flags.

Ok for trunk?

Cheers,
Janus



2017-09-18 19:57 GMT+02:00 Janus Weil <janus@gcc.gnu.org>:
> 2017-09-18 16:08 GMT+02:00 Steve Kargl <sgk@troutmask.apl.washington.edu>:
>> On Mon, Sep 18, 2017 at 09:02:22AM +0200, Janus Weil wrote:
>>> Hi Steve,
>>>
>>> >> attached is a (technically) simple patch that implements the compiler
>>> >> flag "-fdefault-real-16" for gfortran.
>>> >
>>> > What about -fdefault-real-10?  If you're going to add bloat to the
>>> > compiler, then you might as well to it right.
>>>
>>> well, yeah. If my only aim was to add bloat to the compiler out of
>>> plain boredom and nastiness, then I might as well add
>>> -fdefault-real-37. But I don't think that would be very useful.
>>
>> Why?  One gets 11-bits of additional precision (on most platforms)
>> and a significant increase in the exponent range (+- ~1024 to
>> +- ~16384).  REAL(10) maps to hardware floating point, which is
>> faster than software quad precision.
>
> Well, ok. If adding -fdefault-real-10 was a serious suggestion from
> your side (which was not so easy to tell through all the sarcasm), I
> can surely add that as well.
>
> Cheers,
> Janus

[-- Attachment #2: pr82143_v2.diff --]
[-- Type: text/plain, Size: 5529 bytes --]

Index: gcc/fortran/invoke.texi
===================================================================
--- gcc/fortran/invoke.texi	(revision 252892)
+++ gcc/fortran/invoke.texi	(working copy)
@@ -119,8 +119,8 @@ by type.  Explanations are in the following sectio
 @gccoptlist{-fall-intrinsics -fbackslash -fcray-pointer -fd-lines-as-code @gol
 -fd-lines-as-comments @gol
 -fdec -fdec-structure -fdec-intrinsic-ints -fdec-static -fdec-math @gol
--fdefault-double-8 -fdefault-integer-8 @gol
--fdefault-real-8 -fdollar-ok -ffixed-line-length-@var{n} @gol
+-fdefault-double-8 -fdefault-integer-8 -fdefault-real-8 @gol
+-fdefault-real-10 -fdefault-real-16 -fdollar-ok -ffixed-line-length-@var{n} @gol
 -ffixed-line-length-none -ffree-form -ffree-line-length-@var{n} @gol
 -ffree-line-length-none -fimplicit-none -finteger-4-integer-8 @gol
 -fmax-identifier-length -fmodule-private -ffixed-form -fno-range-check @gol
@@ -404,6 +404,22 @@ the default width of @code{DOUBLE PRECISION} to 16
 @code{-fdefault-double-8} is given, too. Unlike @option{-freal-4-real-8},
 it does not promote variables with explicit kind declaration.
 
+@item -fdefault-real-10
+@opindex @code{fdefault-real-10}
+Set the default real type to a 10 byte wide type. This option also affects
+the kind of non-double real constants like @code{1.0}, and does promote
+the default width of @code{DOUBLE PRECISION} to 16 bytes if possible, unless
+@code{-fdefault-double-8} is given. Unlike @option{-freal-4-real-10},
+it does not promote variables with explicit kind declaration.
+
+@item -fdefault-real-16
+@opindex @code{fdefault-real-16}
+Set the default real type to a 16 byte wide type. This option also affects
+the kind of non-double real constants like @code{1.0}, and does promote
+the default width of @code{DOUBLE PRECISION} to 16 bytes if possible, unless
+@code{-fdefault-double-8} is given. Unlike @option{-freal-4-real-16},
+it does not promote variables with explicit kind declaration.
+
 @item -fdefault-double-8
 @opindex @code{fdefault-double-8}
 Set the @code{DOUBLE PRECISION} type to an 8 byte wide type.  Do nothing if this
Index: gcc/fortran/lang.opt
===================================================================
--- gcc/fortran/lang.opt	(revision 252892)
+++ gcc/fortran/lang.opt	(working copy)
@@ -457,9 +457,17 @@ Fortran Var(flag_default_integer)
 Set the default integer kind to an 8 byte wide type.
 
 fdefault-real-8
-Fortran Var(flag_default_real)
+Fortran Var(flag_default_real_8)
 Set the default real kind to an 8 byte wide type.
 
+fdefault-real-10
+Fortran Var(flag_default_real_10)
+Set the default real kind to an 10 byte wide type.
+
+fdefault-real-16
+Fortran Var(flag_default_real_16)
+Set the default real kind to an 16 byte wide type.
+
 fdollar-ok
 Fortran Var(flag_dollar_ok)
 Allow dollar signs in entity names.
Index: gcc/fortran/module.c
===================================================================
--- gcc/fortran/module.c	(revision 252892)
+++ gcc/fortran/module.c	(working copy)
@@ -6741,7 +6741,7 @@ use_iso_fortran_env_module (void)
 				   "standard", symbol[i].name, &u->where))
 	        continue;
 
-	      if ((flag_default_integer || flag_default_real)
+	      if ((flag_default_integer || flag_default_real_8)
 		  && symbol[i].id == ISOFORTRANENV_NUMERIC_STORAGE_SIZE)
 		gfc_warning_now (0, "Use of the NUMERIC_STORAGE_SIZE named "
 				 "constant from intrinsic module "
@@ -6808,7 +6808,7 @@ use_iso_fortran_env_module (void)
 	  if ((gfc_option.allow_std & symbol[i].standard) == 0)
 	    continue;
 
-	  if ((flag_default_integer || flag_default_real)
+	  if ((flag_default_integer || flag_default_real_8)
 	      && symbol[i].id == ISOFORTRANENV_NUMERIC_STORAGE_SIZE)
 	    gfc_warning_now (0,
 			     "Use of the NUMERIC_STORAGE_SIZE named constant "
Index: gcc/fortran/trans-types.c
===================================================================
--- gcc/fortran/trans-types.c	(revision 252892)
+++ gcc/fortran/trans-types.c	(working copy)
@@ -530,7 +530,7 @@ gfc_init_kinds (void)
     }
 
   /* Choose the default real kind.  Again, we choose 4 when possible.  */
-  if (flag_default_real)
+  if (flag_default_real_8)
     {
       if (!saw_r8)
 	gfc_fatal_error ("REAL(KIND=8) is not available for "
@@ -538,6 +538,22 @@ gfc_init_kinds (void)
 
       gfc_default_real_kind = 8;
     }
+  else if (flag_default_real_10)
+  {
+    if (!saw_r10)
+      gfc_fatal_error ("REAL(KIND=10) is not available for "
+			"%<-fdefault-real-10%> option");
+
+    gfc_default_real_kind = 10;
+  }
+  else if (flag_default_real_16)
+  {
+    if (!saw_r16)
+      gfc_fatal_error ("REAL(KIND=16) is not available for "
+			"%<-fdefault-real-16%> option");
+
+    gfc_default_real_kind = 16;
+  }
   else if (flag_real4_kind == 8)
   {
     if (!saw_r8)
@@ -571,13 +587,10 @@ gfc_init_kinds (void)
      are specified, we use kind=8, if it's available.  If -fdefault-real is
      specified without -fdefault-double, we use kind=16, if it's available.
      Otherwise we do not change anything.  */
-  if (flag_default_double && !flag_default_real)
-    gfc_fatal_error ("Use of %<-fdefault-double-8%> requires "
-		     "%<-fdefault-real-8%>");
-
-  if (flag_default_real && flag_default_double && saw_r8)
+  if (flag_default_double && saw_r8)
     gfc_default_double_kind = 8;
-  else if (flag_default_real && saw_r16)
+  else if ((flag_default_real_8 || flag_default_real_10 || flag_default_real_16)
+	   && saw_r16)
     gfc_default_double_kind = 16;
   else if (flag_real8_kind == 4)
     {

Re: [Patch, Fortran] PR 82143: add a -fdefault-real-16 flag

[Steve Kargl]

On Thu, Sep 21, 2017 at 09:10:42AM +0200, Janus Weil wrote:
> Attached is an updated patch, where I'm adding -fdefault-real-10
> according to Steve's suggestion. As with -fdefault-real-8 and
> -fdefault-real-16, I'm choosing to set the double kind to 16 in this
> case. Also I'm renaming flag_default_real to flag_default_real_8 (for
> symmetry reasons and to make the code more readable). Finally I'm
> removing the restriction that -fdefault-double-8 must occur together
> with -fdefault-real-8. It may be useful on its own and should be
> combinable with the new flags.
> 
> Ok for trunk?
> 

Although I would prefer these options to be deprecated,
I did read the patch and it appears to be correct.  So,
I suppose it's ok for trunk.

-- 
Steve
20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4
20161221 https://www.youtube.com/watch?v=IbCHE-hONow

Re: [Patch, Fortran] PR 82143: add a -fdefault-real-16 flag

[Janus Weil]

[-- Attachment #1: Type: text/plain, Size: 1787 bytes --]

2017-09-21 22:38 GMT+02:00 Steve Kargl <sgk@troutmask.apl.washington.edu>:
> On Thu, Sep 21, 2017 at 09:10:42AM +0200, Janus Weil wrote:
>> Attached is an updated patch, where I'm adding -fdefault-real-10
>> according to Steve's suggestion. As with -fdefault-real-8 and
>> -fdefault-real-16, I'm choosing to set the double kind to 16 in this
>> case. Also I'm renaming flag_default_real to flag_default_real_8 (for
>> symmetry reasons and to make the code more readable). Finally I'm
>> removing the restriction that -fdefault-double-8 must occur together
>> with -fdefault-real-8. It may be useful on its own and should be
>> combinable with the new flags.
>>
>> Ok for trunk?
>>
>
> Although I would prefer these options to be deprecated,
> I did read the patch and it appears to be correct.  So,
> I suppose it's ok for trunk.

Thanks, Steve. I'm attaching the updated ChangeLog and the two test
cases for the two new flags. Since this appears to be  a somewhat
controversial feature, I'll wait two more days to allow for others to
contribute their feedback (positive or negative). I'll commit on
Sunday if I hear nothing until then.

Cheers,
Janus

2017-09-22  Janus Weil  <janus@gcc.gnu.org>

    PR fortran/82143
    * lang.opt: Add the options -fdefault-real-10 and -fdefault-real-16.
    Rename flag_default_real to flag_default_real_8.
    * invoke.texi: Add documentation.
    * module.c (use_iso_fortran_env_module): flag_default_real is renamed.
    * trans-types.c (gfc_init_kinds): Implement the flags
    -fdefault-real-10 and -fdefault-real-16. Make -fdefault-double-8 work
    without -fdefault-real-8.

2017-09-22  Janus Weil  <janus@gcc.gnu.org>

    PR fortran/82143
    * gfortran.dg/promotion_3.f90: New test case.
    * gfortran.dg/promotion_4.f90: New test case.

[-- Attachment #2: promotion_3.f90 --]
[-- Type: text/x-fortran, Size: 341 bytes --]

! { dg-do run }
! { dg-options "-fdefault-real-16" }
!
! PR 82143: add a -fdefault-real-16 flag
!
! Contributed by Janus Weil <janus@gcc.gnu.org>

real :: r
real(kind=4) :: r4
real(kind=8) :: r8
double precision :: d
if (kind(r4) /= 4) call abort
if (kind(r8) /= 8) call abort
if (kind(r) /= 16) call abort
if (kind(d) /= 16) call abort
end

[-- Attachment #3: promotion_4.f90 --]
[-- Type: text/x-fortran, Size: 341 bytes --]

! { dg-do run }
! { dg-options "-fdefault-real-10" }
!
! PR 82143: add a -fdefault-real-16 flag
!
! Contributed by Janus Weil <janus@gcc.gnu.org>

real :: r
real(kind=4) :: r4
real(kind=8) :: r8
double precision :: d
if (kind(r4) /= 4) call abort
if (kind(r8) /= 8) call abort
if (kind(r) /= 10) call abort
if (kind(d) /= 16) call abort
end

Re: [Patch, Fortran] PR 82143: add a -fdefault-real-16 flag

[Janne Blomqvist]

On Fri, Sep 22, 2017 at 8:02 AM, Janus Weil <janus@gcc.gnu.org> wrote:
> Thanks, Steve. I'm attaching the updated ChangeLog and the two test
> cases for the two new flags. Since this appears to be  a somewhat
> controversial feature, I'll wait two more days to allow for others to
> contribute their feedback (positive or negative). I'll commit on
> Sunday if I hear nothing until then.

Well, if you're actively soliciting bikeshedding, here goes:

Since we're about to have several -fdefault-real-N flags, would it
make sense to instead make a single flag -fdefault-real=SOMEVALUE (and
for backwards compatibility, make -fdefault-real-8 an alias for
-fdefault-real=8)? And similarly for -fdefault-double=.

And since the standard requires that double precision variables are
twice as big as reals, in the absence of an explicit -fdefault-double=
flag, would it make sense to have -fdefault-real=N imply
-fdefault-double=[2*N or if that isn't supported on the target, the
largest supported real kind]? (This is sort-of an extension of the
current -fdefault-real-8 behavior)


-- 
Janne Blomqvist

Re: [Patch, Fortran] PR 82143: add a -fdefault-real-16 flag

[Janus Weil]

2017-09-22 9:11 GMT+02:00 Janne Blomqvist <blomqvist.janne@gmail.com>:
> On Fri, Sep 22, 2017 at 8:02 AM, Janus Weil <janus@gcc.gnu.org> wrote:
>> Thanks, Steve. I'm attaching the updated ChangeLog and the two test
>> cases for the two new flags. Since this appears to be  a somewhat
>> controversial feature, I'll wait two more days to allow for others to
>> contribute their feedback (positive or negative). I'll commit on
>> Sunday if I hear nothing until then.
>
> Well, if you're actively soliciting bikeshedding, here goes:

I'm not soliciting anything. I'm giving people a fair chance to
comment. What you make out of that is completely up to you.


> Since we're about to have several -fdefault-real-N flags, would it
> make sense to instead make a single flag -fdefault-real=SOMEVALUE

I don't think that's a good idea, for several reasons:

1) We're probably not going to have much more N values (adding a
single one is tough enough of a job apparently, plus the list of
supported real kinds is very much limited anyway).

2) The syntax you're proposing is inconsistent with other flags like
-fdefault-integer-8, -fdefault-double-8. I'm sure we don't want to
change all of them.

3) That kind of syntax is not even used in other flags like
-ffree-line-length-n, where the range of possible values is
potentially much larger.



> And since the standard requires that double precision variables are
> twice as big as reals, in the absence of an explicit -fdefault-double=
> flag, would it make sense to have -fdefault-real=N imply
> -fdefault-double=[2*N or if that isn't supported on the target, the
> largest supported real kind]?

That's basically the behavior I tried to implement in my current patch
(although I notice now that you're not necessarily getting the largest
real kind, if 16 is not supported).

Cheers,
Janus

Re: [Patch, Fortran] PR 82143: add a -fdefault-real-16 flag

[Steve Kargl]

On Fri, Sep 22, 2017 at 10:11:55AM +0300, Janne Blomqvist wrote:
> On Fri, Sep 22, 2017 at 8:02 AM, Janus Weil <janus@gcc.gnu.org> wrote:
> > Thanks, Steve. I'm attaching the updated ChangeLog and the two test
> > cases for the two new flags. Since this appears to be  a somewhat
> > controversial feature, I'll wait two more days to allow for others to
> > contribute their feedback (positive or negative). I'll commit on
> > Sunday if I hear nothing until then.
> 
> Well, if you're actively soliciting bikeshedding, here goes:
> 
> Since we're about to have several -fdefault-real-N flags, would it
> make sense to instead make a single flag -fdefault-real=SOMEVALUE (and
> for backwards compatibility, make -fdefault-real-8 an alias for
> -fdefault-real=8)? And similarly for -fdefault-double=.
> 
> And since the standard requires that double precision variables are
> twice as big as reals, in the absence of an explicit -fdefault-double=
> flag, would it make sense to have -fdefault-real=N imply
> -fdefault-double=[2*N or if that isn't supported on the target, the
> largest supported real kind]? (This is sort-of an extension of the
> current -fdefault-real-8 behavior)

The standard requires more than just double precision being twice
as big as default real.  Among other things, storage association
rules require default logical, integer, and real to all occupy
the same number of storage units.  The promotion of DOUBLE
PRECISION to REAL(16), if available, was my misguided attempt to
enforce storage assocation.  That is the essenses of why I think
these options should go away.

But, I understand Janus's position that -fdefault-real-16 allows
a developer to quickly test whether an algorithm works and/or is
stable at higher precision.  The unfortunate side-effect is that
a developer finds that the result of the option appears to work,
so the developer never reviews the actual code.  It is not uncommon
to find old code of the form

       REAL EPS, NEW, OLD
       PARAMETER(EPS=1.E-8)
       ...
C      TEST FOR CONVERGENCE
       IF (ABS(NEW-OLD).LT.EPS) THEN

Is the convergence criteria still correct for -fdefault-real-16?
Only a developer reviewing and properly porting the code to a 
higher precision can make that decision.

-- 
Steve
20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4
20161221 https://www.youtube.com/watch?v=IbCHE-hONow

Re: [Patch, Fortran] PR 82143: add a -fdefault-real-16 flag

[Janus Weil]

[-- Attachment #1: Type: text/plain, Size: 776 bytes --]

2017-09-22 11:44 GMT+02:00 Janus Weil <janus@gcc.gnu.org>:
> 2017-09-22 9:11 GMT+02:00 Janne Blomqvist <blomqvist.janne@gmail.com>:
>> And since the standard requires that double precision variables are
>> twice as big as reals, in the absence of an explicit -fdefault-double=
>> flag, would it make sense to have -fdefault-real=N imply
>> -fdefault-double=[2*N or if that isn't supported on the target, the
>> largest supported real kind]?
>
> That's basically the behavior I tried to implement in my current patch
> (although I notice now that you're not necessarily getting the largest
> real kind, if 16 is not supported).

Attached is a new version of the patch, which improves this point. In
the absence of further comments, I'll commit this by tomorrow.

Cheers,
Janus

[-- Attachment #2: pr82143_v3.diff --]
[-- Type: text/plain, Size: 7038 bytes --]

Index: gcc/fortran/invoke.texi
===================================================================
--- gcc/fortran/invoke.texi	(revision 253108)
+++ gcc/fortran/invoke.texi	(working copy)
@@ -119,8 +119,8 @@ by type.  Explanations are in the following sectio
 @gccoptlist{-fall-intrinsics -fbackslash -fcray-pointer -fd-lines-as-code @gol
 -fd-lines-as-comments @gol
 -fdec -fdec-structure -fdec-intrinsic-ints -fdec-static -fdec-math @gol
--fdefault-double-8 -fdefault-integer-8 @gol
--fdefault-real-8 -fdollar-ok -ffixed-line-length-@var{n} @gol
+-fdefault-double-8 -fdefault-integer-8 -fdefault-real-8 @gol
+-fdefault-real-10 -fdefault-real-16 -fdollar-ok -ffixed-line-length-@var{n} @gol
 -ffixed-line-length-none -ffree-form -ffree-line-length-@var{n} @gol
 -ffree-line-length-none -fimplicit-none -finteger-4-integer-8 @gol
 -fmax-identifier-length -fmodule-private -ffixed-form -fno-range-check @gol
@@ -404,6 +404,22 @@ the default width of @code{DOUBLE PRECISION} to 16
 @code{-fdefault-double-8} is given, too. Unlike @option{-freal-4-real-8},
 it does not promote variables with explicit kind declaration.
 
+@item -fdefault-real-10
+@opindex @code{fdefault-real-10}
+Set the default real type to a 10 byte wide type. This option also affects
+the kind of non-double real constants like @code{1.0}, and does promote
+the default width of @code{DOUBLE PRECISION} to 16 bytes if possible, unless
+@code{-fdefault-double-8} is given. Unlike @option{-freal-4-real-10},
+it does not promote variables with explicit kind declaration.
+
+@item -fdefault-real-16
+@opindex @code{fdefault-real-16}
+Set the default real type to a 16 byte wide type. This option also affects
+the kind of non-double real constants like @code{1.0}, and does promote
+the default width of @code{DOUBLE PRECISION} to 16 bytes if possible, unless
+@code{-fdefault-double-8} is given. Unlike @option{-freal-4-real-16},
+it does not promote variables with explicit kind declaration.
+
 @item -fdefault-double-8
 @opindex @code{fdefault-double-8}
 Set the @code{DOUBLE PRECISION} type to an 8 byte wide type.  Do nothing if this
Index: gcc/fortran/lang.opt
===================================================================
--- gcc/fortran/lang.opt	(revision 253108)
+++ gcc/fortran/lang.opt	(working copy)
@@ -457,9 +457,17 @@ Fortran Var(flag_default_integer)
 Set the default integer kind to an 8 byte wide type.
 
 fdefault-real-8
-Fortran Var(flag_default_real)
+Fortran Var(flag_default_real_8)
 Set the default real kind to an 8 byte wide type.
 
+fdefault-real-10
+Fortran Var(flag_default_real_10)
+Set the default real kind to an 10 byte wide type.
+
+fdefault-real-16
+Fortran Var(flag_default_real_16)
+Set the default real kind to an 16 byte wide type.
+
 fdollar-ok
 Fortran Var(flag_dollar_ok)
 Allow dollar signs in entity names.
Index: gcc/fortran/module.c
===================================================================
--- gcc/fortran/module.c	(revision 253108)
+++ gcc/fortran/module.c	(working copy)
@@ -6741,7 +6741,7 @@ use_iso_fortran_env_module (void)
 				   "standard", symbol[i].name, &u->where))
 	        continue;
 
-	      if ((flag_default_integer || flag_default_real)
+	      if ((flag_default_integer || flag_default_real_8)
 		  && symbol[i].id == ISOFORTRANENV_NUMERIC_STORAGE_SIZE)
 		gfc_warning_now (0, "Use of the NUMERIC_STORAGE_SIZE named "
 				 "constant from intrinsic module "
@@ -6808,7 +6808,7 @@ use_iso_fortran_env_module (void)
 	  if ((gfc_option.allow_std & symbol[i].standard) == 0)
 	    continue;
 
-	  if ((flag_default_integer || flag_default_real)
+	  if ((flag_default_integer || flag_default_real_8)
 	      && symbol[i].id == ISOFORTRANENV_NUMERIC_STORAGE_SIZE)
 	    gfc_warning_now (0,
 			     "Use of the NUMERIC_STORAGE_SIZE named constant "
Index: gcc/fortran/trans-types.c
===================================================================
--- gcc/fortran/trans-types.c	(revision 253108)
+++ gcc/fortran/trans-types.c	(working copy)
@@ -530,7 +530,7 @@ gfc_init_kinds (void)
     }
 
   /* Choose the default real kind.  Again, we choose 4 when possible.  */
-  if (flag_default_real)
+  if (flag_default_real_8)
     {
       if (!saw_r8)
 	gfc_fatal_error ("REAL(KIND=8) is not available for "
@@ -538,6 +538,22 @@ gfc_init_kinds (void)
 
       gfc_default_real_kind = 8;
     }
+  else if (flag_default_real_10)
+  {
+    if (!saw_r10)
+      gfc_fatal_error ("REAL(KIND=10) is not available for "
+			"%<-fdefault-real-10%> option");
+
+    gfc_default_real_kind = 10;
+  }
+  else if (flag_default_real_16)
+  {
+    if (!saw_r16)
+      gfc_fatal_error ("REAL(KIND=16) is not available for "
+			"%<-fdefault-real-16%> option");
+
+    gfc_default_real_kind = 16;
+  }
   else if (flag_real4_kind == 8)
   {
     if (!saw_r8)
@@ -571,14 +587,20 @@ gfc_init_kinds (void)
      are specified, we use kind=8, if it's available.  If -fdefault-real is
      specified without -fdefault-double, we use kind=16, if it's available.
      Otherwise we do not change anything.  */
-  if (flag_default_double && !flag_default_real)
-    gfc_fatal_error ("Use of %<-fdefault-double-8%> requires "
-		     "%<-fdefault-real-8%>");
-
-  if (flag_default_real && flag_default_double && saw_r8)
+  if (flag_default_double && saw_r8)
     gfc_default_double_kind = 8;
-  else if (flag_default_real && saw_r16)
-    gfc_default_double_kind = 16;
+  else if (flag_default_real_8 || flag_default_real_10 || flag_default_real_16)
+    {
+      /* Use largest available kind.  */
+      if (saw_r16)
+	gfc_default_double_kind = 16;
+      else if (saw_r10)
+	gfc_default_double_kind = 10;
+      else if (saw_r8)
+	gfc_default_double_kind = 8;
+      else
+	gfc_default_double_kind = gfc_default_real_kind;
+    }
   else if (flag_real8_kind == 4)
     {
       if (!saw_r4)
Index: gcc/testsuite/gfortran.dg/promotion_3.f90
===================================================================
--- gcc/testsuite/gfortran.dg/promotion_3.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/promotion_3.f90	(working copy)
@@ -0,0 +1,16 @@
+! { dg-do run }
+! { dg-options "-fdefault-real-16" }
+!
+! PR 82143: add a -fdefault-real-16 flag
+!
+! Contributed by Janus Weil <janus@gcc.gnu.org>
+
+real :: r
+real(kind=4) :: r4
+real(kind=8) :: r8
+double precision :: d
+if (kind(r4) /= 4) call abort
+if (kind(r8) /= 8) call abort
+if (kind(r) /= 16) call abort
+if (kind(d) /= 16) call abort
+end
Index: gcc/testsuite/gfortran.dg/promotion_4.f90
===================================================================
--- gcc/testsuite/gfortran.dg/promotion_4.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/promotion_4.f90	(working copy)
@@ -0,0 +1,16 @@
+! { dg-do run }
+! { dg-options "-fdefault-real-10" }
+!
+! PR 82143: add a -fdefault-real-16 flag
+!
+! Contributed by Janus Weil <janus@gcc.gnu.org>
+
+real :: r
+real(kind=4) :: r4
+real(kind=8) :: r8
+double precision :: d
+if (kind(r4) /= 4) call abort
+if (kind(r8) /= 8) call abort
+if (kind(r) /= 10) call abort
+if (kind(d) /= 16) call abort
+end

Re: [Patch, Fortran] PR 82143: add a -fdefault-real-16 flag

[Janus Weil]

2017-09-22 21:32 GMT+02:00 Janus Weil <janus@gcc.gnu.org>:
> 2017-09-22 11:44 GMT+02:00 Janus Weil <janus@gcc.gnu.org>:
>> 2017-09-22 9:11 GMT+02:00 Janne Blomqvist <blomqvist.janne@gmail.com>:
>>> And since the standard requires that double precision variables are
>>> twice as big as reals, in the absence of an explicit -fdefault-double=
>>> flag, would it make sense to have -fdefault-real=N imply
>>> -fdefault-double=[2*N or if that isn't supported on the target, the
>>> largest supported real kind]?
>>
>> That's basically the behavior I tried to implement in my current patch
>> (although I notice now that you're not necessarily getting the largest
>> real kind, if 16 is not supported).
>
> Attached is a new version of the patch, which improves this point. In
> the absence of further comments, I'll commit this by tomorrow.

Landed on trunk as r253117.

Cheers,
Janus

Re: [Patch, Fortran] PR 82143: add a -fdefault-real-16 flag

[Gerald Pfeifer]

Hi Dominique, hi Fortran developers,

somehow I had flagged this for "later response", and that became
really quite a bit later.

On Mon, 18 Sep 2017, Janus Weil wrote:
>> (2) I think your time would be better used by dealing with your 
>> assigned PRs.
> I think I can very well decide for myself where to waste my spare
> time. There were actually times when I enjoyed contributing to
> gfortran and reading this list very much, but recently it's really
> becoming a PITA and I feel like I could spend my time on much nicer
> things ...

This is really a bit of a concern.  Many of us (including myself) 
are volunteers, and carving out time and priority for GCC is not 
always easy.  And that creates pressure that we tend to put on 
ourselves.  (I certainly feel that myself.)

Let's make sure we do not reflect that on others, be they volunteers
or not.  That would not be fair, nor would it be helpful.

I hope this makes sense?

Gerald

Re: [Patch, Fortran] PR 82143: add a -fdefault-real-16 flag

[David Edelsohn]

On Tue, Sep 26, 2017 at 4:44 AM, Janus Weil <janus@gcc.gnu.org> wrote:
> 2017-09-25 23:23 GMT+02:00 Steve Kargl <sgk@troutmask.apl.washington.edu>:
>> On Mon, Sep 25, 2017 at 11:14:42PM +0200, Janus Weil wrote:
>>> 2017-09-25 17:07 GMT+02:00 David Edelsohn <dje.gcc@gmail.com>:
>>> > promotion_3.f90 and promotion_4.f90 are failing on at least PowerPC
>>> > and AArch64.  Are these new tests limited to x86 or some long double
>>> > assumptions?
>>>
>>> These tests require the availability of  a 10- or 16-byte-wide REAL
>>> type, respectively. I have to admit that I do not have a complete
>>> overview of which targets in GCC's wide portfolio provide such a type.
>>>
>>> It seems that REAL(16) is supported via libquadmath on 32-bit x86,
>>> x86-64 and Itanium at least. I'm not sure about REAL(10).
>>>
>>> Targets that do not support such a type probably need to be XFAILed.
>>>
>>
>> Janus, I think you can control with a dg option
>>
>> dg-require-effective-target fortran_large_real
>>
>> See, for example, gfortran.dg/random_3.f90
>
> Thanks for the pointer, Steve.
>
> However, it seems that "fortran_large_real" only requires some real
> type that is larger than 8 byte, but makes no assumptions on its
> actual size (10 or 16 byte). Therefore it's probably not very useful
> for promotion_{3,4}.
>
> But: I found that there's also a "fortran_real_16", which should be
> suitable for promotion_3. Can someone verify if the following fixes
> the problem on the failing targets:
>
> Index: promotion_3.f90
> ===================================================================
> --- promotion_3.f90    (revision 253134)
> +++ promotion_3.f90    (working copy)
> @@ -1,5 +1,6 @@
>  ! { dg-do run }
>  ! { dg-options "-fdefault-real-16" }
> +! { dg-require-effective-target fortran_real_16 }
>  !
>  ! PR 82143: add a -fdefault-real-16 flag
>  !
>
>
> If it does, I'll be happy to commit that. For promotion_4, we probably
> need to add an effective target "fortran_real_10" (which does not seem
> to exists yet).

Testing fortran_real_16 fixes promotion_3.f90 on AIX.  I expect that
the new dg test will work for promotion_4.f90.

Thanks, David

Re: [Patch, Fortran] PR 82143: add a -fdefault-real-16 flag

[Janus Weil]

[-- Attachment #1: Type: text/plain, Size: 735 bytes --]

Hi Rainer,

>> Attached is a more complete patch, which should fix all problems that
>> were reported concerning these two test cases. Would be great if
>> someone could confirm that it works on a failing target (I currently
>> only have access to x86_64-linux-gnu machines).
>
> I've just checked sparc-sun-solaris2.11: works fine.  promotion_3.f90
> PASSes as before, but promotion_4.f90 is now UNSUPPORTED instead of
> failing.

thanks for checking!


>> Ok for trunk?
>
> The new fortran_real_10 effective-target keyword needs documenting in
> sourcebuild.texi.

Good point. fortran_real_16 was missing there as well. Added both (new
patch attached).

I'll commit this tonight, unless there are further comments ...

Cheers,
Janus

[-- Attachment #2: pr82324_v2.diff --]
[-- Type: text/plain, Size: 2475 bytes --]

Index: gcc/doc/sourcebuild.texi
===================================================================
--- gcc/doc/sourcebuild.texi	(revision 253134)
+++ gcc/doc/sourcebuild.texi	(working copy)
@@ -1357,6 +1357,12 @@ Target has runtime support for any options added w
 @item fortran_integer_16
 Target supports Fortran @code{integer} that is 16 bytes or longer.
 
+@item fortran_real_10
+Target supports Fortran @code{real} that is 10 bytes or longer.
+
+@item fortran_real_16
+Target supports Fortran @code{real} that is 16 bytes or longer.
+
 @item fortran_large_int
 Target supports Fortran @code{integer} kinds larger than @code{integer(8)}.
 
Index: gcc/testsuite/gfortran.dg/promotion_3.f90
===================================================================
--- gcc/testsuite/gfortran.dg/promotion_3.f90	(revision 253134)
+++ gcc/testsuite/gfortran.dg/promotion_3.f90	(working copy)
@@ -1,5 +1,6 @@
 ! { dg-do run }
 ! { dg-options "-fdefault-real-16" }
+! { dg-require-effective-target fortran_real_16 }
 !
 ! PR 82143: add a -fdefault-real-16 flag
 !
Index: gcc/testsuite/gfortran.dg/promotion_4.f90
===================================================================
--- gcc/testsuite/gfortran.dg/promotion_4.f90	(revision 253134)
+++ gcc/testsuite/gfortran.dg/promotion_4.f90	(working copy)
@@ -1,5 +1,6 @@
 ! { dg-do run }
 ! { dg-options "-fdefault-real-10" }
+! { dg-require-effective-target fortran_real_10 }
 !
 ! PR 82143: add a -fdefault-real-16 flag
 !
@@ -12,5 +13,5 @@ double precision :: d
 if (kind(r4) /= 4) call abort
 if (kind(r8) /= 8) call abort
 if (kind(r) /= 10) call abort
-if (kind(d) /= 16) call abort
+if (kind(d)  < 10) call abort
 end
Index: gcc/testsuite/lib/target-supports.exp
===================================================================
--- gcc/testsuite/lib/target-supports.exp	(revision 253134)
+++ gcc/testsuite/lib/target-supports.exp	(working copy)
@@ -1464,7 +1464,21 @@ proc check_effective_target_fortran_real_16 { } {
     }]
 }
 
+# Return 1 if the target supports Fortran real kind 10,
+# 0 otherwise. Contrary to check_effective_target_fortran_large_real
+# this checks for real(10) only.
+#
+# When the target name changes, replace the cached result.
 
+proc check_effective_target_fortran_real_10 { } {
+    return [check_no_compiler_messages fortran_real_10 executable {
+	! Fortran
+	real(kind=10) :: x
+	x = cos (x)
+	end
+    }]
+}
+
 # Return 1 if the target supports Fortran's IEEE modules,
 # 0 otherwise.
 #

Re: [Patch, Fortran] PR 82143: add a -fdefault-real-16 flag

[Rainer Orth]

Hi Janus,

> Attached is a more complete patch, which should fix all problems that
> were reported concerning these two test cases. Would be great if
> someone could confirm that it works on a failing target (I currently
> only have access to x86_64-linux-gnu machines).

I've just checked sparc-sun-solaris2.11: works fine.  promotion_3.f90
PASSes as before, but promotion_4.f90 is now UNSUPPORTED instead of
failing.

> Ok for trunk?

The new fortran_real_10 effective-target keyword needs documenting in
sourcebuild.texi.

Thanks.
        Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [Patch, Fortran] PR 82143: add a -fdefault-real-16 flag

[Janus Weil]

[-- Attachment #1: Type: text/plain, Size: 2293 bytes --]

2017-09-26 10:44 GMT+02:00 Janus Weil <janus@gcc.gnu.org>:
> 2017-09-25 23:23 GMT+02:00 Steve Kargl <sgk@troutmask.apl.washington.edu>:
>> On Mon, Sep 25, 2017 at 11:14:42PM +0200, Janus Weil wrote:
>>> 2017-09-25 17:07 GMT+02:00 David Edelsohn <dje.gcc@gmail.com>:
>>> > promotion_3.f90 and promotion_4.f90 are failing on at least PowerPC
>>> > and AArch64.  Are these new tests limited to x86 or some long double
>>> > assumptions?
>>>
>>> These tests require the availability of  a 10- or 16-byte-wide REAL
>>> type, respectively. I have to admit that I do not have a complete
>>> overview of which targets in GCC's wide portfolio provide such a type.
>>>
>>> It seems that REAL(16) is supported via libquadmath on 32-bit x86,
>>> x86-64 and Itanium at least. I'm not sure about REAL(10).
>>>
>>> Targets that do not support such a type probably need to be XFAILed.
>>>
>>
>> Janus, I think you can control with a dg option
>>
>> dg-require-effective-target fortran_large_real
>>
>> See, for example, gfortran.dg/random_3.f90
>
> Thanks for the pointer, Steve.
>
> However, it seems that "fortran_large_real" only requires some real
> type that is larger than 8 byte, but makes no assumptions on its
> actual size (10 or 16 byte). Therefore it's probably not very useful
> for promotion_{3,4}.
>
> But: I found that there's also a "fortran_real_16", which should be
> suitable for promotion_3. Can someone verify if the following fixes
> the problem on the failing targets:
>
> Index: promotion_3.f90
> ===================================================================
> --- promotion_3.f90    (revision 253134)
> +++ promotion_3.f90    (working copy)
> @@ -1,5 +1,6 @@
>  ! { dg-do run }
>  ! { dg-options "-fdefault-real-16" }
> +! { dg-require-effective-target fortran_real_16 }
>  !
>  ! PR 82143: add a -fdefault-real-16 flag
>  !
>
>
> If it does, I'll be happy to commit that. For promotion_4, we probably
> need to add an effective target "fortran_real_10" (which does not seem
> to exists yet).


Attached is a more complete patch, which should fix all problems that
were reported concerning these two test cases. Would be great if
someone could confirm that it works on a failing target (I currently
only have access to x86_64-linux-gnu machines).

Ok for trunk?

Cheers,
Janus

[-- Attachment #2: pr82324.diff --]
[-- Type: text/plain, Size: 1830 bytes --]

Index: gcc/testsuite/gfortran.dg/promotion_3.f90
===================================================================
--- gcc/testsuite/gfortran.dg/promotion_3.f90	(revision 253134)
+++ gcc/testsuite/gfortran.dg/promotion_3.f90	(working copy)
@@ -1,5 +1,6 @@
 ! { dg-do run }
 ! { dg-options "-fdefault-real-16" }
+! { dg-require-effective-target fortran_real_16 }
 !
 ! PR 82143: add a -fdefault-real-16 flag
 !
Index: gcc/testsuite/gfortran.dg/promotion_4.f90
===================================================================
--- gcc/testsuite/gfortran.dg/promotion_4.f90	(revision 253134)
+++ gcc/testsuite/gfortran.dg/promotion_4.f90	(working copy)
@@ -1,5 +1,6 @@
 ! { dg-do run }
 ! { dg-options "-fdefault-real-10" }
+! { dg-require-effective-target fortran_real_10 }
 !
 ! PR 82143: add a -fdefault-real-16 flag
 !
@@ -12,5 +13,5 @@ double precision :: d
 if (kind(r4) /= 4) call abort
 if (kind(r8) /= 8) call abort
 if (kind(r) /= 10) call abort
-if (kind(d) /= 16) call abort
+if (kind(d)  < 10) call abort
 end
Index: gcc/testsuite/lib/target-supports.exp
===================================================================
--- gcc/testsuite/lib/target-supports.exp	(revision 253134)
+++ gcc/testsuite/lib/target-supports.exp	(working copy)
@@ -1464,7 +1464,21 @@ proc check_effective_target_fortran_real_16 { } {
     }]
 }
 
+# Return 1 if the target supports Fortran real kind 10,
+# 0 otherwise. Contrary to check_effective_target_fortran_large_real
+# this checks for real(10) only.
+#
+# When the target name changes, replace the cached result.
 
+proc check_effective_target_fortran_real_10 { } {
+    return [check_no_compiler_messages fortran_real_10 executable {
+	! Fortran
+	real(kind=10) :: x
+	x = cos (x)
+	end
+    }]
+}
+
 # Return 1 if the target supports Fortran's IEEE modules,
 # 0 otherwise.
 #

Re: [Patch, Fortran] PR 82143: add a -fdefault-real-16 flag

[Janus Weil]

2017-09-25 23:23 GMT+02:00 Steve Kargl <sgk@troutmask.apl.washington.edu>:
> On Mon, Sep 25, 2017 at 11:14:42PM +0200, Janus Weil wrote:
>> 2017-09-25 17:07 GMT+02:00 David Edelsohn <dje.gcc@gmail.com>:
>> > promotion_3.f90 and promotion_4.f90 are failing on at least PowerPC
>> > and AArch64.  Are these new tests limited to x86 or some long double
>> > assumptions?
>>
>> These tests require the availability of  a 10- or 16-byte-wide REAL
>> type, respectively. I have to admit that I do not have a complete
>> overview of which targets in GCC's wide portfolio provide such a type.
>>
>> It seems that REAL(16) is supported via libquadmath on 32-bit x86,
>> x86-64 and Itanium at least. I'm not sure about REAL(10).
>>
>> Targets that do not support such a type probably need to be XFAILed.
>>
>
> Janus, I think you can control with a dg option
>
> dg-require-effective-target fortran_large_real
>
> See, for example, gfortran.dg/random_3.f90

Thanks for the pointer, Steve.

However, it seems that "fortran_large_real" only requires some real
type that is larger than 8 byte, but makes no assumptions on its
actual size (10 or 16 byte). Therefore it's probably not very useful
for promotion_{3,4}.

But: I found that there's also a "fortran_real_16", which should be
suitable for promotion_3. Can someone verify if the following fixes
the problem on the failing targets:

Index: promotion_3.f90
===================================================================
--- promotion_3.f90    (revision 253134)
+++ promotion_3.f90    (working copy)
@@ -1,5 +1,6 @@
 ! { dg-do run }
 ! { dg-options "-fdefault-real-16" }
+! { dg-require-effective-target fortran_real_16 }
 !
 ! PR 82143: add a -fdefault-real-16 flag
 !


If it does, I'll be happy to commit that. For promotion_4, we probably
need to add an effective target "fortran_real_10" (which does not seem
to exists yet).

Cheers,
Janus

Re: [Patch, Fortran] PR 82143: add a -fdefault-real-16 flag

[Steve Kargl]

On Mon, Sep 25, 2017 at 11:14:42PM +0200, Janus Weil wrote:
> 2017-09-25 17:07 GMT+02:00 David Edelsohn <dje.gcc@gmail.com>:
> > promotion_3.f90 and promotion_4.f90 are failing on at least PowerPC
> > and AArch64.  Are these new tests limited to x86 or some long double
> > assumptions?
> 
> These tests require the availability of  a 10- or 16-byte-wide REAL
> type, respectively. I have to admit that I do not have a complete
> overview of which targets in GCC's wide portfolio provide such a type.
> 
> It seems that REAL(16) is supported via libquadmath on 32-bit x86,
> x86-64 and Itanium at least. I'm not sure about REAL(10).
> 
> Targets that do not support such a type probably need to be XFAILed.
> 

Janus, I think you can control with a dg option

dg-require-effective-target fortran_large_real

See, for example, gfortran.dg/random_3.f90 

-- 
Steve
20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4
20161221 https://www.youtube.com/watch?v=IbCHE-hONow

Re: [Patch, Fortran] PR 82143: add a -fdefault-real-16 flag

[Janus Weil]

2017-09-25 17:07 GMT+02:00 David Edelsohn <dje.gcc@gmail.com>:
> promotion_3.f90 and promotion_4.f90 are failing on at least PowerPC
> and AArch64.  Are these new tests limited to x86 or some long double
> assumptions?

These tests require the availability of  a 10- or 16-byte-wide REAL
type, respectively. I have to admit that I do not have a complete
overview of which targets in GCC's wide portfolio provide such a type.

It seems that REAL(16) is supported via libquadmath on 32-bit x86,
x86-64 and Itanium at least. I'm not sure about REAL(10).

Targets that do not support such a type probably need to be XFAILed.

Cheers,
Janus

Re: [Patch, Fortran] PR 82143: add a -fdefault-real-16 flag

[David Edelsohn]

promotion_3.f90 and promotion_4.f90 are failing on at least PowerPC
and AArch64.  Are these new tests limited to x86 or some long double
assumptions?

f951: Fatal Error: REAL(KIND=16) is not available for '-fdefault-real-16' option
compilation terminated.

f951: Fatal Error: REAL(KIND=10) is not available for '-fdefault-real-10' option
compilation terminated.

Thanks, David

Re: [Patch, Fortran] PR 82143: add a -fdefault-real-16 flag

[Steve Kargl]

On Sat, Sep 23, 2017 at 12:46:20AM +0200, Dominique d'Humières wrote:
> 
> 
> > If a calculation requires 113-bits of precision, it does not
> > matter how fast a 24-bit floating point type is. 
> 
> But how slow quadmath is really matter.
> 

Compared to what?  If you need more than 64 bits of precision
and 113 bit of precision is sufficient, then REAL(16) gives
that to you.  You can use David Bailey's mpfun2015 (or one
of his other packages) or mpfr/gmp or write your own arbitrary
precision library.  Or, you can flip REAL to REAL(16) and
be done.

Getting back to the speed of the benchmarks you posted, it is
totally irrelevant with regards to what Janus's patch is meant
to do.  You threw out a red herring.

-- 
Steve
20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4
20161221 https://www.youtube.com/watch?v=IbCHE-hONow

Re: [Patch, Fortran] PR 82143: add a -fdefault-real-16 flag

[Dominique d'Humières]

> test_fpu is a horrible benchmark for testing floating point performance. 

Why? It is mostly testing a tiny subset of LAPACK subroutines and yes know that linear algebra does not cover all the uses of floating point calculations. What I have done (almost six years ago) in the REAL(16) variant was to replace all the DOUBLE PRECISION with REAL(16) and a few DXXX with XXX (as in DABS to ABS), the later preventing me to use -fdefault-real-8.

Note that I gave some timing for other tests in the polyhedron suite. If someone is interested I can provide the following variants for REAL(16): capacita_16.f90, channel_16.f90, fatigue_16.f90,  nduct_16.f90, kepler_16.f90, linpk_16.f90, nf_16.f90, protein_16.f90, test_fpu_16.f90, and tfft_16.f90.

> How big is your L1 and L2 cache?

Although I don’t think it is relevant, I am using a laptop with a 2.8 Ghz Core i7, 4 cores/8 threads. AFAIK
L1 is 64 kbytes per core (likely 32k instructions, 32k data),
L2 is 256 kbytes per core,
L3 is at least 6 Mbytes (may be 8, don’t remember).

> That aside, no one who does numerical computations for a living
> will ever confuse a software-backed implementation of REAl(16)
> as being as fast as a hardware-backed implementation of REAL.

What let you think I am doing the confusion?

> If a calculation requires 113-bits of precision, it does not
> matter how fast a 24-bit floating point type is. 

But how slow quadmath is really matter.

> 
> -- 
> Steve
> 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4
> 20161221 https://www.youtube.com/watch?v=IbCHE-hONow

Dominique

Re: [Patch, Fortran] PR 82143: add a -fdefault-real-16 flag

[Steve Kargl]

On Fri, Sep 22, 2017 at 12:06:12PM +0200, Dominique d'Humières wrote:
> 
> > Le 18 sept. 2017 à 20:13, Janus Weil <janus@gcc.gnu.org> a écrit :
> > 
> > 2017-09-18 11:31 GMT+02:00 Dominique d'Humières <dominiq@lps.ens.fr>:
> >> (1) real(16) is an order of magnitude slower than real(8) for the codes I have tested (a long time ago). So its real utility is quite low.
> > 
> > I am fully aware that performance with quad-precision is lower than
> > with double precision. How much will certainly depend on the specifics
> > of the code in question.
> 
> Indeed! The polyhedron test protein.f90 goes from 19s to 32s.
> 
> > The flag I'm proposing would help in evaluating this performance hit.
> 
> My memory did not serve me well, for floating point intensive calculations it is not one order of magnitude but two (the one order of magnitude was probably for IBM REAL(16), i.e., two RAL(8))
> 

test_fpu is a horrible benchmark for testing floating point
performance.  How big is your L1 and L2 cache?

That aside, no one who does numerical computations for a living
will ever confuse a software-backed implementation of REAl(16)
as being as fast as a hardware-backed implementation of REAL.
If a calculation requires 113-bits of precision, it does not
matter how fast a 24-bit floating point type is. 

-- 
Steve
20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4
20161221 https://www.youtube.com/watch?v=IbCHE-hONow

Re: [Patch, Fortran] PR 82143: add a -fdefault-real-16 flag

[Janus Weil]

2017-09-22 12:06 GMT+02:00 Dominique d'Humières <dominiq@lps.ens.fr>:
>>> (2) I think your time would be better used by dealing with your assigned PRs.
>>
>> I think I can very well decide for myself where to waste my spare time.
>
> Indeed! However, as soon as you post something to a list, you are interacting (at least you are expecting it) with other people: exchanging opinion, reviewing submitted patches, bike-shedding, … .

I'm fully aware of that.


> Any way, in my mind my comment was an appreciation of your past, recent, and hopefully future contribution to gfortran.

Did not come across like this at all.


> If I have upset you, it was not intended and please accept my deepest apologies.

You certainly have. You event did it twice recently, and I'm starting
to get a bit allergic to these kinds of comments. It's simply not up
to you to decide what I spend my time on (unless you're willing to pay
for my work or at least send me a bar of chocolate or something).

Anyway, apologies accepted. Let' move on ...


> Concerning bike-shedding, please don’t add a new syntax for -fdefault-*.

I'm not planning to.

Cheers,
Janus

Re: [Patch, Fortran] PR 82143: add a -fdefault-real-16 flag

[Dominique d'Humières]

> Le 18 sept. 2017 à 20:13, Janus Weil <janus@gcc.gnu.org> a écrit :
> 
> 2017-09-18 11:31 GMT+02:00 Dominique d'Humières <dominiq@lps.ens.fr>:
>> (1) real(16) is an order of magnitude slower than real(8) for the codes I have tested (a long time ago). So its real utility is quite low.
> 
> I am fully aware that performance with quad-precision is lower than
> with double precision. How much will certainly depend on the specifics
> of the code in question.

Indeed! The polyhedron test protein.f90 goes from 19s to 32s.

> The flag I'm proposing would help in evaluating this performance hit.

My memory did not serve me well, for floating point intensive calculations it is not one order of magnitude but two (the one order of magnitude was probably for IBM REAL(16), i.e., two RAL(8))

Results for the original test_fpu.f90

Test1 - Gauss 2000 (101x101) inverts  1.1 sec  Err= 0.000000000000104
Test2 - Crout 2000 (101x101) inverts  1.2 sec  Err= 0.000000000000289
Test3 - Crout  2 (1001x1001) inverts  1.0 sec  Err= 0.000000000000082
Test4 - Lapack 2 (1001x1001) inverts  0.8 sec  Err= 0.000000000001333
                             total =  4.1 sec

Results for the REAL(10) variant

Test1 - Gauss 2000 (101x101) inverts  5.7 sec  Err= 0.000000000000000
Test2 - Crout 2000 (101x101) inverts  2.9 sec  Err= 0.000000000000000
Test3 - Crout  2 (1001x1001) inverts  2.8 sec  Err= 0.000000000000000
Test4 - Lapack 2 (1001x1001) inverts  5.4 sec  Err= 0.000000000000000
                             total = 16.8 sec

Results for the REAL(16) variant

Test1 - Gauss 2000 (101x101) inverts 119.8 sec  Err=      0.0000000000000000000000000000001018749071
Test2 - Crout 2000 (101x101) inverts 122.9 sec  Err=      0.0000000000000000000000000000003968958171
Test3 - Crout  2 (1001x1001) inverts 116.6 sec  Err=      0.0000000000000000000000000000002046368750
Test4 - Lapack 2 (1001x1001) inverts 102.2 sec  Err=      0.0000000000000000000000000000033745673898
                             total = 461.6 sec

channel.f90 went from 1s to 97s, induct.f90 from 7s to 1135s, and tfft.f90 from 1.4s to 58s.
> 
>> (2) I think your time would be better used by dealing with your assigned PRs.
> 
> I think I can very well decide for myself where to waste my spare time.

Indeed! However, as soon as you post something to a list, you are interacting (at least you are expecting it) with other people: exchanging opinion, reviewing submitted patches, bike-shedding, … .

Any way, in my mind my comment was an appreciation of your past, recent, and hopefully future contribution to gfortran. If I have upset you, it was not intended and please accept my deepest apologies.

> There were actually times when I enjoyed contributing to
> gfortran and reading this list very much, but recently it's really
> becoming a PITA and I feel like I could spend my time on much nicer
> things ...
> 
> Over and out,
> Janus

Concerning bike-shedding, please don’t add a new syntax for -fdefault-*.

Cheers,

Dominique

Re: [Patch, Fortran] PR 82143: add a -fdefault-real-16 flag

[Janus Weil]

2017-09-18 11:31 GMT+02:00 Dominique d'Humières <dominiq@lps.ens.fr>:
> (1) real(16) is an order of magnitude slower than real(8) for the codes I have tested (a long time ago). So its real utility is quite low.

I am fully aware that performance with quad-precision is lower than
with double precision. How much will certainly depend on the specifics
of the code in question. The flag I'm proposing would help in
evaluating this performance hit.


> (2) I think your time would be better used by dealing with your assigned PRs.

I think I can very well decide for myself where to waste my spare
time. There were actually times when I enjoyed contributing to
gfortran and reading this list very much, but recently it's really
becoming a PITA and I feel like I could spend my time on much nicer
things ...

Over and out,
Janus

Re: [Patch, Fortran] PR 82143: add a -fdefault-real-16 flag

[Dominique d'Humières]

For the record, I just stumbled on http://www.davidhbailey.com/dhbpapers/mpfun2015.pdf.

IMO if real(8) is not enough for a given problem, this is really the way to go (there is no guarantee that real(16) will be enough). In my "real life", real(8) was not enough only once and real(16) was not enough too: I had to use precisions between 40 and 200 with Mathematica.

Dominique

Re: [Patch, Fortran] PR 82143: add a -fdefault-real-16 flag

[Dominique d'Humières]

As said in bugzilla

(1) real(16) is an order of magnitude slower than real(8) for the codes I have tested (a long time ago). So its real utility is quite low.

(2) I think your time would be better used by dealing with your assigned PRs.

But now the wasted time is done, I don’t have further objection.

Dominique

Note: Using -fdefault-* for "production" is a very bad idea.