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
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,
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?
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!
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.
Good :). Here is my test program:
program chkcosum implicit none real :: x
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.
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.
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)
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.
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?
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)
opps forgot the runtime:
ifort -o u809003-3 u809003-3.f90 -qopenmp
1.000000 2.000000 4.000000 4.000000
Ooo but look - A BUG!!! -parallel does NOT work
ifort -o u809003-3 u809003-3.f90 -parallel
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
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.