Regressions in new release

[Juergen_R_R]

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

[Janus]

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

[may_ka]

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.

[FortranFan]

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.

[Janus]

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

[Janus]

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.

[Janus]

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.

[FortranFan]

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.

[may_ka]

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.

[FortranFan]

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.

[FortranFan]

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.

[Juergen_R_R]

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)

[Janus]

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

[Juergen_R_R]

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. 

[mecej4]

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.

[Juergen_R_R]

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 ()

[FortranFan]

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:

1. 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
2. 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,

[Juergen_R_R]

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

[FortranFan]

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,

[Juergen_R_R]

No, doesn't look like.

[FortranFan]

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.,

Can you confirm the support you are requesting with Intel OSC is using Fortran-specific test cases along the lines what you show in Quotes #12 and #16 above?  If your test cases are any more involved and should they require other components such as OCaml compiler, it won't be surprising if matters are on hold - that will be too complex and resource-intensive for almost any software support staff and few, if any, will investigate further.

To the extent your test cases can be investigated easily and directly with Intel Fortran compiler, Intel support staff is really great with their responses and the Fortran compiler team is making great progress, particularly considering all their resource constraints.  I instead extend the Fortran compiler development and support team my sincere thanks and I give them a big round of applause for all the enhancements and fixes they have made to all my support requests.

An immediate illustration of the Intel Fortran team's progress can be noticed with your own main-ut.f90 test case in Quote #12 which works as you expect using both 19.0 Update 1 and 2, though it's shown below with Update 2 on Windows:

C:\Temp>ifort /standard-semantics /warn:all /check:all /stand main_ut.f90
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version
 19.0.2.190 Build 20190117
Copyright (C) 1985-2019 Intel Corporation.  All rights reserved.

main_ut.f90(62): remark #7712: This variable has not been used.   [CHECK]
  function model_data_get_field_ptr_pdg (model, pdg, check) result (ptr)
-----------------------------------------------------^
main_ut.f90(408): remark #7712: This variable has not been used.   [RES_HIST]
  subroutine resonance_history_clear (res_hist)
--------------------------------------^
Microsoft (R) Incremental Linker Version 14.16.27026.1
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:main_ut.exe
-subsystem:console
main_ut.obj

C:\Temp>main_ut >>v19.0.2-resonances_3.log

C:\Temp>

I think the onus lies with you/Whizard team to cooperate with the Intel Fortran team with simple and direct Fortran-specific test cases as in main-ut.f90 example and when you report on an Intel forum on your disappointments, you may want to point to stats of pending issues with such Fortran-specific cases that other readers are able to try out also using Intel Fortran compiler ONLY i.e., not needing OCaml, etc,