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

Regressions in new release

Juergen_R_R
Valued Contributor I
1,586 Views

The new release contains some regressions like in 17.0.0 and 18.0.0. Our problems have been reported already as support ticket 03646329, and here are the details:

Our software, which you can download from here: http://www.hepforge.org/archive/whizard/whizard-2.6.4.tar.gz
With ifort v19.0.0.117 we observe (though we have already reported errors along these lines!) failures in 5/125 unit tests and 12/277 functional tests are failing. To run the full tests, you need the OCaml compiler, v3.12.0 or newer. Then just do
./configure, make, make check. The unit tests can be separately run in the directory tests/unit_tests, and the functional tests in tests/functional_tests

0 Kudos
41 Replies
Juergen_R_R
Valued Contributor I
516 Views

I provided a 832 lines reproducer to the Intel team, that should be enough.

0 Kudos
FortranFan
Honored Contributor II
516 Views

Juergen R. wrote:

I provided a 832 lines reproducer to the Intel team, that should be enough.

832/844 (Quote #14) - what's in the number of lines, is there a difference?!!!

Anyways, if this "832 lines of reproducer" is the same as the main-ut.f90 in Quote #12 (which has 844 lines per a text editor but that's including some blank lines in the attachment with Quote #12), it appears Intel software team likely fixed the regression issue in Update 1 itself and it remains fixed with Update 2 also.

 

0 Kudos
Juergen_R_R
Valued Contributor I
516 Views

Well, this is just a short reproducer. Apparently, this seems to work, but it is not the whole story. Only the full tests exhibit the behavior. For the moment, we don't have the personpower to tackle this issue, so for us ifort 19 remains excluded.

0 Kudos
FortranFan
Honored Contributor II
516 Views

Juergen R. wrote:

Well, this is just a short reproducer. Apparently, this seems to work, but it is not the whole story. Only the full tests exhibit the behavior. For the moment, we don't have the personpower to tackle this issue, so for us ifort 19 remains excluded.

@Juergen R.,

You're contradicting yourself now with respect to your earlier comment, "I provided a 832 lines reproducer to the Intel team, that should be enough."  It appears Intel Fortran team helped you resolve the problem in the one clear case you submitted.

Now that you write, "Only the full tests exhibit the behavior" and the indication that for anyone, especially Intel support staff, to run your full tests would need other resources (e.g., OCaml compiler) means the issue you're presenting is unreasonable and also unknowable in terms of root cause.

You may think it is a regression because the tests ran successfully with an earlier Intel Fortran compiler version or other compilers.  But the reality can be different.  Whizard code uses a lot of features from Fortran 2003 and later standard revisions.  It's possible also Intel Fortran 19.0 and later updates have the standard-conforming implementation of some of these features which then lead to errors in your tests.

Until you/Whizard team can expend the "personpower" to narrow down the issue, your claim of regression and "disappointments" with Intel Fortran should remain questionable.

0 Kudos
Juergen_R_R
Valued Contributor I
516 Views

Questionable remains solely the purpose of your replies. Relevant is that responses from other compiler teams until now were much more efficient than the Intel team. Of course it can happen that I was not successful in narrowing down the case, but that's also not my job, I am not a software developer.

0 Kudos
FortranFan
Honored Contributor II
516 Views

Juergen R. wrote:

Questionable remains solely the purpose of your replies. Relevant is that responses from other compiler teams until now were much more efficient than the Intel team. Of course it can happen that I was not successful in narrowing down the case, but that's also not my job, I am not a software developer.

As a forum reader and more importantly a user of Intel Fortran compiler, I remain alarmed by the title of this post, "the new release is completely unusable because of severe regressions".  Quote #18 is of further concern.  The purpose of my replies here is to share my concerns the accuracy of information posted by OP in this thread re: the Intel Fortran compiler; this is so that OP and possibly Intel staff and other readers can clear the matters for OP and I and all others so no one is misdirected and otherwise misinformed regarding Intel Fortran compiler product.

I request Intel forum administration staff to take note here this is not happening thus far.  Phrases such as "completely unusable" are too absolute to be any help to me as a reader and Intel Fortran user, subsequent posts re: continued regression in Intel Fortran product appear unverified.

Neither is a comment such as "Relevant is that responses from other compiler teams were much more efficient than the Intel team." beneficial for me with my experience as a user of Intel Fortran, particularly noting the lack of any discernible corroborative evidence by OP to accompany the comment.

0 Kudos
Juergen_R_R
Valued Contributor I
516 Views

Regarding the most recent post: from my history I can tell that since 2016, our experience with the fixing of regressions with gfortran and nagfor has been much more efficient than with Intel, Intel always took much longer to get regressions fixed, and cases like this where it is tricky to get to know what is going on, we got much better and more direct help than with Intel. Before 2016, there was a support representative of Intel in my country to whom we had direct contact and who were helpful in the very same manner, and because of the direct contact even better. Unfortunately, that person retired and Intel reorganized their support. Response times are not very fast and always indirect, but in the same way it is for PGI.

Regarding our code, well yes, most of our features are usable, one particular feature is not at the moment with ifort 19. We still have to figure out what the problem is, whether it is a problem with the compiler, or maybe a code inconsistency. The latter was not found or confirmed by the Intel team. This feature in our code is still not working with Update 2. These are the facts.

0 Kudos
mecej4
Honored Contributor III
516 Views

Jürgen, for what it is worth, here is what I got from running the a.out produced by NAG 6.2 - build 6223, with -C=undefined -g for the code in #12:

Resonance history with 0 resonances:
Resonance history with 1 resonances:
  Resonance contributors: 1 2 f(-24)
Segmentation fault (core dumped)

Rerunning under GDB shows the SIGSEGV to occur on line 444.

This could well be a fault in the code produced by the NAG compiler, but when a SIGSEGV occurs we have an opportunity to capture an error in the program or the compiler. 

0 Kudos
Juergen_R_R
Valued Contributor I
516 Views

Dear mecej4, we run in our CI our code with nagfor with -C=all, it doesn't report any problems with any of our tests. Probably at some point I reduced our test case to radically.

 

0 Kudos
mecej4
Honored Contributor III
516 Views

Jürgen, even with your reduced code of #12, I do not see any error unless I use -C=undefined with the NAG compiler. Perhaps, there is a complication because an INTENT(OUT) variable with allocatable components is interacting with realloc-lhs actions.

0 Kudos
Juergen_R_R
Valued Contributor I
516 Views

Well, yes, this test case now also seems to work with Intel 19 Update 2, as far as I can see. However, there are still our failing tests in the test suite. For the moment, I don't have time to look into this, so we have to keep v19 out of our hands.

0 Kudos
FortranFan
Honored Contributor II
516 Views

mecej4 wrote:

Jürgen, for what it is worth, here is what I got from running the a.out produced by NAG 6.2 - build 6223, with -C=undefined -g for the code in #12:

Resonance history with 0 resonances:
Resonance history with 1 resonances:
  Resonance contributors: 1 2 f(-24)
Segmentation fault (core dumped)

Rerunning under GDB shows the SIGSEGV to occur on line 444.

This could well be a fault in the code produced by the NAG compiler, but when a SIGSEGV occurs we have an opportunity to capture an error in the program or the compiler. 

"SIGSEGV to occur on line 444" with NAG compiler, eh?  See Quote #17 dated Sep. 18, 2018 above where I had pointed out the assignment instruction on line 444 and my suggestions to both Intel support as well as OP to investigate re: the combination of defined and intrinsic assignments with the complicated derived type design used in this code.

It appears to me Intel Fortran support staff did indeed follow up and fix the regression with the derived type assignment in Intel Fortran compiler starting with Update 1 - kudos to them.

0 Kudos
Steve_Lionel
Honored Contributor III
516 Views

As a former support engineer, I can't begin to tell you how frustratingly useless it is to have a customer say "I can't use your product but I'm not going to lift a finger to help you find and fix the problem - you'll just have to guess." It's great if you can send a reduced test case, but always include the full application as well it is often the case that different bugs are at play even if they have a similar appearance.

If you can't be bothered to send Intel your actual application, then it's not appropriate for you to make blanket statements about it being "unusable". Sure, it doesn't work for you - I get that. If you want that to change, make the effort.

0 Kudos
FortranFan
Honored Contributor II
516 Views

Juergen R. wrote:

Well, yes, this test case now also seems to work with Intel 19 Update 2, as far as I can see. However, there are still our failing tests in the test suite. For the moment, I don't have time to look into this, so we have to keep v19 out of our hands.

Intel support staff,

As a forum reader and a user of Intel Fortran compiler, my hope and expectation is to find accurate and beneficial information re: Intel Fortran compiler on the Intel software forums and not be misled and misinformed by possibly incomplete, unverified, or even incorrect postings on your product such as with regressions in compiler updates.

Attached please find a Windows OS zip containing Microsoft Visual Studio (VS) solution and VS projects with the source code mentioned in the original post of this thread which is my attempt to put together a workable reproducer of the unit tests alluded to by OP.  Please note the Fortran project has ~25 files with thousands of lines of code, mostly downloaded unchanged from the link in the original post while 3 of the files - kinds.f90, system_dependencies_f90, and main_ut.f90 - are "best guess" additions of code to achieve a functioning executable.  There is also a C project with essentially a "dummy" signal_interface.c file to complete the link step

expl.PNG

Please note the above attempt at a workable program has failed to reproduce the errors in the unit tests claimed by OP in this thread and this one: upon building and execution using Intel Fortran 19.0 Update 2 of such big code outputs the following:

C:\Temp\main-ut>main_ut64.exe
Running test: resonances_1Test: resonances_1
 ... success.
  Success.
Running test: resonances_2Test: resonances_2
 ... success.
  Success.
Running test: resonances_3Test: resonances_3
 ... success.
  Success.
Running test: resonances_4Test: resonances_4
 ... success.
  Success.
Running test: resonances_5Test: resonances_5
 ... success.
  Success.
Running test: resonances_6Test: resonances_6
 ... success.
  Success.
Running test: resonances_7Test: resonances_7
 ... success.
  Success.

C:\Temp\main-ut>

If Intel staff indeed intends to support OP with supposed issues with regression(s) in Intel Fortran compiler, the attached zip can be utilized in which way Intel staff sees fit to guide the resolution process.

As a user of Intel Fortran, I am pleased to see a program involving such complicated code with large amounts of instructions execute as supposedly intended using ifort 19.0.2.  On the other hand, postings regarding "continued regressions" alarm and bother me, especially when they are not accompanied by reproducers, that independent efforts too do not reveal problems with Intel Fortran compiler as captured in the attached zip of this post and also shown in Quote #21.

If Intel staff intends to support this issue, I request please for Intel support to do what will be called in the urban lingo "take it offline, guys!"  Meaning work directly with OP via OSC/private communication channels in a manner that does not lead to airing by OP of whatever grievances there may be on the Intel Fortran forum.

Thank you.

 

0 Kudos
Juergen_R_R
Valued Contributor I
516 Views

Steve Lionel (Ret.) wrote:

As a former support engineer, I can't begin to tell you how frustratingly useless it is to have a customer say "I can't use your product but I'm not going to lift a finger to help you find and fix the problem - you'll just have to guess." It's great if you can send a reduced test case, but always include the full application as well it is often the case that different bugs are at play even if they have a similar appearance.

If you can't be bothered to send Intel your actual application, then it's not appropriate for you to make blanket statements about it being "unusable". Sure, it doesn't work for you - I get that. If you want that to change, make the effort.

Don't worry, Steve, I send the Intel support team the full application, and gave them detailed instructions what to do to check the full application.

0 Kudos
Steve_Lionel
Honored Contributor III
516 Views

Thanks, Juergen. I hope you submitted this through https://supporttickets.intel.com/?lang=en-US as that's the fastest and best way to get attention to the topic.

0 Kudos
Juergen_R_R
Valued Contributor I
516 Views

FortranFan wrote:

Quote:

Juergen R. wrote:

 

Well, yes, this test case now also seems to work with Intel 19 Update 2, as far as I can see. However, there are still our failing tests in the test suite. For the moment, I don't have time to look into this, so we have to keep v19 out of our hands.

 

 

Intel support staff,

As a forum reader and a user of Intel Fortran compiler, my hope and expectation is to find accurate and beneficial information re: Intel Fortran compiler on the Intel software forums and not be misled and misinformed by possibly incomplete, unverified, or even incorrect postings on your product such as with regressions in compiler updates.

 

 

 

  On the other hand, postings regarding "continued regressions" alarm and bother me, especially when they are not accompanied by reproducers.

If Intel staff intends to support this issue, I request please for Intel support to do what will be called in the urban lingo "take it offline, guys!"  Meaning work directly with OP via OSC/private communication channels in a manner that does not lead to airing by OP of whatever grievances there may be on the Intel Fortran forum.

 

 

FortranFan, you tested our resonances unit test which indeed seem to be working since Update 1 of ifort19 again. Did you also test our resonance_insertion, restricted_subprocesses and simulations self tests or our functional tests resonances_X (X=1,....,9)? They are still leading to errors like that one:

| Phase space: keeping configuration file 'simulations_14_p.i1.phs'
| Creating library for resonant subprocesses 'simulations_14_p_R'
| Process library 'simulations_14_p_R': initialized
forrtl: severe (151): allocatable array is already allocated
Image              PC                Routine            Line        Source             
lt-whizard_ut      00000000012BD35B  for_alloc_allocat     Unknown  Unknown
libwhizard.so.1.0  00007F9AA37CDFD6  resonances_mp_res     Unknown  Unknown
lt-whizard_ut      0000000001274553  Unknown               Unknown  Unknown
lt-whizard_ut      000000000127382A  Unknown               Unknown  Unknown
lt-whizard_ut      00000000012736D3  Unknown               Unknown  Unknown
lt-whizard_ut      00000000012736D3  Unknown               Unknown  Unknown
lt-whizard_ut      0000000001274E1E  for_alloc_assign_     Unknown  Unknown
libwhizard.so.1.0  00007F9AA26FAD00  restricted_subpro     Unknown  Unknown
libwhizard.so.1.0  00007F9AA27822E5  simulations_mp_en     Unknown  Unknown
libwhizard.so.1.0  00007F9AA273D770  simulations_mp_en     Unknown  Unknown
libwhizard.so.1.0  00007F9AA27ABE9F  simulations_mp_si     Unknown  Unknown
lt-whizard_ut      00000000009E2E6C  Unknown               Unknown  Unknown
libwhizard.so.1.0  00007F9AA3EDC0B9  unit_tests_mp_tes     Unknown  Unknown
lt-whizard_ut      000000000093D70D  Unknown               Unknown  Unknown
lt-whizard_ut      00000000006B5935  Unknown               Unknown  Unknown
lt-whizard_ut      000000000069AC6D  Unknown               Unknown  Unknown
lt-whizard_ut      0000000000698A72  Unknown               Unknown  Unknown
libc-2.23.so       00007F9A9D4CF830  __libc_start_main     Unknown  Unknown
lt-whizard_ut      0000000000698969  Unknown               Unknown  Unknown

 

In your comment at the end, are you seriously proposing to block free opinions in a forum? I know that this is en vogue these days, but one should not follow these trends. I think I had much more reasons to ask for take you offline, which I don't do as I don't want to fall to that level.

Fact is: there are still non-fixed issues, which are regressions being open since at least early September last year (looking back at my first reports).

0 Kudos
Juergen_R_R
Valued Contributor I
516 Views

There is another regression with allocatable components of recursive type here:

https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/804769

0 Kudos
FortranFan
Honored Contributor II
516 Views

Juergen R. wrote:

.. FortranFan, you tested our resonances unit test which indeed seem to be working since Update 1 of ifort19 again. Did you also test our resonance_insertion, restricted_subprocesses and simulations self tests or our functional tests resonances_X (X=1,....,9)? They are still leading to errors like that one ..

In your comment at the end, are you seriously proposing to block free opinions in a forum? I know that this is en vogue these days, but one should not follow these trends. ..

 

@Juergen R.,

Re: "Did you also test our resonance_insertion ... " - no, I don't know at the moment how to run these other tests you mention, note I've no domain knowledge of Whizard code, I have no access whatsoever to OCaml (or even a Linux box for that matter most of the time), or most tools toward scripting or preprocessing and make/build (other than Microsoft VS and Intel Fortran integration).  As you yourself write, what you have is "not so simple. So the context in which .. get the problems is a more complicated setup "  This is why in Quote #21 I suggested you/Whizard team put together Fortran test cases, meaning no OCaml, scripting, etc.. But if you/Whizard team do not have the time for it and/or you feel "it's not" your "job", well you will find few support organizations are going to be able to follow up on the issues either.  Also, the reason why I provided the zip attachment in Quote #35 is so that someone can build on the Fortran project therein and extend it with other tests and given the use of Microsoft VS IDE which has very good graphical debugging capabilities, it may be much easier to track or narrow down any Intel Fortran compiler problem(s).

Re: "are you seriously proposing to block free opinions in a forum" - no, absolutely not.  Just as with "free opinions" in society are also tempered with restrictions toward not shouting fire in a crowded theater or not indulge in libel or not going against non-disclosure (marriage, business, licensing, etc.) arrangements, the earlier title of this post and some of the absolute/categorical assertions are what suggest a direct, separate customer-supplier resolution process between Intel support and Whizard team, no need to "air the dirty laundry" on the forum, so to speak.  Readers can request certain moderation when forum posts become more of a "complaints box", especially when things are not at all straightforward when it comes to Fortran, as in the highly complicated set of resonance unit tests working fine as in Quote #35 yet seeing the thread resurface with the earlier title 

 

0 Kudos
FortranFan
Honored Contributor II
504 Views

Juergen R. wrote:

There is another regression with allocatable components of recursive type here:

https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux...

I agree the severe run-time error (153) involving allocatable components of a recursive type (a feature introduced in Fortran 2008) that is reported in this linked thread is a regression in 19.0 including Updates 1 and 2 relative to 18.0.x versions of Intel Fortran.

I don't know if it is related to the "severe (151): allocatable array is already allocated" error mentioned here.

I'll find it useful (and perhaps other readers too) if there is a Fortran-related explanation available which is shared here of any connection between these 2 errors.

0 Kudos
Devorah_H_Intel
Moderator
504 Views

An Update 3 is coming very shortly and is expected to have the anticipated bugfixes. This thread is locked for further review. Thank you all for your contributions. 

Please contact Intel Support via support tickets for questions on specific bugfixes and status updates.

0 Kudos
Reply