[Top][All Lists]

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

Re: [Tinycc-devel] Call for testing

From: grischka
Subject: Re: [Tinycc-devel] Call for testing
Date: Sun, 06 Jan 2013 17:03:28 +0100
User-agent: Thunderbird (Windows/20090812)

/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

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

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 
[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):
  The headers from include are copied to win32/include during install

  Obviously (if you look at the code) this was not a bug but intended behavior.

  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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]