Jeff Law <l...@redhat.com> writes: > I think (as always) we need to find a balance between throwing > everything *we* find valuable in -Wall and avoiding all changes to > accommodate users on the other end of the spectrum. With that in mind > I'd ask Ian to chime in and say something about the # of warnings we > found in our own codebase vs how many of those warnings represented > real bugs vs false positives.
I already answered that one upstream. There were three occurrences in gcc proper which I fixed. They were: http://gcc.gnu.org/viewcvs/trunk/gcc/df-problems.c?r1=148512&r2=148511&pathrev=148512 http://gcc.gnu.org/viewcvs/trunk/gcc/gcov.c?r1=148512&r2=148511&pathrev=148512 http://gcc.gnu.org/viewcvs/trunk/gcc/cp/parser.c?r1=148512&r2=148511&pathrev=148512 I've seen two other problems in code that we compile without -Werror: libiberty/regex.c and gcc/unwind-dw2-fde-glibc.c. In none of these cases would the code execute incorrectly. In df-problems the problem amounted to missing braces around a switch. In gcov.c an error condition had a goto back to an earlier error condition. The code in cp/parser.c I would describe as spaghetti code which ought to use a helper function instead. The code in libiberty/regex.c seems to have something to do with backtracing; it looks pretty ugly (it's goto restore_best_regs on line 7476). The code in unwind-dw2-fde-glibc.c, the only goto in the file, skips over a variable declaration in the middle of a function. This sort of code is always going to be a little bit dubious simply because it can only happen with a goto into the middle of a function somewhere, or a switch statement written in a peculiar way. That said, I'm perfectly amenable to moving the new warning to -Wextra or just turning it on only with -Wc++-compat. I don't personally care that much, actually. Ian