Path: ...!news.nobody.at!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: tcc - first impression. Was: Baby X is bor nagain Date: Mon, 01 Jul 2024 12:14:36 -0700 Organization: A noiseless patient Spider Lines: 158 Message-ID: <864j98diw3.fsf@linuxsc.com> References: <20240624160941.0000646a@yahoo.com> <20240624181006.00003b94@yahoo.com> <20240625113616.000075e0@yahoo.com> <87ed8jnbmf.fsf@bsb.me.uk> <867ceadtih.fsf@linuxsc.com> <20240701200924.00003d9a@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Mon, 01 Jul 2024 21:14:37 +0200 (CEST) Injection-Info: dont-email.me; posting-host="46a61ee24880567c9c214dab31571310"; logging-data="1275880"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18gXkMxGuXnFJp4otIF65OJN9BVdaqZoBo=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:ioH6dZNn5Gkzo9MH840ZWIvrdVI= sha1:axbRVZVaNq9ni1HU8DyXcsxXbwI= Bytes: 8325 Michael S writes: > On Thu, 27 Jun 2024 13:23:50 -0700 > Tim Rentsch wrote: > >> bart writes: >> >>> On 26/06/2024 13:15, Ben Bacarisse wrote: >>> >>>> bart writes: >>>> >>>>> On 25/06/2024 16:12, David Brown wrote: >>>> >>>> ... >>>> >>>>>> I /do/ use Python. I use it when it is an appropriate language >>>>>> to use, which is very different circumstances from when I use C >>>>>> (or C++). Different tools for different tasks. >>>>> >>>>> And yet neither of you are interested in answering my question, >>>>> which was why its simplistic bytecode compiler is acceptable in >>>>> this scenario, but would be considered useless if applied to C >>>>> code. >>>> >>>> You throw out a lot of these sorts of question, by which I mean >>>> questions that you either /do/ know the answers to or which you >>>> /should/ know the answers to. >>>> >>>> If a software engineering student asked me this sort of "challenge" >>>> question it would immediately become homework: come up with at >>>> least two scenarios in which a simplistic C bytecode compiler >>>> would be an unacceptable tool to use, and two in which Python with >>>> a trivial bytecode compiler would be an acceptable tool to use. >>>> In each case explain why. Anyone who could not would get marked >>>> down on the course. >>> >>> I'm not sure what you're implying here. >>> >>> Some here are consistently saying that any compiler whose internal >>> processes are not at the scale or depth that you find in >>> professional', 'industrial scale' products like gcc, clang, icc, is >>> not worth bothering with and is basically a useless toy. >> >> After reading the above I decided to try tcc. I used tcc for >> the first time earlier today. >> >> First I tried using tcc for my most recent project. That >> didn't go anywhere, because that project relies on C11, >> and tcc doesn't support C11. >> >> Next I tried using tcc on a small part of my larger current >> project. That test involves compiling one .c file to produce a >> .o file, and linking with several other .o files to produce an >> executable, and running the executable. The .c file being >> compiled uses C99 and doesn't need C11. >> >> The first thing that came up is tcc doesn't support all of >> C99. There are some C99 features that tcc just doesn't >> understand. In this case the infringements were minor so I >> edited the source to work around the missing features. >> >> The second thing to come up is some language incompatibilities. >> There are language features that tcc understands, sort of, >> but implements them in a way that didn't work with my source >> code. To be fair, a case could be made that what tcc does >> conforms to the C standard. However, the code I had before >> works fine with gcc and clang, and doesn't with tcc. Here >> again the changes needed were minor so I edited the source >> to work around the problem. >> >> The third thing to come up was the link step. Compiling the >> one .c file with tcc -- and there are three other .o files >> produced using gcc -- implicated the link step, which needed >> to be done with tcc to avoid some undefined symbols. That >> kind of surprised me; I'm used to being able to mix gcc >> object files and clang object files with no difficulty, >> so having the link step fail caught me off guard. >> >> After taking care of all that the build did manage to produce an >> executable, which appears to have run successfully. >> >> After doing a trial run with the produced executable, I looked at >> the tcc man page. As best I can tell, tcc simply silently >> ignores the -fPIC option. (I didn't test that, I only read what >> the tcc man page says.) That project absolutely relies on -fPIC, >> so if tcc doesn't support it that's a deal breaker. >> >> Not offering any conclusion. Just reporting my experience. > > I tried tcc too. > > 1. It is easy to download. It does not need installation apart from > unzip. I installed tcc on linux by using apt-get. Worked with no problem. > 2. It is very fast. Even when used from makefile, which is not an > optimal mode of use, in my tests more than 3 times faster than MSVC in > non-parallel build and more that twice faster in parallel build on > quad-core CPU. And that on project that spends unproportionally long > time in link. I am ready to believe that on more typical projects > (i.e. more compile time, less link time) the difference would be over > 5x. > For the record, on this project 'gcc -O2' was ~1.7x slower than 'MSVC > -O2' and 'gcc -O0' was ~1.1x slower than 'MSVC -O2'; the later > difference probably because somewhat faster compilation by 'gcc -O0' was > outdone by much slower link. > > 3. Exe is slow, but not slower than gcc -O0. About the same. In this > particular test it meant ~2.5 times slower than optimized gcc or MSVC > binary. I didn't measure the speed either of the compiler or the executable. Apparently tcc doesn't understand -S to produce assembly. > 4. In this particular project I encountered few inconvenient > incompatibilities: > 4.1. no support for %zd and %zu. May be, Linux version is better in that > regard? I tried %zu in tcc on linux and it worked fine. > 4.2. Code like below does not compile. I don't know whether it is legal > 'C' or not, > but gcc, clang and MSVC compilers accept it o.k. > label:int bar; Putting a label on a declaration is not supported in either C99 or C11. Maybe those other compilers are using a later version of C or compiler extensions. Did you use a -std=c?? option, along with -pedantic? I used -std=c99 -pedantic. tcc accepts -std=c11 but it seems to make no difference to what is accepted. > 4.3. c11/c17 things that are supported even by MSVC, which is generally > does not claim full C11 support: > _Alignof() Support issues that came up in my tests: 1. tcc doesn't understand _Generic at all. That is in keeping with tcc claiming to be for C99, since _Generic was added in C11. 2. tcc doesn't understand the simplest form of variably modified types, such as int foo( int n, unsigned v[n] ); 3. A tcc header for does give a macro definition for va_end(), but it is not as robust as one would like. > It's close to advertised, i.e. it is not C17, but has few features of > C17. I didn't make any effort to do exhaustive testing. I simply grabbed some C source files I had lying around and tried to compile (and later link) them with tcc.