[Bug fortran/96047] New: Bogus unitialized warning for derived type with allocatable components

[Bug fortran/96047] New: Bogus unitialized warning for derived type with allocatable components

[jellby at yahoo dot com]

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

            Bug ID: 96047
           Summary: Bogus unitialized warning for derived type with
                    allocatable components
           Product: gcc
           Version: 10.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jellby at yahoo dot com
  Target Milestone: ---

The program below gives a bogus warning when compiling with -O0, but not with
-O1 or higher:

$ gfortran a.f90 -Wall -O0
a.f90:9:0:

 call new(a,3)

Warning: ‘a.dim[0].ubound’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
a.f90:9:0: Warning: ‘a.dim[0].lbound’ may be used uninitialized in this
function [-Wmaybe-uninitialized]

The warning goes away if the "allocate(a(0))" line is uncommented, but that
should not be necessary, because the argument is "intent(out)", so it it must
be allocated in the subroutine.

$ cat a.f90
program test
implicit none
type foo
  real, allocatable :: c(:)
end type foo
type(foo), allocatable :: a(:)

!allocate(a(0))
call new(a,3)

contains

subroutine new(m,n)
type(foo), allocatable, intent(out) :: m(:)
integer, intent(in) :: n
integer :: i
allocate(m(n))
do i=1,n
  allocate(m(i)%c(n))
end do
end subroutine new

end program

[Bug fortran/96047] Bogus unitialized warning for derived type with allocatable components

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic,
                   |                            |missed-optimization

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
The FE emits

  <bb 2> :
  FRAME.16.FRAME_BASE.PARENT = 0B;
  a.data = 0B;
  _1 = a.data;
  if (_1 != 0B)
    goto <bb 3>; [INV]
  else
    goto <bb 9>; [INV]

  <bb 3> :
  _2 = a.dim[0].ubound;
  _3 = a.dim[0].lbound;
  _4 = _2 - _3;
  _20 = _4 + 1;
  _21 = _20;
  _22 = _21 + -1;
  S.8_23 = 0;

  <bb 4> :
  # S.8_12 = PHI <S.8_23(3), S.8_26(7)>
  if (S.8_12 > _22)
    goto <bb 8>; [INV]
  else
    goto <bb 5>; [INV]

where you see the loads from a.dim[0].{u,l}bound are uninitialized if
bb3 is entered.  With optimization turned on we only do the "maybe"
warning late which is after loads of optimization (everything inlined
into main()) that elided the loads.  Even w/o inlining test () is optimized
to just

test ()
{
  struct array01_foo a;

  <bb 2> [local count: 1073741824]:
  a.data = 0B;
  new (&a, &C.3979);
  a ={v} {CLOBBER};
  return;

maybe the FE can be a little bit smarter emitting

  <bb 2> :
  a.data = 0B;
  _1 = a.data;
  if (_1 != 0B)

?

[Bug fortran/96047] Bogus unitialized warning for derived type with allocatable components

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
At some compile-time cost we could also evaluate (but not actually optimize)
branches when not optimizing.

[Bug fortran/96047] Bogus unitialized warning for derived type with allocatable components

[dominiq at lps dot ens.fr]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2020-07-08
             Status|UNCONFIRMED                 |WAITING

--- Comment #3 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> At some compile-time cost we could also evaluate (but not actually optimize)
> branches when not optimizing.

Wouldn't be simpler to disable -Wmaybe-uninitialized at -O0?