Re: Baby X is bor nagain

On 27/06/2024 23:47, bart wrote:

On 27/06/2024 20:51, David Brown wrote:

On 27/06/2024 18:28, bart wrote:

On 27/06/2024 13:31, David Brown wrote:

On 27/06/2024 13:16, bart wrote:

>

>

No one doubts that gcc is slower than tcc.  That is primarily because it does vastly more, and is a vastly more useful tool.  And for most C compiles, gcc (even gcc -O2) is more than fast enough.

 And for most of /my/ compiles, the code produced by gcc-O0 is fast enough. It also about the same speed as code produced by one of my compilers.
 

With most of your compiles, is "gcc -O2" too slow to compile?  If not, then why would you or anyone else actively /choose/ to have a poorer quality output and poorer quality warnings?  I appreciate that fast enough output is fast enough (just as I say the same for compilation speed) - but choosing a slower output when a faster one is just as easy makes little sense.  The only reason I can think of why "gcc -O2 -Wall" is not the starting point for compiler flags is because you write poor C code and don't want your compiler to tell you so!

So I tend to use it when I want the extra speed, or other compilers don't work, or when a particular app only builds with that compiler.
 Otherwise the extra overheads are not worth the bother.
  

And it is free, and easily available on common systems.  Therefore there is no benefit to using tcc except in very niche cases.

 And my argument would be the opposite. The use of gcc would be the exception. (Long before I used gcc or tcc, I used lccwin32.)

On Linux, almost everyone uses gcc, except for a proportion who actively choose to use clang or icc.  The same applies to other many other *nix systems, though some people will use their system compiler on commercial Unixes.  For Macs, it is clang disguised as gcc that dominates.  On Windows, few people use C for native code (C++, C# and other languages dominate).  I expect the majority use MSVC for C, and there will be people using a variety of other tools including lcc-win and Borland, as well as gcc in various packagings.  (And embedded developers use whatever cross-compile tools are appropriate for their target, regardless of the host - the great majority use gcc now.)
I don't believe that in any graph of compiler usage on any platform, tcc would show up as anything more than a tiny sliver under "others".

 Here's the result of an experiment I did. gcc 14 is about 800MB and over 10,000 files. I wanted to see the minimal set of files that would compile one of my generated C files.

Why?  800 MB is a few pence worth of disk space.  For almost all uses, it simply doesn't matter.

 I can't explain to somebody who doesn't get it why a small, simple tool is desirable.
 

If you were trying to say that tcc is simpler to /use/ than gcc, that would be a different matter entirely.  That would be a relevant factor. The size of the gcc installation, is all hidden behind the scenes.  Few people know how big it is on their system, fewer still care.
(And I am not sure I agree with such a claim - certainly you /can/ have very advanced and complicated use of gcc.  But in comparison to learning C itself, running "gcc -Wall -O2 -o hello hello.c" is hardly rocket science.  But I would certainly be much more open to a "simpler to use" argument.)