This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Uninitialized warnings
- To: Stan Shebs <shebs at apple dot com>
- Subject: Re: Uninitialized warnings
- From: Diego Novillo <dnovillo at redhat dot com>
- Date: Wed, 18 Jul 2001 09:40:03 -0400
- Cc: Carlo Wood <carlo at alinoe dot com>, Dale Johannesen <dalej at apple dot com>, Kevin Atkinson <kevina at users dot sourceforge dot net>, Joern Rennecke <amylaar at redhat dot com>, Joe Buck <jbuck at synopsys dot COM>, gcc at gcc dot gnu dot org
- Organization: Red Hat Canada
- References: <20010718003301.A4121@alinoe.com> <200107181324.f6IDNxw14897@scv2.apple.com>
On Tue, 17 Jul 2001, Stan Shebs wrote:
> On Tuesday, July 17, 2001, at 03:33 PM, Carlo Wood wrote:
>
> > On Tue, Jul 17, 2001 at 09:51:06AM -0700, Dale Johannesen wrote:
> >> we're the first people to think of this, which gives me pause. Is a
> >> patch that checks for uninitalized variables even without optimization
> >> likely to be accepted?
> >
> > Please don't add any warning that can generate false positives.
> > I'd rather have no warning at all for 100 actual bugs than
> > 100 correct warnings and a false positive. [...]
>
> I think there's some confusion here. What Dale is getting at
> is that -Wuninitialized is basically useless without -O<something>,
> so why not make -Wuninitialized turn on enough dataflow analysis
> to be meaningful, but without letting it alter the output? In other
> words, fix -Wuninitialized, even it means making the compiler run
> a little more slowly when the flag is on.
>
FWIW, this should be relatively straightforward to implement once
the tree SSA infrastructure is incorporated. The current
version is already doing reachability analysis for
-Wunreachable-code using the flowgraph.
Checking for potentially uninitialized variables is just a matter
of traversing the use-def web. It might take a while until the
code is stable enough to be of any real use, of course.
Diego.