This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: illegally shared subreg
> From: Stan Shebs <shebs@apple.com>
>
> Geoff Keating wrote:
>
> >>PS: I wish the regression checker would notice warning regressions to
> >>catch things like this. I.e. things that don't cause a bootstrap or
> >>testsuite failure, but which are clearly bugs. We've discussed
> >>strategies for implementing this without too much trouble in the past,
> >>I hope this example will encourage you to see that it's worthwhile. :-)
> >>
> >
> >Yes. I'd really rather notice this sort of thing before it gets to
> >the regression tester, though, ideally with a build failure; there are
> >no circumstances under which 'assignment makes integer from pointer'
> >is an OK warning while bootstrapping GCC, and notice that both Stuart
> >and I both bootstrapped with this patch and didn't notice the warning.
> >
> Thus the oft-expressed wish to have -Werror in the 2nd and 3rd stages...
>
> How close are we anyway? Warnings in the mainline bootstrap seem
> to be few and far between these days, in fact I can't remember the
> last time I saw one.
> Stan
On some platforms, we're in the 20-30 range. Look at the bottom of
these testsuite reports, they include warnings results:
i686-pc-linux-gnu: 19 http://gcc.gnu.org/ml/gcc-testresults/2002-10/msg00326.html
i686-pc-cygwin: 35 http://gcc.gnu.org/ml/gcc-testresults/2002-10/msg00309.html
sparc-sun-solaris2.8: 21 http://gcc.gnu.org/ml/gcc-testresults/2002-10/msg00257.html
mips-sgi-irix6.5: 29 http://gcc.gnu.org/ml/gcc-testresults/2002-10/msg00240.html
While Zack came up with a neat hack to allow tuning -Werror on a per
file basis, the problem with -Werror is still that you have to be at
exactly zero warnings >for all platforms forever< on any file you
activate it on. IMHO that's impossible.
Very often an innocent looking and warning free change on one system
will cause warnings on another. This can occur for several reasons
including host platform differences (system header quirks, sizeof
HOST_WIDE_INT, etc), or because of the twisty maze of target macro
definitions we have, or because of quirks in GCC (e.g. I've seen
"uninitialized" warnings that GCC only detects on certain targets with
certain optimization flags.)
Less frequently but still possible: new types of warnings also get
added from time to time. E.g. the recent type punning warning. It's
not always practical to eliminate all diagnostics from GCC itself on
every "primary evaluation" platform (let alone every existing
platform) before adding the new warning detection code to GCC.
So what ends up happening is that we'll see much more bootstrap
breakage. (I'm basing this anecdotally on how often I notice warning
regressions on just the two platforms I test on.) People will get
pissed. They'll either call for removing -Werror or disable it in
their local tree. Either way we're back to square one.
I much very believe we need to automate detection and "nagging" about
these regressions without breaking bootstraps for innocent third
parties who otherwise could continue to work on GCC. This is a
perfect job for the regression tester.
I also believe it would be easy to set up. We can use the
contrib/warn_summary script to generate a baseline of expected
warnings for our test platforms and recheck it every time the tester
runs using a diff process similar to that which checks for bug
regressions. This is very cheap and fast to do, it would not
noticibly affect the total run time of the checker. There might be
some post-processing of the warn-summary output we'd have to do via
sed. E.g. we'd want to strip out line numbers from warnings because
they tend to move around as people add and delete code. But otherwise
it should be very simple. I would be willing to help write the shell
code to generate whatever output you tell me the tester expects.
Please (pretty please :-) consider this. I think if we ever want to
consider -Werror, this is a necessary first step.
--Kaveh
--
Kaveh R. Ghazi ghazi@caip.rutgers.edu