[Bug fortran/59065] New: questionable bounds for unassociated allocatable/pointer arrays?

[Bug fortran/59065] New: questionable bounds for unassociated allocatable/pointer arrays?

[zeccav at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59065

            Bug ID: 59065
           Summary: questionable bounds for unassociated
                    allocatable/pointer arrays?
           Product: gcc
           Version: 4.8.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: zeccav at gmail dot com

! gfortran produces SIGSEV at run time for access to unassociated
allocatable/pointer arrays
! questionable bounds for unassociated allocatable/pointer arrays?
! such arrays properties are undefined but I suggest lbound be 1, ubound 0,
size 0
! to minimize damage to erroneous code accessing such arrays
! -fcheck=all does not help
! Linux Fedora 19 bash shell 4.2.45-1
      real, pointer :: ap(:)=>null()
      real, allocatable :: aa(:)
      print *,lbound(aa),ubound(aa),size(aa) ! displays "0 garbage garbage"
should be "1 0 0"?
      print *,lbound(ap),ubound(ap),size(ap) ! displays "0 0 1" should be "1 0
0"?
      call sub(aa,ap)
      contains 
      subroutine sub(va,vp)
      real, intent(in) :: vp(:)
      real, intent(in) :: va(:)
      print *,lbound(va),ubound(va),size(va) ! displays "1 garbage garbage"
should be "1 0 0"?
      print *,lbound(vp),ubound(vp),size(vp) ! displays "1 1 1" should be "1 0
0"?
      print *,va(1) ! SIGSEGV here -fcheck=all does not detect it
      print *,vp(1) ! ditto
      end subroutine
      end

[Bug fortran/59065] questionable bounds for unassociated allocatable/pointer arrays?

[kargl at gcc dot gnu.org]

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?

[zeccav at gmail dot com]

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?

[sgk at troutmask dot apl.washington.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59065

--- Comment #3 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Sun, Nov 10, 2013 at 07:46:55PM +0000, zeccav at gmail dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59065
> 
> --- Comment #2 from Vittorio Zecca <zeccav at gmail dot com> ---

(compiler results deleted to keep this short).

Thanks for checking other compilers.

> All of them put SIZE to zero that looks to me better
> than one as gfortran does.

So, how does one distinguish bewteen a valid and an invalid
program?

program foo
  integer, allocatable :: i(:)
  allocate(i(0))
  print *, size(i)
end

This has a valid zero sized array, whereas this doesn't

program foo
  integer, allocatable :: i(:)
  print *, size(i)
end

> But best behavior is g95's that detects the bug, and displays the
> correct line number

Agreed.  Detecting bugs is better.  But, the best behavior 
would be for the programmer not to write invalid code. :-)

[Bug fortran/59065] questionable bounds for unassociated allocatable/pointer arrays?

[dominiq at lps dot ens.fr]

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.

[Bug fortran/59065] questionable bounds for unassociated allocatable/pointer arrays?

[zeccav at gmail dot com]

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?

[anlauf at gmx dot de]

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.
ARRAY        shall 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?

[zeccav at gmail dot com]

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?

[sgk at troutmask dot apl.washington.edu]

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 +0000, 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?

[zeccav at gmail dot com]

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?

[zeccav at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59065

--- Comment #10 from Vittorio Zecca <zeccav at gmail dot com> ---
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?

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59065

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #11 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> This issue seems to have been resolved in the trunk gfortran 11.0.0

Confirmed for gfortran 11, no diagnostic in 10.2.1.