The code of TCC (0.9.26) is kind hard to compile, I have discovered in the past year, while developing a minimal C compiler to compile the TCC sources [1]. For that reason, I have concluded that TCC is its own test set. It uses the constant 0x80000000, which is an edge case for if you want to print it as a signed integer only using 32-bit operators. There is a switch statement with an post-increment operator in the switch expression. There are also switch statements with fall throughs and with goto statements in the cases. It uses the ## operator where the result is the name of a macro. Just to name a few.
I've never seen another repo with public commit access like that. I guess the project is niche enough that you don't get spammed with bad or malicious commits.
>The idea is to provide unmoderated side channel for random contributors to work on a project, with similar rationale as e.g. Wikipedia - that given enough interested people, the quality will grow rapidly and occassional "vandalism" will get fixed quickly. Of course this may not work nearly as well for software, but here we are, to give it a try.
When pugs (a perl6 implementation in Haskell) was a thing, you gained commit access by asking and it was immediately granted to everyone. It was insane and awesome.
It is also interesting to note that while the repository is quite active, there has not been any release for _8 years_, and the website is the same one at the top of this conversation, i.e. the one where the old maintainer says he quit and the benchmarks are from 20 years ago.
A small and minimalistic C compiler is actually a very important foundational project for the software world IMNSHO.
Years ago I built a scripting language that transpiled to TCC and then compiled to machine code in memory. It produced human-readable C code so it was very easy to get going: when debugging the compiler I could just look at the generated C code without having to learn any special infrastructure/ecosystem/syntax etc. Plus basically zero-overhead interop with C out of the box => immediate access to a lot of existing libraries (although a few differences in calling conventions between TCC and GCC did bite me once). Another feature I had was "inline C" if you wanted to go low level, it was super trivial to add, too. It was pretty fast, maybe two times slower than GCC, IIRC, but more than enough for a scripting language.
libtcc doesn't give you much control AST wise, you basically just feed it strings. I'm using it for the purpose you mentioned though--scripting language backend--since for my current "scripting-language" project I can emit C89, and it's plenty fast enough for a REPL!
/* add a file (either a C file, dll, an object, a library or an ld script). Return -1 if error. */
int tcc_add_file(TCCState *s, const char *filename);
/* compile a string containing a C source. Return non zero if error. */
int tcc_compile_string(TCCState *s, const char *buf);
Thanks. The hardest part has been slogging through the segfaults and documenting all the unprincipled things I've had to add. Post-bootstrap, I have to undo it all because my IR is a semantically rich JSON format that is turing-incomplete by design. I'm building a substrate for rich applications over bounded computation, like eBPF but for applications and inference.
Anyone know a good resource for getting started writing a compiler? I'm not trying to write a new LLVM, but being a "software engineer" writing web-based APIs for a living is leaving me wanting more.
The dragon book is a classic, and was a terrific resource thirty and forty years ago. Today there are many far better resources. Several listed adjacent to this one.
It’s focused on theory and very heavy on parsing. All of that is fine, but not especially useful for the hobbies.
> The professor just really liked tcc for some reason.
Perhaps, or maybe they just got tired of students coming in and claiming that their program worked perfectly on such-and-such compiler.[1] It looks like tcc would run on most systems from the time of its introduction, and perhaps some that are a great deal older. When I took a few computer science courses, they were much more restrictive. All code had to be compiled with a particular compiler on their computers, and tested on their computers. They said it was to prevent cheating but, given how trivial it would have been to cheat with their setup, I suspect it had more to do with shutting down arguments with students who came in to argue over grades.
[1] I was a TA in the physical sciences for a few years. Some students would try to argue anything for a grade, and would persist if you let them.
The professor could have just insisted on `-std=c99` or a similar GCC flag which disallows GNU extensions.
When I taught programming (I started teaching 22 years ago), the course was still having students either use GCC with their university shell accounts, or if they were Windows people, they would use Borland C++ we could provide under some kind of fair use arrangement IIANM, and that worked within a command shell on Windows.
On the other hand, with tcc, you'd know exactly what you were dealing with.
I used it just the other day to do some tests. No dependencies, no fiddling around with libwhater-1.0.dll or stuff like that when on Windows and so on.
That is, I believe, one the points of AI and Open Source many contacts. Something like TCC, with a good coding agent and a developer that cares about the project, and knows enough about it, can turn into a project that can be maintained without the otherwise large efforts needed, that resulted into the project being abandoned. I'm resurrecting many projects of mine I had no longer the time to handle, like dump1090, linenoise, ...
I don't think it is not maintained, there is plenty of activity going on in the repo: https://repo.or.cz/tinycc.git, they just don't seem to be cutting releases?
Man I can't wait for tcc to be reposted for the 4th time this week with the license scrubbed and the comment of "The Latest AI just zero-shotted an entire C compiler in 5 minutes!"
There actually was an article like this from Anthropic the other day but instead of 5 minutes I think it was weeks and $20,000 worth of tokens. Don't have the link handy though.
Except it was written in a completely different language (Rust), which likely would have necessitated a completely different architecture, and nobody has established any relationship either algorithmically or on any other level between that compiler and TCC. Additionally, and Anthropic's compiler supports x86_64 (partially), ARM, and RISC-V, whereas TCC supports x86, x86_64, and ARM. Additionally, TCC is only known to be able to boot a modified version of the Linux 2.4 kernel[1] instead of an unmodified version of Linux 6.9.
Additionally, it is extremely unlikely for a model to be able to regurgitate this many tokens of something, especially translated into another language, especially without being prompted with the starting set of tokens in order to specifically direct it to do that regurgitation.
So, whatever you want to say about the general idea that all model output is plagiarism of patterns it's already seen or something. It seems pretty clear to me that this does not fit the hyperbolic description put forward in the parent comments.
Except it was written in a completely different language (Rust), which would have necessitated a completely different architecture, and nobody has established any relationship either algorithmically or on any other level between that compiler and TCC.
The code of TCC (0.9.26) is kind hard to compile, I have discovered in the past year, while developing a minimal C compiler to compile the TCC sources [1]. For that reason, I have concluded that TCC is its own test set. It uses the constant 0x80000000, which is an edge case for if you want to print it as a signed integer only using 32-bit operators. There is a switch statement with an post-increment operator in the switch expression. There are also switch statements with fall throughs and with goto statements in the cases. It uses the ## operator where the result is the name of a macro. Just to name a few.
[1] https://github.com/FransFaase/MES-replacement
You have simply made one tiny step, that the guys who used AI and $25,000 to write a C compiler in Rust, could not make:
You are using the compiler to compile itself.
"TCC is its own test set." Absolutely brilliant.
Used in the impressive Guix bootstrap.
https://guix.gnu.org/manual/1.5.0/en/html_node/Full_002dSour...
Riiiight, I forgot about htat.
The unofficial repo continuing tcc has geoblocked the UK.
https://repo.or.cz/tinycc.git
This is the most rational response to poorly written laws. If everyone did it, maybe they would repeal that law.
https://repo.or.cz/uk-blocked.html
The most rational response to poorly written laws is collective action against government that wrote them.
But that would require terminally online frogs acting in their collective interests, not isolating at home hoping the heat never reaches them.
There is an actively maintained fork with RISC-V support and such
https://repo.or.cz/w/tinycc.git
https://github.com/TinyCC/tinycc
I've never seen another repo with public commit access like that. I guess the project is niche enough that you don't get spammed with bad or malicious commits.
Yeah it's basically anarchy (to some extent)
https://repo.or.cz/h/mob.html
>The idea is to provide unmoderated side channel for random contributors to work on a project, with similar rationale as e.g. Wikipedia - that given enough interested people, the quality will grow rapidly and occassional "vandalism" will get fixed quickly. Of course this may not work nearly as well for software, but here we are, to give it a try.
When pugs (a perl6 implementation in Haskell) was a thing, you gained commit access by asking and it was immediately granted to everyone. It was insane and awesome.
I would be interested in contributing to this but the UK is geoblocked.
It is also interesting to note that while the repository is quite active, there has not been any release for _8 years_, and the website is the same one at the top of this conversation, i.e. the one where the old maintainer says he quit and the benchmarks are from 20 years ago.
A small and minimalistic C compiler is actually a very important foundational project for the software world IMNSHO.
I'm definitely reminded of: https://xkcd.com/2347/
Does anyone use libtcc for a scripting language backend? Smaller and faster than llvm. You'd have to transpile to a C ast I imagine.
Years ago I built a scripting language that transpiled to TCC and then compiled to machine code in memory. It produced human-readable C code so it was very easy to get going: when debugging the compiler I could just look at the generated C code without having to learn any special infrastructure/ecosystem/syntax etc. Plus basically zero-overhead interop with C out of the box => immediate access to a lot of existing libraries (although a few differences in calling conventions between TCC and GCC did bite me once). Another feature I had was "inline C" if you wanted to go low level, it was super trivial to add, too. It was pretty fast, maybe two times slower than GCC, IIRC, but more than enough for a scripting language.
libtcc doesn't give you much control AST wise, you basically just feed it strings. I'm using it for the purpose you mentioned though--scripting language backend--since for my current "scripting-language" project I can emit C89, and it's plenty fast enough for a REPL!
Currently striving towards my own TypeScript to native x86_64 physical compiler quine bootstrapped off of TCC and QuickJS. Bytecode and AST are there!
This sounds like a really cool project. What challenges have you encountered so far?
Thanks. The hardest part has been slogging through the segfaults and documenting all the unprincipled things I've had to add. Post-bootstrap, I have to undo it all because my IR is a semantically rich JSON format that is turing-incomplete by design. I'm building a substrate for rich applications over bounded computation, like eBPF but for applications and inference.
I recall, there where similar items back in late 70s and early 80s .
Tiny C, Small C are names I seem to recall, buts its very fuzzy - Not sure if they were compilers, may have been interpreters....
Anyone know a good resource for getting started writing a compiler? I'm not trying to write a new LLVM, but being a "software engineer" writing web-based APIs for a living is leaving me wanting more.
https://craftinginterpreters.com/
Traditionally you would start with the Dragon Book[1]. Another starting point is reading the documentation for Yacc (aka Bison) and Lex.
[1] https://en.wikipedia.org/wiki/Compilers:_Principles,_Techniq...
The dragon book is a classic, and was a terrific resource thirty and forty years ago. Today there are many far better resources. Several listed adjacent to this one.
It’s focused on theory and very heavy on parsing. All of that is fine, but not especially useful for the hobbies.
I would highly recommend Wirth's Compiler Construction. Great, short book with a lot to say.
What advantage does this have over SDCC?
There is even smaller C compiler that fits within the 512 bytes https://xorvoid.com/sectorc.html
This was the compiler I was required to use for my courses in university. GCC was forbidden. The professor just really liked tcc for some reason.
> The professor just really liked tcc for some reason.
Perhaps, or maybe they just got tired of students coming in and claiming that their program worked perfectly on such-and-such compiler.[1] It looks like tcc would run on most systems from the time of its introduction, and perhaps some that are a great deal older. When I took a few computer science courses, they were much more restrictive. All code had to be compiled with a particular compiler on their computers, and tested on their computers. They said it was to prevent cheating but, given how trivial it would have been to cheat with their setup, I suspect it had more to do with shutting down arguments with students who came in to argue over grades.
[1] I was a TA in the physical sciences for a few years. Some students would try to argue anything for a grade, and would persist if you let them.
The prof could have just said "Use GCC <version>" then, which would run on even more systems than TCC. Professor probably just really liked TCC.
Seems like a good way to get students to write C rather than GNU C.
TCC - just like many other C compilers - supports many GNU extensions.
The professor could have just insisted on `-std=c99` or a similar GCC flag which disallows GNU extensions.
When I taught programming (I started teaching 22 years ago), the course was still having students either use GCC with their university shell accounts, or if they were Windows people, they would use Borland C++ we could provide under some kind of fair use arrangement IIANM, and that worked within a command shell on Windows.
On the other hand, with tcc, you'd know exactly what you were dealing with.
I used it just the other day to do some tests. No dependencies, no fiddling around with libwhater-1.0.dll or stuff like that when on Windows and so on.
There also is an unofficial mirror which has updates.
https://github.com/TinyCC/tinycc
That has the same content as git://repo.or.cz/tinycc.git
What a blast from the past TCC!
Sad but not surprised to see it's no longer maintained (8 years ago!).
Even in the era of terabyte NVMe drives my eyes water when I install MSVC (and that's usually just for the linker!)
That is, I believe, one the points of AI and Open Source many contacts. Something like TCC, with a good coding agent and a developer that cares about the project, and knows enough about it, can turn into a project that can be maintained without the otherwise large efforts needed, that resulted into the project being abandoned. I'm resurrecting many projects of mine I had no longer the time to handle, like dump1090, linenoise, ...
I don't think it is not maintained, there is plenty of activity going on in the repo: https://repo.or.cz/tinycc.git, they just don't seem to be cutting releases?
Still maintained. You have the mob repo in another comment.
Debian, Fedora, Arch and others pull their package from the mob repo. They're pretty good at pulling in CVE fixes almost immediately.
Thomas Preud'homme is the new maintainer lead, though the code is a mob approach.
There's still activity on the mailing list. It may still be maintained.
https://lists.nongnu.org/archive/html/tinycc-devel/2026-02/t...
TCC is fantastic! I use it a lot to do fast native-code generation for language projects, and it works really really well.
Man I can't wait for tcc to be reposted for the 4th time this week with the license scrubbed and the comment of "The Latest AI just zero-shotted an entire C compiler in 5 minutes!"
And the subsequent youtube hype videos of "COMPILER WRITING IS OVER!"
I may have missed this. Do you have a link when AI verbatim copied tcc and it was publicized? I have my doubts.
There actually was an article like this from Anthropic the other day but instead of 5 minutes I think it was weeks and $20,000 worth of tokens. Don't have the link handy though.
Sixteen Claude AI agents working together created a new C compiler - Ars Technica
https://arstechnica.com/ai/2026/02/sixteen-claude-ai-agents-...
> The $20,000 experiment compiled a Linux kernel but needed deep human management.
We tasked Opus 4.6 using agent teams to build a C Compiler | Hacker News
https://news.ycombinator.com/item?id=46903616
Quoting my sibling comment:
Except it was written in a completely different language (Rust), which likely would have necessitated a completely different architecture, and nobody has established any relationship either algorithmically or on any other level between that compiler and TCC. Additionally, and Anthropic's compiler supports x86_64 (partially), ARM, and RISC-V, whereas TCC supports x86, x86_64, and ARM. Additionally, TCC is only known to be able to boot a modified version of the Linux 2.4 kernel[1] instead of an unmodified version of Linux 6.9.
Additionally, it is extremely unlikely for a model to be able to regurgitate this many tokens of something, especially translated into another language, especially without being prompted with the starting set of tokens in order to specifically direct it to do that regurgitation.
So, whatever you want to say about the general idea that all model output is plagiarism of patterns it's already seen or something. It seems pretty clear to me that this does not fit the hyperbolic description put forward in the parent comments.
[1]: https://www.bellard.org/tcc/tccboot.html
Except it was written in a completely different language (Rust), which would have necessitated a completely different architecture, and nobody has established any relationship either algorithmically or on any other level between that compiler and TCC.
I don't understand what you could possibly be talking about. Do you care to elaborate?
I mixed it up with LCC which was used in Quake 3. Still this is pretty cool.
TCC is fantastic! Very hackable, easy to compile to WASM for some interesting in-browser compilation
I thought it only targeted x86? What's the point running in a browser?