Severe regressions in ifort17 and 18

[Juergen_R_R]

What happened to this once so great compiler? Since v17 and now in 18beta so many things are broken? How could that happen? I will try to come up with a list of issues, but I'm really frustrated. The full test case is here: http://www.hepforge.org/archive/whizard/whizard-2.4.1.tar.gz

Note that you need OCaml besides the ifort compiler. Just do configure, make, and then make check. 4 of 114 unit tests fail, and 127 of 224 functional tests. I'm not yet sure whether these are the same issue(s) that I already reported for the 17.0.X version of ifort. I will try to reduce this.

[Juergen_R_R]

This is with ifort2018 beta. In ifort v17.X I cannot test this with the double free or corruption problem. This is really frustrating. The was the heroic version 16.0.X that was working after hard efforts, but now, the ifort is completely broken since 2 years.

[Kevin_D_Intel]

Ok. Yes, I understand, it is frustrating. I have/will discuss this again w/management. Is the shower unit test and 10 functional tests in the bundle mentioned in your original post from this thread?

[Juergen_R_R]

Kevin, yes they are all part of the big tarball. However, you need to apply some of the patches that I mentioned in the other support tickets, e.g. to src/beams/dispatch_beams.f90. Within the next few days we are making a new release. This includes all the fixes known to us and will be sufficient to expose the problem. 

[FortranFan]

Juergen R. wrote:

.. There is, however, one thing which I cannot isolate. The basically insane message

forrtl: severe (153): allocatable array or pointer is not allocated

when hitting the line

if (allocated (prt%child))  deallocate (prt%child)

My attempts to construct a small test case failed. This definitely means that we cannot the Intel compiler any more. ..

So what shall I do?

If "child" here refers to a derived type whose components or subcomponents have the POINTER attribute, you may want to replace such components with the ALLOCATABLE option; it may help you greatly not just with Intel compiler but with your program in general especially with your lack of use of FINAL procedures but also with the somewhat muddy situation with finalization in the standard (e.g., buried in Fortran 2008 combined corrigenda that only limited number of folks seem to be aware of) and incomplete compiler implementations.

Note this is only based on what you show with main_ut.f90 where no use case is immediately apparent for the POINTER components in derived types (I have not looked at the big tarball from the original post), 

[Juergen_R_R]

Nope, they are all allocatables. No pointer components here. 

[Juergen_R_R]

Kevin, is there any progress on this issue? We tried to find the case but could not see where ifort screws up the code. I wrote something in the support request 02776855.  We could not isolate the problem, but it looks like as ifort confuses the allocate status of the derived type particle_t with the allocate status of its component child. The debugger didn't show anything beyond our debug attempts. We need someone here who is expert with the Intel compiler.  This might sound devastating but since ca. fall 2016 the Intel compiler so buggy that it has become impossible to use it anymore. 

[Kevin_D_Intel]

There is no progress on the earlier escalated issue, CMPLRS-42619. I pinged the assigned Developer on that one.

The other open issue discussed in this thread, related to using the original large test case and the shower unit + 10 functional tests, has not been escalated. We do not yet have the required OCaml component available within our lab to complete the configure. You mentioned planning a new build that incorporated various work around/changes from this and your other Premier issues. If that's available, could you attach it to your request 02776855?

I'm sorry to hear that about our compiler's stability/usability. Hopefully we can change the direction on that.

[Juergen_R_R]

Great, Kevin, thanks. Update 4 of ifort17 fixed all open issues for that version of the compiler, so finally ifort 17 works for our complete code again. We are looking forward to see all remaining issues to be fixed before official release of ifort 18 as well. :)

[Kevin_D_Intel]

Glad to hear that. My results using the original code (unmodified) attached in this thread w/17.0 update 4 and 18.0 Beta are attached. I don't know how those compare but again this is with no modifications.

[Juergen_R_R]

Well, as I said we made already many fixes in WHIZARD with Ifort 18. Most of them, or I think all, should be in our distribution 2.5.0.