Intel Fortran Compiler 21.2 still completely broken

[JRR]

What is the general status of the new Intel Compiler? Great that this is
a freely available compiler now, on the other hand it is very much
broken: our code which worked since roughly Intel 2017 is not
functioning at all with it. Just running our test suite, almost a third
of all unit tests are failing and 90% of all functional tests. I
remember that I isolated a problem but it seems that it will take years
until that compiler is usable again.


--
Juergen Reuter
Theoretical Particle Physics
Deutsches Elektronen-Synchrotron
Hamburg, Germany
---------------------------------
invalid is desy .and. com is de

[Harald Anlauf]

Hi Jürgen,

JRR schrieb am Donnerstag, 1. April 2021 um 19:09:26 UTC+2:
> What is the general status of the new Intel Compiler?

do you know that it is actually 2 compilers ("classic" ifort and "beta" ifx)?

With ifx you can experience many new adventures (e.g. -check does not yet work),
and I just encountered the error:

error #5533: Feature found on this line is not yet supported in ifx

for harmless code that looks like standard F90... (I haven't reduced it yet)
and which worked with any ifort since at least v7.

> our code which worked since roughly Intel 2017 is not
> functioning at all with it. Just running our test suite, almost a third
> of all unit tests are failing and 90% of all functional tests. I
> remember that I isolated a problem but it seems that it will take years
> until that compiler is usable again.

My personal release-to-release experience was more like alternating ok, not ok, ok, ...

It's hard to guess why, not knowing how good/big their regression test suite is.

[JRR]

Am 01.04.21 um 23:49 schrieb Harald Anlauf:

> Hi Jürgen,
>
> JRR schrieb am Donnerstag, 1. April 2021 um 19:09:26 UTC+2:
>> What is the general status of the new Intel Compiler?
>
> do you know that it is actually 2 compilers ("classic" ifort and "beta" ifx)?
>

Yes, I know, the classic has the Intel-developed back end and the other
is based on LLVM. The ifx doesn't even compile our code, because not all
language features are implemented.
The more disturbing thing is that I reported this issue from the beta
version in April 2020 (during our first lockdown apparently), and it got
'escalated to their development team' in February 2021. It seems that
there are a plethora of problems lurking around.

> With ifx you can experience many new adventures (e.g. -check does not yet work),
> and I just encountered the error:
>
> error #5533: Feature found on this line is not yet supported in ifx
>

It seems that all projects based on LLVM are not yet very mature, be it
ifx, be it the new nvidia driver, or so.

> for harmless code that looks like standard F90... (I haven't reduced it yet)
> and which worked with any ifort since at least v7.
>
> > our code which worked since roughly Intel 2017 is not
>> functioning at all with it. Just running our test suite, almost a third
>> of all unit tests are failing and 90% of all functional tests. I
>> remember that I isolated a problem but it seems that it will take years
>> until that compiler is usable again.
>
> My personal release-to-release experience was more like alternating ok, not ok, ok, ...
>
> It's hard to guess why, not knowing how good/big their regression test suite is.
>

--
Juergen Reuter
Theoretical Particle Physics
Deutsches Elektronen-Synchrotron
Hamburg, Germany

------------------------------------

[FortranFan]

On Thursday, April 1, 2021 at 1:09:26 PM UTC-4, JRR wrote:

> What is the general status of the new Intel Compiler? Great that this is
> a freely available compiler now, on the other hand it is very much
> broken: our code which worked since roughly Intel 2017 is not
> functioning at all with it. Just running our test suite, almost a third
> of all unit tests are failing and 90% of all functional tests. I
> remember that I isolated a problem but it seems that it will take years
> until that compiler is usable again.

> ..

Hi Juergen,

Re: "What is the general status of the new Intel Compiler?," please note our experience remains IFORT is the most robust and best optimizing *Fortran 2018* compiler for Intel CPUs and it has undergone tremendous positive transformation on several fronts following some hiccups starting their 19.0 compiler version release.

On the other hand, IFX is nowhere close to being a toolset for "production" codes. It will take a long time, if at all *ever*, when IFX reaches the current level of IFORT.

Now, as much positive as the news is of their license-free compiler availability with their Intel oneAPI toolkits, the fact remains it's a *commercial* product. Hence any team out there - be it in open-source and/or academia and/or non-profit and/or governmental or international research or the commercial sectors, etc. - who intend to rely on IFORT compiler in any *meaningful* manner will be better off procuring support subscription from Intel toward use of their oneAPI toolkits. Hence if your team(s) have not procured such premier support, it will be better to have someone with access to some funding to contact Intel and start the negotiation for right level of support services to buy. Without this support, *unfortunately* it will be very difficult to get attention to issues faced by your codes with IFORT. Also it's unfortunate that even with support, certain issues may not get attention some customers think they deserve. But the fact is without support, chances of any attention to issues depend on a number of other factors and one cannot rely on them always.

And if you have premium support, continue to use that to submit requests for ALL your issues and keep requesting the support team for status and schedule toward resolution.

As to your one previous regression issue with IFORT, please refer to this thread from your past discussion:
https://groups.google.com/g/comp.lang.fortran/c/HbCC2XBsQrE/m/d_VbVc3bCQAJ

You will note with the case you provide in that thread, as I had hinted previously, you may be available to workaround IFORT with a small change in your code: note the line "d = d // " => " below

--- original code section ---
..
subroutine process_def_import_component (def, &
i, prt_in)
class(process_def_t), intent(inout) :: def
integer, intent(in) :: i
type(prt_spec_t), dimension(:), intent(in), optional :: prt_in
integer :: p
associate (comp => def%initial(i))
if (present (prt_in)) then
allocate (comp%prt_in (size (prt_in)))
comp%prt_in = prt_in
end if
if (allocated (comp%prt_in)) then
associate (d => comp%description)
d = ""
d = d // " => " !<--- IFORT crashes here
end associate
comp%description = " => "
end if
end associate
end subroutine process_def_import_component
..
--- end section ---

--- begin possible workaround ---
..
if (allocated (comp%prt_in)) then
comp%description = " => "
end if
..
--- end workaround ---

If you notice the above issue is part of your "process_libraries" module and as such, many if not all of your test may depend on it. So if it were to fail with one problem, all of the other tests may fail also. So see if the above workaround is helpful with your tests.

And if you can create reproducers (~300 lines or fewer) of other failures with your unit tests and functional tests, perhaps readers may be able to suggest workarounds that ultimately allow you to use IFORT on your entire code.

[FortranFan]

On Friday, April 2, 2021 at 11:42:08 AM UTC-4, FortranFan wrote:

> --- original code section ---
> ..

> associate (comp => def%initial(i))
> if (present (prt_in)) then
> allocate (comp%prt_in (size (prt_in)))
> comp%prt_in = prt_in
> end if
> if (allocated (comp%prt_in)) then
> associate (d => comp%description)
> d = ""
> d = d // " => " !<--- IFORT crashes here
> end associate
> comp%description = " => "

Please ignore the last line above 'comp%description = " => " ', it was a copy-and-paste error while I was posting my comment about my suggestion with the short-term workaround to get around the IFORT problem.

[JRR]

Am 02.04.21 um 17:42 schrieb FortranFan:

>
> Re: "What is the general status of the new Intel Compiler?," please note our experience remains IFORT is the most robust and best optimizing *Fortran 2018* compiler for Intel CPUs and it has undergone tremendous positive transformation on several fronts following some hiccups starting their 19.0 compiler version release.

Hi Vipul,
that is your assessment but it is not ours. In public research we have
to rely on regulations from the tax authorities. And regarding our
'value-for-prize' ratio gfortran is clearly leading.

>
> On the other hand, IFX is nowhere close to being a toolset for "production" codes. It will take a long time, if at all *ever*, when IFX reaches the current level of IFORT.

Probably agreed.

>
> Now, as much positive as the news is of their license-free compiler availability with their Intel oneAPI toolkits, the fact remains it's a *commercial* product. Hence any team out there - be it in open-source and/or academia and/or non-profit and/or governmental or international research or the commercial sectors, etc. - who intend to rely on IFORT compiler in any *meaningful* manner will be better off procuring support subscription from Intel toward use of their oneAPI toolkits. Hence if your team(s) have not procured such premier support, it will be better to have someone with access to some funding to contact Intel and start the negotiation for right level of support services to buy. Without this support, *unfortunately* it will be very difficult to get attention to issues faced by your codes with IFORT. Also it's unfortunate that even with support, certain issues may not get attention some customers think they deserve. But the fact is without support, chances of any attention to issues depend on a number of other factors and one cannot rely on them always.

Our national lab still has a subscription (but it is under discussion to
cancel this), and I reported this Intel support. Quite slow reactions. I
inquired again recently.

>
> And if you have premium support, continue to use that to submit requests for ALL your issues and keep requesting the support team for status and schedule toward resolution.
>
> As to your one previous regression issue with IFORT, please refer to this thread from your past discussion:
> https://groups.google.com/g/comp.lang.fortran/c/HbCC2XBsQrE/m/d_VbVc3bCQAJ
>
> You will note with the case you provide in that thread, as I had hinted previously, you may be available to workaround IFORT with a small change in your code: note the line "d = d // " => " below

Many of our test work with your proposed workaround, however, not all of
them. The others might be related to similar things, however, I will be
waiting for a fix from the Intel team. In the past years we have been
cleaning our code a lot of compiler bug workaround, and most of them
actually were from Intel compiler bugs. We don't wanna introduce a lot
of them unnecessarily again. Until then, we refrain from using the Intel
compiler in v21 and stick to version 20.

[Ron Shepard]

On 4/3/21 7:31 AM, JRR wrote:
> Am 02.04.21 um 17:42 schrieb FortranFan:

[...]

>> You will note with the case you provide in that thread, as I had
>> hinted previously, you may be available to workaround IFORT with a
>> small change in your code: note the line "d = d // " => " below
>
> Many of our test work with your proposed workaround, however, not all of
> them.

Can you explain exactly what is the problem? Is it the use of
associate() to simplify the expression, or is it that d, which is an
allocatable character string, was not allocated prior to its use in the
expression? If it is the latter, then that isn't really a compile bug is
it, it is a program error.

$.02 -Ron Shepard

[JRR]

Am 03.04.21 um 20:15 schrieb Ron Shepard:

It is the associate construct. Without that it works. So the parser of
the compiler translates structures inside the associate into the wrong
code.

> $.02 -Ron Shepard

>


--
Juergen Reuter
Theoretical Particle Physics

Deutsches Elektronen-Synchrotron (DESY)
Hamburg, Germany