Fortran 2023 standard

Help
132

Can you please list the contexts you have in mind when it comes to accessing the character data of a string type? That will help clarify.

133

For use in an expression, as a subroutine argument, on the left hand side of a character expression, in a pointer assignment, etc. In addition to the efficiency aspect, there are many situations where you want to access the data itself, not a copy of the data.

134

Sticking this here, as good a place as any…

The F2023 FDIS went out for ballot on August 3. According to the ISO Project page, close of voting is September 28. Assuming there are no disqualifying objections, publication should occur in October.

The ISO Editor has asked for some minor boilerplate changes before publication, which should not hold things up. So close!

Looking to the future, WG5 is joining an effort by the C and C++ projects to request that ISO allow paragraph numbers in programming language standards, so that we don’t have to request exemptions each time. We did not make that request for F2023, so the published standard will not have paragraph numbers. Our “interpretation document”, which the committee uses internally, will continue to have both paragraph and line numbers.

13 Likes
135

Congratulations. Thanks for the update and for serving as convenor.

136

Balloting on the F2023 FDIS closed yesterday. There were 16 member bodies that voted (14 P-members and 2 O-members). All voted to approve.

What’s left is some boilerplate cleanup, and the standard should be published sometime in October or maybe early November.

15 Likes
137

This page WG5 Fortran - Fortran 2023 still says “Fortran 2018 is the current standard.”

But the ISO website tells another story :champagne: :

General information

  • Status: Published
    Publication date: 2023-11
    Stage: International Standard published [60.60]
  • Edition: 5
    Number of pages: 674
  • Technical Committee : ISO/IEC JTC 1/SC 22
    ICS : 35.060

It happened yesterday, the 17th November.

10 Likes
138

Wonderful news - I didn’t receive notice of this.

8 Likes
139

Other languages having a new ISO standard in 2023 are (from the oldest to the youngest):

6 Likes
140

People love Fortran.

18 Likes
141

This was our most successful tweet to date. It reached over 130K people and we got close to 300 (~10%) new followers in two days. Happy Thanksgiving, all.

23 Likes
142

Are you aware of any of the new features already supported (as an extension) in any of renowned compilers?

143

https://www.intel.com/content/www/us/en/developer/articles/technical/fortran-language-and-openmp-features-in-ifx.html

These features from Fortran 2023 are implemented.

  • The REDUCE locality spec on DO CONCURRENT
  • BOZ constants on RHS of INTEGER and REAL assignment statements
  • BOZ constants as INTEGER and REAL values in PARAMETER statements
  • BOZ constants as INTEGER or REAL as array constructor values
  • BOZ constants as INTEGER values in ENUMERATION statements
  • Intrinsic trigonometric functions returning degrees ACOSD(X), ASIND(X), ATAND(X), ATAN2D(Y, X), COSD(X), SIND(X), and TAND(X)
1 Like
144

If I correctly read the 23-007r1 Draft description of ALLOCATE modified syntax, incl. R933/937/939, the following should be doable in F2023:

integer, parameter :: r=3, size=5
real, rank(r), allocatable :: tab
...
allocate(tab([(size,i=1,r)]))

to allocate a rank-r array with parametrized rank. Changing the rank requires just one modification. That could be hardly achieved with colon syntax. Surely probably any real processing of such arrays would still require to pass them as assumed-rank object to a procedure and there using select rank construct. So it is just a small step forward.

145

The new optional lower argument of the c_f_pointer intrinsic, allows one to implement a very cryptic impure integer addition function,

function iadd(a, b) result(c)
    use, intrinsic :: iso_c_binding
    integer, value :: a, b
    integer :: c
    character(c_char), pointer :: t(:)
    call c_f_pointer(c_null_ptr, t, shape=[a+1],lower=[0])
    call c_f_pointer(c_loc(t(a)), t, shape=[b+1],lower=[0])
    c = transfer(c_loc(t(b)), iadd)
end function

that in some odd sense, mimics what the x86 hardware is doing with the LEA instruction (see below). Note, I haven’t tested the routine above since I’m not sure any compiler supports lower yet. (I’m aware I’m using +1 to get the shape, but didn’t want to complicate this any further. On a two’s complement machine, you can add 1 using -not(i).)

pure function plus(a,b) result(c)
   integer, value :: a, b
   integer :: c
   c = a + b
end function

plus_:
        lea     eax, [rdi+rsi]
        ret

According to the System V calling conventions, eax serves as the result register (c), and rdi and rsi are the registers of the first two arguments (a and b in this case).

I took the idea from the following C code found on Stack Overflow,

int add(int a, int b) {
   const char *c = 0;
   return &(&c[a])[b];
}

(Don’t use this code, it’s just a silly example to demonstrate some addressing concepts.)

146

What would @ivanpribec’s iadd function do if a+b would overflow?

147

A few resources I consulted state the lea instruction does not set any condition codes (carry, overflow), meaning you cannot discern if the signed overflow or unsigned wraparound occurred.

In practice I observe signed overflow occurs:

#include <stdio.h>
#include <limits.h>

int add(int a, int b) {
   const char *c = 0;
   return (int) &(&c[a])[b];
}

int main(void) {
    printf("c = %d\n", add(INT_MAX,0));
    printf("c = %d\n", add(INT_MAX,1));
    return 0;
}

$ gcc-13 -Wall -Wno-pointer-to-int-cast -std=c99 -Os -fno-inline && ./a.out
c = 2147483647
c = -2147483648

According to the gfortran documentation, integer overflow is prohibited (in the sense the programmer guarantees it will not happen). So from this point of view a compiler can happily assume c_loc(t(a)) will always return a valid valid address.

Perhaps not for everyone, but there is an interesting talk on a related topic: *(char*)0 = 0; - What Does the C++ Programmer Intend With This Code?

148

If I understand is correctly, the draft document is no longer available for Fortran 2023 from WG5. I found a version at J3 and some further changes in txt files, but it is somewhat unfortunate and can lead to problems when searching what is a compiler defect and what is the standard behaviour.

149

There will be a new “Interpretation reference document” on the J3 site soon - I have a preliminary version, but Malcolm (Editor) gets to decide when it goes out. ISO is very protective of its copyrights, so the WG5 site doesn’t publish drafts (and hasn’t since I created it in 2017.)

2 Likes
150

What is the difference between the “Interpretation reference document” and the latest draft?

151

If by “latest draft” you mean 23-007r1, that is close to the published standard, with the addition of paragraph and line numbers, but there were some changes made based on ballot comments and some typo corrections. “Interpretation reference document”, such as 18-007r1 for F2018, is what the committee uses as a reference, and includes paragraph and line numbers. I don’t know anyone on the committee who buys the ISO printed version. I expect that the one for F2023 will be called 24-007.

1 Like