- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

Is the following a bug? Compiled with Fortran 2019u4 x64 under Windows 10 with /O:d. I have read the **Floating-point Optimizations** section of the manual, but didn't find any mention of the treatment of minus zero.

With s=-1; y=s*0.0_8 we have IEEE_CLASS(y)==IEEE_POSITIVE_ZERO

program signed_zero_03 use, intrinsic :: ieee_arithmetic implicit none integer s real(8) x,y s=-1 x=0.0_8 y = s * x write(*,*) (IEEE_CLASS(y)==IEEE_POSITIVE_ZERO) y = -1 * 0.0_8 write(*,*) (IEEE_CLASS(y)==IEEE_POSITIVE_ZERO) y = s * 0.0_8 write(*,*) (IEEE_CLASS(y)==IEEE_POSITIVE_ZERO) end

with output

F F T

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

Not a bug. If you want to rely on the stranger parts of IEEE arithmetic, you have to compile with /fp:strict.

I modified the program as follows:

program signed_zero_03 use, intrinsic :: ieee_arithmetic implicit none integer s real(8) x,y s=-1 x=0.0_8 y = s * x write(*,101) (IEEE_CLASS(y)==IEEE_POSITIVE_ZERO), y 101 format (L1, 1X, Z16.16) y = -1 * 0.0_8 write(*,101) (IEEE_CLASS(y)==IEEE_POSITIVE_ZERO), y y = s * 0.0_8 write(*,101) (IEEE_CLASS(y)==IEEE_POSITIVE_ZERO) , y end

Compiling normally, I get:

F 8000000000000000 F 8000000000000000 T 0000000000000000

so you can see that the first two are negative zero, but the third is "positive zero".

But with /fp:strict:

F 8000000000000000 F 8000000000000000 F 8000000000000000

Now all three are negative zero. Without /fp:strict, the compiler is looser about such things and can give you arithmetically correct results that aren't what you get by strictly adhering to IEEE 754. Performance will be degraded in this mode.

Link Copied

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

Not a bug. If you want to rely on the stranger parts of IEEE arithmetic, you have to compile with /fp:strict.

I modified the program as follows:

program signed_zero_03 use, intrinsic :: ieee_arithmetic implicit none integer s real(8) x,y s=-1 x=0.0_8 y = s * x write(*,101) (IEEE_CLASS(y)==IEEE_POSITIVE_ZERO), y 101 format (L1, 1X, Z16.16) y = -1 * 0.0_8 write(*,101) (IEEE_CLASS(y)==IEEE_POSITIVE_ZERO), y y = s * 0.0_8 write(*,101) (IEEE_CLASS(y)==IEEE_POSITIVE_ZERO) , y end

Compiling normally, I get:

F 8000000000000000 F 8000000000000000 T 0000000000000000

so you can see that the first two are negative zero, but the third is "positive zero".

But with /fp:strict:

F 8000000000000000 F 8000000000000000 F 8000000000000000

Now all three are negative zero. Without /fp:strict, the compiler is looser about such things and can give you arithmetically correct results that aren't what you get by strictly adhering to IEEE 754. Performance will be degraded in this mode.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

Thanks. I hadn't cared about signed zeroes for a while and had forgotten which flags did what.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

FWIW, I once tried arguing with the developers that a USE of the IEEE modules ought to imply /fp:strict. I was unpersuasive at this.Chapter 17.1 (Exceptions and IEEE Arithmetic) spends a lot of text saying that if certain items from the modules are "accessible" then certain behaviors are in effect. For example:

The processor’s fullest support is provided when all of IEEE_FEATURES is accessed as in

USE, INTRINSIC :: IEEE_ARITHMETIC; USE, INTRINSIC :: IEEE_FEATURES

but execution might then be slowed by the presence of a feature that is not needed.

Given the number of questions similar to yours that I received over the years, I thought such an implementation was appropriate and in the spirit if not the letter of the standard.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

I have served on a IEEE Committee related to metric for many years, one sees the huge amount of free work these committee people do and they should be thanked, as applies to the many on this board who give generous time to answer many questions, some of which are actually difficult.

As noted by Dr Fortran - standards are a compromise, but so is life. But my life is a lot richer for Fortran and the friendly people on this forum.

John

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page