Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

iFort changes since 2020-10?

AONym
New Contributor II
843 Views

I have been trying to get a list of changes/fixes to the  iFort Classic compiler since the 2020-10 release. The release notes say only "Bug fixes", and Premier Support refuses to provide any more information.

The new oneAPI version of the compiler lacks important features that we need, and Premier Support told me they were not expected for another year, if ever.

Furthermore, iFort Classic doesn't even seem to be supported any more, since when I attempt to post a request for more info, it says "This product is now supported in the Intel Forums".

0 Kudos
7 Replies
Steve_Lionel
Honored Contributor III
822 Views

Intel stopped providing lists of bug fixes at least five years ago. To be honest, and as someone who spent a lot of time writing these, they're really not that helpful. Most bugs require a rather specific combination of code to trigger, not something you can explain in a pithy release note. Furthermore, many users would seize on a particular bug fix, say "that's my problem!", and be disappointed when it turns out that their code triggers a different, but similar-sounding bug.

If you have paid support, you have access to Intel Premier Support, even for the Classic compiler. If your support has expired, or you're using a noncommercial license (or oneAPI without buying support), then the forums are where you go.

I am curious as to what feature is missing from the oneAPI Classic compiler (don't use ifx for production work), as it is one of only two full-language F2018 compilers out there.

The release notes do list new features.

0 Kudos
AONym
New Contributor II
807 Views

Steve, I'm glad to see you're still active in the Fortran community. Intel support has not been the same without you.

When I attempted to compile my project with ifx, I got (among numerous other errors):

ifx: command line warning #10148: option '/QaxCORE-AVX2' not supported

ifx: command line warning #10148: option '/Qparallel' not supported

C:/AUC/MyProject/MyProject_libFortran\RationalArithmetic.f90(265): catastrophic error: **Internal compiler error: internal abort** Please report this error along with the circumstances in which it occurred in a Software Problem Report. Note: File and line given may not be explicit cause of this error.
ifx: error #10298: problem during post processing of parallel object compilation

Premier Support told me they had a fix for the above internal compiler error, but also that the Beta ifx compiler is still quite raw (in April 2021). That means it cannot be used for production sw.

"Note that ifx doesn't have the Qax feature (multiple path creation for vectoorization and auto-dispatching). The alternative is to use Qx.

Qparallel is also not available. The demand for this option was too low since it was able to auto-parallelize only some trivial loops via OpenMP."

The paid support expired in June, but I can't get an answer to my questions that are outstanding, nor any idea of when or whether ifx will be usable.

As far as your comments on bug lists, of course, I'm most interested in fixes to the bugs I reported. I'm sure Intel has some internal system for tracking bug reports; is it too much to ask to see a list of these, no additional work on Intel's part involved.

At this point, it looks to me as if Intel is no longer supporting iFort, and since I can't use ifx, I'm stuck.

0 Kudos
Steve_Lionel
Honored Contributor III
791 Views

You are incorrect in saying Intel is not supporting ifort. Use ifort, not ifx. I expect it will be 2-3 years before ifx becomes ready to replace ifort.

AONym
New Contributor II
771 Views

Steve, thanks for the advice; you have an excellent record of being right in the past.

So, I guess I will be using ifort, and just hoping Intel will be fixing some of the problems (and improving communication).

Most of those problems are in the Visual Studio integration, and in the past they have not changed ifort much in the respect.

0 Kudos
Steve_Lionel
Honored Contributor III
763 Views

What problems are you seeing in Visual Studio? I do know that debugger issues have been fixed recently, so it's not correct to say that there are no changes.

0 Kudos
AONym
New Contributor II
733 Views

1) Step 1 line (F10) doesn't work properly. It checks every suboperation on the line, so, for example, a line `a(1:10000)=0` takes forever to step over.

2) Data tips for variables don't work properly. When a variable is shown in a pgm, its value should be available (for a debug build). This should be true for arguments, variables in modules, as well as stack variables and allocated variables.

3) Go to definition doesn't work properly. For any variable, it should be able to find the definition, but it fails about 50% of the time.

4) Auto (display of variables in the current few lines) isn't implemented. Even if data tips worked 100% correctly, Auto is still a big time saver.

5) Display of the stack is not always correct. Often, only the last few frames are shown.

6) There is no way to get the machine address of a Fortran variable from the debugger. This is sometimes needed to figure out why a pgm isn't working properly.

7) Display of Locals shows all variables as all upper-case. I realize for purposes of the compiler these are correct, but for debugging it is a lot easier to have variables shown as they are written in the pgm (or definition).

There is no way to see variables in individual threads, making debugging multi-threaded pgms much more difficult.

9) The project properties windows are using some old VS protocol that doesn't have the editing features the current protocol has, for instance, display of macros and their resolution.

These are some problems off the top of my head. I've reported most of these to Premier Support, but no joy.

0 Kudos
Steve_Lionel
Honored Contributor III
723 Views

Most of these are feature requests.  The issue of stepping over array assignments has been around for a long time, though I have seen improvements. The way the VS debugger works is to step by instruction and check to see if the line number changes. Clearly for an operation that takes hundreds of thousands of instructions, this can be time-consuming. 

Part of the problem is that Microsoft makes limited functionality available to the Fortran integration. What is implemented should work. 

As for your #6, you can do this. Just type LOC(varname) in the Memory window.

 

0 Kudos
Reply