tinycc-devel
[Top][All Lists]
Advanced

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

Re: [Tinycc-devel] global declaration behavior of TCC


From: Fabrice Bellard
Subject: Re: [Tinycc-devel] global declaration behavior of TCC
Date: Thu, 24 Oct 2002 00:38:55 +0200
User-agent: Mutt/1.2.5i

On Wed, Oct 23, 2002 at 11:53:38PM +0200, Basile STARYNKEVITCH wrote:
> Sorry, 
> 
> (I don't have my ISO99 C standard here so I might be wrong)
> 
> It seems that TCC don't handle correctly a declaration appearing
> several times (because it is in an include file):
> 
> // file e1.c
> #include "i.h"
> int plusi(int x) { return i+x; };
> // eof e1.c
> 
> // file e2.c
> #include <stdio.h>
> #include <stdlib.h>
> 
> #include "i.h"
> int main(int argc, char**argv) {
>     int y=0;
>     if (argc>1) y=atoi(argv[1]);
>     if (argc>2) i=atoi(argv[2]);
>     printf("y=%d i=%d plusi(y)=%d\n",
>            y, i, plusi(y));
>     return 0;
> }
> // eof e2.c
> 
> // file i.h
> int i;
> // eof i.h
> 
> 
> When compiling with tcc -o e e1.c e2.c  I am getting:
> In file included from e2.c:6:
> i.h:3: 'i' defined twice
> 
> I think this behavior might not be correct. (and I know that C and C++
> differs on these matters). At least gcc don't have it

GCC generates uninitialized global variables by default as "commons"
whereas TCC generates them directly in the .bss section. ld accepts
that commons are multiply defined (you can enable a warning in ld to
signal it). You can also use '-fno-common' with gcc to have the same
behaviour as TCC. So this is more a linker related issue than a
compiler related one.

> I also suggest that TCC should swallow either silently or with a
> warning any -O option (even if it does not do any additional
> optimisation).

I included such a feature in TCC 0.9.13. 

I have been very busy on other projects recently so I was not able to
publish TCC 0.9.13 as planned. The most notable feature of this
release is that "libtcc" becomes usable (many memory leaks fixed,
errors are non fatal, reentrancy in most of the API) and some bug
fixes on the 'long long' type handling.

Fabrice.




reply via email to

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