[Tinycc-devel] RE :Re: Many new warnings since yesterday

[Christian JULLIEN]

Hello Thomas, my concern is not that I want a warning free release, my concern is that yesterday we had no warning (as several weeks ago) and many of us qualified tcc as this which is a very long process
Now, after yesterday change, gcc sees new warnings which potentially will break already qualified code. Yesterday changes requires code review to see if warnings are potentially dangerous, I admin that code review is a pain yet probably 95% of them are obvious to fix.

Other solution is to revert to yesterday types which qualified a lot of code

> I'm curious to see what warning you have on Fedora. I don't have any on Debian x86_64.

This one on CentOS si similar to the one I have on Fedora, yesterday CentOS has no warning

address@hidden tinycc]$ make
gcc -o tcc.o -c tcc.c -DCONFIG_LDDIR="\"lib64\"" -DTCC_TARGET_X86_64 -I.  -Wall -g -O2
gcc -o libtcc.o -c libtcc.c -DCONFIG_LDDIR="\"lib64\"" -DTCC_TARGET_X86_64 -I.  -Wall -g -O2
gcc -o tccpp.o -c tccpp.c -DCONFIG_LDDIR="\"lib64\"" -DTCC_TARGET_X86_64 -I.  -Wall -g -O2
tccpp.c: In function 'hash_cached_include':
tccpp.c:1251: warning: pointer targets in assignment differ in signedness
tccpp.c: In function 'next_nomacro1':
tccpp.c:2226: warning: pointer targets in passing argument 2 of 'tok_alloc_new' differ in signedness
tccpp.c:195: note: expected 'const char *' but argument is of type 'uint8_t *'
gcc -o tccgen.o -c tccgen.c -DCONFIG_LDDIR="\"lib64\"" -DTCC_TARGET_X86_64 -I.  -Wall -g -O2
tccgen.c: In function 'is_compatible_func':
tccgen.c:2113: warning: dereferencing type-punned pointer will break strict-aliasing rules
tccgen.c:2113: warning: dereferencing type-punned pointer will break strict-aliasing rules
tccgen.c: In function 'parse_btype':
tccgen.c:3057: warning: dereferencing type-punned pointer will break strict-aliasing rules
tccgen.c:3059: warning: dereferencing type-punned pointer will break strict-aliasing rules
tccgen.c:3060: warning: dereferencing type-punned pointer will break strict-aliasing rules
tccgen.c: In function 'decl0':
tccgen.c:5700: warning: dereferencing type-punned pointer will break strict-aliasing rules
tccgen.c:5701: warning: dereferencing type-punned pointer will break strict-aliasing rules
tccgen.c:5705: warning: dereferencing type-punned pointer will break strict-aliasing rules
tccgen.c: In function 'ieee_finite':
tccgen.c:100: warning: dereferencing pointer '({anonymous})' does break strict-aliasing rules
tccgen.c:100: note: initialized from here
tccgen.c: In function 'decl0':
tccgen.c:5700: warning: dereferencing pointer 'r.367' does break strict-aliasing rules
tccgen.c:5699: note: initialized from here
tccgen.c:5701: warning: dereferencing pointer 'r.367' does break strict-aliasing rules
tccgen.c:5701: note: initialized from here
tccgen.c:5704: warning: dereferencing pointer 'r.367' does break strict-aliasing rules
tccgen.c:5704: note: initialized from here
gcc -o tccelf.o -c tccelf.c -DCONFIG_LDDIR="\"lib64\"" -DTCC_TARGET_X86_64 -I.  -Wall -g -O2
tccelf.c: In function 'rebuild_hash':
tccelf.c:60: warning: pointer targets in assignment differ in signedness
tccelf.c:75: warning: pointer targets in passing argument 1 of 'elf_hash' differ in signedness
tccelf.c:38: note: expected 'const unsigned char *' but argument is of type 'char *'
tccelf.c: In function 'put_elf_sym':
tccelf.c:117: warning: pointer targets in passing argument 1 of 'elf_hash' differ in signedness
tccelf.c:38: note: expected 'const unsigned char *' but argument is of type 'const char *'
tccelf.c: In function 'find_elf_sym':
tccelf.c:147: warning: pointer targets in passing argument 1 of 'elf_hash' differ in signedness
tccelf.c:38: note: expected 'const unsigned char *' but argument is of type 'const char *'
tccelf.c:151: warning: pointer targets in assignment differ in signedness
tccelf.c: In function 'relocate_syms':
tccelf.c:434: warning: pointer targets in assignment differ in signedness
tccelf.c:438: warning: pointer targets in assignment differ in signedness
tccelf.c: In function 'put_got_entry':
tccelf.c:1037: warning: pointer targets in assignment differ in signedness
tccelf.c: In function 'elf_output_file':
tccelf.c:1628: warning: pointer targets in assignment differ in signedness
tccelf.c:1665: warning: pointer targets in assignment differ in signedness
tccelf.c:1694: warning: pointer targets in assignment differ in signedness
tccelf.c:1712: warning: pointer targets in assignment differ in signedness
tccelf.c:1756: warning: pointer targets in assignment differ in signedness
tccelf.c: In function 'tcc_load_object_file':
tccelf.c:2432: warning: pointer targets in assignment differ in signedness
tccelf.c:2553: warning: pointer targets in assignment differ in signedness
tccelf.c:2569: warning: pointer targets in assignment differ in signedness
tccelf.c: In function 'tcc_load_alacarte':
tccelf.c:2673: warning: pointer targets in assignment differ in signedness
tccelf.c: In function 'tcc_load_dll':
tccelf.c:2810: warning: pointer targets in assignment differ in signedness
tccelf.c:2839: warning: pointer targets in assignment differ in signedness
tccelf.c:2848: warning: pointer targets in assignment differ in signedness
gcc -o tccasm.o -c tccasm.c -DCONFIG_LDDIR="\"lib64\"" -DTCC_TARGET_X86_64 -I.  -Wall -g -O2
gcc -o tccrun.o -c tccrun.c -DCONFIG_LDDIR="\"lib64\"" -DTCC_TARGET_X86_64 -I.  -Wall -g -O2
tccrun.c: In function 'rt_printline':
tccrun.c:256: warning: pointer targets in assignment differ in signedness
tccrun.c:349: warning: pointer targets in passing argument 3 of 'pstrcpy' differ in signedness
tcc.h:998: note: expected 'const char *' but argument is of type 'unsigned char *'



> ----- Message d'origine -----
> De : "Thomas Preud'homme" <address@hidden>
> Date ven. 15/02/2013 11:03 (GMT +01:00)
> À : "Christian JULLIEN" <address@hidden>
> Cc : "address@hidden" <address@hidden>
> Objet : Re: [Tinycc-devel] Many new warnings since yesterday
>
> Le vendredi 15 février 2013 07:11:58, Christian Jullien a écrit :
> > Yesterday, Grischka applied my patch to remove last warning (thanks
> > Grischka), tcc compiled with NO warning at all.
> > 
> > This morning, with no changes on my config (same compiler, same options,
> > same script to fetch mod and compile), I get many more warnings on RPi as
> > well as on Fedora 18 x86_64
>
> I'm curious to see what warning you have on Fedora. I don't have any on Debian 
> x86_64.
>
> > 
> > Please note that RPi uses default unsigned char which is different than
> > x86, so sign warnings may be annoying
>
> I know :)
>
> > 
> > To me, a release build should be warning free. Warning free does not mean
> > that build is free of ALL possible warnings (for example using extra -Wxx,
> > using llvm or splint - I recommend splint) it means release manager is
> > aware of suspicious code and either, by order of priority:
> > 
> > - fix it
> > - patch it in order to make build happy
> > - remove offending warning flag for release (and reintroduce this flag in
> > trunk right after the official release)
>
> I'm sorry but I disagree. Trying to fix these bugs now might result in 
> breakages and would delay the release longer. Trying to make the perfect 
> release might lead us to delay by many months at best, or never release in the 
> worst case. There is still several things broken: variadic function are 
> unusable with libgcc for instance.
>
> Yes you're right, warning indicates possible coding errors but there is also 
> false positive. Hence we should definitely look at these warnings and fix what 
> is programming error and leave the other ones. Masking them (with compiler 
> switch) would also mask other legitimate warnings so it's better to let false 
> positive be reported and hope for static analysis in compilers to improve.
>
> In other words, I suggest we look (you're welcome to look at it yourself if 
> you want things to be fixed faster) at it just after the release and target 
> another release not so long time from now. It would be nice to have a release 
> a year I think. It would allow for fixes to flow in stable release faster.
>
> > 
> > Btw, I don't see what recent change produces those new warnings.
>
> Me neither.
>
> Thomas