Re: [dev] GCC situation

From: Markus Wichmann <nullplan_AT_gmx.net>
Date: Mon, 24 Nov 2014 06:35:51 +0100

On Sun, Nov 23, 2014 at 10:20:44PM +0000, Henrique Lengler wrote:
> Hi,
>
> What is the situation of GCC, is it bloated?

Holy shit, yes! Ever tried to compile it?

And in the end, GCC has a lot of optimizers that make pedantic
asumptions about the code they compile. For instance, if i is of signed
integer type, i + 1 can never be smaller than i. Yeah, right. Nevermind
that this asumption removes most overflow checking code.

I know that this case is undefined or implementation-defined or
something, but... well, the problem is, most code out there is not
strictly conforming to the C standard. For instance, did you know that
converting a floating point value into an integer type where the integer
part can not be represented causes undefined behavior? I didn't until
recently. So converting an FP value that might be negative to an
unsigned type is undefined, but converting an FP value that is definitly
in range to a signed integer type and that to an unsigned integer type
is completely defined. What?

u = fp;

is undefined, but

u = (int)fp;

is not?

> I'm asking because I don't find too much on suckless site about it
> I don't have experience in any other compiler.
>

Well, there's always clang. It's completely written in C++, but is way
better organized than GCC and it is contained entirely in a lib, so it
can be easily integrated into IDEs and other programs. If you need a C
parser, have a look at libclang.

> I also found someday TCC (Tiny C compiler - bellard.org/tcc/)
> And it looks cool.
>

Yeah, but good luck compiling anything with it that requires GCC
extensions.

See, GCC is bloated, but there is also a reason for that: It is written
to be as commonly usable as possible. Why do you think you need (at last
count) three different multi-precision libraries to compile GCC? Because
in the general case you cannot assume that the native types will be big
enough to hold all the values of the target types.

> The site shows the speed of it:
> Compiler Time(s) lines/second MBytes/second
> TinyCC 0.9.22 2.27 859000 29.6
> GCC 3.2 -O0 20.0 98000 3.4
>
> What they don't talk about is the speed of execution, wich I think
> is faster with gcc. But if I were create a suckless gcc I would
> probably fork TCC.
>
> So what do you think, GCC is ok? Or no?
>

Oh, heavens, no! But it is a necessary evil. IIRC the linux kernel can
only partially be compiled with clang (and tinycc doesn't stand a lick
of a chance), so there is a necessity for gcc.

Regarding execution time: Yes, with GCC that will be much better than
with tinycc, because the former has way more and way more aggressive
optimizers.

By now, the only thing that really bugs me is that GCC's optimizers make
code undebuggable. Or is that GDB's fault.

> Regards,

Ciao,
Markus
Received on Mon Nov 24 2014 - 06:35:51 CET