[Bug fortran/86330] New: False positive warnings about uninitialized offset/lbound/ubound when allocating on assignment

[tomastrnka at gmx dot com]

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

Bug ID: 86330
   Summary: False positive warnings about uninitialized
offset/lbound/ubound when allocating on assignment
   Product: gcc
   Version: 8.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tomastrnka at gmx dot com
  Target Milestone: ---

The following testcase generates false positive warnings because "x" is
unallocated before assignment:

program realloc_uninitialized
   implicit none

   integer, allocatable :: x(:)

!allocate(x(0))
!deallocate(x)
   x = foo()

   write(*,*) x

contains
   function foo() result(a)
  integer, allocatable :: a(:)

  allocate(a(5))
  a = 0
   end function
end program

$ gfortran -fdump-tree-original -Wall -O3 -fno-inline -o realloc_uninitialized
realloc_uninitialized.f90
realloc_uninitialized.f90:8:0:

x = foo()

Warning: ‘x.offset’ is used uninitialized in this function [-Wuninitialized]
realloc_uninitialized.f90:8:0: Warning: ‘x.dim[0].lbound’ is used uninitialized
in this function [-Wuninitialized]
realloc_uninitialized.f90:8:0: Warning: ‘x.dim[0].ubound’ is used uninitialized
in this function [-Wuninitialized]

Uncommenting the allocate/deallocate makes the warning go away.
I'm using gcc version 8.1.1 20180502 (Red Hat 8.1.1-1) (GCC) (stock Fedora 28
compiler), but I have also seen this previously on GCC 7. My self-compiled gcc
version 6.4.1 20180314 (GCC) doesn't trigger the warning.

I guess this is because of the following references to "x" at the very start of
"realloc_uninitialized ()" in "realloc_uninitialized.f90.003t.original":
D.3797 = (integer(kind=4)[0:] * restrict) x.data;
D.3798 = x.offset;
D.3799 = x.dim[0].lbound;
D.3800 = x.dim[0].ubound;
None of these D.*s is subsequently used.

[Bug fortran/86330] False positive warnings about uninitialized offset/lbound/ubound when allocating on assignment

[tomastrnka at gmx dot com]

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

--- Comment #1 from Tomáš Trnka  ---
Looks like a duplicate of bug 85855.

[Bug fortran/87937] New: [8/9 Regression] LHS reallocation broken inside "select type"

[tomastrnka at gmx dot com]

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

Bug ID: 87937
   Summary: [8/9 Regression] LHS reallocation broken inside
"select type"
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tomastrnka at gmx dot com
  Target Milestone: ---

The fix for pr85954 broke LHS reallocation inside "select type" blocks. The
following program segfaults with current 8.2 branch (including the system
compiler 8.2.1 20181011 on my Fedora 29):

program lhsalloc
   type, abstract :: A
  real, allocatable :: x(:)
   end type

   type, extends(A) :: B
   end type

   class(A), allocatable :: t
   real :: y(4)

   y = 1

   allocate(B::t)

   select type (t)
   type is (B)
  t%x = y
   end select

   write(*,*) allocated(t%x)
end program

The code to allocate t%x is simply never generated.

Partially reverting the offending change by removing these two lines from
gfc_is_reallocatable_lhs fixes the issue:

if (sym->attr.associate_var)
  return false;

Although pr87625 sounds related, its fix doesn't help here because the
associate_var check comes earlier.

[Bug fortran/87937] [8/9 Regression] LHS reallocation broken inside "select type"

[tomastrnka at gmx dot com]

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

--- Comment #2 from Tomáš Trnka  ---
(In reply to Dominique d'Humieres from comment #1)
> > The code to allocate t%x is simply never generated.
> 
> How do you see that?
> 
> WORKSFORME on darwin.

Weird, I wouldn't expect the frontend to behave in a platform-specific way.
What version are you using to test? (8.2.0 is not affected. I haven't actually
tried it with 9, but AFAICS the code is the same.)

Running "gfortran -fdump-tree-original lhsalloc.f90" with and without the
associate_var check produces the two attached files, with the allocation
obviously missing from the bad one.

[Bug fortran/87937] [8/9 Regression] LHS reallocation broken inside "select type"

[tomastrnka at gmx dot com]

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

--- Comment #3 from Tomáš Trnka  ---
Created attachment 44972
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44972&action=edit
Original tree dump from 8.2.1 20181011

[Bug fortran/87937] [8/9 Regression] LHS reallocation broken inside "select type"

[tomastrnka at gmx dot com]

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

--- Comment #4 from Tomáš Trnka  ---
Created attachment 44973
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44973&action=edit
Original tree dump after removing the offending check