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

[xin.liu@compiler-dev.com]

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

--- Comment #5 from xin liu <xin.liu@compiler-dev.com> ---
(In reply to Paul Thomas from comment #2)
> (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

I get it, Thanks for your explain.