This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: -Wuninitialized issues
- From: Jeffrey A Law <law at redhat dot com>
- To: Daniel Jacobowitz <drow at false dot org>
- Cc: Mark Mitchell <mark at codesourcery dot com>, gcc at gcc dot gnu dot org
- Date: Mon, 31 Oct 2005 18:37:14 -0700
- Subject: Re: -Wuninitialized issues
- References: <4365CA5E.3070401@codesourcery.com> <1130802583.19967.122.camel@localhost.localdomain> <20051031235227.GA10103@nevyn.them.org>
- Reply-to: law at redhat dot com
On Mon, 2005-10-31 at 18:52 -0500, Daniel Jacobowitz wrote:
> On Mon, Oct 31, 2005 at 04:49:43PM -0700, Jeffrey A Law wrote:
> > On Sun, 2005-10-30 at 23:40 -0800, Mark Mitchell wrote:
> > > In reviewing the PR list, I saw several (maybe 5?) PRs about problems
> > > with -Wuninitialized.
> > [ ... ]
> > After pondering this some more I almost wonder if what we need is a
> > separate warning for variables which were potentially uninitialized
> > but which optimization passes somehow proved were unused or the paths
> > in which the variable was uninitialized were unexecutable.
> >
> > So the early pass would catch unconditionally uninitialized variables;
> > it would also record (but not warn for) maybe uninitialized variables
> > (by detecting default definitions appearing in PHI nodes).
>
> > Thoughts?
>
> I think that sounds very clever...
I just cobbled up some proof of concept code... It wasn't terribly
difficult. I think the question we need to answer is whether or not
we want to distinguish between potentially uninitialized uses remaining
after optimization and those which were either optimized away or the
object was proven always initialized.
jeff