[a / b / c / d / e / f / g / gif / h / hr / k / m / o / p / r / s / t / u / v / vg / vm / vmg / vr / vrpg / vst / w / wg] [i / ic] [r9k / s4s / vip] [cm / hm / lgbt / y] [3 / aco / adv / an / bant / biz / cgl / ck / co / diy / fa / fit / gd / hc / his / int / jp / lit / mlp / mu / n / news / out / po / pol / pw / qst / sci / soc / sp / tg / toy / trv / tv / vp / vt / wsg / wsr / x / xs] [Settings] [Search] [Mobile] [Home]
Board
Settings Mobile Home
/g/ - Technology


Thread archived.
You cannot reply anymore.


[Advertise on 4chan]


File: TCCvsGCC.jpg (297 KB, 900x506)
297 KB
297 KB JPG
Benefits of TCC:
>Small compiler size
>Runs extremely fast
>Suckless

Benefits of GCC:
>More compiler optimizations
>Faster runtime
>Found on pretty much all linux distros

So /g/ros at what point do you think it's more sensible to use TCC over GCC? Personally I'd think it's better to have a program that runs faster than one that is compiled quicker. What are your opinions? Are there use cases (look the said the funny word!) in which you'd prefer TCC over GCC if your disk size is not an issue?
>>
>>108195654
Just taking your statement at face value, TCC seems to be better suited for development and GCC for actual final production code.
>>
>>108195668
If it's a project of considerable size or complexity I would be worried that some differences in the binary could cause problems. Do you think the chance for that is negligible?
>>
>>108195773
>Do you think the chance for that is negligible
NTA but no, it's not negligible. This was a common practice back in the day, people would use Borland Turbo C for development due to its snappy compile times and excellent debugger, then switch to Watcom C for release builds. There were always a few issues that came up. Watcom did produce zippy code though, it was the only C compiler that produced tight machine code comparable to that of a decent assembly programmer so it was worth it.
>>
>>108195773
this should only happen when your code doesn't conform to the standard, so catching these errors is a good thing, right?
>>
>>108195654
>what point do you think it's more sensible to use TCC over GCC?
never. what kind of retarded question is this?
>>
>>108195884
real world code is littered in compiler specific attributes.
>>
>>108195654
>n which you'd prefer TCC over GCC if your disk size is not an issue?
You've missed an important variable: Trust.

If you cannot trust the compiler, you can't trust much else downstream. GCC has earned trust over time. What you offering on TCC for that?
>>
>>108196034
>What you offering on TCC for that?
Due to its small size (35k LOC vs 15 Mil LOC for GCC) it'd be much harder to have any bugs or backdoors in TCC which are not noticed by someone.
>>
TCC is non-optimizing. So basically trash.
>>
>>108195989
sadly the standard behavior is to ignore unknown attributes.
some libs - e.g. glib - use the __cleanup__ attribute for RAII-like cleanup. It compiles with TCC but omit the cleanups and produces memory leaks.

Last time I tried, glibc headers didnt even comlile with TCC. So there goes the most popular libc implelemtation. What a shame.
>>
>>108195654
>Small compiler size
Who cares?
>Runs extremely fast
Yeah, but the compiled code is like times slower
>Suckless
It's not an advantage.
>>
>>108198063
>Who cares?
Why have a bigger compiler when you can have a smaller one with barely any drawbacks? If tcc was perfect I'd ditch gcc easily
>Yeah, but the compiled code is like times slower
I know but I wonder by how much. I heard it runs three times slower but if it's a program that's very fast anyway or I barely run it'd still make sense if the compilation took a long time
>It's not an advantage.
No nobility in sucking
>>
TCC is just a throwaway dependency for building GCC
Not used for much else
>>
>>108198123
What about code quality? I mean TCC is a very small compiler and yet the code quality kinda suck, it's a fucking mess. I tried to add modifier to it once and I failed, it's not a clean an organized code base.

>>108198123
In general, suckless sucks more.
>>
>>108198361
>What about code quality?
If I was able to judge that I wouldn't need to ask you guys on when to use tcc
>In general, suckless sucks more.
Only if low LOC becomes a goal onto itself. I think the reduction of scope and LOC is in general a good metric.
>>
>>108195654
I really love tcc and have contributed to it a couple of times. I assume you're using a recent mob version, if not then you should check it out as it's been developed heavily since Bellard's last release. It's really nice having a compiler that's as fast as this, and also simple enough that you can realistically make changes to it.
The codebase is unfortunately quite messy and if I remember correctly the mailing list isn't very keen on attempts to clean it up (renaming single-letter variables, removing globals, even applying consistent code formatting basics like tabs vs spaces all seem to be off limits.
>>
File: 1676316942545183.png (6 KB, 208x242)
6 KB
6 KB PNG
TCC can't even do TCO.
>>
>>108195654
a compiler no one uses vs a compiler everyone uses. is it even a choice? TCC is the tinker tranny choice.
>>
>>108198123
>Why have a bigger compiler when you can have a smaller one with barely any drawbacks?
Shit generated code is not a small drawback. It's a big one.
>If tcc was perfect I'd ditch gcc easily
Wow really? You'd rather use something perfect, rather something flawed? What a novel idea.
>>
File: ballman-from-intel.jpg (260 KB, 1202x1020)
260 KB
260 KB JPG
>>108196034

hehehe, i saw no reply from Gnusoids about some C features pushed into compiler, the defer runtime feature, whos co-author is a glowie, some ballman surname from Intel

this was on reddit and my comment was simply deleted in those C_programming groups

since then i assume anyone who use GCC injects some trojans into their binaries. thats yer trust over time.
>>
>>108198648
>The codebase is unfortunately quite messy and if I remember correctly the mailing list isn't very keen on attempts to clean it up (renaming single-letter variables, removing globals, even applying consistent code formatting basics like tabs vs spaces all seem to be off limits.
The more I read about suckless software the more it sounds like it sucks cock. Globals sound fine though.
>>
>>108195654
>muh compilation speed
Use incremental compilation
>>
>>108198940
>The more I read about suckless software the more it sounds like it sucks cock.
It's not made by the suckless team, it just follows the philosophy to a degree and gets a shoutout on the page among other c compilers.
>>
>>108198940
>Globals sound fine though.
For some things I agree. In games they make sense.
tcc is supposed to be embedded as a library (libtcc). The use of globals really disrupts library use... you can't always destroy a libtcc instance cleanly and it's not reentrant.
>>
>>108195654
tcc is great: use it for my .C programs now. I like how it doesn't bitch when I refuse to put "int" before "main()". Hey, none of the examples in my K&R book use int and those two made C!

One correction: gcc used to mean "GNU C Compiler" but now means "GNU Compiler Collection" because it has several languages, including C, C++, Objective C & C++ and Fortran, whereas tcc is *just* a C compiler, so they cannot be compared 100%.

Has anyone used tcc to compile a large (not minimal) kernel? Did it behave correctly like one compiled with gcc? I am afraid to try. :p
>>
i just use clang. fuck gnuslop.
>>
>>108198939
clang is going the same way but it is able to produce really packed/small binaries and disable some retarded "features" mostly on a link stage

tcc is not as refined and sophisticated in linking, i didnt see where to set section padding, it seem to insert 4KB pads, though i want 16 bytes or alike in clang

so TCC or CLANG. GNU-tards BTFO
>>
>>108198982
>but now means "GNU Compiler Collection" because it has several languages, including C, C++, Objective C & C++ and Fortran,
Well that explains the size difference at least.
>>
>suckless
reddit buzzword

TCC is a literal toy compiler btw, but just use clang, clang is faster and actually has a modern clean codebase
>>
>>108195654
Can TCC generate arm-none-eabi code? I could switch if it does reliably
>>
>>108200040
>Can TCC generate arm-none-eabi code?
I believe it is somewhat restricted when it comes to possible target platforms
>>
>>108199012
>>108198939
lol he mad
>>
>>108195654
>>108196102
>35k LOC
bloat. you only need 512 bytes. https://xorvoid.com/sectorc.html
>>
for me it's chibicc
>>
>>108195654
Is TCC even still maintained? I thought Bellard stopped developing it. Still, clang and GCC are good enough for me
>>
>>108204465
yes but not on bellard's website. arm and riscv backends ware added and such. but it's really stale
>>
>>108198982
It could work for bootstrapping a kernel large enough to bring about a competent enough environment for building a full Linux kernel.
By making use of tools similar to kexec, you can just reboot straight into a new kernel, with no friction from the bootloader or BIOS, even when you're at a stage without disk drivers.
>>
>>108204465
https://repo.or.cz/tinycc.git
Trolls from here keep adding "nigger" and "fourthreich" and shit to the content tags
>>
>>108205004
lookup tccboot
>>
>>108205086
>Trolls from here keep adding "nigger" and "fourthreich" and shit to the content tags
If /g/ is against it I must be on the right track
>>
>>108196034
I've had even recent versions of gcc segfault from code I've written. Maybe for C it's fine but there are zero good C++ compilers.
>>
>>108198573
90% of the legitimate suckless complaints is just gnome/systemd/redhat. Most of the other stuff is actually fine/better and gets caught in the crossfire.



[Advertise on 4chan]

Delete Post: [File Only] Style:
[Disable Mobile View / Use Desktop Site]

[Enable Mobile View / Use Mobile Site]

All trademarks and copyrights on this page are owned by their respective parties. Images uploaded are the responsibility of the Poster. Comments are owned by the Poster.