Possibly invalid Fortran leading to compiler segfault

[andrewmcleod]

I'm not sure if this is valid Fortran or not (I am beginning to think it is not but I am struggling to translate the F2003 draft standard):

MODULE mpi_communication_module

integer :: lastrank ! id of final proc. (numtasks - 1)

END MODULE mpi_communication_module

SUBROUTINE sink_receive_accretion(send,recv)
use mpi_communication_module, only : lastrank
implicit none

integer, intent(out) :: send ! MPI send handles
!integer, intent(out) :: recv(1:lastrank) ! MPI receive handles ! - If you uncomment this line
integer, intent(out) :: recv(1:max(1,lastrank)) ! MPI receive handles ! - and comment this one and it works

recv(1:max(1,lastrank)) = 0
send = 0

return
END SUBROUTINE sink_receive_accretion

I am using:
ifort (IFORT) 11.0 20081105
Copyright (C) 1985-2008 Intel Corporation. All rights reserved.

with command line:
ifort -check all -gen-interfaces -c sink_receive_accretion.F90

and getting this error:
: 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 sink_receive_accretion.F90 (code 3)

If I drop either the -gen-interfaces OR the -check all, it compiles without error.

It should be trivial for me to work round this, I am just curious whether I am violating the standard and obviously the compiler shouldn't crash.

Thanks,
Andrew

[TimP]

The internal error (which also occurs with 11.1/023 x86_64) is clearly a bug. Arrays which may have zero length have been covered by the Fortran standard for many years. Even if there were a violation of standard, the compiler should say so, or should report a conflict between -check and -gen-interfaces, rather than throwing internal error.
-check should be inserting a run-time check on whether lastrank is initialized; apparently, this introduces a complication which exposes a compiler bug.
Experts generally advise use of allocatable with error checking, rather than an automatic array, which has no satisfactory error checking option. It would be curious, if an automatic array of zero length would be considered a run-time error.
The use of Intel checking options with MPI raises some questions, as MPI headers cause run-time checks for existence of receive buffers which aren't about to be used. However, you didn't include any MPI headers, and this problem shows up independent of any MPI inclusions.

[Ron_Green]

I'll get a bug report started. DPD200120700 is the tracking number.

As for the syntax: I'll have to check: For example,

integer, parameter :: lastrank=42

would avoid the problem.

ron

[TimP]

Quoting - Ronald Green (Intel)

As for the syntax: I'll have to check, but I am not sure your automatic arrays can have bounds that are neither arguments or parameterized variables. For example,

integer, parameter :: lastrank=42

would avoid the problem.

This would no longer be an automatic array, in the Fortran 90 sense. For sure, it would avoid run-time checking for initialization and for an in-range value for subsequent usage.
Ron has a valid point, as far as it goes. Some references state explicitly that the size of an automatic array must be a dummy argument, or calculated directly in an expression using only a dummy argument and parameter constants. Others state that it may also be present in a COMMON block at entry. These are the expected usages on which Fortran 90 changed it from an extension implemented by a few f77 compilers into a standard. So the quoted code has gone off into a possibly untested corner, possibly one which wasn't considered by the standards committee. It's hard to see why a module variable would not work at least as well as a common block variable. If the compiler doesn't support the usage, it should say so; it should not fail with internal error.

[andrewmcleod]

Quoting - tim18

This would no longer be an automatic array, in the Fortran 90 sense. For sure, it would avoid run-time checking for initialization and for an in-range value for subsequent usage.
Ron has a valid point, as far as it goes. Some references state explicitly that the size of an automatic array must be a dummy argument, or calculated directly in an expression using only a dummy argument and parameter constants. Others state that it may also be present in a COMMON block at entry. These are the expected usages on which Fortran 90 changed it from an extension implemented by a few f77 compilers into a standard. So the quoted code has gone off into a possibly untested corner, possibly one which wasn't considered by the standards committee. It's hard to see why a module variable would not work at least as well as a common block variable. If the compiler doesn't support the usage, it should say so; it should not fail with internal error.

All I can find in the F2003 draft standard is the section below, which suggests that strictly speaking it is not an automatic array (because it is a dummy argument), just an explicit shape array whose bounds are defined by evaluating the bounds expression at entry to the subroutine. To me this suggests that any expression should be OK provided it can be evaluated. But I could easily be missing a restriction on dummy arguments somewhere. Do you think it is valid Fortran?

Some references seem to this refer to 'adjustable arrays', which is not a term I could find in the standard.

Just out of curiosity where is the bug tracker webpage for the bug tracker ID given above?

Thanks :)

"5.1.2.5.1 Explicit-shape array
An explicit-shape array is a named array that is declared with an explicit-shape-spec-list. This species
explicit values for the bounds in each dimension of the array.
R511 explicit-shape-spec is [ lower-bound : ] upper-bound
R512 lower-bound is specication-expr
R513 upper-bound is specication-expr
C542 (R511) An explicit-shape array whose bounds are not initialization expressions shall be a dummy
argument, a function result, or an automatic array of a procedure.
An automatic array is an explicit-shape array that is declared in a subprogram, is not a dummy
argument, and has bounds that are not initialization expressions.
If an explicit-shape array has bounds that are not initialization expressions, the bounds, and hence
shape, are determined at entry to the procedure by evaluating the bounds expressions. The bounds of
such an array are unaffected by the redenition or undenition of any variable during execution of the
procedure.
The values of each lower-bound and upper-bound determine the bounds of the array along a particular
dimension and hence the extent of the array in that dimension. The value of a lower bound or an upper
bound may be positive, negative, or zero. The subscript range of the array in that dimension is the set
of integer values between and including the lower and upper bounds, provided the upper bound is not
less than the lower bound. If the upper bound is less than the lower bound, the range is empty, the
extent in that dimension is zero, and the array is of zero size. If the lower-bound is omitted, the default
value is 1. The number of sets of bounds specied is the rank."

[TimP]

You're right, I misread the example.
The terminology "adjustable array" was last used in the f77 standard. The specification about allowing the dimension bound to appear either in the argument list or in COMMON is in the f77 standard. I always found the change in terminology (20 years ago) difficult to grasp. "assumed-size" was introduced in the f77 standard, and retained, and didn't necessarily have a different implementation from became specified as "explicit-shape." As the change came with the introduction of module, the old term couldn't strictly be applied here.
In some of the most popular f77 implementations, a zero sized adjustable array was treated as an unrecoverable run-time error, but I thought one of the goals in more recent standards was to make zero sized arrays useable.

[Ron_Green]

Andrew,

Our bug tracking is not published externally to the Internet. What you can do is open an issue at http://premier.intel.com. Make is a short bug report, something like "I reported a bug on the User Forum, post 65015. Please open an issue for me on this, assign ownership to Ronald Green, reference DPD200120700"

The Premier issue then will alert you when a fix is ready to test.

OR you can watch this forum thread.

ron

[Ron_Green]

This bug is fixed in the latest 11.1 and 'Composer XE 2011' compilers.

ron