Fortran - a problem with XLF compiler

Author

a problem with XLF compiler

Fei Liu

2008-03-14, 7:32 pm

Hello Group,

Recently I encountered a problem with XLF compiler failing when this
code is run:

call my_sub(a=(/1,2,3/))

subroutien my_sub(a)
integer, dimension(:), optional :: a
integer, dimension(10) :: la ! domain knowledge, size(a) <= 10
if(present(a)) then
la = a
! correct way follows:
! la(1:size(a)) = a
endif
end subroutine

I don't remember the fortran standard forbids assigning a smaller
assumed shape array to a larger automatic array. This code works with
various compilers but not xlf compiler. Is this a geniune coding error
or a compiler problem?

What's the general guide line when making array assignments
(different types of LHS and RHS arrays)?

Thanks,

Fei

Richard Maine

2008-03-14, 7:32 pm

Fei Liu <fei.liu@gmail.com> wrote:

> call my_sub(a=(/1,2,3/))
>
> subroutien my_sub(a)
> integer, dimension(:), optional :: a
> integer, dimension(10) :: la ! domain knowledge, size(a) <= 10
> if(present(a)) then
> la = a
> ! correct way follows:
> ! la(1:size(a)) = a
> endif
> end subroutine
>
> I don't remember the fortran standard forbids assigning a smaller
> assumed shape array to a larger automatic array.

There is no automatic array here, but that isn't relevant anyway. The
shapes of the arrays are required to conform... which basically means
that they must be the same shape (or it is ok if the RHS is scalar).

There is nothing particularly subtle about that rule. It is also
reasonaby intuitive in that there is no way for an array of size 10 to
have a value of size 3. THey just aren't compatible.

As of f2003, things are different if the LHS is allocatable array. In
that case, the LHS is reallocated to the needed size as part of the
assignment.

> This code works with
> various compilers but not xlf compiler. Is this a geniune coding error
> or a compiler problem?

There are many, many coding errors that aren't necessarily detected by
compilers. That is particularly so for run-time error detection such as
this. The error is in the code - not the compiler.

> What's the general guide line when making array assignments
> (different types of LHS and RHS arrays)?

I assume you aren't talking about "types" as in Fortran types; that
doesn't seem to have much to do with the question. The example seems to
be just about array shapes instead of types. The basic rule for shapes
is quite simple. If both the LHS and RHS sides are arrays, they must be
the same shape. There is a slight extra bit in f2003 in that an
allocatable LHS will be alocated to the needed shape; one might say that
the same rule applies, but the reallocation makes it always be right.

If by array "types" you mean things like automatic (which you mention)
versus fixed size, that makes no difference.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain

Fei Liu

2008-03-14, 7:32 pm

Richard Maine wrote:
> Fei Liu <fei.liu@gmail.com> wrote:
>
>
> There is no automatic array here, but that isn't relevant anyway. The
> shapes of the arrays are required to conform... which basically means
> that they must be the same shape (or it is ok if the RHS is scalar).
>
> There is nothing particularly subtle about that rule. It is also
> reasonaby intuitive in that there is no way for an array of size 10 to
> have a value of size 3. THey just aren't compatible.
>
> As of f2003, things are different if the LHS is allocatable array. In
> that case, the LHS is reallocated to the needed size as part of the
> assignment.
>
>
> There are many, many coding errors that aren't necessarily detected by
> compilers. That is particularly so for run-time error detection such as
> this. The error is in the code - not the compiler.
>
>
>
> I assume you aren't talking about "types" as in Fortran types; that
> doesn't seem to have much to do with the question. The example seems to
> be just about array shapes instead of types. The basic rule for shapes
> is quite simple. If both the LHS and RHS sides are arrays, they must be
> the same shape. There is a slight extra bit in f2003 in that an
> allocatable LHS will be alocated to the needed shape; one might say that
> the same rule applies, but the reallocation makes it always be right.
>
> If by array "types" you mean things like automatic (which you mention)
> versus fixed size, that makes no difference.
>

Thanks, Rich and Walter. I got the message.

Fei

robin

2008-03-19, 7:15 pm

"Fei Liu" <fei.liu@gmail.com> wrote in message news:47DAA01C.1040400@gmail.com...
> Hello Group,
>
> Recently I encountered a problem with XLF compiler failing when this
> code is run:
>
> call my_sub(a=(/1,2,3/))
>
> subroutien my_sub(a)
> integer, dimension(:), optional :: a
> integer, dimension(10) :: la ! domain knowledge, size(a) <= 10

Surely you want:

integer, allocatable :: la(:)

> if(present(a)) then

allocate (la(size(a))

> la = a
> ! correct way follows:
> ! la(1:size(a)) = a
> endif
> end subroutine

Sponsored Links