Re: gcc Build Warnings

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



"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

[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux