Bug 31688 - Bogus "may be used uninitialized" warning
Summary: Bogus "may be used uninitialized" warning
Status: RESOLVED DUPLICATE of bug 29459
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.3.0
: P3 normal
Target Milestone: ---
Assignee: Francois-Xavier Coudert
URL:
Keywords: diagnostic
: 31683 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-04-24 19:56 UTC by Tobias Burnus
Modified: 2007-07-04 07:43 UTC (History)
14 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2007-07-03 10:37:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Burnus 2007-04-24 19:56:49 UTC
[Based on PR 31683]
Compiling the following program with "gfortran -O -Wall" gives the bogus warning:

foo2.f90:4: warning: 'offset.7' may be used uninitialized in this function
foo2.f90:4: warning: 'stride.6' may be used uninitialized in this function
foo2.f90:4: warning: 'pab.0' may be used uninitialized in this function

However, this part of code is not reachable if uninitialized.

The code is essentially:

int offset.7;
if(pab != 0B)
    offset.7 = -stride.6;
if (pab == 0B) return;
*force_a = (*pab.0)[offset.7]

Full Fortran source:

MODULE test
  IMPLICIT NONE
CONTAINS
  SUBROUTINE overlap(s, lds, pab, force_a)
    INTEGER, INTENT(IN)                         :: lds
    REAL, DIMENSION(lds, lds, *), INTENT(INOUT) :: s
    REAL, DIMENSION(:), INTENT(IN), OPTIONAL    :: pab
    REAL, INTENT(OUT)                           :: force_a

    if(.not.present(pab)) return
    force_a = pab(1)*s(1,1,1)
  END SUBROUTINE
END MODULE test
Comment 1 Andrew Pinski 2007-04-24 20:05:45 UTC
This is really the oldest uninitialized variable warning bug out there.  PR 5035.

*** This bug has been marked as a duplicate of 5035 ***
Comment 2 Joost VandeVondele 2007-06-20 15:20:00 UTC
*** Bug 31683 has been marked as a duplicate of this bug. ***
Comment 3 Joost VandeVondele 2007-06-20 15:25:52 UTC
Tobias, could you reopen this bug (I can't). This is different from PR 5035. Whereas PR 5035 warns about variables present in the users code, these warnings come from frontend generated variables (i.e. offset.7 is nowhere present in the users code). These warnings are thus needlessly confusing and supposedly can be easily supressed by giving them proper attributes in the fronted.
Comment 4 Tobias Burnus 2007-06-20 16:25:24 UTC
> Tobias, could you reopen this bug (I can't). This is different from PR 5035.
> Whereas PR 5035 warns about variables present in the users code, these warnings
> come from frontend generated variables
Well, for the middle end it is all the same.

> These warnings are thus needlessly confusing and supposedly can be
> easily supressed by giving them proper attributes in the fronted.
I don't know how one should properly handle these in the front end (without unneeded initialization of variables), but I reopened the bug and moved it to the Fortran front end.
Comment 5 Francois-Xavier Coudert 2007-07-03 10:36:33 UTC
(In reply to comment #4)
> I don't know how one should properly handle these in the front end (without
> unneeded initialization of variables), but I reopened the bug and moved it to
> the Fortran front end.

They need to be marked with TREE_NO_WARNING. I did that once, but never came close to submitting the patch. I'll take care of this.
Comment 6 Francois-Xavier Coudert 2007-07-04 07:43:59 UTC

*** This bug has been marked as a duplicate of 29459 ***