Internal compiler error on invalid pointer remapping

[Harald]

The following (invalid) code leads to a "catastrophic error":

  integer, pointer :: a(:)
  integer, target  :: b
  a(0:0) => b
end

% ifort -V ifort_pointer_remapping.f90
Intel(R) Fortran Compiler XE for applications running on IA-32, Version 15.0.2.164 Build 20150121
Copyright (C) 1985-2015 Intel Corporation.  All rights reserved.
FOR NON-COMMERCIAL USE ONLY

 Intel(R) Fortran 15.0-1793
ifort_pointer_remapping.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 ifort_pointer_remapping.f90 (code 1)

[Steven_L_Intel1]

Thanks, we'll check it out.

[Steven_L_Intel1]

Escalated as issue DPD200369231. But why do you say the remapping is invalid? I can't find any language rule this violates.

[Steven_L_Intel1]

Ah, I see now (from discussion in comp.lang.fortran).

Quoting from 15-007 (F2015 draft):

If bounds-remapping-list appears, it specifies the upper and lower bounds of each dimension of the pointer, and thus the extents; the pointer target shall be simply contiguous (6.5.4) or of rank one, and shall not be a disassociated or undefined pointer. (7.2.2.3)

The question then is if the target is "simply contiguous". You'd think at first that a scalar is, of course, "simply contiguous", but that's not how it's defined, as 6.5.4 keeps referring to "array".

I think this is "interp" material - I see no reason why a scalar can't be considered "simply contiguous", at least in this context.

[Steven_L_Intel1]

I thought about this some more, and tried other compilers. What you're doing is, conceptually, the same as passing a scalar actual argument to an array dummy, which is explicitly prohibited. (I'm not counting an array element here.) Therefore it follows, to me, that this pointer remapping should also be disallowed. I started work on an interpretation request for it but found that the changes started to look very weird.

NAG gives an error for this example. gfortran 4.8 (the only one I have handy) also gets an internal error. Have you tried gfortran 4.9?

I've asked the ifort team to give an error for this case and won't be proceeding with the interpretation request.

[Harald]

I only now looked at the definition of "simply contiguous" in 6.5.4, and learned that the formulation is rather restrictive and not very intuitive.  Consider e.g.:

  integer, pointer :: a(:)
  integer, target  :: c(1,1)
  a(0:0) => c           ! OK (no subscript range)
  a(0:0) => c( : , : )  ! OK
  a(0:0) => c( : ,1:1)  ! OK

! These are OK because of rank 1:
  a(0:0) => c( : , 1 )
  a(0:0) => c(1:1, 1 )
  a(0:0) => c( 1 , : )
  a(0:0) => c( 1 ,1:1)

! These are "not simply contiguous" according to 6.5.4:
! a(0:0) => c(1:1, : )
! a(0:0) => c(1:1,1:1)
! a(0:0) => c(1,1)      ! rank 0
end

So it disallows a few things one might like to use.

I do not understand why you think that what I am trying to do is "conceptually, the same as passing a scalar actual argument to an array dummy".  Can you elaborate on that?

Harald

[Steven_L_Intel1]

You want to associate an array with a scalar. It is similar to the following:

real :: r_scalar
call sub (r_scalar)
...
subroutine sub (r_array)
real :: r_array(1)

While this special case may seem reasonable, the standard disallows it:

If the actual argument is a noncoindexed scalar, the corresponding dummy argument shall be scalar unless the actual argument is default character, of type character with the C character kind (15.2.2), or is an element or substring of an element of an array that is not an assumed-shape, pointer, or polymorphic array. [12.5.2.4, paragraph 13]

This rule has bitten many in the past who started getting compile-time errors when we added generated interface checking. This prohibition has always been in the language (though without the exceptions in the past), but compilers didn't check it and people wrote code that passed scalars to arrays.

As I wrote above, I spent some time trying to craft suggested edits to the standard to allow this case but found it got more and more complex as I went along, leading me to believe it would not be acceptable to the standards committee.

[Harald]

Steve Lionel (Intel) wrote:

You want to associate an array with a scalar. It is similar to the following:

real :: r_scalar
call sub (r_scalar)
...
subroutine sub (r_array)
real :: r_array(1)

That's actually what I do NOT want.  In fact, the intent is to have:

integer, pointer :: a(:)
a(1:1) => scalar
call sub (a)
...
subroutine sub (a)
integer :: a(:)

(where "integer" is actually a user-defined type).  So this is not quite the same as your example.

Another option would be to rewrite the existing "sub" as an IMPURE ELEMENTAL subroutine.

IMO, the restrictions imposed for "simply contiguous" is unfortunate as it ignores that arrays of size 1, whatever their rank, and including scalars, cannot be associated through pointer remapping (EXCEPT the target being rank 1), although I do not see any technical reason for it.

But I do understand that modifications to the standard could be very difficult to formulate for a relaxed notion of  "simply contiguous".

[Steven_L_Intel1]

I agree that, conceptually, it's safe. But is the use case so compelling as to complicate other parts of the language? A feature restricted to size 1 arrays is very weird.

[Steven_L_Intel1]

The bug has been fixed so that version 16 will give an error for this usage.