"Tom Browder" <tom.browder@xxxxxxxxx> writes: > On Mon, Dec 29, 2008 at 5:10 PM, Tom Browder <tom.browder@xxxxxxxxx> wrote: >> On Mon, Dec 29, 2008 at 4:05 PM, Ian Lance Taylor <iant@xxxxxxxxxx> wrote: >>> "Tom Browder" <tom.browder@xxxxxxxxx> writes: >>>> I'll go back and redo my last build and look at the warnings, but I'm >>>> pretty sure I see mostly the usual warnings about comparison of signed >>>> versus unsigned and such that are probably due to developer >>>> optimizations, but they are bothersome. > > I have attached a much-shortened list of the kinds of warnings I'm > talking about--all from stage 2 or later. Shouldn't these be taken > care of by the developers (i.e., suppressed somehow)? Yes, ideally they should. Patches are welcome. We are all gcc developers. > # stage 2 and later > checking whether vasprintf is declared... ../../gcc-4.4-20081226/libiberty/cp-demangle.c: In function 'cplus_demangle_type': > ../../gcc-4.4-20081226/libiberty/cp-demangle.c:1914: warning: 'ret' may be used uninitialized in this function > gengtype-lex.c: In function 'yy_get_next_buffer': > gengtype-lex.c:1661: warning: old-style function definition > gengtype-lex.c: In function 'yy_get_previous_state': > gengtype-lex.c:1793: warning: old-style function definition > gengtype-lex.c: In function 'input': > gengtype-lex.c:1906: warning: old-style function definition > ../../gcc-4.4-20081226/gcc/gengtype-lex.l: At top level: > gengtype-lex.c:1906: warning: 'input' defined but not used Difficult to control because gengtype-lex.c is generated by flex, and the warnings apply to the generated code. > build/genrecog ../../gcc-4.4-20081226/gcc/config/i386/i386.md \ > insn-conditions.md > tmp-recog.c > ../../gcc-4.4-20081226/gcc/config/i386/i386.md:19694: warning: operand 1 missing mode? The missing mode is unusual but intentional because the insn intends to accept a set of modes which may be used for the condition code. It would be nice to have a way to represent this in the MD file, or alternatively a way to suppress the warning. > /usr/local/src/gcc_projects/gccsnapshots/build/./prev-gcc/xgcc -B/usr/local/src/gcc_projects/gccsnapshots/build/./prev-gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -Wno-error -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.4-20081226/gcc -I../../gcc-4.4-20081226/gcc/. -I../../gcc-4.4-20081226/gcc/../include -I../../gcc-4.4-20081226/gcc/../libcpp/include -I/usr/local/include -I../../gcc-4.4-20081226/gcc/../libdecnumber -I../../gcc-4.4-20081226/gcc/../libdecnumber/bid -I../libdecnumber ../../gcc-4.4-20081226/gcc/bitmap.c -o bitmap.o > ../../gcc-4.4-20081226/gcc/bitmap.c: In function 'bitmap_obstack_alloc_stat': > ../../gcc-4.4-20081226/gcc/bitmap.c:359: warning: request for implicit conversion from 'void *' to 'struct bitmap_head_def *' not permitted in C++ > ../../gcc-4.4-20081226/gcc/bitmap.c: In function 'bitmap_obstack_free': > ../../gcc-4.4-20081226/gcc/bitmap.c:394: warning: request for implicit conversion from 'void *' to 'struct bitmap_element *' not permitted in C++ This one (and the other bitmap ones) are (I think) easy to fix but there has been some disagreement about cast uglification merely to make the code compilable by a C++ compiler. Probably we should just put the casts in. > /usr/local/src/gcc_projects/gccsnapshots/build/./prev-gcc/xgcc -B/usr/local/src/gcc_projects/gccsnapshots/build/./prev-gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.4-20081226/gcc -I../../gcc-4.4-20081226/gcc/. -I../../gcc-4.4-20081226/gcc/../include -I../../gcc-4.4-20081226/gcc/../libcpp/include -I/usr/local/include -I../../gcc-4.4-20081226/gcc/../libdecnumber -I../../gcc-4.4-20081226/gcc/../libdecnumber/bid -I../libdecnumber ../../gcc-4.4-20081226/gcc/diagnostic.c -o diagnostic.o > ../../gcc-4.4-20081226/gcc/dfp.c: In function 'encode_decimal32': > ../../gcc-4.4-20081226/gcc/dfp.c:142: warning: dereferencing type-punned pointer will break strict-aliasing rules > ../../gcc-4.4-20081226/gcc/dfp.c: In function 'decode_decimal32': > # etc. > ../../gcc-4.4-20081226/gcc/dfp.c:274: warning: dereferencing type-punned pointer will break strict-aliasing rules > ../../gcc-4.4-20081226/gcc/dfp.c:267: warning: dereferencing pointer '({anonymous})' does break strict-aliasing rules > ../../gcc-4.4-20081226/gcc/dfp.c:267: note: initialized from here I think these are just bugs. Not sure about the rest, they look pretty easy to fix. Ian