The 3 big ones, Linux, GCC and Git require a human to vouch/explain the work in question.

Once the 3 big ones start using LLM to review/accept the work for speed reliability sake, who knows what is going to happen.

▲

lumost 10 hours ago | parent | next [-]

If you are asking a human to review something, it should have been verified/reviewed by a human first.

I have no interest reading someone else’s ai output that has not been verified.

	▲	noir_lord 10 hours ago \| parent [-]
		Agreedm Modifying Hitchen's Maxim - "That which can be asserted without thought and be dismissed without thought". Or to put it another way, expecting me to review code you didn't and had an LLM generate is pushing the onus onto me and that's not happening.

▲

rurban 9 hours ago | parent | prev [-]

Already happened. My AI coded C compiler already bypassed gcc in less failures, compiles 10x faster, and with their new policy they'll fall far behind.

▲

tavavex 8 hours ago | parent | next [-]

Does your compiler replicate 100% of gcc's functionality? I've heard of similar compiler projects skimping on the lesser used functions and taking shortcuts. gcc is BIG.

But the real point is even if we get an ability to AI generate an accurate and fully-featured C compiler from scratch, everyone will keep using gcc. C compilers are solved, gcc is already here and it's pretty amazing. It's not flawed or in need of replacement, there's nothing for it to fall far behind on. We don't need another C compiler, the reason why AI users are attracted to the topic is just to "look ma, no hands!". And using gcc also ensures that I'm using something that has been looked at by thousands of qualified eyes in the past and will be looked at by thousands more for the foreseeable future. Will an AI compiler be comprehensible in ten years? Will every update be guaranteed to be better than the previous?

▲

rurban 8 hours ago | parent [-]

Of course not. I don't care for gcc's broken optimizer to remove dead code without any warning.

gcc has too many bugs for my taste, sorry. And I don't want to wait 20m on gcc compilation, when tcc can do it in 1m.

▲

tavavex 7 hours ago | parent [-]

If you're just declaring gcc broken and removing its functionality, then why compare yourself to it? For any of the metrics you're using to hold water, you want the project to actually be comparable to gcc in terms of features, otherwise you could just remove half of their features and declare yourself as more efficient because half of gcc would compile faster than gcc.

And why are you talking about the optimizer? What I'm curious about is whether this compiler will successfully compile any project that can be compiled with gcc. Will it?

In addition to build time comparisons not meaning anything if the projects aren't equivalent, I also just don't get why it's so important. Most people don't spend their days recompiling gcc, they just want it to compile their projects quickly and accurately.

	▲	rurban 7 hours ago \| parent \| next [-]
		It compiles the kernel and my big projects, but I haven't released it yet. Feature wise I don't do bitint, decimal and FloatX. No auto-vectorization, but better than most simd/neon projects, which don't use __attribute__((vector_size(N))). Manual vectorization. no sanitizers nor flto. rcc is for the people who want to compile their projects sanily, and fast. And who want to find unicode attacks. And for those who run into tcc bugs, there are many still. gcc and clang are insanily slow.
	▲	cozzyd 7 hours ago \| parent \| prev [-]
		C compilers are already so fast... Now a fast C++ or rust compiler would be useful.

▲

Cthulhu_ 9 hours ago | parent | prev | next [-]

A bold claim with no sources to back it up.

▲

rurban 9 hours ago | parent [-]

[flagged]

▲

encyclopedism 6 hours ago | parent | next [-]

I couldn't find the prompts you used. They are the source code now so would be interesting to view them.

	▲	rurban 6 hours ago \| parent [-]
		No way. No open prompts. But I use omp /collab, so I prompt it from my phone. Constantly

▲

antoinealb 8 hours ago | parent | prev [-]

From the README of that repo, rcc seems to only compile ~2x as fast as GCC. You claim 10x. Where is the proof ?

▲

ethin 8 hours ago | parent | prev [-]

Prove it and that your compiler is fully C compliant and can handle all possible inputs GCC can accept (and optimize as well as GCC), then we'll talk. Only then will your compiler risk leaving GCC behind.

▲

rurban 8 hours ago | parent [-]

The proof is gcc's torture test suite. Have a look

▲

ethin 7 hours ago | parent [-]

I did also say optimize as well as. As in: your compiler needs to be genuinely better than GCC to compete with it. Good Windows support is a start, but you have yet to reach architecture equality of what GCC provides (which is fair I suppose) and you shell out to GCC for linking (which is pretty funny given that you claim GCC is being left behind...). Although "being left behind" is so nebulous as to be meaningless. For example does your compiler autovectorize? It doesn't look at a glance like it supports OpenMP or OpenACC either.

	▲	rurban 6 hours ago \| parent [-]
		No openmp, no openacc, though that would all be trivial. For linking, my own linker still has a lot of regressions, but is at least 10x faster than shelling out to gcc/ld. Similar to tcc. No linker scripts, no LTO via the native linker. rcc can easily fallback to the gcc linker for such features. Auto vectorization would need extensive -O3 opts, which I dont do yet. No ssa, no escape analysis. The compiler should stay fast. And I prefer manual vectorization via attributes. Still better than using the insane and platform dependent SSE/neon apis, everyone else is using. See the torture/vect/ tests. They all pass