[Bug fortran/97920] [FINAL] -O2 segment fault due to extend derive type's member being partially allocated

["pault at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

Paul Thomas <pault at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING
                 CC|                            |pault at gcc dot gnu.org

--- Comment #2 from Paul Thomas <pault at gcc dot gnu.org> ---
(In reply to Martin Liška from comment #1)
> Confirmed with valgrind. At least as old as 4.9.0.

Hi,

>From a quick perusal of the standard, I find in F2003 16.4.2.1:

"Unless a pointer is initialized (explicitly or by default), it has an initial
association status of undefined. A pointer may be initialized to have an
association status of disassociated".

In your testcase, the status of b%b is undefined and so the compiler can do
anything it wants with it, including segfaulting. I think therefore that you
should initialize the derived types in your application as follows:

  type t1
    real, dimension(:), pointer :: a => NULL ()
  contains
    final :: t1f
  end type

  type, extends(t1) :: t2
    real, dimension(:), pointer :: b => NULL ()
  contains
    final :: t2f
  end type

This clears the valgrind error "Conditional jump or move depends on
uninitialised value(s)". Also the finalization is invoked so that the programme
completes with zero memory allocation,

To my surprise (probably due to standard ignorance), leaving the declared type
declarations as you have them, and declaring 'b' as

  type(t2) :: b = t2 (NULL(), NULL())

clears the valgrind fault but no finalization occurs. I notice that
finalization does not occur if an entity has the save attribute. gfortran
assigns 'b' the IMPLICIT-SAVE attribute, which is why the finalization does not
occur. I have been unable to find whether or not this is conforming.

However, initializing 'b' in an assignment:
  b = t2(NULL(), NULL())

clears the valgrind fault and results in the deallocation of memory. This
confirms my suspicion about the save attribute.

In conclusion, I do not believe that this is a bug. If you do not use pointers
as pointers, make them allocatable instead. These are automatically nullified
on entry into scope.

Thanks for the report by the way!

Paul