allocate with stat

[Gd]

I appear to have a problem with the allocate as my integer n grows. Specifically, the stat code returns a value 5014 and I notice that as n grows, the vector (set2 below) gets allocated even before an allocate is called upon it! I could check this with:
if (allocated (set2)) then
stop
end if

There apparently was some discussion on a similar topic on gcc mailing list (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50937) but can't figure out what the conclusion was. Is there something wrong with the way I am performing the allocation?

!----------------------
module global
save
integer, allocatable :: set1 (:), set2 (:), set3 (:)
end module
!----------------------
subroutine task1
use global
implicit none
! .. does nothing with set2
! .. do something with set1
end subroutine
!----------------------
subroutine task2
use global
implicit none
integer:: ierr, n
! ... do some calculations to generate n
allocate ( set2 ( n ), stat = ierr)
if (ierr /= 0) then
write (*,*) "set2 not allocated, stat = ", ierr
stop
end if
end subroutine
!----------------------
program main
use global
implicit none
call task1
call task2
stop
end program

[Gordon Sande]

On 2016-09-01 15:44:42 +0000, Gd said:

> I appear to have a problem with the allocate as my integer n grows.
> Specifically,

> the stat code returns a value 5014

Since you fail to mention a compiler or an operating system you will have to
Read The Fine Manual (know as RTFM with Fine being no so polite) yourself.

As a random guess (you get what you pay for) you have probably managed to
overwrite the internal allocation data structure with either a bad subscript
or a bad call. So turn on EVERY last debugging option you can find and try
again. Evwn better switch to a full debugging compier like NAG (for $$$)
or Silverfrost (ex Salford) (for free on Windows for personal use.

[Gd]

> Since you fail to mention a compiler or an operating system you will have to
> Read The Fine Manual (know as RTFM with Fine being no so polite) yourself.

GNU Fortran (Ubuntu 5.4.0-6ubuntu1~16.04.2) 5.4.0 20160609
Not sure if this helps?

[Gordon Sande]

The part that would have helped was where you reported what the f***ing manual
said about the error message number. ("When all else fails read the manual"
as Confucius would have said if there were computers back then)

Hold your nose and borrow a Windows box to run Silverfrost on what is probably
a not very large program and turn on ALL the debugging features of that
compiler.

[Thomas Jahns]

the options to try are

-g -fcheck=bounds,do,mem,pointers

Consider doing

man gfortran.

Thomas

[FortranFan]

On Thursday, September 1, 2016 at 11:44:44 AM UTC-4, Gd wrote:

> I appear to have a problem with the allocate as my integer n grows. Specifically, the stat code returns a value 5014 and I notice that as n grows, the vector (set2 below) gets allocated even before an allocate is called upon it! .. Is there something wrong with the way I am performing the allocation?
>
> ..


@Gd,

Some suggestions:

1) The code you post in not a working example of the problem. In order to obtain relevant and useful responses, it will be better if you post working code that illustrates the problem.

2) You can search for previous discussions on this forum too to look for answer(s) to your issue.

3) Look into ERRMSG= argument option with ALLOCATE statement in the Fortran standard. You can then see for yourself what the compiler says about the error it generates.

4) Your global variables (set1, set2, etc.) have the SAVE attribute. Given this, it makes sense to always inquire of allocation status with ALLOCATED intrinsic before performing the allocation.

5) As alluded to by other posters, look into compiler documentation and check the code with additional compilers, if possible.

6) Have you tried to run the code on any other computer with more (or less) memory to see if you are up against the limits of the system.

Good luck,

[campbel...@gmail.com]

Gd,

I would suggest that most of the other answers are unnecessary.
You sample code indicates that you first call task1 which uses arrays that have not been allocated.
This is illegal and you need to fix it.
How the program responds after that really is not the issue.

"I notice that as n grows, the vector (set2 below) gets allocated even before an allocate is called upon it!"

No, you have not identified a new standard conforming approach to using unallocated arrays.

[robin....@gmail.com]

On Friday, September 2, 2016 at 1:44:44 AM UTC+10, Gd wrote:

1. From the main, you call task 1, which uses SET1.
But SET1 has not been allocated.
2. From the main, you call set2. You allocate SET2,
but its dimension, n, has not been read in or assigned.

[Gd]

@robin

On Friday, 2 September 2016 10:16:52 UTC+1, robin....@gmail.com wrote:
> 1. From the main, you call task 1, which uses SET1.
> But SET1 has not been allocated.
> 2. From the main, you call set2. You allocate SET2,
> but its dimension, n, has not been read in or assigned.

The code I have is too big to paste here but I do allocate SET1 in task1. The dimension n is generated with some calculations (another 100 lines of code) before allocate is called on SET2.

@FortranFan

> 3) Look into ERRMSG= argument option with ALLOCATE statement in the Fortran >standard. You can then see for yourself what the compiler says about the >error it generates.

Yes, when I print msg in

allocate ( set2 ( n ), stat = ierr, errmsg = msg)
write (*,*) "error message is ", msg

I get
error message is Attempt to allocate an allocated object

I believe this is because the vector gets allocated even before allocate is called. I am not sure what is causing this unexpected behavior.

>>6) Have you tried to run the code on any other computer with more (or less) >>memory to see if you are up against the limits of the system.

Yes, it stopped with the same error message on another computer (with higher memory). I will try to recompile the code with additional compiler options to find where the bug could be.

[FortranFan]

On Friday, September 2, 2016 at 10:47:23 AM UTC-4, Gd wrote:

> ..

>
> I believe this is because the vector gets allocated even before allocate is called. I am not sure what is causing this unexpected behavior.
>

> ..


This comment of yours, "..vector gets allocated even before allocate is called..," is rather difficult to understand and believe. You may wish to remain open to other possibilities and explanations: putting together a small reproducer of your problem will be best, if you can focus your time and effort (and some imagination and being able to extrapolate or distill the issues) toward this.

[Stefano Zaghi]

Dear Gd,

One teachings that I learned here from great Fortraners like FortranFan and Richard Maine is that it is better to post a complete (possible concise) example raising the error rather than traing to explain what "we think the problem could be". As a matter of facts, we often start with "the wrong feet" focusing on some aspects that, at the end, are often not "the guilty". In order to obtain their help it is beter to provide them all the necessary data.

Another gold rule learned here is "try always to avoid to guess". However, rules are made to be broken, so let us start to guess :-) I am sure I am wrong, but sometimes I like to bet: is it possible that you are (not counsciously) exploiting the automatic (re)allocation of the left hand side of an array adsignment? I do not remember which standard had introduced this great feature (one of 2003 or 2008), but many (all the biggest?) compilers now support this feature... probably I am wrong because, in general, you have to pass a specific switch to the compiler to activate it, but this could explain why your are trying to allocate an array that is already allocated.

This is just a blind hint, trash it as your convenience.

My best regards.

[Richard Maine]

Stefano Zaghi <stefan...@gmail.com> wrote:

> Another gold rule learned here is "try always to avoid to guess". However,
> rules are made to be broken, so let us start to guess :-) I am sure I am
> wrong, but sometimes I like to bet: is it possible that you are (not
> counsciously) exploiting the automatic (re)allocation of the left hand
> side of an array adsignment? I do not remember which standard had
> introduced this great feature (one of 2003 or 2008), but many (all the
> biggest?) compilers now support this feature... probably I am wrong
> because, in general, you have to pass a specific switch to the compiler
> to activate it, but this could explain why your are trying to allocate
> an array that is already allocated.

Hmm. Hadn't occurred to me, but that does seem like a plausible guess.
It is a feature added in f2003. I was under the impression that most
compilers implemented it by default without special switches. It seems,
after all, a bit strange to have to use a special switch to tell a
compiler to implement the standard. I'm aware that the Intel compiler
at least used to default to violating the standard by default; don't
know whether that might have changed since.

--
Richard Maine
email: last name at domain . net
dimnain: summer-triangle

[Richard Maine]

Did a quick check with the program (this seemed easier than pawing
through the documentation)

program me
integer, allocatable :: array(:)
array = [1, 2, 3]
write (*,*) array
end program me

Worked fine as expected in gfortran with no special switches.
Required the switch -standard-semantics to work with ifort (version
16.0.0). So I guess it's still the case that ifort needs the switch.

[robin....@gmail.com]

On Saturday, September 3, 2016 at 12:47:23 AM UTC+10, Gd wrote:
> @robin

> On Friday, 2 September 2016 10:16:52 UTC+1, r.no...@gmail.com wrote:
> > 1. From the main, you call task 1, which uses SET1.
> > But SET1 has not been allocated.
> > 2. From the main, you call set2. You allocate SET2,
> > but its dimension, n, has not been read in or assigned.
> The code I have is too big to paste here but I do allocate SET1 in task1. The dimension n is generated with some calculations (another 100 lines of code) before allocate is called on SET2.
>
> @FortranFan
> > 3) Look into ERRMSG= argument option with ALLOCATE statement in the Fortran >standard. You can then see for yourself what the compiler says about the >error it generates.
>
> Yes, when I print msg in
>
> allocate ( set2 ( n ), stat = ierr, errmsg = msg)
> write (*,*) "error message is ", msg
>
> I get
> error message is Attempt to allocate an allocated object
>
> I believe this is because the vector gets allocated even before allocate is called. I am not sure what is causing this unexpected behavior.

That cannot happen. Your code has executed an ALLOCATE previously
for the array SET2.

Either there is AN ALLOCATE statement for SET2, or you have executed this ALLOCATE statement already [you are in some kind of loop].

Another possibility is that your code has corrupted itself.
You need to turn on all checks.

When you calculate N, do you print it out immediately?

[Stefano Zaghi]

Dear Richard,

Thank you for this insight, I was not aware the GNU gfortran behaves in a so standard way, probably I had associated it to the behaviour of Intel Compiler. Another explicit switch that I can avoid to pass :-)

Anyhow, Gd should provide more details.

My best regards.

[Stefano Zaghi]

Dear Robin,

> Another possibility is that your code has corrupted itself.

What do you mean with "corrupt itself", this is interesting. The first thing coming to my mind is a bug like the tentavive to access unavailable memore location, but in such a scenario I was expecting something like "segfault", the already allocated error is surprising in such a scenario. I am not able to think to other kind of "corruptions" different from "wrong" memory access (due to my ignorance), thus I am sincerely curiuos to know more details about what you are suspecting.

> You need to turn on all checks.

Totally agree, our first best friend should be the compiler (who is "never" wrong): a bullet-proof-debbuging compilation is always my first step "at the morning". This should be able to catch wrong memory location addressing.

My best regards.

[Thomas Koenig]

Richard Maine <nos...@see.signature> schrieb:

> It seems,
> after all, a bit strange to have to use a special switch to tell a
> compiler to implement the standard.

This is usual for Unix C compilers.

You have to specify -lm to be able to get all the math functions like
sin, cos, exp etc.

[Gordon Sande]

On 2016-09-03 06:14:32 +0000, Stefano Zaghi said:

> Dear Robin,
>
>> Another possibility is that your code has corrupted itself.
> What do you mean with "corrupt itself",

The classical Fortran error is an out of range subscript which allows
you to store
into parts of the executable code. The symptoms are often remote from
the error.
The same effect can also be achieved by having an arguement mismatch,
like array
being given a scalar, in a call. If you are lucky and the subscript is
wild enough
you get then you get a memory fault. For that you need an unintialized
subscript.
or floating point or such. The more usual running of the end of an array just
gets modified code, like the buffer overflow errors that trouble lots of code.

[herrman...@gmail.com]

On Saturday, September 3, 2016 at 11:02:43 AM UTC-7, Gordon Sande wrote:

(snip)

> The classical Fortran error is an out of range subscript which allows
> you to store into parts of the executable code. The symptoms are often
> remote from the error.

In all the years I have been writing programs, and known that this could
happen, I don't know of any actual case. In the Fortran 66 days, code and
data were usually close together. That is much more rare now.

> The same effect can also be achieved by having an argument

> mismatch, like array being given a scalar, in a call. If you are lucky
> and the subscript is wild enough you get then you get a memory fault.

A common implementation of malloc() in C stores the actual length
just before the part that you use. Storing just before the beginning, or
just after (and so just before the next one) tends to really mess up the
allocation system. As many Fortran libraries now use the C library to
do things like allocation, this still applies here.

> For that you need an unintialized subscript. or floating point or such.
> The more usual running of the end of an array just
> gets modified code, like the buffer overflow errors that trouble lots of code.

When you start mixing up integers and pointers (easier in C, but not so
hard here) things can go bad fast.

One that I still remember watching people do so many years ago, when
I knew many beginning Fortran programmers, was to forget (or not know
about the need to) dimension arrays in subroutines. The result is that the
compiler assumes it is a function being passed as an actual argument, and
then starts executing your data. No compile time message about this.

It was common enough that one could guess the problem before knowing
anything else about the program.

(With static allocation Fortran 66, some of the other allocation based
problems didn't occur.)