This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] Fix fortran/25031, multiple allocations
On Wed, Mar 01, 2006 at 06:18:10PM -0800, Brooks Moses wrote:
> Steve Kargl wrote:
> >On Wed, Mar 01, 2006 at 06:03:26PM -0800, Brooks Moses wrote:
> >>F95 Draft Standard, 6.3.1.1: "An allocatable array that has been
> >>allocated by an ALLOCATE statement and has not been subsequently
> >>deallocated (6.3.3) is *currently allocated* and is definable.
> >>Allocating a currently allocated allocatable array causes an error
> >>condition in the ALLOCATE statement." (emphasis in original)
> >
> >So? An "error condition" does not mean that the program fails.
> >It means that if one had used STAT=, then one can determine if
> >an "error condition" occurred. AFAICT, the Standard does not
> >prohibit a memory leak. NAG's compiler compiles the above and
> >Lahey's web based checker also compiles the code.
>
> Point taken; I should have thought more about what "error condition"
> means in standard-speak, rather than assuming.
>
> However, in 6.3.1 just above the 6.3.1.1 section heading is the comment:
> "If an error condition occurs during execution of an ALLOCATE statement
> that does not contain the STAT= specifier, execution of the program is
> terminated."
>
> The preceeding paragraph seems to me to say that, when STAT= is present,
> it should indicate the error condition, and that the allocated array in
> your example should be either allocated as x(4) or x(3), though which of
> those it ends up as is processor-dependent. I believe it's a
> quality-of-implementation issue that the compiler should avoid creating
> memory leaks in such a case.
>
I completely agree with the quality-of-implementation concept.
Unfortunately, the Standard is vague. If STAT= is present
and an error condition occurs the "allocate-object will have
a processor-dependent status". Then later in the same paragraph,
we find "each allocate-object that was not successfully allocated
shall retain its previous allocation status ...". I could be wrong,
but this simply means ALLOCATED(x) will be .true. and we have
either x(4) or x(3). :(
PS: NAG compiles the code. I forgot to run the executable, so
it may abort at runtime. Unfortunately, my NAG compiler is at work,
so I won't be able to test this until tomorrow.
--
Steve