Time to test this year's Intel Fortran 2020 Beta

Ron_Green · ‎04-30-2019

Intel® Fortran Composer XE 2020 Beta

We are pleased to announce Intel® Parallel Studio XE 2020 Technical Preview Composer Edition for Fortran is ready for testing. Packages are available for Linux*, Windows*, and macOS* X.

These packages contain a Pre-Release version of Intel® Fortran version 19.1. That's right, we have a "dot-1" minor release this year. But for Fortran it's anything but minor! This is one of our most ambitious releases to date. We've added many Fortran 2018 features. Get the DETAILS HERE.

When you're ready to join our test program, GO HERE to learn more and sign up!

** NOTE: Visual Studio 2019 Integration is COMING SOON! We hope to have this in Tech Preview Update 1

FortranFan · ‎04-30-2019

Ronald W Green (Blackbelt) wrote:
.. We've added many Fortran 2018 features ..

Mega Kudos to Intel team on an outstanding announcement with great news on an exciting product launch, wonderful "What's New" notes as well.

Keep up the great work,

Steve_Lionel · ‎04-30-2019

Very impressive! But I see VS2019 is not yet supported.

andrew_4619 · ‎05-01-2019

wow so many new goodies.

Arjen_Markus · ‎05-02-2019

I have installed this new version and tried it on a small program that uses coarrays. That worked fine, but when I tried the new collective routines, something went wrong. Is this the place to report such issues (in a new thread?) or should I use the support centre instead?

OP1 · ‎05-02-2019

SELECT RANK and a slew of new coarray features... This truly feels like Christmas, ha ha! This is a great bit of news from Intel. And I echo FortranFan's comment regarding the quality of the "What's New" notes. Now if only we could have the same for bug fixes ;-) .

Thanks for this major update!

Ron_Green · ‎05-02-2019

Arjen, you can post the coarray collective issue here - I can create the bug report from here.

Make SURE for Coarrays that you use the x64 64bit configuration. 32bit CAF is buggy and will be removed soon. We documented this in the Release Notes.

Arjen_Markus · ‎05-02-2019

Good :). Here is my test program:

program chkcosum
    implicit none

    real :: x

    x = this_image()
    write(*,*) x, ' -- ', this_image()

    !call co_sum( x, 1 )
    call co_sum( x )

    sync all

    if ( this_image() == 1 ) then
        write(*,*) 'Sum: ', x
    endif
end program chkcosum

I started with a somewhat larger program and "call co_sum(x, 1)" and that gave strange values. So that is why I reduced it to the above.

When I ran it, I got:

   3.000000      --            3
   8.000000      --            8
   5.000000      --            5
   1.000000      --            1
   4.000000      --            4
   2.000000      --            2
   7.000000      --            7
   6.000000      --            6
forrtl: severe (772): Image number 0 is not a valid image number; valid numbers are 1 to 8
In coarray image 2
Image              PC                Routine            Line        Source
libicaf.dll        00007FFA8A9715A5  Unknown               Unknown  Unknown
chkcosum.exe       00007FF72645112B  Unknown               Unknown  Unknown
chkcosum.exe       00007FF7264A0B32  Unknown               Unknown  Unknown
chkcosum.exe       00007FF7264A0EC0  Unknown               Unknown  Unknown
KERNEL32.DLL       00007FFAA4903DC4  Unknown               Unknown  Unknown
ntdll.dll          00007FFAA6043691  Unknown               Unknown  Unknown

...

forrtl: severe (772): Image number 0 is not a valid image number; valid numbers are 1 to 8
In coarray image 4
Image              PC                Routine            Line        Source
libicaf.dll        00007FFA8A9715A5  Unknown               Unknown  Unknown
chkcosum.exe       00007FF72645112B  Unknown               Unknown  Unknown
chkcosum.exe       00007FF7264A0B32  Unknown               Unknown  Unknown
chkcosum.exe       00007FF7264A0EC0  Unknown               Unknown  Unknown
KERNEL32.DLL       00007FFAA4903DC4  Unknown               Unknown  Unknown
ntdll.dll          00007FFAA6043691  Unknown               Unknown  Unknown


===================================================================================
=   BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
=   RANK 6 PID 3556 RUNNING AT L02223
=   KILLED BY SIGNAL: -1 ()
===================================================================================

===================================================================================
=   BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
=   RANK 7 PID 8536 RUNNING AT L02223
=   KILLED BY SIGNAL: -1 ()
===================================================================================

I am using this pre-release:

Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 19.1.0.056 Pre-Release Beta Build 20190321
Copyright (C) 1985-2019 Intel Corporation. All rights reserved.
ifort: command line warning #10006: ignoring unknown option '/version'

ifort: NOTE: The Beta evaluation period for this product ends on 9-oct-2019 UTC.
ifort: command line error: no files specified; for help type "ifort /help"

BTW the co_broadcast routine seems to work fine.

Lorri_M_Intel · ‎05-02-2019

In your small program, adding back the result image works. (ie, using call co_sum(x, 1))

It would be interesting to see the bigger one that went whacky with the result image.

--Lorri

Arjen_Markus · ‎05-02-2019

I tried that and got:

   1.000000      --            1
 Sum:    1.000000
   7.000000      --            7
   8.000000      --            8
   3.000000      --            3
   2.000000      --            2
   6.000000      --            6
   4.000000      --            4
   5.000000      --            5

Even with a "sync all" before call co_sum I get the answer 1, where I expected the sum of the x's over the images. (See http://fortranwiki.org/fortran/show/co_sum for an almost identical example)

Arjen_Markus · ‎05-02-2019

In reply to #9: here is the (annotated) result from my original program:

 Result:            5  0.6193680
 Result:            4  0.6424150
 Result:            2  0.6213304
 Result:            1  0.6258064
 Result:            8  0.6487952
 Result:            7  0.6229414
 Result:            3  0.6461422
 Result:            6  0.6217359
 Total:            1  0.6258064              <== the expected result
 Exact:      0.6400000      --            1
 Exact:      0.6400000      --            2
 Estimate:   -999.0000      --            2
 Exact:      0.6400000      --            3
 Estimate:   -999.0000      --            3
 Exact:      0.6400000      --            6
 Estimate:   -999.0000      --            6
 Exact:      0.6400000      --            7
 Estimate:   -999.0000      --            7
 Exact:      0.6400000      --            8
 Estimate:   -999.0000      --            8
 Exact:      0.6400000      --            4
 Estimate:   -999.0000      --            4
 Estimate:   7.8225799E-02  --            1  <== I expected ~0.64
 Exact:      0.6400000      --            5
 Estimate:   -999.0000      --            5

I have attached a zip file with the program code. The value printed as total is actually the result of image 1, so that the average which is returned is 1/8th of that. This behaviour is consistent with co_sum not returning the sum over the images.

Arjen_Markus · ‎05-07-2019

I tried another example of the new functionality, th additional clauses for DO CONCURRENT - as I was too lazy to construct one of my own, I used the example of the release notes. My program looks like this:

program doconcurrent
    implicit none

    integer :: n = 10000
    integer :: i
    real    :: x, y, z, r

    x = 1.0
    y = 2.0
    z = 3.0
    r = 4.0

    do concurrent (integer :: i = 1:n) local(x,r) local_init(y) shared(z)
        x = i + 1.0
        r = y

        if ( i == 1 ) then
            z = 4.0
        endif
    enddo

    write(*,*) x, y, z, r

end program doconcurrent

So, except for the value of n, it is the same as in the release notes. The outcome, however, is not:

10001.00 2.000000 4.000000 2.000000

instead of "1.0 2.0 4.0 4.0" as in that example.

A possible explanation for this result is that the loop was not actually parallellised (I cannot find the options to get a detailed report on such matters - I am probably overlooking them). But if that is the case, then the effect of DO CONCURRENT clauses on the variables involved depends on factors outside the control of the programmer, doesn't it?

Ron_Green · ‎05-08-2019

yes, you need parallel or openmp. DOCONCURRENT is implemented with OpenMP.

Linux gives a warning, does Windows?

ifort -o u809003-3 u809003-3.f90
u809003-3.f90(13): warning #5423: Locality information is ignored without one of these command line qualifiers '-qopenmp or -parallel'
do concurrent (integer :: i = 1:n) local(x,r) local_init(y) shared(z)

Ron_Green · ‎05-08-2019

opps forgot the runtime:

ifort -o u809003-3 u809003-3.f90 -qopenmp
rwgreen@orcsle159:~/quad/U809008-3$ ./u809003-3
1.000000 2.000000 4.000000 4.000000

Ron_Green · ‎05-08-2019

Ooo but look - A BUG!!! -parallel does NOT work

ifort -o u809003-3 u809003-3.f90 -parallel
rwgreen@orcsle159:~/quad/U809008-3$ ./u809003-3
10001.00 2.000000 4.000000 2.000000

good thing I checked parallel. Parallel makes more sense in the context of DOCONCURRENT.
I'll write up a bug report, thanks for showing this to us!! Bug ID CMPLRIL0-31589

Ron

Arjen_Markus · ‎05-08-2019

Yes, I got the compiler message when I left out the options and then chose - Qparallel (-parallel) as that indeed is the more natural one :) in this context.