automatic arrays with negative size in g95 and gfortran
beli...@aol.com
module auto_mod
implicit none
contains
function int_func(n) result(ivec)
integer, intent(in) :: n
integer :: ivec(n)
integer :: i
if (n > 0) then
forall (i=1:n) ivec(i) = i
end if
end function int_func
end module auto_mod
!
program xint_func
use auto_mod, only: int_func
implicit none
integer, parameter :: n=3,ii(n)=(/2,0,-1/)
integer :: i
do i=1,n
print*,i,ii(i),int_func(ii(i))
end do
end program xint_func
g95 gives output
1 2 1 2
2 0
3 -1
and gfortran gives
Fortran runtime error: Attempt to allocate a negative amount of memory.
1 2 1 2
2 0
3 -1
For ii(3) equaling -1, gfortran crashes. Are the both compilers
conforming to the standard?
If g95 does, I would prefer that gfortran emulate it in this case.
In function int_func I can replace
integer :: ivec(n)
with
integer :: ivec(max(0,n))
which works for both compilers.
Richard E Maine
[code elided except for one line]
> integer :: ivec(n)
There is no such thing as an array of negative size - automatic or
otherwise. Do not confuse bounds with size. The array declaration does
not directly have the size. It has the bounds, from which the size is
then computed. Yes, it makes a difference, particularly in cases like
this.
The standard is pretty simple and explicit on this one. See f95
5.1.2.4.1 (Explicit-shape array). The antipenultimate sentence of the
section is
"If the upper bound is less than the lower bound, the range is
empty, the extent in that dimension is zero, and the array
is zero size."
That's the situation you are in when n<=0 in the code shown. (The lower
bound is implicitly 1). Thus, for n=-2, which was the case in question,
the size is zero, not negative. The code is standard-conforming (as best
as I can see) and the results reported for g95 are correct.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
Thomas Koenig
>and gfortran gives
>
>Fortran runtime error: Attempt to allocate a negative amount of memory.
As Richard Maine noted, this is a bug in gfortran.
Could you please submit a bug report under http://gcc.gnu.org/bugzilla ?
Thanks!
Thomas
Steven G. Kargl
nos...@see.signature (Richard E Maine) writes:
> <beli...@aol.com> wrote:
> [code elided except for one line]
>> integer :: ivec(n)
>
> There is no such thing as an array of negative size - automatic or
> otherwise. Do not confuse bounds with size. The array declaration does
> not directly have the size. It has the bounds, from which the size is
> then computed. Yes, it makes a difference, particularly in cases like
> this.
>
First, I agree with everything you wrote concerning zero sized
arrays. Looks like a gfortran bug.
However, I'll note your statement above seems to address what you
thought you read and not what was actually written. The only
statement from beliavsky with the word "negative" is gfortran's
error message.
Fortran runtime error: Attempt to allocate a negative amount of memory.
It says "negative amount of memory" not "negative size". gfortran
see it has an array, computes the amount of needed storage, and then
notes that the memory allocation would be a negative number of bytes.
Richard E Maine
> In article <1hgm98f.1ebu74wx4uaoiN%nos...@see.signature>,
> nos...@see.signature (Richard E Maine) writes:
> > There is no such thing as an array of negative size...
> However, I'll note your statement above seems to address what you
> thought you read and not what was actually written. The only
> statement from beliavsky with the word "negative" is gfortran's
> error message....
> It says "negative amount of memory" not "negative size".
That's the only appearance of the word "negative" in the body. But look
in the subject line.
Steven G. Kargl
nos...@see.signature (Richard E Maine) writes:
> Steven G. Kargl <ka...@troutmask.apl.washington.edu> wrote:
>
>> In article <1hgm98f.1ebu74wx4uaoiN%nos...@see.signature>,
>> nos...@see.signature (Richard E Maine) writes:
>
>> > There is no such thing as an array of negative size...
>
>> However, I'll note your statement above seems to address what you
>> thought you read and not what was actually written. The only
>> statement from beliavsky with the word "negative" is gfortran's
>> error message....
>> It says "negative amount of memory" not "negative size".
>
> That's the only appearance of the word "negative" in the body. But look
> in the subject line.
>
Whoops. Subject lines that contain (mis)information should
be repeated in the body of the message. :)
I stand corrected (well, I'm actually seated).
Mark Westwood
the only time in my career when I get the opportunity so here goes ...
... for 'antipenultimate' you should have written 'antepenultimate' ...
so very sorry :-(
Regards
Mark Westwood
Fortran hacker, formerly student of Classical Greek
Jugoslav Dujic
| I'm sorry to have to correct Richard E Maine but this will probably be
| the only time in my career when I get the opportunity so here goes ...
|
| ... for 'antipenultimate' you should have written 'antepenultimate' ...
|
| so very sorry :-(
I wished to correct his misuse of "loose" instead of "lose" several times,
but I refrained for the same reasons ;-).
--
Jugoslav
___________
www.xeffort.com
Please reply to the newsgroup.
You can find my real e-mail on my home page above.
Richard Maine
> ... for 'antipenultimate' you should have written 'antepenultimate' ...
I don't suppose I could claim that I was talking about being opposed to
the penultimate sentence? :-)
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
glen herrmannsfeldt
(snip)
> There is no such thing as an array of negative size - automatic or
> otherwise. Do not confuse bounds with size. The array declaration does
> not directly have the size. It has the bounds, from which the size is
> then computed. Yes, it makes a difference, particularly in cases like
> this.
(snip)
> "If the upper bound is less than the lower bound, the range is
> empty, the extent in that dimension is zero, and the array
> is zero size."
For comparison purposes, the argument to malloc() in most C libraries
is unsigned, so a negative value will be treated as a very large
positive value. Even worse, many will return zero (NULL) when the
argument is zero, a request to allocate a zero size array. Since NULL
is returned when the allocation failed, the program will normally assume
it failed, and treat it appropriately. Some, it seems, treat a request
of zero as a request for 2**32 bytes (on 32 bit systems) which usually
fails.
Recently I was working with an R program which calls a Fortran
subroutine. (Written in Fortran 77, I don't know which compiler was
used.) It seems than neither the R code nor the Fortran code checked
for zero, and passing a zero length array crashed R. (R is like an IDE
where programs and data are modified and run from inside R. If you
don't save your program or data before the crash, it is lost.)
-- glen
robert....@sun.com
glen herrmannsfeldt wrote:
> For comparison purposes, the argument to malloc() in most C libraries
> is unsigned, so a negative value will be treated as a very large
> positive value. Even worse, many will return zero (NULL) when the
> argument is zero, a request to allocate a zero size array. Since NULL
> is returned when the allocation failed, the program will normally assume
> it failed, and treat it appropriately. Some, it seems, treat a request
> of zero as a request for 2**32 bytes (on 32 bit systems) which usually
> fails.
No, the C standard allows that behavior. Some (misguided) people
think it is a good idea. The specific language of the C standard is
If the size of the space requested is zero, the behavior is
implementation-defined: either a null pointer is returned,
or the behavior is as if the size were some nonzero value,
except that the returned pointer shall not be used to access
an object.
Bob Corbett
glen herrmannsfeldt
> glen herrmannsfeldt wrote:
(snip)
>> Some, it seems, treat a request of zero as a request for 2**32
>> bytes (on 32 bit systems) which usually fails.
> No, the C standard allows that behavior. Some (misguided) people
> think it is a good idea. The specific language of the C standard is
> If the size of the space requested is zero, the behavior is
> implementation-defined: either a null pointer is returned,
> or the behavior is as if the size were some nonzero value,
> except that the returned pointer shall not be used to access
> an object.
Yes. I guess I didn't explicitly say that the standard allows
it (to fail), but I didn't say that it didn't allow it (to fail).
So, unlike Fortran which specifically allows dynamic allocation
requests for zero or negative values, (standard) C does not.
-- glen
Richard E Maine
> So, unlike Fortran which specifically allows dynamic allocation
> requests for zero or negative values, (standard) C does not.
No, Fortran does not allow a dynamic allocation request for a negative
value. In fact, there is no way to even express such a request. As
mentioned earlier in the thread. You do not directly specify allocation
size in Fortran; instead you specify array bounds. The allocation size
is computed by the compiler from the array bounds. That computation
never gets a negative value (well - not when done correctly). It is an
incorrect interpretation to describe this as a request to allocate a
negative amount of storage. And if it is negative values of the bounds
that you are talking about, rather than negative values of the
allocation size, then that doesn't necessarily have anything to do with
the question, insomuch as negative values of bounds don't necessarily
imply anything unusual in comparison to C. The criterion for zero size
is an upper bound being less than or equal to the lower bound; this
applies regardless of sign. The word "negative" is just not relevant.
The difference of note here is for the size zero case. There is no
negative size case that can even come up in Fortran.
glen herrmannsfeldt
> glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>>So, unlike Fortran which specifically allows dynamic allocation
>>requests for zero or negative values, (standard) C does not.
> No, Fortran does not allow a dynamic allocation request for a negative
> value. In fact, there is no way to even express such a request. As
> mentioned earlier in the thread. You do not directly specify allocation
> size in Fortran; instead you specify array bounds.
OK, in C one specifies the size and not the bounds. The lower bound is
considered to be zero, and there are well known ways to convert the
desired upper bound to a size: multiply the upper bound+1 (the same
value that is used for non-dynamic allocation) by the size of each
element (from the sizeof operator, where char variables have, by
definition, a size of one).
In most C implementations, the argument to malloc() is an unsigned
integer type, so technically it isn't possible to request a negative
allocation. The conversion of signed integers to unsigned integers is
defined to be modulo one more than the largest value of the unsigned
integer type, often a very large number.
> The allocation size
> is computed by the compiler from the array bounds. That computation
> never gets a negative value (well - not when done correctly). It is an
> incorrect interpretation to describe this as a request to allocate a
> negative amount of storage. And if it is negative values of the bounds
> that you are talking about, rather than negative values of the
> allocation size, then that doesn't necessarily have anything to do with
> the question, insomuch as negative values of bounds don't necessarily
> imply anything unusual in comparison to C. The criterion for zero size
> is an upper bound being less than or equal to the lower bound; this
> applies regardless of sign. The word "negative" is just not relevant.
The point that I was not making very well is that for the case where
the upper bound minus the lower bound is less than negative one, it
seems that Fortran guarantees not fail. C will, in most cases, attempt
to allocate a very large amount of memory, and most likely fail.
Even more, in most cases in C multiplying a signed integer by an
unsigned integer results in an unsigned product. I won't mention
the rules for relational operators, but they can be surprising.
For a request for zero bytes, the C standard allows malloc() to return
NULL, the normal indication for failure to allocate the requested
amount. Even more, C has no max() or min() function that could
conveniently be used to correct the allocation amount.
> The difference of note here is for the size zero case. There is no
> negative size case that can even come up in Fortran.
-- glen
Thomas Koenig
<beli...@aol.com> wrote:
>and gfortran gives
>
>Fortran runtime error: Attempt to allocate a negative amount of memory.
> 1 2 1 2
> 2 0
> 3 -1
>
FYI, this is now fixed on gfortran's main development branch. The fix
will be backported to 4.1 in about a week or so if no problems appear.