- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 ()
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ifort 19, Update 2, and the regression which is present from the very first 19 beta version is still not fixed. Disappointed.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
No, doesn't look like.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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,
![](/skins/images/D3C0B914909A6564BBB97F4AD1ED1973/responsive_peak/images/icon_anonymous_message.png)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page