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