Re: "introduce no new bootstrap warning" criteria. was: Loop iv debugging, patch

["Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>]

 > From: Robert Lipe <robertlipe@usa.net> 
 > 
 > I'm not going to fuss about the commit in question.  But in recent
 > years, a LOT of effort has been spent on getting the warning level in
 > a full bootstrap down to a manageable number.  (Thanks, Kaveh!)  It's
 > easy to watch that number decay as code is added back in that isn't
 > held to the same standards of zero warnings.  Yeah, when major new
 > libraries come it I can see it taking some time for them to stabilize
 > on all combinations of builds, but we're consistently seeing defects
 > introduced into tree that gcc itself would have told us about.
 > 
 > Is it time, in the name of quality/damage control in this project, to
 > make it an acceptance criteria for any commit that it introduce no new
 > warnings?
 > 
 > RJL

Needless to say, I'm in favor of this.  However just making it a
criteria isn't enough.  Unless some automated enforcement is put in
place, it won't be adhered to IMHO.

I looked into what it would take to turn on -Werror and/or
-pedatic-errors and that doesn't seem possible.  There are too many
unfixable messages requiring a pragma silencer and also many warnings
only appear on unusual platforms so we'd have a real hard time getting
this to work without breaking bootstrap on lots of systems.  Plus any
time a new warning is added to -Wall, it would break systems until
completely silenced also.

Instead, my suggestion would be to run some kind of regression checker
like what we have for the testsuite.  Have it email whoever introduces
warnings until they fix it, just like the testsuite nag.  That way we
at least hold the line on the current warning count, and getting
closer to zero is attainable.

I don't have time to make this happen, but I suspect it wouldn't be
too hard using Geoff's current regression checker hooked up to the
contrib/warn_summary script in some fashion.  Focus on the "Number of
warning types:" but ignore line numbers or filename in case moving
code around changes where the warning comes from.

Also, you'll want to use stage3 warnings and not some prior version of
gcc on stage1 since the most recent snapshot has been tuned to emit
the warnings we care about.

That's my $.02 in case anyone wants to tackle this.

		Good luck,
		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions