Path: ...!news.nobody.at!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
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: <v494f9$von8$1@dont-email.me> <v53lf7$34huc$1@dont-email.me> <v53vh6$368vf$1@dont-email.me> <v54se1$3bqsk$1@dont-email.me> <20240624160941.0000646a@yahoo.com> <v5bu5r$va3a$1@dont-email.me> <20240624181006.00003b94@yahoo.com> <v5c86d$11ac7$1@dont-email.me> <JEheO.108086$ED9b.74955@fx11.iad> <v5cblg$11q0j$1@dont-email.me> <gEieO.108089$ED9b.25598@fx11.iad> <20240625113616.000075e0@yahoo.com> <mUzeO.141609$Cqra.55051@fx10.iad> <v5elql$1jmii$1@dont-email.me> <m3BeO.24907$Gurd.16179@fx34.iad> <v5empd$1jndv$2@dont-email.me> <v5eph4$1k6a9$1@dont-email.me> <87ed8jnbmf.fsf@bsb.me.uk> <v5jhls$2m7np$1@dont-email.me> <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 <already5chosen@yahoo.com> writes:

> On Thu, 27 Jun 2024 13:23:50 -0700
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> bart <bc@freeuk.com> writes:
>>
>>> On 26/06/2024 13:15, Ben Bacarisse wrote:
>>>
>>>> bart <bc@freeuk.com> 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 <stdarg.h> 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.