/usr/bin/gcc-4.0.4 -o tcc.o -c tcc.c -DTCC_TARGET_I386 -I. -I/home/didier/documents/tech/dev/tcc/tinycc -Wall -g -O2
I think some people might not feel comfortable to see their absolute paths exposed. Also it makes command lines longer/uglier than necessary and is redundant here anyway (same as -I.).
-fno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare -Wno-unused-result -mpreferred-stack-boundary=2 -march=i386 -falign-functions=0 -m32
Do we need both -march=i386 and -m32? Also, what about removing -mpreferred-stack-boundary=2 and -falign-functions=0 ?
cc1: error: unrecognized command line option "-Wno-unused-result" make: *** [tcc.o] Error 1
Maybe we could test supported switches by running the compiler in configure. Also what about using -D_FORTIFY_SOURCE=0 when -Wno-unused-result is not supported? Also, someone please test the functionality of the install. (I suspect libtcc.h might be missing). Compilation on Windows with MSC fails in tccgen.c:vswap(): ../tccgen.c(476) : error C2143: syntax error : missing ';' before 'type' [more ...] After moving declarations before statements, it fails like this: ../tccgen.c(490) : warning C4308: negative integral constant converted to unsigned type ../tccgen.c(490) : warning C4307: '*' : integral constant overflow ../tccgen.c(490) : warning C4307: '+' : integral constant overflow ../tccgen.c:481: error: incompatible types for redefinition of '__static_assert_t' [more ...] I'd suggest to move that optimization into its own function void memswap(void *p1, void *p2, size_t n); or otherwise to revert it. Other candidates for reversion (OTOH): - http://repo.or.cz/w/tinycc.git/commitdiff/fc574f14984d11f1ead50560d1bdc5ae0eaf6d8d The headers from include are copied to win32/include during install - http://repo.or.cz/w/tinycc.git/commitdiff/943574aba54713ca4a17fe33aadde5abee233b53 Obviously (if you look at the code) this was not a bug but intended behavior. - http://repo.or.cz/w/tinycc.git/commitdiff/3d409b08893873b917ccb8c34398bc41a4e84d7c The patch doesn't fix the real problem which is not duplicate -I's by the user but the very obviously crappy handling of #include_next itself. Of course the patch fixes something, but if we keep it chances are that we'll never see a correct solution. --- grischka _______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel