Re: why doesn't this compile ?



Richard E Maine wrote:
> In article <1114635172.915844@xxxxxxxxxxxxxxxxxxxxxxxxxxx>,
> Bart Vandewoestyne <MyFirstName.MyLastName@xxxxxxxxxx> wrote:
>
> > I am cleaning up my directory with test and example programs, and I
came
> > across the following testprogram that I've written somewhere in the
past:
> >
> >
http://www.cs.kuleuven.ac.be/~bartv/downloads/test_array_arguments.f95
> >
> > I guess I wanted to demonstrate to myself how to write a function
that
> > can act on arrays of both rank 1 and rank 2, but unfortunately this
> > thing doesn't compile anymore.
>
> Looks fine to me. And it compiles and runs fine with both compilers
that
> I just tried (Nag and g95). This suggests a compiler problem.

I think the original code at the link Bart provided was different from
what is currently there, and the original code was not accepted by the
compilers I tried. I think it was

program test_array_arguments

implicit none

! This interface allows us to pass both rank 1 and rank 2 arrays to
the
! function f.
interface f
function f_2(x) result (y)
integer, intent(in), dimension(:,:) :: x
integer, dimension(size(x,2)) :: y
end function f_2
function f_1(x) result (y)
integer, intent(in), dimension(:) :: x
integer :: y
end function f_1
end interface f

integer, dimension(2,3) :: x


! Create a 3x2 array
x(:,1) = (/ 1, 1 /)
x(:,2) = (/ 2, 2 /)
x(:,3) = (/ 3, 3 /)

! Call f on an array argument
print *, f(x)

! Call f on a vector argument
print *, f(x(:,1))

contains

! The function that takes a rank 2
! array as its argument.
function f_2(x) result (y)

integer, intent(in), dimension(:,:) :: x
integer, dimension(size(x,2)) :: y

y = sum(x, dim=1)

end function f_2

! The function that takes a rank 1
! array as its argument.
function f_1(x) result (y)

integer, intent(in), dimension(:) :: x
integer :: y

y = sum(x)

end function f_1

end program test_array_arguments

The code currently at that link looks like what I posted in this
thread, with a few blank lines added. In general, I think it is better
to post code in the newsgroup instead of a link in order to make
messages more self-contained, both for the benefit of current newsgroup
readers and those who may be reading years from now (when the link may
be gone).

.



Relevant Pages

  • Re: A Tale of Two Memory Managers (long)
    ... compilers. ... but the JIT also generates atrocious code. ... Multidimensional array access is even worse. ... deep implications for performance as every structure goes through the stack. ...
    (borland.public.delphi.non-technical)
  • Re: [OT] Funny
    ... matter of what is likely to happen in practice than what the standard ... Or more precisely, mixing f77 and f90. ... That's because f77 had no concept of array stride (i.e. noncontiguous ... to do was pass its starting address...and that's all most compilers ...
    (comp.lang.fortran)
  • Re: xlf Fortran Oddity
    ... I do not believe that Allocatable Derived Type is a Fortran 90/95 construct. ... This is supported by some compilers as an F2k extension. ... When compiled with array bounds checking, ... allocate & initialize derived type ...
    (comp.lang.fortran)
  • Re: internal read of character array. F/ifort differences
    ... undefined variables. ... different resultsfr on different compilers or situations. ... the array defined by the subroutine argument Headers, ... doesn't happen until after the end-of-file is detected. ...
    (comp.lang.fortran)
  • Re: xlf Fortran Oddity
    ... END TYPE MyType ... And, FWIW, I've had some minor issues with the xlf compilers so I wouldn't grant it any ... When compiled with array bounds checking, ...
    (comp.lang.fortran)