
Clang vs. other open-source compilers - peter_d_sherman
https://clang.llvm.org/comparison.html
======
nwallin
I mean this is fine for an advertisement, but it woefully oversells clang if
you're trying to meaningfully compare these things. A lot of what they're
saying is misleading and or false.

In the early days, clang was significantly faster in compilation than GCC.
They also barely implemented any code optimization. Now that clang generates
code which is about 90% as fast, generally, as C++, its compilation speeds and
memory usage have understandably bloated considerably.

Note that I say 90% as fast generally. It still hasn't caught up completely.

Clang pioneered LTO, but GCC does it better now.

Other people have mentioned gcc's previously terrible error message and
inability to dumb ASTs.

I don't think this is up to HN standards.

~~~
mehrdadn
> Clang pioneered LTO, but GCC does it better now.

Sorry, what? VC++ already had link-time code generation by 2005. (No clue
exactly which year it was introduced though.)

~~~
steve1977
The headline is clang vs. other open-source compilers, not sure if VC++
qualifies.

~~~
compiler-guy
open64 had link-time optimization in the early 2000s. (although they called it
IPA for interprocedural analysis).

------
notaplumber
> GCC is licensed under the GPL license. Clang uses a BSD license ...

Looks like this hasn't been updated in a while. As of Clang 9.0 they migrated
everything to the Apache 2.0 license, which is not nearly as permissive as
BSD. Apache 2.0 mixes US Contract law with Copyright law, and that is
considered wholly "not permissive enough" by many, most notably OpenBSD which
is stuck on Clang 8.0.1. They also migrated the libc++/libc++abi C++ standard
libraries from MIT to Apache 2.0 as well (which was a real dick move), but
they don't care.

~~~
mhd
Interesting, I didn't know that And that after the BSDs were quite happy that
a viable non-GPL compiler arrived on the market. Wasn't their final switchover
just in 2017?

~~~
trasz
BSDs in general are quite happy, since Apache is pretty much just BSD with
patents thing sorted out. The only unhappy ones are OpenBSD folks.

------
gok
This is staggeringly out of date (it's from around 2007) and really ought to
be taken down.

~~~
mattst88
Could you provide a few examples of what information is out of date?

~~~
srott
This one is also outdated:

[https://www.phoronix.com/scan.php?page=article&item=gcc7-cla...](https://www.phoronix.com/scan.php?page=article&item=gcc7-clang4-jan&num=4)

haven't checked recently, because gcc sped up and still produces better
binaries

It can dump AST and much more: [https://godbolt.org/](https://godbolt.org/)

------
fouc
Clang takes up to 90GB of disk space [0]

[0] [https://lists.llvm.org/pipermail/llvm-
dev/2019-April/132028....](https://lists.llvm.org/pipermail/llvm-
dev/2019-April/132028.html)

~~~
endorphone
The overwhelming bulk of users are going to install a binary package, not
build from source.

LLVM 9.0 with Clang, a huge array of tools, etc, is 1.9GB on macOS.

~~~
swiley
The point of open source is that individuals from the community can read and
modify their tools. Anything that makes that harder is a bad thing, it might
be justified but it’s still bad.

------
BinaryIdiot
As far as I can tell this page first appeared in 2008. Many of these points
are outdated (some woefully so).

This shouldn't be on the frontpage of HN. If anything, Clang should take this
down or revise it.

------
bla3
As far as I know that page is many years old, from when clang was very new and
comparing to e.g. Elsa made sense. The gcc comparison is probably pretty out
of date.

------
SeekingMeaning
I mean Elsa and and PCC are cool, but who _actually uses_ them? Clang and GCC
are pretty much all there is, but regardless it’s nice to know what people
have tried/are trying to do. These bullet points in particular make me want to
tinker with PCC and see how much it is (and is not) capable of:

> The PCC source base is very small and builds quickly with just a C compiler.

> PCC doesn't support Objective-C or C++ and doesn't aim to support C++.

~~~
kick
PCC was at one time basically the standard C compiler, and you can port it to
just about any architecture you want in less than a day.

It also shipped with many historic operating systems, Plan 9 from Bell
Laboratories being one of them, if I remember correctly.

~~~
4ad
Pcc was never used in Plan 9. The Plan 9 C compilers[1][2] were written by Ken
Thompson, and later reused in the Go toolchain.

[1]
[http://doc.cat-v.org/plan_9/4th_edition/papers/compiler](http://doc.cat-v.org/plan_9/4th_edition/papers/compiler)

[2]
[http://doc.cat-v.org/plan_9/4th_edition/papers/comp](http://doc.cat-v.org/plan_9/4th_edition/papers/comp)

~~~
kick
Yeah it was, you seem to be mistaken:

[http://doc.cat-v.org/plan_9/4th_edition/papers/comp](http://doc.cat-v.org/plan_9/4th_edition/papers/comp)

 _To make it easier to share code with other systems, Plan 9 has a version of
the compiler, pcc, that provides the standard ANSI C preprocessor, headers,
and libraries with POSIX extensions. Pcc is recommended only when broad
external portability is mandated. It compiles slower, produces slower code (it
takes extra work to simulate POSIX on Plan 9), eliminates those parts of the
Plan 9 interface not related to POSIX, and illustrates the clumsiness of an
environment designed by committee. Pcc is described in more detail in APE—The
ANSI /POSIX Environment, by Howard Trickey._

I'm obviously aware that it wasn't the _main_ compiler/compiler suite for Plan
9 (of which I've submitted links to papers about quite a few times), but it
was there.

~~~
4ad
No, it wasn't. Pcc is just kencc ran through a special mode and with special
APE libraries. It has nothing to do with S. C. Johnson's pcc.

> The pcc command acts as a front end to the Plan 9 C compilers and loaders.

[http://man.cat-v.org/plan_9/1/pcc](http://man.cat-v.org/plan_9/1/pcc)

[http://doc.cat-v.org/plan_9/4th_edition/papers/ape](http://doc.cat-v.org/plan_9/4th_edition/papers/ape)

[https://github.com/0intro/plan9/blob/master/sys/src/cmd/pcc....](https://github.com/0intro/plan9/blob/master/sys/src/cmd/pcc.c)

~~~
kick
Point ceded, sorry for being difficult!

------
qeqeqeqe
This info is from 2007, the title should reflect that. This is not a useful
post.

------
peter_d_sherman
Excerpt:

" _Clang can serialize its AST out to disk and read it back into another
program, which is useful for whole program analysis._

GCC does not have this. GCC's PCH mechanism (which is just a dump of the
compiler memory image) is related, but is architecturally only able to read
the dump back into the exact same executable as the one that produced it (it
is not a structured format)."

Clang, you had me at 'hello'.

The point I outlined above is just icing on the cake!

~~~
mhh__
GCC can dump it's AST [https://stackoverflow.com/questions/15800230/how-can-i-
dump-...](https://stackoverflow.com/questions/15800230/how-can-i-dump-an-
abstract-syntax-tree-generated-by-gcc-into-a-dot-file)

~~~
Ace17
GCC can dump its internal representation at almost every stage of the
compilation process.

However, it's intended for diagnosing issues in the compilers or plugins ;
it's definitely not meant to be used as an interoperable format to be loaded
back into a program.

gcc doesn't even provide a way to specify the output path for the dump file
(too bad, as reliable AST dumping could enable implementing ast-based-ccache
(instead of preprocessed-code-based-ccache, for compilation-caching of
preprocessor-less languages)).

