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: ghazi at caip dot rutgers dot edu
- Subject: Re: "introduce no new bootstrap warning" criteria. was: Loop iv debugging, patch
- From: Geoff Keating <geoffk at geoffk dot org>
- Date: Fri, 12 Jan 2001 14:29:42 -0800
- CC: robertlipe at usa dot net, 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
- References: <200101121607.LAA11204@caip.rutgers.edu>
- Reply-to: Geoff Keating <geoffk at redhat dot com>
> Date: Fri, 12 Jan 2001 11:07:39 -0500 (EST)
> From: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>
> 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.
Why do we have unfixable warnings in -Wall? They're not supposed to
be there.
> 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.
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. 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.
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>