Turn on suggestions

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

Blane_J_

New Contributor I

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

09-09-2017
10:46 AM

16 Views

Hi. Since I am doing some fundamental calculation, this problem came up, as:

! This is good. integer(8), parameter :: max_int64 = int(16#8000000000000000, kind = 8) write(*,*) max_int64 ! This is bad. write(*,*) int(16#8000000000000000, kind = 8)

The upper case gives an correct output of 9151314442816847872 but the lower one prints only 0. why is that? Thanks for any help.

Accepted Solutions

Highlighted
I would expect these to be the same, but I can imagine why the compiler has a problem with it. Nevertheless, you are on extremely thin ice with your use of this non-standard syntax from a time when 64-bit didn't exist on the platform. If I interpret the documentation correctly, the expected value is zero because the # syntax for "integer constants" has a kind of "default integer". I won't even start to ask why you are calling this hex value MAX_INT64 since it is not at all the maximum 64-bit integer value - indeed, it is the minimum integer value. If you truly want the largest integer value for kind 8, use HUGE(0_8).

Steve_Lionel

Black Belt Retired Employee

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

09-09-2017
11:42 AM

16 Views

9 Replies

Highlighted
I would expect these to be the same, but I can imagine why the compiler has a problem with it. Nevertheless, you are on extremely thin ice with your use of this non-standard syntax from a time when 64-bit didn't exist on the platform. If I interpret the documentation correctly, the expected value is zero because the # syntax for "integer constants" has a kind of "default integer". I won't even start to ask why you are calling this hex value MAX_INT64 since it is not at all the maximum 64-bit integer value - indeed, it is the minimum integer value. If you truly want the largest integer value for kind 8, use HUGE(0_8).

Steve_Lionel

Black Belt Retired Employee

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

09-09-2017
11:42 AM

17 Views

Highlighted
I see, and I have found the page about "Determining the Data Type of Nondecimal Constants" in the manual. Thanks Steve and BTW, max is a mistake.

Blane_J_

New Contributor I

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

09-09-2017
11:36 PM

16 Views

Highlighted
The section you want is "Integer Constants" - the # syntax is treated differently from the BOZ syntax.

Steve_Lionel

Black Belt Retired Employee

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

09-10-2017
03:51 AM

16 Views

Highlighted

andrew_4619

Valued Contributor III

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

09-10-2017
05:44 AM

16 Views

Highlighted

jimdempseyatthecove

Black Belt

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

09-10-2017
08:47 AM

16 Views

FWIW

Z'8000000000000000'

Has sign bit set and remainder bits are 0 thus representing min_int64.

(Z'8000000000000000' - 1_8) would result in sign bit 0 and remainder bits set to 1's would represent max_int64

And , -HUGE(0_8) would produce a number 1 greater than the smallest negative number.

It is disputable as to if Z'8000000000000000' represents -0, or potentially arguable as an integer NaN, though the hardware will treat this as .lt. 0.

Jim Dempsey

Highlighted
I believe this case, where there is a number 1 less than -huge(selected_int_kind..), isn't covered by Fortran standard. It does occur for all the usual implementations of 2's complement integer, but presents an opportunity for non-portability.
Of course, the requested use of the 16# extension and the specific kind value 8 affirm the intent of non-portability.

TimP

Black Belt

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

09-10-2017
10:50 AM

16 Views

Highlighted
So for safely use, maybe I should turn to the boz form all the time for constants based other than 2,8,16 are not frequently used anyway. Thanks for all.

Blane_J_

New Contributor I

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

09-10-2017
06:05 PM

16 Views

Highlighted

andrew_4619

Valued Contributor III

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

09-11-2017
05:33 AM

16 Views

Blane J. wrote:

So for safely use, maybe I should turn to the boz form all the time for constants based other than 2,8,16 are not frequently used anyway. Thanks for all.

The BOZ form is standards compliant so is the best way even though it seems a little clumsy at times. I aim to be able to compile any code I work on with standards checking on, it is a good thing to aim for.

Highlighted

mecej4

Black Belt

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

09-11-2017
06:49 AM

16 Views

There is at least one other non-standard convention for specifying byte values for CHARACTER*1 variables:

C CHARACTER*1 CCR, CLF DATA CCR/'0D'X/, CLF/'0A'X/

Until I saw this in some old F77 code a few months ago (taken from an OS-2 code repository), I had never seen it.

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