Re: Converting to ISO C89

["Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>]

 > | You can probably also dispense with some settings of <lang>-warn in
 > | */Make-lang.in now.
 > 
 > Will do so once I'm finished with preparing GCC-3.2.3 prerelease
 > tarballs.
 > -- Gaby

This can be tricky for some of the remaining cases.  One strategy is
to just take them out and see who complains.  Maybe they'll fix each
warning themselves. :-)  But here are some potential problems:

1.  Bison generated files.  Much of this was traditional warnings, but
    some versions of bison would additonally yield signed/unsigned
    warnings in their generated code.  You may want to test the
    several bison versions (1.28, 1.35, 1.50, 1.75, 1.875 ??) that are
    in use and see what happens.

2.  $(cpu).o files.  These would need a cross-compile check to one of
    each type to make sure there's nothing else besides traditional
    warnings.  I know of at least a few which had problems and I don't
    know if someone's cleaned them up in the mean time.

3.  Some of the remaining files get those "string too long" pedantic
    warnings or something else that's annoying but only for some
    platforms.  E.g. varasm.c, gcc.c, insn-conditions.c.  Again these
    would need multiple cross-compile checks to be sure.

For the cases where just one or two targets choke a file but others
pass, we could move the -Wno-error into a target dependent t-*
makefile fragment.  E.g. we do this in t-ia64 already.

Before anyone suggests it, I'd advise against turning off warnings
per-file with e.g. -Wno-sign-compare etc to work around these
problems.  It only lets more cruft creep in.

I can help with the cross-compile testing if you like.

		--Kaveh
--
Kaveh R. Ghazi			ghazi at caip dot rutgers dot edu