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

[David Edelsohn]

On Tue, Sep 26, 2017 at 4:44 AM, Janus Weil  wrote:
> 2017-09-25 23:23 GMT+02:00 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 :
>>> > 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]

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
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]

2017-09-26 10:44 GMT+02:00 Janus Weil :
> 2017-09-25 23:23 GMT+02:00 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 :
>>> > 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
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 :
> On Mon, Sep 25, 2017 at 11:14:42PM +0200, Janus Weil wrote:
>> 2017-09-25 17:07 GMT+02:00 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?
>>
>> 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 :
> > 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 :
> 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

[Janus Weil]

2017-09-22 21:32 GMT+02:00 Janus Weil :
> 2017-09-22 11:44 GMT+02:00 Janus Weil :
>> 2017-09-22 9:11 GMT+02:00 Janne Blomqvist :
>>> 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

[Janus Weil]

2017-09-22 11:44 GMT+02:00 Janus Weil :
> 2017-09-22 9:11 GMT+02:00 Janne Blomqvist :
>> 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
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, >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)
 

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  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]

2017-09-22 9:11 GMT+02:00 Janne Blomqvist :
> On Fri, Sep 22, 2017 at 8:02 AM, Janus Weil  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

[Janne Blomqvist]

On Fri, Sep 22, 2017 at 8:02 AM, Janus Weil  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-21 22:38 GMT+02:00 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.

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  

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  

PR fortran/82143
* gfortran.dg/promotion_3.f90: New test case.
* gfortran.dg/promotion_4.f90: New test case.
! { dg-do run }
! { dg-options "-fdefault-real-16" }
!
! PR 82143: add a -fdefault-real-16 flag
!
! Contributed by Janus Weil 

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
! { dg-do run }
! { dg-options "-fdefault-real-10" }
!
! PR 82143: add a -fdefault-real-16 flag
!
! Contributed by Janus Weil 

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

[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]

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 :
> 2017-09-18 16:08 GMT+02:00 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.
>
> 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
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, >where))
continue;
 
- if ((flag_default_integer || flag_default_real)
+ if ((flag_default_integer || flag_default_real_8)
  && symbol[i].id 

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 :
> (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

[Janus Weil]

2017-09-18 16:08 GMT+02:00 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.

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

[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

[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.

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_id=1318=ListThreads_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 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