Catastrophic error when using deferred shape logical array with namelist read

[Svensmark__Jens]

Hi

When I try to compile this using ifort 18.0.0 (20170811)

module test_logical_read
contains
  subroutine read(logical_array)
    logical, intent(out) :: logical_array(:)
    namelist /group/ logical_array
    read(1, group)
  end subroutine read
end module test_logical_read

I get the following error

logical_read.f90(6): catastrophic error: **Internal compiler error: internal abort** Please report this error along with the circumstances in which it occurred in a Software Problem Report.  Note: File and line given may not be explicit cause of this error.
compilation aborted for logical_read.f90 (code 1)

Anyone knows if this has been fixed in more recent versions of the compiler?

[Juergen_R_R]

Hi Jens,

no, this ICE is still present in the latest version of ifort 18 and also in the newest 19 release. Please report it through the Online Support Center.

Best,

    Jürgen

[Svensmark__Jens]

Btw, the bug doesn't seem to depend on the datatype of the variable. I just tried with integer, real and complex instead of logical, and in all cases the same catastrophic error appeared.

[jimdempseyatthecove]

This may or may not be pertinent... a READ will not perform a reallocate left hand side. IOW it reads into existing assigned memory. Now this would be (should be) a runtime error, perhaps the compiler optimization is attempting to ascertain an optimal code based on what is being read. This bug should be fixed (at least to the point of complaining at run time).

Jim Dempsey

[FortranFan]

Svensmark, Jens wrote:

Btw, the bug doesn't seem to depend on the datatype of the variable. I just tried with integer, real and complex instead of logical, and in all cases the same catastrophic error appeared.

Hopefully OP will submit a support request at the Intel Online Support Center.

With an open-source compiler, one can conceivably get to understand the root cause of an ICE and help everyone along the way, both the compiler developers as well as coders, on how to avoid such a nasty problem.  But not so here.  One might presume this commercial compiler is running into issues due to the namelist object being a dummy argument with assumed-shape and/or INTENT(OUT) attributes, especially considering a constraint in the Fortran standard which prohibits an assumed-size array being a namelist object.  If so, one can workaround this ICE via autotargeting facility in Fortran with a local namelist object with a POINTER attribute instead.  This might help get past the issue until the (possibly long intervening) time it will take for the vendor to fix the ICE in an update and for coder(s) to upgrade their compute environment to a fixed compiler version:

C:\Temp>type p.f90
module test_logical_read
   use, intrinsic :: iso_fortran_env, only : input_unit
contains
   subroutine read(logical_array)
      logical, intent(out), target :: logical_array(:)
      logical, pointer :: lar(:)
      namelist /group/ lar
      lar => logical_array
      read(input_unit, group)
      lar => null()
   end subroutine read
end module test_logical_read
   use test_logical_read
   logical :: lar(2)
   call read( lar )
   print *, "lar = ", lar, "; expected is T, F"
end

C:\Temp>ifort /standard-semantics /warn:all /stand p.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.

Microsoft (R) Incremental Linker Version 14.16.27026.1
Copyright (C) Microsoft Corporation.  All rights reserved.

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

C:\Temp>p.exe
&group lar=T F /
 lar =  T F ; expected is T, F

C:\Temp>