topic Dear mecej4, we run in our CI in Intel® Fortran Compiler

Regressions in new release

Juergen_R_R — Thu, 13 Sep 2018 14:24:38 GMT

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

Hi Jürgen,

Janus — Fri, 14 Sep 2018 08:23:24 GMT

Hi Jürgen,

first off, I unfortunately have to agree with your assessment that all the recent ifort releases had severe quality issues. The 18.x releases were (and still are) particularly problematic for us (showing at least four wrong-code regressions that were not present in 17.x, and are still unfixed on 18.x). 19.0 actually seems to be a bit better for our purpose from what I see so far.

Regarding your issues: What you report seems to be at least one (or even several) runtime regressions, going from 18.3 to 19.0. Correct?

I have recently tried my cmake script that runs part of the gfortran testsuite (already reported here earlier) on ifort 19.0, using the test base from the current GCC trunk (see https://github.com/janusw/gcc/commits/janus/gfortran_testing). The (possible) runtime regressions of 19.0 (wrt 18.3) that I find with this method are the following:

coarray/allocate_errgmsg.f90
coarray/dummy_1.f90
coarray/get_array.f90
coarray/lock_2.f90
coarray/scalar_alloc_1.f90
coarray/sendget_array.f90
dtio_1.f90
mod_large_1.f90
read_eof_all.f90

Note that I have not yet verified for all these cases whether they are actual ifort 19 bugs. But they might be starting points to look into. If you're not using coarrays, that leaves only three cases.

In case you find out more details about what triggers the issues in your testsuite, please report back here.

Cheers,

Janus

Fully agree,

may_ka — Fri, 14 Sep 2018 11:26:05 GMT

Fully agree,

this code is screwed already:

Module mod_test_1
  implicit none
  Private
  Type, Public :: test_1
  End type test_1
End Module mod_test_1
Module Mod_test_2
  use Mod_test_1, only: test_1
  implicit none
  Private
  Type, Public :: test_2
  contains
    Procedure, Pass :: s1=>Sub1
  end type test_2
  Interface
    Module Subroutine Sub1(this)
      Class(test_2), Intent(Inout) :: this
    end Subroutine
  End Interface
end Module Mod_test_2
SubModule(Mod_test_2) smod_test_2
contains
  Module Procedure sub1
    Implicit None
    Type(test_1) :: a
  end procedure
end SubModule smod_test_2

ifort 19 cannot handle the "private" statement in module "mod_test_2", but it runs in 17.07, 18.03 and gfortran 8.2. Therefore I assume a bug.

Intel really starts to suck. I am still stuck at 17.07 because all 18 releases were unusable, (still waiting for 18.04). Was hoping 19 will fix it but bad luck.

Quote:may.ka wrote:

FortranFan — Fri, 14 Sep 2018 16:27:39 GMT

may.ka wrote:

.. this code is screwed already: ..

ifort 19 cannot handle the "private" statement in module "mod_test_2", but it runs in 17.07, 18.03 and gfortran 8.2. Therefore I assume a bug. ..

@may.ka,

Trust you will submit a support request for this regression at the Intel OSC? In it, you can request this nice case be added to the regression test suite for the Fortran compiler.

Quote:Janus wrote:

Janus — Fri, 14 Sep 2018 19:01:49 GMT

Janus wrote:

The (possible) runtime regressions of 19.0 (wrt 18.3) that I find with this method are the following:

coarray/allocate_errgmsg.f90

coarray/dummy_1.f90

coarray/get_array.f90

coarray/lock_2.f90

coarray/scalar_alloc_1.f90

coarray/sendget_array.f90

dtio_1.f90

mod_large_1.f90

read_eof_all.f90

Starting with the non-coarray tests, I just had a closer look at dtio_1.f90. Does look like an actual regression. Here is a slight reduction:

MODULE p
USE ISO_FORTRAN_ENV
TYPE :: person
    CHARACTER (LEN=20) :: name = 'Charlie'
    INTEGER(4) :: age = 99
    CONTAINS
      procedure :: pwf
      GENERIC :: WRITE(FORMATTED) => pwf
END TYPE person
CONTAINS
SUBROUTINE pwf (dtv,unit,iotype,vlist,iostat,iomsg)
    CLASS(person), INTENT(IN) :: dtv
    INTEGER, INTENT(IN) :: unit
    CHARACTER (LEN=*), INTENT(IN) :: iotype
    INTEGER, INTENT(IN) :: vlist(:)
    INTEGER, INTENT(OUT) :: iostat
    CHARACTER (LEN=*), INTENT(INOUT) :: iomsg
    iomsg = "SUCCESS"
    iostat=0
    print *, "in pwf"
END SUBROUTINE pwf
END MODULE p

PROGRAM test
USE p
TYPE (person), SAVE :: chairman
TYPE (person), SAVE :: member
character(80) :: astring
astring = "FAILURE"
write (10, "(DT'zeroth',3x, DT'three'(11,4,10),11x,DT'two'(8,2))", &
& iostat=myiostat, iomsg=astring) member, chairman, member
if (myiostat.ne.0) STOP 3
print *, astring
if (astring.ne."SUCCESS") STOP 4
END PROGRAM test

With gfortran this gives the (supposedly correct) output:

in pwf
in pwf
in pwf
SUCCESS

But ifort 19 prints:

in pwf
in pwf
in pwf
FAILURE

4

Apparently that means that ifort calls the type-bound write procedure, but fails to set the iomsg. Apparently this was working with 18.3.

Cheers,

Janus

mod_large_1 also looks like

Janus — Fri, 14 Sep 2018 19:25:00 GMT

mod_large_1 also looks like an actual bug to me. I amended it with some print statements:

program mod_large_1
implicit none
real :: r1
r1 = mod (1e22, 1.7)
print *,r1
if (abs(r1 - 0.995928764) > 1e-5) STOP 1
r1 = modulo (1e22, -1.7)
print *,r1
if (abs(r1 + 0.704071283) > 1e-5) STOP 2
end program mod_large_1

gfortran prints the expected output:

0.995928764
-0.704071283

but ifort 19 prints:

0.9959288
0.0000000E+00
2

Again, ifort 18.3 got it right apparently.

read_eof_all.f90 is slightly

Janus — Fri, 14 Sep 2018 20:07:26 GMT

read_eof_all.f90 is slightly less obvious. Here is a reduction:

character(len=2) :: str
integer :: a, b
str = ''

read(str,'(i2,/,i2)',end=121,pad='no') a, b
STOP 6
121 continue

end

ifort 19 prints:

forrtl: severe (67): input statement requires too much data, unit -5, file Internal Formatted Read

That runtime error is not exactly 'wrong', but maybe a bit overzealous. gfortran and ifort 18 just silently jump to the end label, instead of throwing a runtime error.

Quote:Janus wrote:

FortranFan — Fri, 14 Sep 2018 20:51:00 GMT

Janus wrote:

.. ifort .. fails to set the iomsg. ..

Fortran standard has in the section on Defined input/output procedures, "If the defined input/output procedure returns a nonzero value for the iostat argument, the procedure shall also return an explanatory message in the iomsg argument. Otherwise, the procedure shall not change the value of the iomsg argument" (emphasis mine).

So my understanding is Intel Fortran 19.0 gets this correct whereas Intel's earlier versions as well as gfortran don't.

Quote:FortranFan wrote:

may_ka — Fri, 14 Sep 2018 21:31:23 GMT

FortranFan wrote:

Quote:

may.ka wrote:

.. this code is screwed already: ..

ifort 19 cannot handle the "private" statement in module "mod_test_2", but it runs in 17.07, 18.03 and gfortran 8.2. Therefore I assume a bug. ..

@may.ka,

Trust you will submit a support request for this regression at the Intel OSC? In it, you can request this nice case be added to the regression test suite for the Fortran compiler.

I have submitted a support request already.

Quote:Janus wrote:

FortranFan — Fri, 14 Sep 2018 23:49:42 GMT

Janus wrote:

read_eof_all.f90 is slightly less obvious. ..

That runtime error is not exactly 'wrong', but maybe a bit overzealous. gfortran and ifort 18 just silently jump to the end label, instead of throwing a runtime error.

I think Intel Fortran 19.0 gets it right with the kind of IO statement present in this test case. The situation is not an END= condition (nor an EOR= one), rather it is an ERR= situation.

Quote:Janus wrote:

FortranFan — Fri, 14 Sep 2018 23:59:02 GMT

Janus wrote:

mod_large_1 also looks like an actual bug to me. ..

MODULO operation on floating-point objects is not without issues and confusion. To me it's unclear whether the result of MODULO( a, p ) can be trusted anytime a processor, whether it be gfortran or any other compiler, doesn't have an integer kind to handle FLOOR( a/p ) which is the case in this test case.

This is the reproducer of

Juergen_R_R — Sat, 15 Sep 2018 04:46:42 GMT

This  is the reproducer of one of our unit tests, together with the expected output, unfortunately still relatively lengthy. (it corresponds to the resonances_3 unit test of our test suite). This is the expected output:

Resonance history with 0 resonances:
Resonance history with 1 resonances:
  Resonance contributors: 1 2 f(-24)
Resonance history with 2 resonances:
  Resonance contributors: 1 2 f(-24)
  Resonance contributors: 1 2 3 f(23)
Resonance history with 1 resonances:
  Resonance contributors: 1 2 3 f(23)
Resonance history with 1 resonances:
  Resonance contributors: 1 2 f(-24)
Resonance history with 2 resonances:
  Resonance contributors: 1 2 f(-24)
  Resonance contributors: 1 2 3 f(25)
Resonance history set:
 1 Resonance history with 1 resonances:
   1 2 f(-24)
   contained in (2,4)
 2 Resonance history with 2 resonances:
   1 2 f(-24)
   1 2 3 f(23)
   contained in ()
 3 Resonance history with 1 resonances:
   1 2 3 f(23)
   contained in (2)
 4 Resonance history with 2 resonances:
   1 2 f(-24)
   1 2 3 f(25)
   contained in ()
   Resonance history with 2 resonances:
     Resonance contributors: 1 2 f(-24)
     Resonance contributors: 1 2 3 f(23)

Resonance history with 1 resonances:
  Resonance contributors: 1 2 f(-24)

Resonance history with 2 resonances:
  Resonance contributors: 1 2 f(-24)
  Resonance contributors: 1 2 3 f(23)

Resonance history with 1 resonances:
  Resonance contributors: 1 2 3 f(23)

Resonance history with 2 resonances:
  Resonance contributors: 1 2 f(-24)
  Resonance contributors: 1 2 3 f(25)
Resonance history with 1 resonances:
  Resonance contributors: 1 2 f(-24)
Resonance history with 2 resonances:
  Resonance contributors: 1 2 f(-24)
  Resonance contributors: 1 2 3 f(23)
Resonance history with 1 resonances:
  Resonance contributors: 1 2 3 f(23)
Resonance history with 1 resonances:
  Resonance contributors: 1 2 f(-24)
Resonance history set:
 1 Resonance history with 1 resonances:
   1 2 f(-24)
   contained in ()

And this is the code: (attached) (with the file containing the expected output)

Quote:FortranFan wrote:

Janus — Sat, 15 Sep 2018 07:09:22 GMT

FortranFan wrote:

Fortran standard has in the section on Defined input/output procedures, "If the defined input/output procedure returns a nonzero value for the iostat argument, the procedure shall also return an explanatory message in the iomsg argument. Otherwise, the procedure shall not change the value of the iomsg argument" (emphasis mine).

So my understanding is Intel Fortran 19.0 gets this correct whereas Intel's earlier versions as well as gfortran don't.

Thanks for digging out this standard reference. However, it sounds more like a requirement on the user side, since the user is the one who sets up the I/O procedure and its internal logic. Probably ifort sets up a wrapper around the user I/O procedure to enforce this requirement. I'm not 100% convinced that this is a good idea (may lead to surprises). But detecting this at compile time is quite hard, I guess. A run-time error may be possible.

In any case the test case is invalid and should be fixed in the GCC repo. I'll report this in bugzilla.

Cheers,

Janus

This was the reply from the

Juergen_R_R — Tue, 18 Sep 2018 05:05:40 GMT

This was the reply from the Intel support:

Here is the update: I can reproduce the difference output of 19.0 and 18.0 compiler using your last attached 844 lines of code; however, due to the complexity of the code structure it will take me some time to sort out the cause of the difference. It isn't like the segmentation fault in the old ticket which is quite straight forward a compiler defect.

Thanks,

Xiaoping Duan

This is not very encouraging reply. 844 lines may not be the smallest reproducer, but for the moment I am the only person from our team working on this, and I reduced it from 500,000 lines to 844 lines. This is a severe regression, and yes, it might be a bit complicated, but if Intel wants to live up to the standards of gfortran or nagfor then they should do all they can to sort it out. But I am pretty sure that in the same way we veto in our code ifort 17.0.0/1/2/3 we are going to veto 19.0.0/1/2/3. The last time this happened with gfortran was for 4.9.0/1/2.

Jürgen, Ifort 18.0.3 (Windows

mecej4 — Tue, 18 Sep 2018 09:56:00 GMT

Jürgen, Ifort 18.0.3 (Windows) gives the same result as in your "expected" result file in #12. If you don't mind, please post the incorrect result from 19.0. I may be able to reduce the size of your reproducer if I can have that output. Someone else reading this post who has 19.0 installed can help by compiling and running the program and posting the result here.

I do not have, and will probably not install 19.0 until Update-1 is released (I did the same with 18.0), because of the incompatibilities with Visual Studio 2017 that have been reported by a number of early adopters.

Quote:mecej4 wrote:

Juergen_R_R — Tue, 18 Sep 2018 10:03:40 GMT

mecej4 wrote:

Jürgen, Ifort 18.0.3 (Windows) gives the same result as in your "expected" result file in #12. If you don't mind, please post the incorrect result from 19.0. I may be able to reduce the size of your reproducer if I can have that output. Someone else reading this post who has 19.0 installed can help by compiling and running the program and posting the result here.

I do not have, and will probably not install 19.0 until Update-1 is released (I did the same with 18.0), because of the incompatibilities with Visual Studio 2017 that have been reported by a number of early adopters.

Dear mecej4,

thanks for picking this up. This is the faulty output from 19.0 below, particularly the contained in part is different. The background is a Monte Carlo generator for collider simulations, where we check for resonant subprocesses. The resonant subprocesses are stored in a DT data structure (actually an allocatable array thereof), and then it is checked whether some resonant subchannels are contained in each other. ifort19 seems to lose some of this information.

Resonance history with 0 resonances:
Resonance history with 1 resonances:
  Resonance contributors: 1 2 f(-24)
Resonance history with 2 resonances:
  Resonance contributors: 1 2 f(-24)
  Resonance contributors: 1 2 3 f(23)
Resonance history with 1 resonances:
  Resonance contributors: 1 2 3 f(23)
Resonance history with 1 resonances:
  Resonance contributors: 1 2 f(-24)
Resonance history with 2 resonances:
  Resonance contributors: 1 2 f(-24)
  Resonance contributors: 1 2 3 f(25)
Resonance history set:
 1 Resonance history with 1 resonances:
   1 2 f(-24)
   contained in ()
 2 Resonance history with 2 resonances:
   1 2
   1 2 3
   contained in ()
 3 Resonance history with 1 resonances:
   1 2 3 f(23)
   contained in ()
 4 Resonance history with 2 resonances:
   1 2 f(25)
   1 2 3
   contained in ()
   Resonance history with 2 resonances:
     Resonance contributors: 1 2
     Resonance contributors: 1 2 3
 
Resonance history with 1 resonances:
  Resonance contributors: 1 2 f(-24)
 
Resonance history with 2 resonances:
  Resonance contributors: 1 2
  Resonance contributors: 1 2 3
 
Resonance history with 1 resonances:
  Resonance contributors: 1 2 3 f(23)
 
Resonance history with 2 resonances:
  Resonance contributors: 1 2
  Resonance contributors: 1 2 3
Resonance history with 1 resonances:
  Resonance contributors: 1 2 f(-24)
Resonance history with 2 resonances:
  Resonance contributors: 1 2 f(-24)
  Resonance contributors: 1 2 3 f(23)
Resonance history with 1 resonances:
  Resonance contributors: 1 2 3 f(23)
Resonance history with 1 resonances:
  Resonance contributors: 1 2 f(-24)
Resonance history set:
 1 Resonance history with 1 resonances:
   1 2 f(-24)
   contained in ()

Quote:Juergen R. wrote:

FortranFan — Tue, 18 Sep 2018 15:52:00 GMT

Juergen R. wrote:

This was the reply from the Intel support:

Here is the update: I can reproduce the difference output of 19.0 and 18.0 compiler using your last attached 844 lines of code; however, due to the complexity of the code structure it will take me some time to sort out the cause of the difference. It isn't like the segmentation fault in the old ticket which is quite straight forward a compiler defect.

Thanks,

Xiaoping Duan

This is not very encouraging reply. 844 lines may not be the smallest reproducer, ..

@Juergen R. and Intel Support,

My hunch is the issue in Intel Fortran 19.0 compiler is with the intrinsic assignment of array objects of resonance_info_t derived type as in line 444 of the code:

440  subroutine resonance_history_assign (res_hist_out, res_hist_in)
441    class(resonance_history_t), intent(out) :: res_hist_out
442    class(resonance_history_t), intent(in) :: res_hist_in
443    if (allocated (res_hist_in%resonances)) then
444       res_hist_out%resonances = res_hist_in%resonances  !<--- this assignment is failing
445       res_hist_out%n_resonances = res_hist_in%n_resonances
446    end if
447  end subroutine resonance_history_assign

It's possible the issue may further trickle down to intrinsic assignment of flavor_t derived type. I'll suggest the following checks:

Strip out all code other than model_data, flavors, and that with resonance_contributors_t and resonance_info_t
Write a unit test with array assignment i.e., bar = foo where bar and foo are of resonance_info_t and with a shape of 2. It's likely this will fail with Intel Fortran 19.0 whereas it works with 18.0.3. This may have give the compiler team further information on what to investigate.

As a short-term workaround only to @Juergen R. toward further checks of 19.0 compiler, I will suggest trying the following:

Implement defined assignment with ELEMENTAL attribute with flavors_t derived type with suitable logic (deep vs shallow copy) of field_data_t component with the POINTER attribute
Modify the defined assignment of resonance_contributors_t to have ELEMENTAL attribute, presently it is only PURE

Or alternately removing the defined assignment for resonance_contributors_t and leaving both components of resonance_info_t to follow the intrinsic assignment route.

Good luck,

Ifort 19, Update 2, and the

Juergen_R_R — Wed, 06 Feb 2019 06:30:50 GMT

Ifort 19, Update 2, and the regression which is present from the very first 19 beta version is still not fixed. Disappointed.

Quote:Juergen R. wrote:

FortranFan — Wed, 06 Feb 2019 14:31:09 GMT

Juergen R. wrote:
Ifort 19, Update 2, and the regression which is present from the very first 19 beta version is still not fixed. Disappointed.

@Juergen R.,

Have you run into any additional regressions with 19.0 Update 2?

Thanks,

No, doesn't look like.

Juergen_R_R — Wed, 06 Feb 2019 14:32:00 GMT

No, doesn't look like.