Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Matt_Thompson
Novice
169 Views

Fortran Regression with Intel 2021.1.1

For some reason, I wasn't allowed/able to open a Support Ticket (#04949042) for this because of some reason (I do have an Intel license and have opened tickets in the past), so I'll post it here as suggested in case someone can help.

We have a code that works with Intel 19.1.3 but fails with 2021.1.1. We've managed to boil the code down to a reproducer (attached).

To wit, with Intel 19.1.3:

$ ifort -V
Intel(R) Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 19.1.3.304 Build 20200925_000000
Copyright (C) 1985-2020 Intel Corporation. All rights reserved.

$ ifort -g -O0 gFTL-2021.1.1_reproducer.F90
$ ./a.out
adding
adding
adding
erasing
$ echo $?
0

 

With Intel 2021.1.1:

$ ifort -V
Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running on Intel(R) 64, Version 2021.1 Build 20201112_000000
Copyright (C) 1985-2020 Intel Corporation. All rights reserved.

$ ifort -g -O0 gFTL-2021.1.1_reproducer.F90
$ ./a.out
adding
adding
adding
erasing
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image PC Routine Line Source
a.out 0000000000424D4A Unknown Unknown Unknown
libpthread-2.22.s 00002AAAAAFDCC10 Unknown Unknown Unknown
a.out 0000000000416205 Unknown Unknown Unknown
a.out 0000000000416F21 Unknown Unknown Unknown
a.out 0000000000416F21 Unknown Unknown Unknown
a.out 0000000000418109 Unknown Unknown Unknown
a.out 000000000040FF8F Unknown Unknown Unknown
a.out 000000000040FA4C Unknown Unknown Unknown
a.out 0000000000413B2F Unknown Unknown Unknown
a.out 000000000041341E Unknown Unknown Unknown
a.out 0000000000413268 Unknown Unknown Unknown
a.out 00000000004029D2 Unknown Unknown Unknown
libc-2.22.so 00002AAAAB209725 __libc_start_main Unknown Unknown
a.out 00000000004028E9 Unknown Unknown Unknown
$ echo $?
174

 
I can reproduce this bug on SLES 12 and on macOS 10.15.7.

Now in the reproducer, if lines 1580-1582 are commented out and line 1583 is uncommented the code will run correctly.

So the offending code:

associate(a => this%elements(i-delta),b =>this%elements(i))
  a=b
end associate


and the "workaround" (when uncommented):

!!$ this%elements(i-delta) = this%elements(i)
 
Note: It's not easy for us to implement this workaround as this code is actually automatically generated via include files from a lower-level library. We are looking at putting in an "if intel 21" patch into that library, but it might take time. It would be nicer if Intel 2021 didn't seg fault!

 

0 Kudos
7 Replies
JohnNichols
Valued Contributor I
150 Views

I ran your code with VS 2019 Preview and the compiler is Classic 2021.1.2

In 32 bit code I got the following error 

Untitled.png

IN 64 bit code I got the following error 

UntitledA.png

I have no idea how to fix it -- but you asked the correct people. 

jimdempseyatthecove
Black Belt
139 Views

That program works using x64 Debug build on Windows:

Intel® Parallel Studio XE 2020 Composer Edition for Fortran Windows* Package ID: w_comp_lib_2020.0.166
Intel® Parallel Studio XE 2020 Composer Edition for Fortran Windows* Integration for Microsoft Visual Studio* 2019, Version 19.1.0055.16, Copyright © 2002-2019 Intel Corporation. All rights reserved.

Jim Dempsey

jimdempseyatthecove
Black Belt
135 Views

>> It's not easy for us to implement this workaround as this code is actually automatically generated via include files from a lower-level library.

Can you automatically edit the "automatically generated via include files from a lower-level library"?

BTW what is wrong with using the 19.1.3 version until a fix is available?

FWIW I've experienced issues with associate where it mostly works but in some cases it doesn't. There were (and may still be) issues relating to issues of using associate within a parallel region when using OpenMP (e.g. the associate name in some cases being shared as opposed to private).

Jim Dempsey

Matt_Thompson
Novice
126 Views

Can you automatically edit the "automatically generated via include files from a lower-level library"?

It's hard to see how. These files are #include'd much like how C++ has inclusions (the code is part of a Fortran package that emulates part of the C++ STL). Thus to correctly workaround this, the base library needs to be fixed so that it generates the correct code so when include the code at compile time, it has working code.

BTW what is wrong with using the 19.1.3 version until a fix is available?

We can use Intel 19.1.3, but my job is to make sure that our model isn't caught out by bugs in newly released compilers, MPI stacks, operating system updates, etc. This worked in Intel 19.1.3 and fails in Intel 2021.1, thus I consider it a regression and I wanted to report it. I also report any issues that are ICEs (internal compiler errors) on compilation, run-time errors like this, issues with Intel MPI, issues with Intel MPI, anything I see that worked in a previous version with Intel products and our model and now doesn't, I will report to Intel.

Moreover, since Intel oneAPI is now (essentially?) free, it's the first time we might be able to use Intel compilers in our CI setup for our model. Until now we have been using GNU because they are free, but our production is run with the Intel compilers. I was pretty sure it wasn't right that because we have a license for Intel at our supercomputing site that even if I could install Intel 19.1.3 somehow, it could be rightfully used on AWS/Google Cloud/Microsoft Azure/etc wherever GitHub Actions, CircleCI, Travis CI, etc. actually run. And I'm not a student, so I couldn't rightfully use a Student license either.

But if Intel oneAPI does now provide a free Intel Fortran compiler I can use in a CI system like AWS/Google Cloud/Microsoft Azure (by, say, putting into a docker image) without need of somehow installing FlexLM or whatever the Intel license server is, then I can look to make our CI work like our production system which is always a good thing for a CI system.

JohnNichols
Valued Contributor I
115 Views

Based on previous experience, I think you will be contacted by one of the Intel reps - I have a casual correspondence with one of them from time to time and I mentioned your problem and one other this morning.  Give them a day or so and I would not be surprised if you are not contacted.  

Barbara_P_Intel
Moderator
110 Views

Thanks for identifying the lines of code that cause the runtime failure!

I duplicated both the success and failure of this reproducer. I filed a bug on your behalf, CMPLRIL0-33592.  I'll keep you posted on the fix.

jimdempseyatthecove
Black Belt
97 Views

>>These files are #include'd much like how C++ has inclusions

If those #include files are automatically generated, then they can be automatically edited (remove the associate block) as a pre-process procedure (e.g. via dependency in make file or pre-build event in MS VS).

If those #include files are static, then these only need to be edited once.

Note (hint):

Because you are using #include (as opposed to Fortran include), you therefore are using the Fortran PreProcessor. It would be QED to make an edit procedure that converted the associate into #define..., and the end associate into the matching #undef...

The only side effect, is debugging will be a little awkward when trying to examine the substituted variables. Something I went through in years past (when updating a solution containing 750 source files from F77 to F95).

Jim Dempsey