Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.

Showing results for

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

Highlighted

David_Billinghurst

New Contributor II

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

01-23-2020
06:33 PM

58 Views

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

Accepted Solutions

Highlighted

Steve_Lionel

Black Belt Retired Employee

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

01-24-2020
06:51 AM

58 Views

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.

4 Replies

Highlighted

Steve_Lionel

Black Belt Retired Employee

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

01-24-2020
06:51 AM

59 Views

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.

Highlighted

David_Billinghurst

New Contributor II

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

01-25-2020
05:57 PM

58 Views

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

Highlighted

Steve_Lionel

Black Belt Retired Employee

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

01-25-2020
06:08 PM

58 Views

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.

Highlighted

JohnNichols

New Contributor II

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

01-26-2020
07:20 AM

58 Views

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

For more complete information about compiler optimizations, see our Optimization Notice.