ifort 18 regression: segfault on ALLOCATE with SOURCE (using -qopenmp or -recursive)

[Janus]

Hi all,

we just stumbled upon another regression of ifort 18 (in fact this is already the third one I'm aware of). Consider this simple test case:

program alloc_w_source

   type T
      integer, dimension(:), allocatable :: vals
      integer :: k = 3
   end type

   type(T), dimension(:), allocatable :: x

   allocate(x(1:8), source=T())

end

Compiling this with "ifort -qopenmp" or "ifort -recursive" and running the generated executable produces a runtime segfault, which is obviously a compiler bug. Valgrind shows:

==25803== Use of uninitialised value of size 8
==25803==    at 0x404230: copy_src_xdesc_to_dest_xdesc (in /home/janus/fort/ifort_bugs/a.out)
==25803==    by 0x403918: do_alloc_copy (in /home/janus/fort/ifort_bugs/a.out)
==25803==    by 0x403ECA: do_alloc_copy (in /home/janus/fort/ifort_bugs/a.out)
==25803==    by 0x4049BF: for_alloc_copy (in /home/janus/fort/ifort_bugs/a.out)
==25803==    by 0x402E6B: MAIN__ (alloc_w_source.f90:13)
==25803==    by 0x402B6D: main (in /home/janus/fort/ifort_bugs/a.out)
==25803== 
==25803== Invalid read of size 8
==25803==    at 0x404230: copy_src_xdesc_to_dest_xdesc (in /home/janus/fort/ifort_bugs/a.out)
==25803==    by 0x403918: do_alloc_copy (in /home/janus/fort/ifort_bugs/a.out)
==25803==    by 0x403ECA: do_alloc_copy (in /home/janus/fort/ifort_bugs/a.out)
==25803==    by 0x4049BF: for_alloc_copy (in /home/janus/fort/ifort_bugs/a.out)
==25803==    by 0x402E6B: MAIN__ (alloc_w_source.f90:13)
==25803==    by 0x402B6D: main (in /home/janus/fort/ifort_bugs/a.out)
==25803==  Address 0x2ffe86837f0 is not stack'd, malloc'd or (recently) free'd

ifort 17 or earlier works without any problem.

Cheers,

Janus

[FortranFan]

@Janus,

Intel now wants you to submit an incident at their Online Service Center (OSC):

https://supporttickets.intel.com/?lang=en-US

[Janus]

FortranFan wrote:

Intel now wants you to submit an incident at their Online Service Center (OSC):

https://supporttickets.intel.com/?lang=en-US

I know. Just filed this as support request #03214078. But since Intel's bug tracker is unfortunately not public, I though it might be helpful to give a heads-up to other users.

If you're considering upgrading to ifort 18, think twice. IMHO it's not yet ready for production use (even with update 1).

Cheers,

Janus

[Juergen_R_R]

If you're considering upgrading to ifort 18, think twice. IMHO it's not yet ready for production use (even with update 1).

For our code which massively uses F2003 OO, yes, there was a regression in ifort18.0, but actually when ifort17 came out, there were many more 

regressions, four or five regarding our code. But the worst thing was that F2003 allocate-on-assignment was not yet default without any specific flags. Anyways, I'd hope that Intel puts a little more priority in regression testing and QA than into fastest-possible implementation of new features. 

[Janus]

Hi Jürgen,

Juergen R. wrote:

For our code which massively uses F2003 OO, yes, there was a regression in ifort18.0, but actually when ifort17 came out, there were many more regressions, four or five regarding our code.

my impression is that the quality of the last couple of releases was not really good. Every version since 15.0 has one bug or another that makes it more-or-less useless for our purpose. And I'm not talking massive OOP or Coarrays here. Just moderate F03 stuff and OMP.

Juergen R. wrote:

Anyways, I'd hope that Intel puts a little more priority in regression testing and QA than into fastest-possible implementation of new features.

+1

ifort 18 having "full Fortran 2008" support is a pretty bold claim if you ask me. I would also prefer to have some features properly implemented, instead of having "all of them", but with so many bugs that they're unusable.

If you ask me, GCC/gfortran is miles ahead of ifort in terms of stability and overall quality of implementation.

Cheers,

Janus

[FortranFan]

Janus wrote:

.. I know. Just filed this as support request #03214078. But since Intel's bug tracker is unfortunately not public, I though it might be helpful to give a heads-up to other users. ..

@Janus,

Nice sentiment with ".. it might be helpful to give a heads-up to other users ..", I hold the same.  It will help if you preface your original post with some indication if you've filed a support incident e.g.,

https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/754598

[FortranFan]

Janus wrote:

.. If you ask me, GCC/gfortran is miles ahead of ifort in terms of stability and overall quality of implementation. ..

Well, gfortran still has outstanding bugs with some Fortran 95 features, not to mention issues with several Fortran 2003 aspects, rendering it useless for other teams.  No objective, general-purpose comparison is possible between compilers given the state they are all in at the moment, it's all relative to one's needs and interests.

[Janus]

FortranFan wrote:

Quote:

Janus wrote:

.. If you ask me, GCC/gfortran is miles ahead of ifort in terms of stability and overall quality of implementation. ..

Well, gfortran still has outstanding bugs with some Fortran 95 features, not to mention issues with several Fortran 2003 aspects, rendering it useless for other teams.  No objective, general-purpose comparison is possible between compilers given the state they are all in at the moment, it's all relative to one's needs and interests.

I certainly agree that there is no bug-free Fortran compiler out there, and that the set of bugs encountered with a specific code is subjective.

The best practical (and somewhat objective) measure of compiler quality I can think of is running a large amount of test cases with a given compiler. One pretty good example of such a collection is the gfortran testsuite, which I have recently tried to run with the ifort compiler (at least a subset, namely the runtime tests) via this cmake script:

https://gist.github.com/janusw/17a294125d6956bea736a20c409e7881

This shows that ifort 18 can successfully run 82% of the roughly 1500 runtime tests. This measure is certainly a bit biased towards gfortran (since those are only test cases that are known to work with gfortran, and they might even use non-standard GNU extensions in some cases), so this number is to be taken with a grain of salt. In any case the failures include 10 internal compiler errors and 64 (!) runtime segfaults.

Also this approach reveals that there are nine cases that work with ifort 17, but fail with ifort 18 ("regressions"). I will report those in a separate thread later tonight ...

Cheers,

Janus