[Bug fortran/59065] questionable bounds for unassociated allocatable/pointer arrays?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59065 Dominique d'Humieres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Dominique d'Humieres --- > This issue seems to have been resolved in the trunk gfortran 11.0.0 Confirmed for gfortran 11, no diagnostic in 10.2.1.
[Bug fortran/59065] questionable bounds for unassociated allocatable/pointer arrays?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59065 --- Comment #10 from Vittorio Zecca --- This issue seems to have been resolved in the trunk gfortran 11.0.0 gfortran gfbug109.f -fcheck=pointer -g [vitti f95]$./a.out At line 9 of file gfbug109.f Fortran runtime error: Allocatable argument 'aa' is not allocated Error termination. Backtrace: #0 0x1458cf822d74 in ??? #1 0x1458cf823849 in ??? #2 0x1458cf823e5a in ??? #3 0x401b94 in MAIN__ at /home/vitti/f95/gfbug109.f:9 #4 0x401eb1 in main at /home/vitti/f95/gfbug109.f:11
[Bug fortran/59065] questionable bounds for unassociated allocatable/pointer arrays?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59065 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P5
[Bug fortran/59065] questionable bounds for unassociated allocatable/pointer arrays?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59065 --- Comment #7 from Vittorio Zecca zeccav at gmail dot com --- I believe most times a code knows if and when the size of an array must be nonzero, so a zerosize array would raise suspicions in those cases. Anyway in my opinion gfortran run time should detect when an unallocated/unassociated array is referenced and should raise an error situation, except for allocated intrinsic function. Only if that were impossible or too much time consuming I would suggest to force it as a zerosize array with one as lower bound and zero as upper bound for each dimension. A clever code should detect that something is wrong and take the right action (crashing?).
[Bug fortran/59065] questionable bounds for unassociated allocatable/pointer arrays?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59065
--- Comment #8 from Steve Kargl sgk at troutmask dot apl.washington.edu ---
On Tue, Nov 12, 2013 at 08:13:14AM +, zeccav at gmail dot com wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59065
--- Comment #7 from Vittorio Zecca zeccav at gmail dot com ---
I believe most times a code knows if and when the size of an array
must be nonzero, so a zerosize array would raise suspicions in
those cases.
Given the description of the return value for SIZE(), a
better value would be -1 as -1 is not a possible return
for valid code. Using a negative value for {L|U}BOUND
does not work as well as the bounds can be negative.
Anyway in my opinion gfortran run time should detect when an
unallocated/unassociated array is referenced and should raise
an error situation, except for allocated intrinsic function.
Only if that were impossible or too much time consuming
And here is your answer. Time. Someone would need to rewrite
a (possibly large?) chunk of the compiler (and be available
to fix the new bugs introduced).
I would suggest to force it as a zerosize array
with one as lower bound and zero as upper bound for each dimension.
A clever code should detect that something is wrong and take the right
action (crashing?).
A clever code would not access an unallocated or unassociated entity.
The clever programmer would have written
if (allocated(a)) then
! Do stuff with a
end if
or
if (.not. allocated(a)) allocate(a(some_arra_spec)
Yes, I'm aware that a programmer may want to write
subroutine foo(a)
real b(size(a))
where it is not possible to use the ALLOCATED (or ASSOCIATED) intrinsic.
Of course, using a block if-statement as shown above would prevent
calling foo with an unallocated (or unassociated) entity.
[Bug fortran/59065] questionable bounds for unassociated allocatable/pointer arrays?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59065 --- Comment #9 from Vittorio Zecca zeccav at gmail dot com --- Unfortunately associated() does not allow unassociated array pointers as input so your code works for allocatable arrays but not for array pointers. Yes, a negative value for size() is good. It is a pity there are not the human resources for detecting and handling access to unassociated array pointers. I stumbled into this issue by looking at abinit, a code in the public domain. I mean this is an example taken from a real life situation, it is not just fabricated as an exercise.
[Bug fortran/59065] questionable bounds for unassociated allocatable/pointer arrays?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59065 --- Comment #5 from Vittorio Zecca zeccav at gmail dot com --- I do not think SIZE should be used to detect an undefined array pointer, but a size of zero warns the code that the array is mostly unusable and that perhaps something is wrong, while a nonzero size is telling the program it is fine to use the array. I agree with Dominique, I am still writing invalid code all the time, also because interactive computing makes it so easy and fast to write, compile, link and execute code. When I used punched cards in the seventies I had more time to think and reflect about my programs, also because the turnaround time was about 30 minutes as compared with 30 seconds today If the programmers did not write invalid code many people would be out of business:-)
[Bug fortran/59065] questionable bounds for unassociated allocatable/pointer arrays?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59065 Harald Anlauf anlauf at gmx dot de changed: What|Removed |Added CC||anlauf at gmx dot de --- Comment #6 from Harald Anlauf anlauf at gmx dot de --- (In reply to Vittorio Zecca from comment #5) I do not think SIZE should be used to detect an undefined array pointer, but a size of zero warns the code that the array is mostly unusable and that perhaps something is wrong, while a nonzero size is telling the program it is fine to use the array. No. As Steve pointed out in comment #3, a zero sized array is perfectly fine. IMO that was a good choice in Fortran, so one does not have to special-case these when writing code. Your opinion may differ. Please also have a look at the Fortran standard, e.g. 13.7.156 SIZE (ARRAY [, DIM, KIND]) Description. Size of an array or one extent. Class. Inquiry function. Arguments. ARRAYshall be an array of any type. It shall not be an unallocated allocatable variable or a pointer that is not associated. ... I agree with Dominique, I am still writing invalid code all the time, also because interactive computing makes it so easy and fast to write, compile, link and execute code. When I used punched cards in the seventies I had more time to think and reflect about my programs, also because the turnaround time was about 30 minutes as compared with 30 seconds today If the programmers did not write invalid code many people would be out of business:-) Or they would be more productive...
[Bug fortran/59065] questionable bounds for unassociated allocatable/pointer arrays?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59065 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org Severity|normal |enhancement --- Comment #1 from kargl at gcc dot gnu.org --- The code is invalid, so gfortran's current behavior is accepted. What do other compilers do with the code? Although I think this should be closed with WONTFIX, I've changes the status to enhancement.
[Bug fortran/59065] questionable bounds for unassociated allocatable/pointer arrays?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59065 --- Comment #2 from Vittorio Zecca zeccav at gmail dot com --- g95: complains about deallocated array passed to LBOUND Intel ifort: 1 0 0 1 0 0 1 0 0 1 0 0 NAG nagfor: -220021792 -220021793 0 1 0 0 1 0 0 1 0 0 Lahey Fujitsu lfc: 0 0 0 0 0 0 1 0 0 1 0 0 All of them put SIZE to zero that looks to me better than one as gfortran does. But best behavior is g95's that detects the bug, and displays the correct line number as in the following: rm a.out ; g95 gfbug109.f -ftrace=full -g; ./a.out At line 8 of file gfbug109.f (Unit 6) Traceback: not available, compile with -ftrace=frame or -ftrace=full Fortran runtime error: Deallocated array passed to LBOUND So it would be an enhancement to sensibly handle unallocated/unassociated arrays.
[Bug fortran/59065] questionable bounds for unassociated allocatable/pointer arrays?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59065 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-11-10 Ever confirmed|0 |1 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr --- Agreed. Detecting bugs is better. But, the best behavior would be for the programmer not to write invalid code. :-) 'Let anyone among you who is without sin be the first to throw a stone at her. ...' and I love the following sentence: 'When they heard it, they went away, one by one, beginning with the elders' (john 7:53-8:11). I think there is a couple of PR's about invalid use of unallocated arrays or pointers.
