| Summary: | [5/6 Regression] Spurious warning on derived type initialization | ||
|---|---|---|---|
| Product: | gcc | Reporter: | Jonathan Hogg <jhogg41> |
| Component: | fortran | Assignee: | Dominique d'Humieres <dominiq> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | burnus, janus, mikael, vehre |
| Priority: | P4 | Keywords: | wrong-code |
| Version: | 4.8.1 | ||
| Target Milestone: | 5.5 | ||
| See Also: | https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56670 | ||
| Host: | Target: | ||
| Build: | Known to work: | ||
| Known to fail: | Last reconfirmed: | 2014-03-11 00:00:00 | |
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.
The 4.7 branch is being closed, moving target milestone to 4.8.4. GCC 4.8.4 has been released. (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). The gcc-4_8-branch is being closed, re-targeting regressions to 4.9.3. GCC 4.9.3 has been released. GCC 4.9 branch is being closed Fixed by r241885. Thanks Mikael for pointing this out. Waiting one week for regressions to be reported before closing. Let see if I can come with a test for it. BTW does it make sense to back port r241885? Well, the change introduced by r241885 is quite complicated. It may cause major regressions. I don't recommend backporting it. > Well, the change introduced by r241885 is quite complicated.
> It may cause major regressions. I don't recommend backporting it.
Agreed.
> > 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. |
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?