[Bug fortran/41129] New: unassociated pointers are reported as associated by associated function in types

[Bug fortran/41129] New: unassociated pointers are reported as associated by associated function in types

[evan dot fishbein at jpl dot nasa dot gov]

The following code segment

program scr
  type S1
     real, dimension(:), pointer :: P           ! NLEV
     real, dimension(:), pointer :: t           ! NLEV
  end type S1

  type S0
     real, dimension(:), pointer :: P           ! NLEV
  end type S0

  type (S0) :: x0
  type (S1) :: x1
  write (*,*)  'x0%P', associated(x0%P)
  allocate(x0%P(20))
  write (*,*)  'x0%P', associated(x0%P)

  write (*,*)  'x1%P', associated(x1%P)
  allocate(x1%P(20))
  write (*,*)  'x1%P', associated(x1%P)

 if (associated(x11%P)) deallocate(x11%P)
end program scr

compiled under gfortran:

gfortran -o scr scr.f90 ; scr
 x0%P F
 x0%P T
 x1%P T
 x1%P T
*** glibc detected *** double free or corruption (out): 0x0000000000400bc0 ***
Abort

compiled using the absoft compiler
/opt/absoft/bin/f90 -o scr scr.f90 ; scr
 x0%P F
 x0%P T
 x1%P F
 x1%P T

The textbook "Fortran 90 programing,  Ellis et al" says that the absoft
compiler is producing the correct answer -- the gfortran is not.  Generally the
compiler is misinterpreting types containing multiple pointers. attempts to
deallocate a pointer returned as associated produces an error


-- 
           Summary: unassociated pointers are reported as associated by
                    associated function in types
           Product: gcc
           Version: 4.1.2
            Status: UNCONFIRMED
          Severity: critical
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: evan dot fishbein at jpl dot nasa dot gov


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

[Bug fortran/41129] unassociated pointers are reported as associated by associated function in types

[evan dot fishbein at jpl dot nasa dot gov]

------- Comment #1 from evan dot fishbein at jpl dot nasa dot gov  2009-08-20 04:11 -------
(In reply to comment #0)
> The following code segment
> 
> program scr
>   type S1
>      real, dimension(:), pointer :: P           ! NLEV
>      real, dimension(:), pointer :: t           ! NLEV
>   end type S1
> 
>   type S0
>      real, dimension(:), pointer :: P           ! NLEV
>   end type S0
> 
>   type (S0) :: x0
>   type (S1) :: x1
>   write (*,*)  'x0%P', associated(x0%P)
>   allocate(x0%P(20))
>   write (*,*)  'x0%P', associated(x0%P)
> 
>   write (*,*)  'x1%P', associated(x1%P)
>   allocate(x1%P(20))
>   write (*,*)  'x1%P', associated(x1%P)
> 
>  if (associated(x11%P)) deallocate(x11%P)
> end program scr
> 
> compiled under gfortran:
> 
> gfortran -o scr scr.f90 ; scr
>  x0%P F
>  x0%P T
>  x1%P T
>  x1%P T
> *** glibc detected *** double free or corruption (out): 0x0000000000400bc0 ***
> Abort
> 
> compiled using the absoft compiler
> /opt/absoft/bin/f90 -o scr scr.f90 ; scr
>  x0%P F
>  x0%P T
>  x1%P F
>  x1%P T
> 
> The textbook "Fortran 90 programing,  Ellis et al" says that the absoft
> compiler is producing the correct answer -- the gfortran is not.  Generally the
> compiler is misinterpreting types containing multiple pointers. attempts to
> deallocate a pointer returned as associated produces an error
> 

There is a missing line in the code above:

type (S1) :: x11


-- 


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

[Bug fortran/41129] unassociated pointers are reported as associated by associated function in types

[kargl at gcc dot gnu dot org]

------- Comment #2 from kargl at gcc dot gnu dot org  2009-08-20 05:59 -------
gfortran 4.5.0 gives

REMOVE:kargl[5] ./z
 x0%P T
 x0%P T
 x1%P F
 x1%P T

Given that you are using a f95 compiler, I believe that you are
invoking processor-dependent behavior.  F95 states

  2.4.6    Pointer
  A pointer is a variable that has the POINTER attribute. A pointer
  is associated with a target by allocation (6.3.1) or pointer assignment
  (7.5.2).  A pointer shall neither be referenced nor defined until it is
  associated.

You're first use of ASSOCIATED references a pointer that has not been
associated with a target or through allocation.  Further, in Section
4.4.1 it states

   A component is a pointer if its component-attr-spec-list contains
   the POINTER attribute.  Pointers have an association status of
   associated, disassociated, or undefined.  If no default initialization
   is specified, the initial status is undefined.

Your derived types do not use default initialization.  Finally, one finds

  13.14.13   ASSOCIATED (POINTER [, TARGET])

     Description. Returns the association status of its pointer argument
     or indicates the pointer is associated with the target.

     Class. Inquiry function.

     Arguments.

     POINTER           shall be a pointer and may be of any type.
     Its pointer association status shall not be undefined.

Thus, I think gfortran is giving an acceptable answer.

PS: gfortran  bugs are never have a severity of critical.

PPS: I'll let someone else determine if my analysis is correct.  I've
been known to read the standard with a fairly strict interpretation.

PPPS:  Fortran 2003 has different restriction on ASSOCIATED and pointers.
I'm too lazy at the moment to look up the differences.

PPPPS: You really want to update from version 4.1.2 to at least a 4.4.x
version.


-- 

kargl at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|critical                    |normal


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

[Bug fortran/41129] unassociated pointers are reported as associated by associated function in types

[jv244 at cam dot ac dot uk]

------- Comment #3 from jv244 at cam dot ac dot uk  2009-08-20 07:09 -------
the pointers are undefined and thus it is not standard conforming to ask for
their state. This is like asking if an uninitialized integer is 0 or not.

you can use

  type S0
     real, dimension(:), pointer :: P  => NULL()         ! NLEV
  end type S0

to provide an 'initial value'.


-- 

jv244 at cam dot ac dot uk changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


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

[Bug fortran/41129] unassociated pointers are reported as associated by associated function in types

[burnus at gcc dot gnu dot org]

------- Comment #4 from burnus at gcc dot gnu dot org  2009-08-20 07:12 -------
(In reply to comment #0)
>   type S0
>      real, dimension(:), pointer :: P           ! NLEV
>   end type S0
> 
>   type (S0) :: x0
>   write (*,*)  'x0%P', associated(x0%P)

You have never initialized the pointer x0%P. Contrary to allocatables, pointers
have three states: associated, disassociated, or undefined. And your pointer is
in the "undefined" state.

Solutions:

a) If you want to stick to Fortran 90:
Add a "NULLIFY(x0%P)" after "type(S0) :: x0"

b) Using the Fortran 95, add a default initializer to the type declaration
   type S0
      real, dimension(:), pointer :: P => NULL()
   end type S0

c) Using a post-Fortran 95 compiler, which supports technical report TR 15581
or that part of Fortran 2003:

   type S0
      real, dimension(:), ALLOCATABLE :: P
   end type S0

   if (.not. ALLOCATED (X0%P)) allocate(X0%P(...))

Using (c) has the advantage that allocatables are nicer and faster.
(Allocatables can never leak memory and have only two states - allocated and
not allocated; and as they cannot not share the memory address with another
variable, the compiler can do better optimizations and generate thus faster
code.)

While most Fortran 95 compilers offer allocatable components, I think Absoft
does not do so (yet?).

> The textbook "Fortran 90 programing,  Ellis et al" says that the absoft
> compiler is producing the correct answer

Well, the authoritative source is the Fortran standard with all the corrigenda
(and answered interpretation requests), see 
http://gcc.gnu.org/wiki/GFortranStandards for links.

I am not sure whether Ellias et al. got it wrong, described it misleadingly or
whether you have just misreading it.

(For the relevant quotes from the standard, see comment 2.)


Can we close the bug as INVALID or do you still see something which gfortran
seems to do wrongly?


-- 


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