forums.silverfrost.com

[DanRRight]

Meantime let's return to our sheep.
This example does not compile with FTN95

[PaulLaidler]

Dan
Would you use this feature of Fortran 2003/8 if it was added to FTN95?
These "suggestions" should be about useful additions.

[DanRRight]

Paul,

This is another demo of another 2003-2008 feature from the codes i learn and i try to use which are compiled with gFortran, Intel etc but not with FTN95. If these codes would compile with FTN95 that would simplify the life immensely as there are no such nice GUI debuggers for other Linux compilers like SDBG64. Without such GUI debugger just to understand how these codes doing even elementary things is like deciphering Enigma machine.

When i find new unknown to FTN95 features in the codes i then search the web and find good demo which demonstrates this feature.

My postings would be unnecessary if you guys at Silverfrost just try to compile these codes i mentioned before and find what the other programmers seems very widely using. My shocking discovery of last months was that if in some other respects FTN95 is by far ahead of other compilers (GUI, OpenGL, fast compilation, HDMI, graphics, bug hunting in older codes) but in the Fortran 2003-2008, OpenMP and OpenMPI parallelization, fast execution, C/C++ integration it is not just the last but lagging far behind all other Fortran compilers which all compile these codes. This is leaving FTN95 not only as the one which can not compile modern codes but which seems is not even close. Intel for example is already fully Fortran-2018 capable.

Additionally what FTN95 missing are the major features which are associated in the perception of absolutely all people with why to use Fortran, not some other compilers Like C, Python, Matlab or new fashion Julia. Because all think that first of all Fortran means being #1 in speed. I afraid the lag here is like a decade or more because the same Intel for example is using all cores of processors by auto-parallelization and in some even single core tests beating FTN95 by an order of magnitude. It also supports all other parallelization techniques including graphics GPU-based like NVIDIA CUDA what all other compilers also do (GPU is a new unstoppable trend) while FTN95 has none excluding one proprietary workaround (i mean FTN95 specific multithreading subroutine. I may also add linear algebra libraries like Laipe or MKL). That in most cases gives additional orders and orders of magnitude ahead of FTN95.

Autoparallelization these my "modern Fortran" codes not using. And not using GPU. Which means that even these my modern codes are not that modern.

[DanRRight]

More extractions from these PIC codes which are Fortran 2003/2008 addition:

1) "ERROR STOP" instead of just STOP.

Used for stopping all running images (processes) while STOP just stops execution of the current image.

2) "Protected" (Fortran 2003)
Example:
integer, protected :: GAS_num_gases = 0

3) NEWUNIT in OPEN (Fortran 2008).
The NEWUNIT specifier opens a file on an unused unit number that is automatically chosen.

Example:
open (newunit=my_unit, ....

4) attribute "non_overridable" (Fortran 2003)

Example:
procedure, non_overridable :: set_random_seed

5) Got error here

[PaulLaidler]

Dan

Although our aim is to provide the best Fortran compiler that we can, it is sensible for us to prioritise and look first at the improvements that are most useful to our current users.

I suggest that you use a different compiler (i.e. not FTN95) when exploring the latest additions to the Fortran Standard. When you see a feature that you understand and would like to use in your own code, then make a request.

Frankly I don't think that you are likely to need or use any of the new features that you have listed. If you are collaborating with others who use these features then you will need to use the same compiler that they are using.

In the meantime, ask for something that is do-able in a matter of days not years. Your request for NORM2, for example, required 2 or 3 man days to implement. It was also something that other FTN95 users might want to use.

[Kenneth_Smith]

In Fortran 2008, the intrinsic function ATAN now has an extra form ATAN(Y,X), which is exactly the same as ATAN2(Y,X), i.e. the following code is valid in Fortran 2008:

[PaulLaidler]

Thanks Ken. I will make a note of this.

[Kenneth_Smith]

Thanks Paul, I think it is important that the core math functions of the later versions of the standard find their way into Silverfrost Fortran - and you have come a long way toward achieving this since this thread was started, for which we are all grateful.

There has been an extension to the support for complex numbers in 2008 that permit the independent assignment of the real and imaginary parts of a complex number. It is also possible to extract these parts without the use of the REAL or AIMAG functions. Below is a simple example of what is now possible via the % operator i.e. the complex number looks like a derived type in this context.

[PaulLaidler]

Thanks Ken. I will add it to the list.

[PaulLaidler]

ATAN(y,x) has now been added for the next release of FTN95.

[Kenneth_Smith]

Thanks Paul, I can see ATAN(y,x) is implemented in the latest download.

[JohnCampbell]

Paul,

I was trying to locate what features had been added to iso_fortran_env but could not find any documentation.

I wrote the following program to see what might come out.

I noted:
"integer_kinds" is not included ?
"iostat_end" /= -1 and "iostat_eor" not included
"numeric_storage_size" and "file_storage_size" not included

("int128" and "real80" are not in the standard, but I think "real128" is)

I think these are just constants so some may be an easy update and may help with documentation ?

[PaulLaidler]

Thanks John. I have made a note of your suggestion.

[PaulLaidler]

iso_fortran_env has been ammended for the next full release of FTN95.

The associated results for real_kinds and real80 relate to 64 bit FTN95 and are:

INTEGER,PARAMETER::REAL80=-1
INTEGER,PARAMETER::REAL_KINDS(2)=(/1,2/)

The values for 32 bit FTN95 are different from those provided by iso_fortran_env and are:

INTEGER,PARAMETER::REAL80=3
INTEGER,PARAMETER::REAL_KINDS(3)=(/1,2,3/)

[JohnCampbell]

Paul,

It is good to include in ISO_FORTRAN_ENV, those parameters that are relevant to FTN95 extensions for F03 and F08.

Just to clarify; I was checking if real80 or integer128 possibly might have existed. They are not in the standard, but should be listed in REAL_KINDS and INTEGER_KINDS if relevant.

It is a good change that "real_kinds" differ for 32 and /64

"integer_kinds" are in the standard and are an important report.

Thanks for these prompt updates.

John

( ps : have you considered including a /32 compile option ? )