Bug 17506

Summary: [4.0/4.1 Regression] warning about uninitialized variable points to wrong location
Product: gcc Reporter: Nathan Sidwell <nathan>
Component: tree-optimizationAssignee: Not yet assigned to anyone <unassigned>
Status: RESOLVED FIXED    
Severity: minor CC: ahs3, amylaar, fang, gcc-bugs, james, manu, P.Schaffnit, reichelt
Priority: P2 Keywords: diagnostic, monitored
Version: 4.0.0   
Target Milestone: 4.2.0   
Host: Target:
Build: Known to work: 3.4.2 4.2.0
Known to fail: 4.0.0 4.1.3 Last reconfirmed: 2006-02-01 04:44:45
Bug Depends on:    
Bug Blocks: 24639    
Attachments: stripped of line markers
Patch which fixes the problem
new patch
This patch checks if the warning location is within cfun.

Description Nathan Sidwell 2004-09-15 18:38:11 UTC
In patching cp/class.c I get the following error out of a bootstrap,

../../gcc/gcc/cp/class.c: In function `finish_struct_1':
../../gcc/gcc/tree.h:80: warning: 'ix' is used uninitialized in this function

*) tree.h:80 is a static inline function, which is called from finish_struct_1
*) finish_struct_1 nor that inline function have a variable called 'ix' (that I
can see).

I've attached a preprocessed source with all the #lines removed, and the
expansion of tree.h:80 split onto several lines for easy location. It has the
same problems, reporting

nathan@garibaldi:390>./cc1 -quiet -fdump-tree-all -Wall -W  -g -O2 unused.i
unused.i: In function `finish_struct_1':
unused.i:4262: warning: 'ix' is used uninitialized in this function

line 4262 is '  if (vec_ && ix_ < vec_->num)' -- a distinct lack of 'ix'.
Comment 1 Nathan Sidwell 2004-09-15 18:41:29 UTC
Created attachment 7142 [details]
stripped of line markers
Comment 2 Wolfgang Bangerth 2004-09-15 20:25:58 UTC
Confirmed. BTW, the problem is in function finish_struct_1, but the 
line 4262 to which the compiler warning refers is in a static inline 
function VEC_tree_iterate. That function doesn't have a variable "ix", 
though it has one named "ix_" -- which is probably sheer coincidence... 
 
W. 
Comment 3 Wolfgang Bangerth 2004-09-15 20:27:32 UTC
Oh, and if I only use flags "-O -Wall" instead of "-O2 -W -Wall -g", then 
the message is still there (and at the same line) but it is noted for line 
fixup_inline_methods. 
 
W. 
Comment 4 Volker Reichelt 2004-09-15 20:28:53 UTC
Confirmed. This is caused by inlining:

===================================
inline int foo (int i)
{
    if (i) return 1;
    return 0;
}

void bar()
{
    int j;
    for (; foo(j); ++j) ;
}
===================================

Compiling this with "-O1 -Wall" yields:

PR17506.c: In function `bar':
PR17506.c:3: warning: 'j' is used uninitialized in this function


Btw, Nathan, please compress files that large before attaching them to a PR.
Comment 5 Nathan Sidwell 2004-09-15 20:42:21 UTC
aha, I've found the problem in fixup_inline_methods, which is inlined into
its only caller -- finish_struct_1.
Comment 6 Wolfgang Bangerth 2004-09-15 20:52:25 UTC
And indeed in fixup_inline_methods, you use "ix" uninitialized. I'm 
surprised how quickly Volker reduced this -- I'm not even halfway there 
(though I filed another PR in the meantime :-) 
 
W. 
Comment 7 Andrew Pinski 2004-09-15 21:37:26 UTC
Since this is only a diagnostic problem, rather than a real bug in the compiler, moving down the 
severity.
Comment 8 Wolfgang Bangerth 2004-09-15 22:17:32 UTC
I consider this important. Nathan has (involuntarily) shown that 
it can be very hard to find the place where the problem really 
is. This is a serious regression! 
 
W. 
Comment 9 Nathan Sidwell 2004-09-16 06:52:48 UTC
It's a pretty severe diagnostic problem, as the location information given
is very nearly useless.  However, I've figured a workaround, which is
'-O2 -W -Wall -fno-inline'.  We should mention that in release notes, if this
bug does not get fixed.
Comment 10 Wolfgang Bangerth 2004-09-16 12:49:18 UTC
I don't consider this a reasonable stop-gap[1]. And I wouldn't see why, 
in the presence of a small testcase at the beginning of stage 3 we 
shouldn't be able to fix this properly. 
 
W. 
 
[1] Nobody reads the release nodes (as shown with many PRs about not 
being able to access elements of template base class), and we're bound 
to get lots of bug reports that will be hard to reduce because the 
compiler doesn't say where a problem happens. 
Comment 11 Nathan Sidwell 2004-09-16 14:33:23 UTC
No, I don't consider it a reasonable stopgap either :)  Just thought I'd mention
it, if you find yourself in the same position. BTW, if you replace 'inline' with
'static' in the reduced testcase of #4, you'll get the same problem (which is
what happens in class.c).  This is extremely confusing, because there are no
inline keywords anywhere :)
Comment 12 Andrew Pinski 2004-10-21 04:05:50 UTC
Created attachment 7391 [details]
Patch which fixes the problem

ChangeLog:
* tree-ssa.c (warn_uninit): Say where the variables are declared.
(warn_uninitialized_var): Use %qD.
(warn_uninitialized_phi): Likewise.
Comment 13 Andrew Pinski 2004-10-21 04:09:10 UTC
I will post this patch after you say if the message is a good idea or not.
I messed up on the patch though, it should be inform instead of "note".  I changed it from warning as it 
should not be warning.
Comment 14 Andrew Pinski 2004-10-21 04:14:32 UTC
Created attachment 7392 [details]
new patch

Lets try a patch which I really was about to build with
Comment 15 Andrew Pinski 2004-11-25 20:56:51 UTC
I am going to post this patch soon (after dinner) with an update to the testsuite.
Comment 16 Volker Reichelt 2005-01-20 23:52:12 UTC
Andrew, what happended to the patch?
Comment 17 Volker Reichelt 2005-07-13 11:41:38 UTC
The warning disappeared on mainline, see PR22456.
Comment 18 Andrew Pinski 2005-07-13 11:48:01 UTC
(In reply to comment #17)
> The warning disappeared on mainline, see PR22456.
Only in the reduced testcase as it was an empty loop.
Comment 19 Volker Reichelt 2005-07-13 12:05:55 UTC
> Only in the reduced testcase as it was an empty loop.

Right. Here's a new testcase that still triggers the bug on mainline:

============================
inline int foo (int i)
{
    if (i) return 1;
    return 0;
}

void baz();

void bar()
{
    int j;
    for (; foo(j); ++j)
        baz();
}
============================
Comment 20 Andrew Pinski 2005-10-23 00:02:42 UTC
No longer working on this.  If someone to take my patch and update it and also update the testsuite, that is ok with me.
Comment 21 Mark Mitchell 2005-10-30 22:53:14 UTC
Leaving as P2; as stated in the audit trail, this problem has the potential to seriously confuse people.
Comment 22 Mark Mitchell 2006-02-24 00:25:14 UTC
This issue will not be resolved in GCC 4.1.0; retargeted at GCC 4.1.1.
Comment 23 Richard Biener 2006-05-12 13:42:08 UTC
The patch from comment #14 is not really useful as it f.i. warns for

int sink;
void bar()
{
    int j;
    sink = j;
}

t.c: In function 'bar':
t.c:5: warning: 'j' is used uninitialized in this function
t.c:4: note: 'j' was declared here
Comment 24 Mark Mitchell 2006-05-25 02:32:00 UTC
Will not be fixed in 4.1.1; adjust target milestone to 4.1.2.
Comment 25 Jorn Wolfgang Rennecke 2006-08-24 20:04:37 UTC
Created attachment 12131 [details]
This patch checks if the warning location is within cfun.

I probably won't find CPU cycles to test this properly in the near future.
Comment 26 Kazu Hirata 2006-08-25 20:41:56 UTC
I'm going to test the patch in Comment #25.
Comment 27 Kazu Hirata 2006-08-28 17:28:29 UTC
The real fix it to issue "uninitialized warnings" before the inliner kicks in
but after we go into SSA, which is impossible until we start doing early SSA.

As Nathan suggests, this caveat should be mentioned in the release notes.
Comment 28 Jorn Wolfgang Rennecke 2006-08-29 15:53:07 UTC
Subject: Bug 17506

Author: amylaar
Date: Tue Aug 29 15:52:54 2006
New Revision: 116564

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116564
Log:
gcc:

2006-08-29  Nathan Sidwell  <nathan@codesourcery.com>
	    J"orn Rennecke  <joern.rennecke@st.com>

	PR tree-optimization/17506
	* tree-ssa.c (warn_uninit): If warning about a location outside of
	the current function, note where the variable was declared.

testsuite:

2006-08-29  Volker Reichelt  <reichelt@igpm.rwth-aachen.de>
	    Kazu Hirata  <kazu@codesourcery.com>

	PR tree-optimization/17506
	* gcc.dg/pr17506.c: New.

Added:
    trunk/gcc/testsuite/gcc.dg/pr17506.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-ssa.c

Comment 29 Nathan Sidwell 2006-08-29 17:20:25 UTC
(In reply to comment #28)

> 2006-08-29  Nathan Sidwell  <nathan@codesourcery.com>
>             J"orn Rennecke  <joern.rennecke@st.com>
> 
>         PR tree-optimization/17506
>         * tree-ssa.c (warn_uninit): If warning about a location outside of
>         the current function, note where the variable was declared.

I have no recollection of writing any patch about this (and have no objection to being removed from the credits :)
Comment 30 Andrew Pinski 2006-08-30 03:33:36 UTC
I will file tomorrow the bug reports about the cases I mentioned to the patches list.
Comment 31 Jorn Wolfgang Rennecke 2006-08-30 18:47:25 UTC
(In reply to comment #29)
> (In reply to comment #28)
> 
> > 2006-08-29  Nathan Sidwell  <nathan@codesourcery.com>
> >             J"orn Rennecke  <joern.rennecke@st.com>
> > 
> >         PR tree-optimization/17506
> >         * tree-ssa.c (warn_uninit): If warning about a location outside of
> >         the current function, note where the variable was declared.
> 
> I have no recollection of writing any patch about this (and have no objection
> to being removed from the credits :)
> 

Oops, I mixed up comments #11 and #12.
Comment 32 Jorn Wolfgang Rennecke 2006-08-30 18:58:03 UTC
Subject: Bug 17506

Author: amylaar
Date: Wed Aug 30 18:57:54 2006
New Revision: 116593

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116593
Log:
Fixed attribution for patch for PR tree-optimization/17506

Modified:
    trunk/gcc/ChangeLog

Comment 33 Richard Biener 2006-10-18 09:27:19 UTC
A backport bootstraps and regtests ok on the 4.1 branch.  Don't know if the side-effects of this patch makes it appplicable for backporting though.
Comment 34 Andrew Pinski 2007-04-03 06:19:45 UTC
*** Bug 31181 has been marked as a duplicate of this bug. ***
Comment 35 Manuel López-Ibáñez 2007-08-15 15:23:20 UTC
If there are not going to be more releases of GCC 4.0 or 4.1, I guess we can close this, no?
Comment 36 Richard Biener 2008-02-20 22:34:00 UTC
Fixed since 4.2.0, wontfix for older branches.