Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Moderator
74 Views

Time to test this year's Intel Fortran 2020 Beta

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

0 Kudos
15 Replies
Highlighted
Honored Contributor I
74 Views

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, 

0 Kudos
Highlighted
Black Belt Retired Employee
74 Views

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

0 Kudos
Highlighted
Valued Contributor III
74 Views

wow so many new goodies.

0 Kudos
Highlighted
Valued Contributor II
74 Views

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?

0 Kudos
Highlighted
Beginner
74 Views

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!

0 Kudos
Highlighted
Moderator
74 Views

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.

0 Kudos
Highlighted
Valued Contributor II
74 Views

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.

     

    0 Kudos
    Highlighted
    74 Views

    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

    0 Kudos
    Highlighted
    Valued Contributor II
    74 Views

    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)

     

    0 Kudos
    Highlighted
    Valued Contributor II
    74 Views

    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.

    0 Kudos
    Highlighted
    Valued Contributor II
    74 Views

    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?

     

    0 Kudos
    Highlighted
    Moderator
    74 Views

    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)

    0 Kudos
    Highlighted
    Moderator
    74 Views

    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

    0 Kudos
    Highlighted
    Moderator
    74 Views

    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

    0 Kudos
    Highlighted
    Valued Contributor II
    74 Views

    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.

    0 Kudos