Bug 60500 - [5/6 Regression] Spurious warning on derived type initialization
Summary: [5/6 Regression] Spurious warning on derived type initialization
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.8.1
: P4 normal
Target Milestone: 5.5
Assignee: Dominique d'Humieres
URL:
Keywords: wrong-code
Depends on:
Blocks:
 
Reported: 2014-03-11 10:56 UTC by Jonathan Hogg
Modified: 2017-09-16 09:48 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2014-03-11 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jonathan Hogg 2014-03-11 10:56:19 UTC
The following code:

module spurious_warning
   implicit none
   
   type :: ntype
      integer :: level = 1
   end type ntype
contains
   subroutine sub1(n1, n2, st)
      integer, intent(in) :: n1, n2
      integer, intent(out) :: st

      type(ntype), dimension(:), allocatable :: work1
      integer, dimension(:), allocatable :: work2

      allocate(work1(n1), stat=st)
      if(st.ne.0) return

      allocate(work2(n2), stat=st)
      if(st.ne.0) return
   end subroutine sub1
end module spurious_warning

Produces the following spurious warning:
[user@host]$ gfortran-4.8 -O2 -Wall -c bug.f90
bug.f90: In function ‘sub1’:
bug.f90:12:0: warning: ‘work1.dim[0].ubound’ may be used uninitialized in this function [-Wmaybe-uninitialized]
       type(ntype), dimension(:), allocatable :: work1
 ^

With the following compiler version:
GNU Fortran (Ubuntu 4.8.1-2ubuntu1~12.04) 4.8.1

Notes:
Removal of -O2 removes the sprurious warning.
Removal of the second allocation removes spurious warning.
Removal of default value in type definition removes spurious warning.

Working theory: The automatic initialization accesses array size as part of implementation?
Comment 1 Dominique d'Humieres 2014-03-11 11:14:48 UTC
No warning when compiling the test with r176695 (2011-07-23), warning with r176935 (2011-07-29).
Comment 2 Richard Biener 2014-03-31 09:39:08 UTC
The value is used uninitialized on the work1.data == NULL error path:

                  work1.data = (void * restrict) __builtin_malloc (MAX_EXPR <D.2352, 1>);
                  if (work1.data == 0B)
                    {
                      stat.0 = 5014;
                    }
                }
              }
          }
        if ((logical(kind=4)) __builtin_expect ((integer(kind=8)) (stat.0 == 0), 1, 33))
          {
            work1.dtype = 297;
            work1.dim[0].lbound = 1;
            work1.dim[0].ubound = (integer(kind=8)) *n1;
            work1.dim[0].stride = 1;
            work1.offset = -1;
          }
        if ((logical(kind=4)) __builtin_expect ((integer(kind=8)) (stat.0 != 0), 0, 33)) goto L.1;
        L.1:;
        *st = stat.0;
        {
          struct ntype D.2358;
          struct ntype ntype.3;
          integer(kind=8) D.2356;
          integer(kind=8) D.2355;
          integer(kind=8) D.2354;
          struct ntype[0:] * restrict D.2353;

          D.2353 = (struct ntype[0:] * restrict) work1.data;
          D.2354 = work1.offset;
          D.2355 = work1.dim[0].lbound;
          D.2356 = work1.dim[0].ubound;
          ntype.3.level = 1;
          D.2358 = ntype.3;
          {
            integer(kind=8) S.4;

            S.4 = D.2355;
            while (1)
              {
                if (S.4 > D.2356) goto L.3;
                (*D.2353)[S.4 + D.2354] = D.2358;
                S.4 = S.4 + 1;
              }
            L.3:;

possibly the L.1 label is misplaced?  At least the result would crash if
malloc returned NULL.

Frontend wrong-code bug.
Comment 3 Richard Biener 2014-06-12 13:41:20 UTC
The 4.7 branch is being closed, moving target milestone to 4.8.4.
Comment 4 Jakub Jelinek 2014-12-19 13:24:16 UTC
GCC 4.8.4 has been released.
Comment 5 Mikael Morin 2015-03-16 12:10:30 UTC
(In reply to Richard Biener from comment #2)
> possibly the L.1 label is misplaced?  At least the result would crash if
> malloc returned NULL.
> 
Mmh, yes;  it seems L.1 should come after the (default-)initialization of the just allocated array.
There is nothing that can be done inside gfc_trans_allocate, because initialization comes from a frontend-generated statement after the allocate statement (introduced at revision r164305).
Comment 6 Richard Biener 2015-06-23 08:13:12 UTC
The gcc-4_8-branch is being closed, re-targeting regressions to 4.9.3.
Comment 7 Jakub Jelinek 2015-06-26 19:51:35 UTC
GCC 4.9.3 has been released.
Comment 8 Richard Biener 2016-08-03 11:34:55 UTC
GCC 4.9 branch is being closed
Comment 9 vehre 2016-11-08 12:54:45 UTC
Fixed by r241885. Thanks Mikael for pointing this out.

Waiting one week for regressions to be reported before closing.
Comment 10 Dominique d'Humieres 2016-11-08 13:52:50 UTC
Let see if I can come with a test for it.
Comment 11 Dominique d'Humieres 2016-11-08 13:54:39 UTC
BTW does it make sense to back port r241885?
Comment 12 vehre 2016-11-09 17:12:51 UTC
Well, the change introduced by r241885 is quite complicated. It may cause major regressions. I don't recommend backporting it.
Comment 13 Dominique d'Humieres 2016-11-09 17:16:25 UTC
> Well, the change introduced by r241885 is quite complicated.
> It may cause major regressions. I don't recommend backporting it.

Agreed.
Comment 14 Dominique d'Humieres 2017-09-16 09:48:14 UTC
> > Well, the change introduced by r241885 is quite complicated.
> > It may cause major regressions. I don't recommend backporting it.
>
> Agreed.

So closing as FIXED.