Segfault and ICE with ifort 16.0.1.150

[Ben3]

Hi,

One of our users has reported a segfault and ICE when attempting compiler a problem. We have a test case (below), however unfortunately it depends on a .mod file (attached) that we don't currently have the source for (and was built with an earlier version of ifort). It builds fine with the 15 series.

MODULE foo
CONTAINS
    SUBROUTINE bar(data_recv,rowl_64,rows_64,ierr64)
        USE mod_prism_get_proto
        INTEGER (kind=8) :: rowl_64
        INTEGER (kind=8) :: rows_64
        INTEGER (kind=8) :: ierr64
        INTEGER (kind=4) :: ierror,var_id32, prism_nsec32
        REAL (kind=8),DIMENSION(1:rowl_64,1:rows_64)::data_recv
        REAL (kind=4),DIMENSION(1:rowl_64,1:rows_64)::data_2d
        CALL prism_get_proto(var_id32,prism_nsec32,data_recv,ierror)
    END SUBROUTINE bar
END MODULE foo

You can produce the error with a simple

ifort -c crash.f90

and the output is

crash.f90: catastrophic error: **Internal compiler error: segmentation violation signal raised** 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 crash.f90 (code 1)

Cheers,

Ben

[Kevin_D_Intel]

Thank you for reporting the internal error. I reproduced and reported it to Development.

The .mod appears to be of 12.1 compiler vintage and perhaps should be usable with 16.0 as you note it is with the 15.x series. I'll let you know what I hear from Development.

(Internal tracking id: DPD200379390)

(Resolution Update on 02/22/2016): This defect is fixed in the Intel® Parallel Studio XE 2016 Update 2 Release (PSXE 2016.2.062/ CnL 2016.2.181 - Linux)

[jimdempseyatthecove]

Not that it should matter, but there could be an additional potential issue with

DIMENSION(1:rowl_64,1:rows_64)

The literal 1 is integer(4), and rowl_64/rows_64 are integer(8).

While the compiler "should" be smart enough to assume you want 64-bit indexing, the implementation might assume you want integer(4) indexing. It is best not to be ambiguous:

DIMENSION(1_8:rowl_64,1_8:rows_64)

Jim Dempsey

[Kevin_D_Intel]

Development moved quickly on this defect and has a fix targeted for the upcoming PSXE 2016 Update 2 in Q1 - 2016. I will post again when an update containing the fix is available.

[Ben3]

Thanks Kevin.

Jim, I think this was just a quick mock up of code to reproduce the fault. But I've passed that along. A lot of their code is compiled with -i8 anyway, which (I think) would make a literal integer have kind=8.

Cheers,
Ben

[jimdempseyatthecove]

Additional note. I am not stating that this is a current problem. There used to be an issue with the older version of compilers where the array descriptor came in two flavors: 32-bit indexing and 64-bit indexing. Using mixed sizes may, or may not, be an issue with the current version of the compiler.

Also note, that while integer kind=8 applies to integer variables, it may or may not apply to literals. Maybe Steve can answer this, for IVF and Standards committee view on this.

Jim

[Steven_L_Intel1]

I'm not sure I get your question, Jim. The addressing/indexing is really simple. If you build with the compiler for IA-32, you get 32-bit indexing. If you build for Intel 64 (x64), you get 64-bit indexing. This is not something you need to choose in your code.

[jimdempseyatthecove]

Let's see if I can explain this.

At one time, years ago, I experienced an issue whereby on x64 platform if an array were declared using integer(4) index ranges, that there would be an issue in addressing arrays larger than 4GB (or possibly 2GB). My assumption at that time was that the array descriptor for that array would then use the integer size supplied on the declaration/allocation. Subsequently the address offset calculations for the indexing were then computed using 32-bit registers, and thus resulted in an offset limited to 2GB (or 4GB) depending on if unsigned arithmetic were used. To overcome this, one would declare or allocate the array using 64-bit integers, and this provided an alternate array descriptor that used 64-bit indexing.

Saying this, my recollection may be wrong on this, but you could answer if two differently sized array descriptors are use internally to Fortran.

Jim Dempsey

[Steven_L_Intel1]

Array descriptors in our implementation have address-sized fields. The size of an address is fixed on each of the two platforms (32-bit and 64-bit). There's no distinction based on kind of an integer index or how the array was declared.

We document the descriptor layout in the mixed-language chapter of the documentation. Also, the F2015 C Descriptors have components that are (effectively) address-sized (well, some of them are "size_t", but the distinction is not important on our platforms.)

[Ben3]

Hi Steve, Jim,

I actually interpreted Jim's comment differently - in terms of how the bounds are interpreted. Are the bounds of the array going to be interpreted as 1_8 to rowl_64 or 1_4 to INT(rowl_64, kind=4), with the latter being a problem if rowl_64 is bigger than the maximum value of a kind=4 integer.

Cheers,
Ben

[Steven_L_Intel1]

On a 64-bit platform, expressions using 64-bit integers will be evaluated as 64 bit integers. There is no down-conversion.

[Kevin_D_Intel]

As noted earlier, the fix for this internal error is available in the recently announced PSXE 2016 Update 2 release (PSXE 2016.2.062/ CnL 2016.2.181 - Linux)