Re: Alternative C compilers on x86_64 Linux?

Hi,


On Tuesday, September 27, 2016 at 1:36:38 PM UTC-5, Aharon Robbins wrote:
>
> In article 16-09-033, <rugxulo@hates.spam> wrote:
> >
> >On Sunday, September 4, 2016 at 2:02:33 PM UTC-5, Aharon Robbins wrote:
> >>
> >> Can I get recommendations for other (free) C compilers besides
> >> GCC and CLANG?
> >>
> >> In short, I'm looking for a faster compiler that actually works.


... that runs on (and targets?) Linux/AMD64 with ELF, C99/POSIX,
widechar/Unicode, etc.


There are a lot of other compilers (and OSes), but they can't all
support literally everything.


> >I'm not sure what miracle advice you expected to get from here.
>
> I develop locally. My system is Ubuntu 16.04 with gcc 5.4 on a
> Skylake Core i5. /proc/cpuinfo claims 4 CPUs, so there are likely
> two hyperthreaded physical cores and there's plenty of RAM.
> The machine is quite fast, even though it's using a conventional
> disk.


Four cpus is still good, better than average. (But even my old
Westmere has that. So where's our "thousands of cores", Intel??
They sure do overhype SMP on every street corner! Humbug!)


And Skylake is very new. (I can't even pretend to remember all
the supported instruction sets.)


Honestly, I'd have been almost surprised if someone like you didn't
already use a "modern" (ugh) setup like this.


I'm not really familiar with tmpfs, but you can presumably use it
to speed some things up.


There was a small regression in GCC 5.x, so I think 6.x is indeed
slightly faster, but it's probably not quite the speedup you wanted.


> I often have to go through this cycle:
>
> make distclean
> ./bootstrap.sh # set modification times on some files
> ./configure && make && make check
>
> For example, when merging into the (too-many) different branches
> and encountering a conflict.


The bottleneck could really be something simple like the makefile
itself, but I realize that rewriting or replacing that isn't usually
easy.


> The time difference between using tcc on the one hand and GCC + make
> -j on the other is quite noticeable; tcc + make -j is even faster.
> Doing many builds an hour can happen, and a faster compiler saves me time.
> tcc also makes a VERY noticeable difference in the time it takes
> to run configure.


I hate all that configure stuff (as I'm not really *nix savvy), but
can't you make a site-wide cache of certain things (that you know
will absolutely never change)?


http://www.gnu.org/software/automake/manual/html_node/config_002esite.html


> When I posted, tcc wasn't an option since it didn't check for duplicate
> case labels, and PCC had stopped working for me. So I was seeking an
> additional, fast compiler.


Regarding PCC, you act like it just started to break. How exactly?
This is why you never upgrade anything unless forced! :-)
So just stick with (stable) older version there (or is that
Debian or Ubuntu's fault?).


TCC hasn't had a release in recent years either. It's fast because
it does everything in one pass, and it does include it's own
assembler and linker. It doesn't optimize well, though.


I guess you know that GCC has slowed down tremendously since the
old days (2.7.x vs. 2.95.x vs. 3.x). Of course, using Skylake,
you shouldn't have any excuse (except binaries compiled for weaker
targets). It may not be reasonable, but you really should give
ClearLinux a shot.


> Dorking with the Makefile to only use -O on certain files isn't really
> an option; autotools sets things up to compile everything the same way
> and for the shipped tarball that is the right option.


If you're going to let AutoTools (or anything else) dictate everything
for you, then you're going to have to live with slow compiles.


> Similarly, I don't really wish to switch off the autotools; I've too
> much time and experience invested in them. They work, crufty as they are,
> and I have not had to invest any real time in keeping things up to date
> with respect to them.


Great, but if that's your bottleneck, then you'll have to fix it.


> Since I originally posted, someone suggested that I just fix tcc on
> my own. I was able to do this with less than 2 hours work so now
> I'm back to being fat, dumb and happy. :-)


There's always room for improvement (overall).

Return to the comp.compilers page.
Search the comp.compilers archives again.