This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Warning policy?


 > From: Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at>
 >  
 > On Sun, 20 Dec 1998, Chip Salzenberg wrote:
 > > I'm bootstrapping EGCS under Linux, and the EGCS sources are
 > > generating a lot of warnings because the configuration default is to
 > > use "gcc -Wall".
 >  
 > Indeed this is the default only for the CVS and snapshot versions, not
 > for releases, as not to confuse ``users''.
 >  
 > > Are the warnings fair game for patches, or is it a configuration error
 > > to use "gcc -Wall" when compiling EGCS?
 >  
 > It is intended to find (and fix) problems. I believe that Kaveh Ghazi
 > <ghazi@caip.rutgers.edu> has been continually working to reduce the 
 > number of warnings, so you might want to coordinate with him.
 >  
 > Gerald

	
	Yup, I'm working on it.  If you are interested, try using
the egcs/contrib/warn_summary script to categorize the warnings.
It has various flags to help you do this.

	The current breakdown looks like this.  (Your mileage may vary
depending on platform and BOOT_CFLAGS.)

Directory	Warnings
---------	--------
gcc topdir	362
Chill		12
C++		7
F77		2
Java		315

	It should be possible to get the java directory warnings down to
the level of the other language subdirs.  The folks doing development
have actually fixed many of these themselves over time.  I'm working on
zapping the last few hundred real soon now. 

	Those remaining in the gcc top level directory are either annoying
to fix, are caused by bugs in the compiler or are warnings about *possible*
problems which gcc can't say for sure.  Here is the approximate breakdown
of the warnings from the top level gcc directory:

Number of warning types:
 121 `???' might be used uninitialized in this function
  81 label `???' defined but not used
  64 missing initializer for `???'
  46 unused parameter `???'
  20 comparison between signed and unsigned
  14 unused variable `???'
  10 variable `???' might be clobbered by `longjmp' or `vfork'
   5 argument `???' might be clobbered by `longjmp' or `vfork'
   1 `???' defined but not used


	Most of the "uninitialized" and "might be clobbered" warnings
are either detection bugs or in the "gcc can't tell for sure" category
so it warns anyway to be safe (but annoying.) I think Jeff said the
buggy ones are due to problems in gcse.c meddling with the flow.  (?)
In the mean time, we are avoiding giving default initializations so that
if someone ever tries to fix this they have something to test against. 
I don't think its being worked on though.  There are some of these
that gcc is documented as being unable to detect properly which are
okay to zap by initialization.  But it requires meticulous code reading
to differentiate these.  Not fun. :-)

	The "label `???' defined but not used" warnings mostly appear in
insn-recog.c.  In this case genrecog.c needs to be fixed.  It may be
non-trivial to deduce which labels are unnecessary, I haven't looked. 
Another approach might be to get the compiler to allow attribute
__unused__ on a label and just mark all of them unused in the generated
insn-recog.c file.

	The "missing initializer" warnings come from toplev.c and are
due to the config/ dir files not containing description strings in the
TARGET_SWITCHES and/or TARGET_OPTIONS macros.  This one is easy to fix
but may take a while and has to be done individually for every target.

	I think the rest are ordinary and just need someone to apply a
fix.  Contributions on any of these (preferably the hard ones :-) )
are welcome.

		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Icon CMT Corp.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]