This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Remaining warnings report


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]