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 |
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 |
Description
Jonathan Hogg
2014-03-11 10:56:19 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. 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. |