Why stack overflow here?

[Bernhard Enders]

I know that I can increase the linker stack size to correct this
problem, but what I really want here is to understand why the following
call gives stack overflow if the involved arrays is already allocated
before calling and no additional (temporary) storage, in principle, is
required by the subroutine. I've already played with compiler
optimizations without success.

integer, parameter :: dp = selected_real_kind(p=15)
:
real(rp), dimension(:), allocatable :: x, y
:
npts = ...
:
allocate(x(npts), y(npts))
:
call print_vec (x, y, filename) ! stack overflow
:
subroutine print_vec (x, y, filename)
real(rp), dimension(:), intent(in) :: x, y
character(len=*), intent(in) :: filename
:
write (unt,fmt,iostat=ios) ( x(i), y(i), i=1, size(x) )
:
end subroutine print_vec

Thanks in advance,

Bernhard Enders.

[Ugo]

In this instruction

call print_vec (x, y, filename) ! stack overflow

the compiler is allowed to copy the value of the arrays x and y to a
new location if print_vec has an explicit interface. The standard
allows but does not impose that the
arrays should be passed by reference, because this would hinder many
optimizations.

The compiler you use ... well, which compiler are you using? On which
platform?

[Michael Metcalf]

"Bernhard Enders" <bge...@gmail.com> wrote in message
news:1142876265....@t31g2000cwb.googlegroups.com...

>I know that I can increase the linker stack size to correct this
> problem, but what I really want here is to understand why the following
> call gives stack overflow if the involved arrays is already allocated
> before calling and no additional (temporary) storage, in principle, is
> required by the subroutine. I've already played with compiler
> optimizations without success.
>

It's not obvious from your example that you have an explicit interface,
required for the assumed-shape array.

Regards,

Mike Metcalf

[Bernhard Enders]

Yes, I have an explicit interface to print_vec subroutine, as required
by assumed-shape dummy arrays. I'm using Intel Fortran Compiler 9 on
Windows and I always think that pass by reference would improve
performance, since we are avoiding unwanted object copy. How can I
force pass by reference in this case?

Bernhard.

[Joost]

you might be getting the stack overflow in the write if I can make a
guess.
Try once with an explicit DO-loop over the write statement.

Joost

[Bernhard Enders]

I've already tried the loop modification without success. I think the
problem here is that I don't know how to avoid array copy, i.e., how to
force 'pass by reference' instead of 'pass by value'. Thanks anyway,

Bernhard.

[Joost]

It would be really strange if an array temporary would be generated for
the call. At least what you show doesn't suggest this would be needed.

Joost

[Bernhard Enders]

I don't know if it does matter, but one thing that I omitted was the
interface to the procedure:

interface print_vec
module procedure print_1D
module procedure print_2D
end interface print_vec

And also that I'm using a beta version (9.1.015) of the Intel Fortran
Compiler for windows.

Bernhard.

[Richard Maine]

Bernhard Enders <bge...@gmail.com> wrote:

> I don't know if it does matter, but one thing that I omitted was the
> interface to the procedure:
>
> interface print_vec
> module procedure print_1D
> module procedure print_2D
> end interface print_vec

This makes no sense.

1. This is *NOT* the interface to print_vec. This is a generic interface
block that does nothing but say that print_1D and print_2D are part of
the generic. I just finished chiding someone else about misuse of the
term "interface". An interface block is not the same thing as an
interface. To determine the interface to the specific procedures
print_1D and print_2D, one would have to look at theirt source code.

2. You show here an interface block for a generic print_vec, while in
the original post you had a specific subroutine print_vec. You can't
have both.... well not both accessible in the same place....
well...anyway not without some subtleties. Do you really have both? Or
were you just trying to describe what you thought was the essense. It is
pretty hard to help someone based on ooking at code that isn't actually
what they have, particularly when the odss seem high that they
misunderstand the problem and thus have left out the critical parts. I
suggest that you need to show the actual code, and much more of it.

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

[Joe Krahn]

Richard Maine wrote:
> Bernhard Enders <bge...@gmail.com> wrote:
>
>
>>I don't know if it does matter, but one thing that I omitted was the
>>interface to the procedure:
>>
>>interface print_vec
>> module procedure print_1D
>> module procedure print_2D
>>end interface print_vec
>
>
> This makes no sense.
>
> 1. This is *NOT* the interface to print_vec. This is a generic interface
> block that does nothing but say that print_1D and print_2D are part of
> the generic. I just finished chiding someone else about misuse of the
> term "interface". An interface block is not the same thing as an
> interface. To determine the interface to the specific procedures
> print_1D and print_2D, one would have to look at theirt source code.
>

This type of confusion is an important lesson: Fortran is in some ways a
fairly simple language, but the nomenclature is not. There are a lot of
seemingly similar terms that are very important to get right, and they
are easy to forget because you don't see them in the source code.

The above is a good example. You see 'interface' and 'print_vec', so it
is easy to think the phrase "interface to print_vec". Even experienced
programmers can do this. It leads to a lot of unintentional confusion.

So, remember: learning Fortran means learning both the Fortran language
syntax and the Fortran Standard language syntax. (I think that's a good
way to say it, or maybe I'm making a mistake on an even higher level of
syntax?)

Joe

[Paul Van Delst]

I think it's more of a "people" thing than a Fortran thing. By that I mean people are
imprecise in everyday speech (usenet posts qualify? :o) that has nothing to do with
Fortran. The definitions for one language (spoken or programmed) may mean something
completely different in another.

cheers,

paulv

--
Paul van Delst
CIMSS @ NOAA/NCEP/EMC

[Bernhard Enders]

I think both Paul and Joe are right. Fortran has its details, as any
other programming language. And details usually make difference. So
thank you Richard (one more time) for your valuable and precise
definition of interface and interface block. In the previous post Paul
got the point: "people are imprecise in everyday speech" and certainly
that's was an imprecise post of mine. In fact, the print_vec procedure
definition provides an
explicit interface, since it is defined in a module, so there is no
need to provide an interface block in this case... but if we'are
playing with procedure overloading (as we are) we must provide a
generic name to the procedure via interface blocks. So, beyond the
explicit interface to the procedure what I have is the interface block
just posted. Please correct me if I'm still wrong or confused. Yes, I
can't have both print_vec names, that was my mistake also. I'll post a
minimal example later. Thank you all.