This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Remaining warnings report
- To: gcc at gcc dot gnu dot org
- Subject: Remaining warnings report
- From: Zack Weinberg <zack at wolery dot cumb dot org>
- Date: Mon, 31 Jan 2000 00:06:50 -0800
After the two patches I just sent in:
Counting all warnings,
there are 118 warnings in stage3 of this bootstrap.
...
Number of warning types:
52 Use of ANSI string concatenation
14 `long' switch expression not converted to `int' in ANSI C
12 signed and unsigned type in conditional expression
12 Ignoring command line option '-Wtraditional'
11 `???' might be used uninitialized in this function
7 comparison between signed and unsigned
2 implicit declaration of function `???'
2 function `???' was previously declared within a block
1 unused variable `???'
1 unused parameter `???'
1 passing arg ??? of `???' discards qualifiers from pointer target type
1 assignment makes pointer from integer without a cast
1 assignment discards qualifiers from pointer target type
1 `???' defined but not used
All of the remaining string-concat warnings come from the Fortran
front end. Ditto the "switch expression not converted" warnings.
I'm not going anywhere near that code.
"Ignoring command line option '-Wtraditional'" comes from cc1plus. It
is fairly nonsensical to ask the C++ compiler for traditional
compatibility warnings. I'd rather it just silently ignored them,
though - convincing the Makefile to not pass that to g++ will be
difficult.
The signed and unsigned type warnings are all over the place. The
code is probably fine in each case, but needs to be examined pretty
carefully to find the proper fix. Most of 'em appear to be use of -1
as a sentinel in an unsigned field.
The uninitialized variable warnings come from four different places:
libgcc2.c - it's complaining about a variable assigned to a
specific machine register. The weird bit is that there are four
machine-register variables in that macro and it only complains
about one of them.
frame.c - legitimate beef; compiler can't prove that a loop body
will execute at least once.
unroll.c, i386.c - spurious; the documented failure mode.
zw