This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: "introduce no new bootstrap warning" criteria. was: Loop iv debugging, patch
- To: geoffk at redhat dot com
- Subject: Re: "introduce no new bootstrap warning" criteria. was: Loop iv debugging, patch
- From: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>
- Date: Sat, 13 Jan 2001 07:49:30 -0500 (EST)
- Cc: aj at suse dot de, dewar at gnat dot com, dkorn at pixelpower dot com, gcc at gcc dot gnu dot org, jsm28 at cam dot ac dot uk, robertlipe at usa dot net
> From: Geoff Keating <geoffk@geoffk.org>
>
> There's a big gotcha here: the regression tester uses gcc 2.95.2 as
> the host compiler. Thus, it gets quite a number of spurious
> warnings due to bugs in 2.95.2.
So we'd have to run a separate build for the warning regression
checker and use a relatively recent CVS gcc to generate the warnings.
> It's also not reproducible,
> because the warnings you get on sparc-solaris are not the same set
> as the warnings you get on x86-linux or even sparc-linux. This is
> likely to be a fatal problem for any such tool.
I think what you mean here is that once the checker finds a
regression, the person who caused it may not be able to reproduce it
on their host platforms. That's quite possible, but having the
checker is better then not having it. I think if we run the checker
native on x86-linux-gnu, we start with a common enough platform that
most developers have access to. If someone working elsewhere
introduces a warning only seen on x86-linux-gnu, they may still be
able to fix it because most warnings are obvious by inspection. Still
we'll have to work out how to fix it some other way via a volunteer if
the original culprit can't do so. I don't think this is fatal.
> IMO, it would be better to switch off -Wall, switch on -Werror, and
> switch on individual warning flags until something breaks.
> - Geoffrey Keating <geoffk@geoffk.org>
I'm not sure if you mean to do this for all bootstraps or just the
warning checker host.
If done for everyone, you'd still run into the problems I outlined in
my previous message about unfixable warnings. If done only for the
checker system, unless you fix every remaining warning you'd have so
few -W* flags turned on that the inactive ones (e.g. -Wsign-compare)
will regress very quickly since no one sees them any more.
IMHO, we could get a regression checker up relatively quickly, but
getting -Werror working is far away. I'm willing to be proven false
by a working example though. :-)
--Kaveh
--
Kaveh R. Ghazi Engagement Manager / Project Services
ghazi@caip.rutgers.edu Qwest Internet Solutions