Continued problems in ifort v19 Update 1

[Juergen_R_R]

Unfortunately (as in the beginning of the ifort17 release series) there is still a regression lingering around that was already present in the first version of ifort v19 beta, was not resolved in Update 1, and then partially resolved in the final release v19.0.0. Now, after I reported a support ticket (#03646329), the problem again was only partially solved. The remaining part is really difficult to boil down. It is a runtime error

forrtl: severe (151): allocatable array is already allocated

for the following peace of code:

  type :: resonance_contributors_t
     integer, dimension(:), allocatable :: c
   contains
    [...]
  end type resonance_contributors_t

  pure subroutine resonance_contributors_assign (contributors_out, contributors_in)
    class(resonance_contributors_t), intent(inout) :: contributors_out
    class(resonance_contributors_t), intent(in) :: contributors_in
    if (allocated (contributors_out%c))  deallocate (contributors_out%c)
    if (allocated (contributors_in%c)) then
       allocate (contributors_out%c (size (contributors_in%c)))
       contributors_out%c = contributors_in%c
    end if
  end subroutine resonance_contributors_assign

The problem is in the line 

allocate (contributors_out%c (size (contributors_in%c)))

where ifort 19 erroneously believes that contributors_out%c (or maybe contributors?) is already allocated.

It is very hard to isolate this issue. Our code unfortunately has many tests which use a Fortran code generator written in OCaml that is mandatory for the tests where the problem occurs. The code can be found here: http://whizard.tp.nt.uni-siegen.de/tarballs/whizard-nightly-latest.tar.gz

You just download, unpack, make a _build directory, and the perform ../configure FC=ifort F77=ifort

and then do 'make'. The failing functional tests are resonance_1 to resonances_6 and resonances_9 to resonances_11.

You can execute them in _build/tests/functional_tests with 'make check TESTS=resonances_1.run'   e.g.

[Steve_Lionel]

I suggest that you submit an issue through the Intel Online Service Center. Posting in the forum is not likely to get the required attention.

[Juergen_R_R]

Thanks, Steve. Sometimes one gets really, really helpful remarks here. But according to your advice, I opened another issue on that topic, #03768779.

[Steve_Lionel]

In any case that involves a potential compiler bug, always submit a bug report to the vendor. 

[FortranFan]

Steve Lionel (Ret.) wrote:

I suggest that you submit an issue through the Intel Online Service Center. Posting in the forum is not likely to get the required attention.

Original post suggests support requests have been submitted at OSC.

Note there is a larger issue with compiler regression that is indicated by OP in this post and also previously with 18.0 and 19.0 official releases:

• regressions in BETA versions identified and submitted at OSC even in June/July timeframe i.e., early enough in the release cycle do not seem to get fixed in the official release that comes usually in October,
• regressions in the official release for which support requests are made in October can take a while to get resolved i.e., Update 1, 2, .. may not include the fixes.

Product stewardship would ordinarily indicate intense effort to resolve all product regressions ASAP but that it's unclear to Intel Fortran customers the level of focus and turnaround achieved with Intel Fortran compiler regressions; posts like this suggest poor success rate in resolving regressions.  Intel Fortran support and development staff would do well to address this.

[FortranFan]

Juergen R. wrote:

Thanks, Steve. Sometimes one gets really, really helpful remarks here. But according to your advice, I opened another issue on that topic, #03768779.

@Juergen R.,

Are you employing the interprocedural optimization -ipo compiler option?  There appears to be some issue (I don't have full  details yet) with this option and generic bindings for defined assignments in derived types.  Perhaps you can try without this option in case you are using and check if that indicates anything.

[mecej4]

Juergen, would it be correct to assume that this bug did not exist in any release of IFort 18? In other words, is 19.0 the release that first displayed this bug?

[Juergen_R_R]

Yes this started with ifort 19beta. So it is a v19 regression.

[Juergen_R_R]

@FortranFan  No, no -ipo flag, we just use the flags that autotools/libtool usually sets, which is -O2 -g I believe.

Concerning the regression, I thought it is just one specific bug because the failures were all in tests testing one specific feature of our code, but maybe there are different facets, or maybe there is even more than one issue as Steve mentioned. Our unit tests usually can be fairly transferred into reproducers, while for the functional tests this is not so easy, and we do have also a person-power problem at the moment. Intel support took my reproducer from the unit tests and seem to have fixed this bug, but they didn't look into the functional tests yet. And I didn't try to come with a possibly shorter reproducer because I was lacking their feedback.

[mecej4]

In March 2018, I had filed support ticket 03350148 related to a bug in formatted output with format G0.d, for d > 10. Just now, I was notified that the bug had been fixed, to check which I downloaded and installed Ifort 2019U1 on Windows an hour ago. With the new compiler at hand, I tried it on the following program, which is basically what Juergen reported above as the problem code, fleshed out to make a complete program.

module res_con
   type :: resonance_contributors_t
      integer, dimension(:), allocatable :: c
   end type resonance_contributors_t
contains

pure subroutine resonance_contributors_assign (contributors_out, contributors_in)
   class(resonance_contributors_t), intent(inout) :: contributors_out
   class(resonance_contributors_t), intent(in) :: contributors_in
   if (allocated (contributors_out%c))  deallocate (contributors_out%c)
   if (allocated (contributors_in%c)) then
      allocate (contributors_out%c (size (contributors_in%c)))
      contributors_out%c = contributors_in%c
   end if
end subroutine resonance_contributors_assign
end module

program tst
use res_con
!
type(resonance_contributors_t) :: rci, rco
allocate(rci%c(3))
rci%c = [1,2,3]
call resonance_contributors_assign(rco, rci)
print *,rci%c
end program tst

The program ran without error when compiled with Ifort 19.0U1 on Windows with default options.

[Juergen_R_R]

Well, mecej4, unfortunately it is not so simple. So the context in which we get the problems is a more complicated setup where it fails. Please try out our full example.