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.
I’m sorry to hear about the continued problems. It is best if you will please report these via the Online Service Center, http://www.intel.com/supporttickets. It allows better/easier private communication and if there are multiple unique underlying issues it enables better individual tracking of their resolution. Thank you.
Some bugs are fixed promptly, others take more time. Your experience seems to be somewhat unusual, based on reports I have seen elsewhere. If you can honor Kevin;s request and provide, as best as possible, minimal test cases, that will help speed the fixes. I know from my time doing support that when presented with a large, unknown program and vague symptoms, analysis takes longer and has lower priority. That you are saying some third-party program reports "failures" doesn't necessarily mean the compiler is at fault. Often times it is the test itself that is wrong or that it makes inappropriate assumptions.
I perfectly understand this. But I already filed several bug reports with smaller test cases. That was based on v17 update1 or 2 I believe. We also have only limited time, and we also give priority to compilers where bugs are fixed fast(er).
I will inquire about the issues with the support system. I don't know what the issues are with that. Thank you for submitting the test case here. I will investigate it shortly.
You might want to check (fix) your pointer assignments. You have:
if (associated (prt%mass_val)) prt%mass_val = mass
when you should have:
if (associated (prt%mass_val)) prt%mass_val => mass
Similar issues elsewhere.
Thanks, Jim, for the remark. The corresponding routines are not used in the example shown here. The routines with prt%mass_val = mass actually are intended really for cases where the pointer is associated and only its value should be changed, while for other functions (erased in the small code snippet) the whole pointer is transferred. Our code including the complete test suite passes gfortran -fcheck=all and nagfor -C=all.
>> ..cases where the pointer is associated and only its value should be changed...
Thanks for clarifying this.
Other than that, I did not notice any coding error. There is one section that, though correct in syntax, may be where the compiler bug is exposed..
subroutine resonance_history_add_resonance (res_hist, resonance) ... type(resonance_info_t), dimension(:), allocatable :: tmp ... allocate (tmp (n + n_max_resonances)) tmp(1:n) = res_hist%resonances(1:n) call move_alloc (from=tmp, to=res_hist%resonances) ...
The type resonance_info_t contains allocatable entities. In past versions of Fortran, sequences like that above exposed errors. I suspect that tmp gets deallocated twice: Once from the move_alloc, and a second time when the subroutine returns (auto deallocation of local allocatables). This is just a hypothesis.
You could test this with:
subroutine resonance_history_add_resonance (res_hist, resonance) ... type(resonance_info_t), dimension(:), allocatable :: tmp ... allocate (tmp (n + n_max_resonances)) tmp(1:n) = res_hist%resonances(1:n) ! call move_alloc (from=tmp, to=res_hist%resonances) res_hist%resonances = tmp delete(tmp) ...
Or simply let tmp auto-deallocate upon return.
No, the move_alloc doesn't seem to be the problem. The problem arises in the subroutine resonance_history_remove_resonance, when assigning res_hist%resonances (i - 1) = res_hist%resonances (i).
I reproduced the failure w/18.0 compiler and noted that the test case runs successfully w/17.0. I submitted it to Development for their analysis.
(Internal tracking id: CMPLRS-42619)
Thanks, Kevin! We discussed this internally, and we believe that an explicit assignment for the derived type resonance_info_t could maybe solve/circumvent the issue. We'll let you know.
One more thing: when using the workaround for the error for the internal tracking #02767138 makes 1 of 4 failing unit tests work again, and instead of 127 failing functional tests, only 55 functional test now fail. We will further investigate.
Juergen R. wrote:
.. We discussed this internally, and we believe that an explicit assignment for the derived type resonance_info_t could maybe solve/circumvent the issue. We'll let you know. ..
I would consider this a blessing in disguise and review all the derived types involved here, starting from the very top, field_data_t. I would then examine closely if components with the POINTER attribute (e.g., mass_val and width_val in field_data_t) are truly necessary or if all such components can now be given the ALLOCATABLE attribute. If POINTERs are stil required, I would include defined assignments in all the derived types where such components are included while paying close attention to deep vs shallow copy of such components. In addition, I would apply FINAL bindings (finalizers) to all such types.
OK, there are now workarounds for most things. 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.
The case can be found in the shower unit test and 10 functional tests: mlm_matching_isr, mlm_matching_fsr, parton_shower_1, parton_shower_2, pythia6_1, pythia6_2, pythia_6_3, pythia6_4 ....