[Bug fortran/98454] New: Apparent wrong initialization in function result

[Bug fortran/98454] New: Apparent wrong initialization in function result

[fmartinez at gmv dot com]

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

            Bug ID: 98454
           Summary: Apparent wrong initialization in function result
           Product: gcc
           Version: 9.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: fmartinez at gmv dot com
  Target Milestone: ---

Created attachment 49845
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49845&action=edit
Module with type implmentation and test driver

Good morning.

The components of a derived type seem to be wrongly initialized when they type
is the output of a function (see code attached).
I would expect that any declaration of the type 
   type(t_test) :: x
would lead to all components initialized with the values explicitly provided in
the type declaration. It seem not to be the case in the attached example.

 Before constructor
   unit      =           -1
   default   =            0
   trace     =  T
   def trace =  F
 After constructor
   unit      =  -1230083984
   default   =        21901
   trace     =  T
   def trace =  F

I have tried with Intel 19.1 and it provides the expected behaviour.

 Before constructor
   unit      =           -1
   default   =            0
   trace     =  T
   def trace =  F
 After constructor
   unit      =           -1
   default   =            0
   trace     =  T
   def trace =  F

The same behaviour is observed in gfortran 11

Best regards,
Fran

[Bug fortran/98454] Apparent wrong initialization in function result

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4
                 CC|                            |kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
Your code is invalid Fortran for a few reasons.  gfortran can do anything it
wants with the code, which may or may not be what you expect.  The bug should
be closed with INVALID.  I'll someone make that final determination.

[Bug fortran/98454] Apparent wrong initialization in function result

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2020-12-27
                 CC|                            |anlauf at gcc dot gnu.org
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #2 from anlauf at gcc dot gnu.org ---
I think there already exists at least one PR with issues with initializers.

A reduced testcase shows that default initialization works for intent(out),
whereas you get random junk for function results.

module m_test
  implicit none
  type t
    integer :: unit = -1
  end type t
  interface test
     module procedure test_fun
  end interface
contains
  function test_fun() result(res)
    type(t) :: res
!    res = t()                     ! <-- workaround
  end function test_fun
  subroutine test_sub (res)
    type(t), intent(out) :: res
  end subroutine test_sub
end module m_test
program p
  use m_test
  implicit none
  type(t) :: x
  write(6,*) 'Before constructor'
  write(6,*) '  unit      = ', x%unit
  x = test()
  write(6,*) 'After constructor (test_fun)'
  write(6,*) '  unit      = ', x%unit
  call test_sub (x)
  write(6,*) 'After test_sub'
  write(6,*) '  unit      = ', x%unit
end program p

If you need a workaround, uncomment the indicated line.

[Bug fortran/98454] Apparent wrong initialization in function result

[anlauf at gcc dot gnu.org]

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
According to the tree-dump, adding a

  print *, res% unit

to the function body invokes the implicit initializer, while the line

  res = t()

actually invokes the initializer effectively twice!

[Bug fortran/98454] Apparent wrong initialization in function result

[kargl at gcc dot gnu.org]

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

--- Comment #4 from kargl at gcc dot gnu.org ---
(In reply to anlauf from comment #2)
> I think there already exists at least one PR with issues with initializers.
> 
> A reduced testcase shows that default initialization works for intent(out),
> whereas you get random junk for function results.

(code elide)

> If you need a workaround, uncomment the indicated line.

The code is invalid Fortran.  gfortran can do anything.
Your work around is invalid.  gfortran can do anything.

>From Fortran 2018:

"If the function result is not a pointer, its value shall be
defined by the function."

and
"A derived-type scalar object is defined if and only if all
of its nonpointer components are defined."


Should be closed as invalid as the original code contains a number
of issues caused by invalid code.

[Bug fortran/98454] Apparent wrong initialization in function result

[anlauf at gcc dot gnu.org]

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #4)
> Should be closed as invalid as the original code contains a number
> of issues caused by invalid code.

Steve, stop it!

My reduced testcase shows that there is a real bug.

[Bug fortran/98454] Apparent wrong initialization in function result

[ffadrique at gmail dot com]

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

--- Comment #6 from Fran Martinez Fadrique <ffadrique at gmail dot com> ---
I have raised the issue with respect to 4.5.3.4 of the ISO standard that
stablishes how the type component are initialized. Not just my expectations.

I have further developed my test case and any local variable declared in any
function or subroutine in the scope of the module where the type is declared
fails to properly initialize its components according to the default
initializations (using the terminology of the standard). The intent(out) seems
to make the difference and subroutine parameters are properly initialized.
Any variable created outside the module declaring the type seems to properly
initialize the components.

I compile with -std=2018 so I would expect that invalid Fortran is flagged, at
least with a warning, which is not the case.

[Bug fortran/98454] Apparent wrong initialization in function result

[ffadrique at gmail dot com]

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

--- Comment #7 from Fran Martinez Fadrique <ffadrique at gmail dot com> ---
By the way, thanks for the workaround. It cleanly solves the problem, at least
temporarily.

[Bug fortran/98454] Apparent wrong initialization in function result

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #8 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Sun, Dec 27, 2020 at 10:15:56PM +0000, ffadrique at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98454
> 
> --- Comment #6 from Fran Martinez Fadrique <ffadrique at gmail dot com> ---
> I have raised the issue with respect to 4.5.3.4 of the ISO standard that
> stablishes how the type component are initialized. Not just my expectations.
> 
> I have further developed my test case and any local variable declared in any
> function or subroutine in the scope of the module where the type is declared
> fails to properly initialize its components according to the default
> initializations (using the terminology of the standard). The intent(out) seems
> to make the difference and subroutine parameters are properly initialized.
> Any variable created outside the module declaring the type seems to properly
> initialize the components.

Putting your code in one file.

module m_test

   implicit none

   type t_test
      integer :: unit = -1
      integer :: def
      logical :: trace = .true.
      logical :: def_trace
   end type t_test

   interface test
      module procedure test_default
   end interface  

   contains
      ! INVALID.
      ! Neither def not def_trace are set.  Therefore, res is undefined.
      ! Function result is not defined on return. 
      function test_default() result(res)
         type(t_test) :: res
      end function test_default
end module m_test

program driver_test
   use m_test
   implicit none
   type(t_test) :: x

   write(6,*) 'Before constructor'
   write(6,*) '  unit      = ', x%unit
   write(6,*) '  default   = ', x%def        ! Invalid.  Undefined component.
   write(6,*) '  trace     = ', x%trace
   write(6,*) '  def trace = ', x%def_trace  ! Invalid.  Undefined component.

   x = test()   ! Invalid.

   ! All of the following can be anything as x is defined (and use defined
   ! here loosely) with an ! undefined function result.
   write(6,*) 'After constructor'
   write(6,*) '  unit      = ', x%unit
   write(6,*) '  default   = ', x%def
   write(6,*) '  trace     = ', x%trace
   write(6,*) '  def trace = ', x%def_trace

end program driver_test

> I compile with -std=2018 so I would expect that invalid Fortran is flagged, at
> least with a warning, which is not the case.

The Fortran standard likely does not require a Fortran processor
to detect the above programmer errors.

[Bug fortran/98454] Apparent wrong initialization in function result

[mscfd at gmx dot net]

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

martin <mscfd at gmx dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mscfd at gmx dot net

--- Comment #9 from martin <mscfd at gmx dot net> ---
Problems with default initialisation of function result were fixed with
PR45489. The relevant testcase added by this PR is initialization_27.f90 which
looks very similar to the reported problem (minus the non-initialised
components).

After playing around a little bit I think the reason why initialization_27.f90
does not fail in contrast to the reported case (with only unit=-1 as component
so as to get valid fortran) is that it has a pointer component. Change t_test
to something like

type :: t_test
  integer :: unit = -1
  integer, pointer :: p => null()
end type

and unit gets properly initialised. Without the pointer component I get bogus
results.

[Bug fortran/98454] Apparent wrong initialization in function result

[anlauf at gcc dot gnu.org]

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

--- Comment #10 from anlauf at gcc dot gnu.org ---
(In reply to martin from comment #9)
> Problems with default initialisation of function result were fixed with
> PR45489. The relevant testcase added by this PR is initialization_27.f90
> which looks very similar to the reported problem (minus the non-initialised
> components).

Maybe they were addressed, but not fixed.

A further reduced testcase for the present problem:

program p
  implicit none
  type t
    integer :: unit = -1
  end type t
  type(t) :: x
  x = g()
  if (x% unit /= -1) stop 2
  x = f()
  if (x% unit /= -1) stop 3
contains
  function f()
    type(t) :: f
  end function f
  function g()
    type(t) :: g
    if (g% unit /= -1) stop 1
  end function g
end

The program fails with

STOP 3

Looking into the tree-dump shows that g() is fine, f() is not.

Thanks for the pointer to PR45489, which may provide a starting point.

[Bug fortran/98454] Apparent wrong initialization in function result

[anlauf at gcc dot gnu.org]

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

--- Comment #11 from anlauf at gcc dot gnu.org ---
The following hack fixes the testcase in comment#10,
but not the testcase in comment#2:

diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 249f402b8d9..2c9570d4641 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -16046,6 +16046,9 @@ resolve_symbol (gfc_symbol *sym)
        /* Mark the result symbol to be referenced, when it has allocatable
           components.  */
        sym->result->attr.referenced = 1;
+
+      if (a->function && sym->result && sym->result->attr.referenced)
+       apply_default_init (sym);
     }

   if (sym->ts.type == BT_CLASS && sym->ns == gfc_current_ns


The logic in resolve_symbol checking for the necessity of
default initialization is hard to parse.  Could need some guidance...