* Re: how *not* to use denormalised numbers?
@ 2015-11-10 16:59 Dominique d'Humières
2015-11-10 18:14 ` Steve Kargl
0 siblings, 1 reply; 9+ messages in thread
From: Dominique d'Humières @ 2015-11-10 16:59 UTC (permalink / raw)
To: mexas; +Cc: sgk, nmm1@cam.ac.uk gfortran
Consider the following modification of the test
use ieee_arithmetic
logical :: gradual
write (*,*) "Support underflow control:", &
ieee_support_underflow_control()
call ieee_get_underflow_mode( gradual )
write (*,*) "Gradual underflow:", gradual
write (*,*) "Support denormals:", ieee_support_denormal()
print *, nearest(tiny(1.0d0), -1.0d0)
print *, nearest(0.0d0, 1.0d0)
! flip underflow mode
call ieee_set_underflow_mode( .not. gradual )
call ieee_get_underflow_mode( gradual )
write (*,*) "Gradual underflow:", gradual
write (*,*) "Support denormals:", ieee_support_denormal()
print *, nearest(tiny(1.0d0), -1.0d0)
print *, nearest(0.0d0, 1.0d0)
end
Compiled with gfortran -O, it outputs
Support underflow control: F
Gradual underflow: T
Support denormals: T
2.2250738585072009E-308
4.9406564584124654E-324
Gradual underflow: F
Support denormals: T
2.2250738585072009E-308
4.9406564584124654E-324
If compiled with -O -fast-math, the output is
Support underflow control: F
Gradual underflow: F
Support denormals: T
0.0000000000000000
0.0000000000000000
Gradual underflow: T
Support denormals: T
0.0000000000000000
0.0000000000000000
IIRC correctly, this is documented somewhere in GCC, but I cannot find where. Indeed -fast-math has other side-effects and cannot be suitable.
Dominique
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: how *not* to use denormalised numbers?
2015-11-10 16:59 how *not* to use denormalised numbers? Dominique d'Humières
@ 2015-11-10 18:14 ` Steve Kargl
0 siblings, 0 replies; 9+ messages in thread
From: Steve Kargl @ 2015-11-10 18:14 UTC (permalink / raw)
To: Dominique d'Humières; +Cc: mexas, nmm1@cam.ac.uk gfortran
On Tue, Nov 10, 2015 at 05:59:12PM +0100, Dominique d'Humières wrote:
> Consider the following modification of the test
>
> use ieee_arithmetic
> logical :: gradual
> write (*,*) "Support underflow control:", &
> ieee_support_underflow_control()
> call ieee_get_underflow_mode( gradual )
> write (*,*) "Gradual underflow:", gradual
> write (*,*) "Support denormals:", ieee_support_denormal()
> print *, nearest(tiny(1.0d0), -1.0d0)
> print *, nearest(0.0d0, 1.0d0)
> ! flip underflow mode
> call ieee_set_underflow_mode( .not. gradual )
> call ieee_get_underflow_mode( gradual )
> write (*,*) "Gradual underflow:", gradual
> write (*,*) "Support denormals:", ieee_support_denormal()
> print *, nearest(tiny(1.0d0), -1.0d0)
> print *, nearest(0.0d0, 1.0d0)
> end
>
> Compiled with gfortran -O, it outputs
>
> Support underflow control: F
> Gradual underflow: T
> Support denormals: T
> 2.2250738585072009E-308
> 4.9406564584124654E-324
> Gradual underflow: F
> Support denormals: T
> 2.2250738585072009E-308
> 4.9406564584124654E-324
>
Your code is wrong. gfortran will constant-fold the intrinsic
procedures in your print statements. This constant folding is
done prior to toggling the FPU. Changing the above code shows
the desired behavior and re-inforces Nick's advice. Consider
program foo
use ieee_arithmetic
logical :: gradual
real x
write (*,*) "Support underflow control:", ieee_support_underflow_control()
call ieee_get_underflow_mode(gradual)
write (*,*) "Gradual underflow:", gradual
write (*,*) "Support denormals:", ieee_support_denormal()
two = 1
call bar(two)
x = tiny(x)
print *, x, x / two
! flip underflow mode
call ieee_set_underflow_mode(.not.gradual)
call ieee_get_underflow_mode(gradual)
write (*,*) "Gradual underflow:", gradual
write (*,*) "Support denormals:", ieee_support_denormal()
two = 1
call bar(two)
x = tiny(x)
print *, x, x / two
contains
subroutine bar(two)
real, volatile :: two
two = 2.
end subroutine bar
end program foo
troutmask:sgk[215] gfc6 -o z -fdump-tree-original s.f90 && ./z
Support underflow control: F
Gradual underflow: T
Support denormals: T
1.17549435E-38 5.87747175E-39
Gradual underflow: F
Support denormals: T
1.17549435E-38 0.00000000
--
Steve
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: how *not* to use denormalised numbers?
2015-11-10 17:11 ` N.M. Maclaren
@ 2015-11-10 19:55 ` FX
0 siblings, 0 replies; 9+ messages in thread
From: FX @ 2015-11-10 19:55 UTC (permalink / raw)
To: N.M. Maclaren; +Cc: mexas, sgk, fortran
>> The default in gfortran is "do not change the FPU state".
>
> And I believe that should not be changed.
It won’t be changed. It is the only sane behavior.
FX
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: how *not* to use denormalised numbers?
2015-11-10 16:50 ` FX
@ 2015-11-10 17:11 ` N.M. Maclaren
2015-11-10 19:55 ` FX
0 siblings, 1 reply; 9+ messages in thread
From: N.M. Maclaren @ 2015-11-10 17:11 UTC (permalink / raw)
To: FX; +Cc: mexas, sgk, fortran
On Nov 10 2015, FX wrote:
>
>> I agree. I would hope that the default is to use the 'native' mode,
>> whatever that is, on the grounds that changing the mode is bad news
>> for interoperability with C and some libraries,
>
>The default in gfortran is "do not change the FPU state".
And I believe that should not be changed.
Regards,
Nick Maclaren.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: how *not* to use denormalised numbers?
2015-11-10 16:27 ` Anton Shterenlikht
@ 2015-11-10 16:50 ` FX
2015-11-10 17:11 ` N.M. Maclaren
0 siblings, 1 reply; 9+ messages in thread
From: FX @ 2015-11-10 16:50 UTC (permalink / raw)
To: mexas; +Cc: nmm1, sgk, fortran
[Anton]
> My understanding was that the use has to request
> the use of denormalised numbers explicitly, via USE statement,
> e.g. MFE, p.225.
Fortran 2008, 14.5: "The initial underflow mode is processor dependent”
[Nick]
> I agree. I would hope that the default is to use the 'native' mode,
> whatever that is, on the grounds that changing the mode is bad news
> for interoperability with C and some libraries,
The default in gfortran is “do not change the FPU state”.
[Anton]
> call ieee_get_underflow_mode( gradual )
Fortran 2008, 14.11.8: "IEEE_GET_UNDERFLOW_MODE shall not be invoked unless IEEE_SUPPORT_UNDERFLOW_CONTROL (X) is true for some X”
> So underflow control is not supported.
No. Underflow control is not "supported for all floating-point kinds". But it is supported, on your platform, for binary32 and binary64 floating-point types, i.e. real(kind=4) and real(kind=8).
Try ieee_support_underflow_control(0.)
FX
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: how *not* to use denormalised numbers?
2015-11-10 15:49 ` N.M. Maclaren
@ 2015-11-10 16:27 ` Anton Shterenlikht
2015-11-10 16:50 ` FX
0 siblings, 1 reply; 9+ messages in thread
From: Anton Shterenlikht @ 2015-11-10 16:27 UTC (permalink / raw)
To: nmm1, sgk; +Cc: fortran, mexas
From nmm1@hermes.cam.ac.uk Tue Nov 10 15:51:26 2015
>
>On Nov 10 2015, Steve Kargl wrote:
>>
>>Although I haven't checked, you'll probably need to use the
>>IEEE arithmetic modules to control subnormal numbers or use
>>C interop and fenv features to manipulate the FPU.
>
>I agree. I would hope that the default is to use the 'native' mode,
>whatever that is, on the grounds that changing the mode is bad news
>for interoperability with C and some libraries,
I'm confused:
$ cat z.f90
use ieee_arithmetic
logical :: gradual
write (*,*) "Support underflow control:", &
ieee_support_underflow_control()
call ieee_get_underflow_mode( gradual )
write (*,*) "Gradual underflow:", gradual
write (*,*) "Support denormals:", ieee_support_denormal()
! flip underflow mode
call ieee_set_underflow_mode( .not. gradual )
call ieee_get_underflow_mode( gradual )
write (*,*) "Gradual underflow:", gradual
write (*,*) "Support denormals:", ieee_support_denormal()
end
$ gfortran6 -Wl,-rpath="/usr/local/lib/gcc6" z.f90
$ ./a.out
Support underflow control: F
Gradual underflow: T
Support denormals: T
Gradual underflow: F
Support denormals: T
$
So underflow control is not supported.
Why then ieee_set_underflow_mode pretends to
switch gradual underflow off?
Another compiler gives:
Support underflow control: T
Gradual underflow: F
Support denormals: F
Gradual underflow: T
Support denormals: T
which makes sense.
So the impression I get is that denormals are
enabled by default in gfortran and cannot be switched off.
I read that denormals processing could be substantially
slower that just flash to zero. I think my code might
be affected.
Anton
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: how *not* to use denormalised numbers?
2015-11-10 15:16 ` Steve Kargl
@ 2015-11-10 15:49 ` N.M. Maclaren
2015-11-10 16:27 ` Anton Shterenlikht
0 siblings, 1 reply; 9+ messages in thread
From: N.M. Maclaren @ 2015-11-10 15:49 UTC (permalink / raw)
To: Steve Kargl; +Cc: Anton Shterenlikht, fortran
On Nov 10 2015, Steve Kargl wrote:
>
>Although I haven't checked, you'll probably need to use the
>IEEE arithmetic modules to control subnormal numbers or use
>C interop and fenv features to manipulate the FPU.
I agree. I would hope that the default is to use the 'native' mode,
whatever that is, on the grounds that changing the mode is bad news
for interoperability with C and some libraries,
Regards,
Nick Maclaren.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: how *not* to use denormalised numbers?
2015-11-10 14:41 Anton Shterenlikht
@ 2015-11-10 15:16 ` Steve Kargl
2015-11-10 15:49 ` N.M. Maclaren
0 siblings, 1 reply; 9+ messages in thread
From: Steve Kargl @ 2015-11-10 15:16 UTC (permalink / raw)
To: Anton Shterenlikht; +Cc: fortran
On Tue, Nov 10, 2015 at 06:41:48AM -0800, Anton Shterenlikht wrote:
> Are denormalised numbers supported by default by gfortran6 (or 5)?
> My understanding was that the use has to request
> the use of denormalised numbers explicitly, via USE statement,
> e.g. MFE, p.225.
>
> I have a program that does *not* USE ieee_features,
> compiled by gfortran6 with these flags:
>
> -fopenmp -fbacktrace -Wall
>
> It returns (FreeBSD amd64):
>
> Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL
>
> suggesting denormalised numbers were used.
>
> I don't want to use denormalised numbers.
> A flash to zero is acceptable, provided
> this will trigger underflow exception.
> What gfortran option(s) will achieve this?
>
Although I haven't checked, you'll probably need to use the
IEEE arithmetic modules to control subnormal numbers or use
C interop and fenv features to manipulate the FPU.
--
Steve
^ permalink raw reply [flat|nested] 9+ messages in thread
* how *not* to use denormalised numbers?
@ 2015-11-10 14:41 Anton Shterenlikht
2015-11-10 15:16 ` Steve Kargl
0 siblings, 1 reply; 9+ messages in thread
From: Anton Shterenlikht @ 2015-11-10 14:41 UTC (permalink / raw)
To: fortran
Are denormalised numbers supported by default by gfortran6 (or 5)?
My understanding was that the use has to request
the use of denormalised numbers explicitly, via USE statement,
e.g. MFE, p.225.
I have a program that does *not* USE ieee_features,
compiled by gfortran6 with these flags:
-fopenmp -fbacktrace -Wall
It returns (FreeBSD amd64):
Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL
suggesting denormalised numbers were used.
I don't want to use denormalised numbers.
A flash to zero is acceptable, provided
this will trigger underflow exception.
What gfortran option(s) will achieve this?
Thanks
Anton
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2015-11-10 19:55 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-11-10 16:59 how *not* to use denormalised numbers? Dominique d'Humières
2015-11-10 18:14 ` Steve Kargl
-- strict thread matches above, loose matches on Subject: below --
2015-11-10 14:41 Anton Shterenlikht
2015-11-10 15:16 ` Steve Kargl
2015-11-10 15:49 ` N.M. Maclaren
2015-11-10 16:27 ` Anton Shterenlikht
2015-11-10 16:50 ` FX
2015-11-10 17:11 ` N.M. Maclaren
2015-11-10 19:55 ` FX
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).