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
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'.
Created attachment 7142 [details]
stripped of line markers
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...
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
Confirmed. This is caused by inlining:
inline int foo (int i)
if (i) return 1;
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.
aha, I've found the problem in fixup_inline_methods, which is inlined into
its only caller -- finish_struct_1.
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 :-)
Since this is only a diagnostic problem, rather than a real bug in the compiler, moving down the
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!
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.
I don't consider this a reasonable stop-gap. 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.
 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.
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 :)
Created attachment 7391 [details]
Patch which fixes the problem
* tree-ssa.c (warn_uninit): Say where the variables are declared.
(warn_uninitialized_var): Use %qD.
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.
Created attachment 7392 [details]
Lets try a patch which I really was about to build with
I am going to post this patch soon (after dinner) with an update to the testsuite.
Andrew, what happended to the patch?
The warning disappeared on mainline, see PR22456.
(In reply to comment #17)
> The warning disappeared on mainline, see PR22456.
Only in the reduced testcase as it was an empty loop.
> 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;
for (; foo(j); ++j)
No longer working on this. If someone to take my patch and update it and also update the testsuite, that is ok with me.
Leaving as P2; as stated in the audit trail, this problem has the potential to seriously confuse people.
This issue will not be resolved in GCC 4.1.0; retargeted at GCC 4.1.1.
The patch from comment #14 is not really useful as it f.i. warns for
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
Will not be fixed in 4.1.1; adjust target milestone to 4.1.2.
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.
I'm going to test the patch in Comment #25.
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.
Subject: Bug 17506
Date: Tue Aug 29 15:52:54 2006
New Revision: 116564
2006-08-29 Nathan Sidwell <firstname.lastname@example.org>
J"orn Rennecke <email@example.com>
* tree-ssa.c (warn_uninit): If warning about a location outside of
the current function, note where the variable was declared.
2006-08-29 Volker Reichelt <firstname.lastname@example.org>
Kazu Hirata <email@example.com>
* gcc.dg/pr17506.c: New.
(In reply to comment #28)
> 2006-08-29 Nathan Sidwell <firstname.lastname@example.org>
> J"orn Rennecke <email@example.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 :)
I will file tomorrow the bug reports about the cases I mentioned to the patches list.
(In reply to comment #29)
> (In reply to comment #28)
> > 2006-08-29 Nathan Sidwell <firstname.lastname@example.org>
> > J"orn Rennecke <email@example.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.
Subject: Bug 17506
Date: Wed Aug 30 18:57:54 2006
New Revision: 116593
Fixed attribution for patch for PR tree-optimization/17506
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.
*** Bug 31181 has been marked as a duplicate of this bug. ***
If there are not going to be more releases of GCC 4.0 or 4.1, I guess we can close this, no?
Fixed since 4.2.0, wontfix for older branches.