public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/29199]  New: do not require -O for -Wunitialized
@ 2006-09-24  8:00 jhi at iki dot fi
  2006-09-24  8:19 ` [Bug c/29199] " steven at gcc dot gnu dot org
  0 siblings, 1 reply; 2+ messages in thread
From: jhi at iki dot fi @ 2006-09-24  8:00 UTC (permalink / raw)
  To: gcc-bugs

The man page of gcc states:

       -Wuninitialized
           Warn if an automatic variable is used without first being initial-
           ized or if a variable may be clobbered by a "setjmp" call.

           These warnings are possible only in optimizing compilation, because
           they require data flow information that is computed only when opti-
           mizing.  If you don't specify -O, you simply won't get these warn-
           ings.

This limitation, while understandable from the implementation standpoint, has a
nasty consequence:
one cannot use -Wunitialized and debug at the same time, because the -O very
efficiently destroys
information that is needed for debugging (such as being able to display local
variables).

The above triplets are for Apple's gcc 4.0.0, but that is irrelevant, the same
thing happens on every gcc
platform.  In effect, this means that one needs to do two separate compiles
while debugging a program: 
a "warnings" compile and a "debugging" compile.

Suggestion: if the -Wunitialized is specified (and no -O), do just enough data
flow analysis to perform
the analysis required for the -Wunitialized, but abstain from doing anything
that breaks debuggability.


-- 
           Summary: do not require -O for -Wunitialized
           Product: gcc
           Version: 4.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jhi at iki dot fi
 GCC build triplet: powerpc-apple-darwin8
  GCC host triplet: powerpc-apple-darwin8
GCC target triplet: powerpc-apple-darwin8


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29199


^ permalink raw reply	[flat|nested] 2+ messages in thread

* [Bug c/29199] do not require -O for -Wunitialized
  2006-09-24  8:00 [Bug c/29199] New: do not require -O for -Wunitialized jhi at iki dot fi
@ 2006-09-24  8:19 ` steven at gcc dot gnu dot org
  0 siblings, 0 replies; 2+ messages in thread
From: steven at gcc dot gnu dot org @ 2006-09-24  8:19 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #1 from steven at gcc dot gnu dot org  2006-09-24 08:19 -------
The choice to do things the way gcc does has been discussed many times over,
and the conclusion always has been that either all warnings should be done in
the front end, or dataflow analysis has to be used.  The latter is what GCC
does, and dataflow is indeed done only at -O1 and above.

Doing "enough dataflow analysis" for -Wuninitialized wouldn't work because many
of the uninitialized variables are discovered after optimization (e.g. removal
of unreachable code). So you would end up with a compiler that reports
different warnings at -O0 and -O1.  That is even worse than the current
situation.

Since this has been discussed so many times on the gcc mailing lists, the
current situation is the consensus (or rather status quo) that gcc developers
are happy with. That means this bug will not be fixed.


-- 

steven at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |WONTFIX


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29199


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2006-09-24  8:19 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-09-24  8:00 [Bug c/29199] New: do not require -O for -Wunitialized jhi at iki dot fi
2006-09-24  8:19 ` [Bug c/29199] " steven at gcc dot gnu dot org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).