800471 - Consider compiling with Clang by default on Linux (but keep building with GCC in TBPL running smoketests)

Status: RESOLVED DUPLICATE of bug 1480631

(Firefox Build System :: Toolchains, defect)

Description

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Since we compile with Clang by default on Macs and there are versions of Clang in the tree, let's consider compiling with Clang by default on Linux.

We will then only have 2 compilers (MSVC & Clang) instead of 3 (MSVC, GCC & Clang).

Also, we are considering removing Linux PGO builds too as per the thread below.

Ref thread on mozilla.dev.platform:

https://groups.google.com/forum/?fromgroups=#!topic/mozilla.dev.platform/hud9aK0qZWI

Comment 1

[(not currently active) Ted Mielczarek]

I don't particularly care what compiler we build our Linux builds with, but there's no way we can deprecate GCC support anytime soon. There are just too many people out there using it, so we're going to have to keep our code building on GCC anyway (note that we don't currently have the option to use clang for our Android builds).

Comment 2

[Rafael Ávila de Espíndola (:espindola) (not reading bugmail)]

Attachment: talos comparison of clang and gcc 4.5

Comment 3

[Rafael Ávila de Espíndola (:espindola) (not reading bugmail)]

Clang does support android, but I have not tried building firefox on it. In any case, the suggestion is not drop support for building with gcc, it is just to do our builds with clang.

We could still do a smoke build/test with gcc, but would not put developer time in handling gcc problems. Upgrading the minimum required gcc would also become trivial.

Comment 4

[Mike Hommey [:glandium]]

(In reply to Rafael Ávila de Espíndola (:espindola) from comment #2)
> Created attachment 670493 [details]
> talos comparison of clang and gcc 4.5

What is compared to what in that data dump? gcc+pgo on the left and clang on the right? if so, then building with clang would actually be a win...

Comment 5

[Rafael Ávila de Espíndola (:espindola) (not reading bugmail)]

> What is compared to what in that data dump? gcc+pgo on the left and clang on
> the right? if so, then building with clang would actually be a win...

no, it is gcc without pgo and clang. To be exact, the 64 bit build is using

browser/config/mozconfigs/linux64/nightly

and the 32 bit one is using

browser/config/mozconfigs/linux32/nightly.

Comment 6

[Alex Vincent [:WeirdAl]]

FYI, Fedora 17 currently doesn't support clang all that well...
http://ask.fedoraproject.org/question/2193/clang-not-working-in-fedora-17

Comment 7

[Gregory Szorc [:gps]]

(In reply to Alex Vincent [:WeirdAl] from comment #6)
> FYI, Fedora 17 currently doesn't support clang all that well...
> http://ask.fedoraproject.org/question/2193/clang-not-working-in-fedora-17

There is talk about exposing Mozilla's Clang binaries on a public server. If we build things properly, we should be able to provide a self-contained package that works on any Linux distro. This should help overcome "distro X doesn't have a good Clang" concerns. Also, we have a script in the tree that builds Clang from source. It is currently tightly coupled with buildbot, but that could change.

We also have a system bootstrapping framework in the tree now (python/mozboot/). On OS X it already installs a new enough Clang if your Xcode doesn't provide one. We can add similar support for Linux distros (the tool already supports many popular Linux distros for toolchain and required dependencies installation).

Anyway, I wouldn't be concerned about "Clang isn't provided on a distro:" that's a solvable problem. We should be concerned with de-supporting/prioritizing GCC and the inevitable issues this will cause.

Comment 8

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

(In reply to Rafael Ávila de Espíndola (:espindola) from comment #3)
> Clang does support android, but I have not tried building firefox on it. In
> any case, the suggestion is not drop support for building with gcc, it is
> just to do our builds with clang.

Perhaps my comment 0 wasn't clear enough, I wasn't advocating dropping GCC altogether, I was proposing to compile with Clang on Linux by default instead.

GCC builds can still continue to happen on tbpl running smoketests or something light.

Comment 9

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

In other words, I'm agreeing with Rafael in comment 3.

Comment 10

[Rafael Ávila de Espíndola (:espindola) (not reading bugmail)]

Attachment: talos comparison of gcc 4.5+pgo and clang

With pgo gcc produces better results is most tests (quiet a bit better in tsvgr_opacity). It is only worse in dromaeo_dom, num_ctors and tp5n_main_rss_paint (64 bits).

I noticed the gcc build is using -O3 and the clang one is using -Os. I might try a clang -O3 too.

Comment 11

[Trevor Saunders (:tbsaunde)]

(In reply to Rafael Ávila de Espíndola (:espindola) from comment #10)
> Created attachment 670790 [details]
> talos comparison of gcc 4.5+pgo  and clang
> 
> With pgo gcc produces better results is most tests (quiet a bit better in
> tsvgr_opacity). It is only worse in dromaeo_dom, num_ctors and
> tp5n_main_rss_paint (64 bits).
> 
> I noticed the gcc build is using -O3 and the clang one is using -Os. I might
> try a clang -O3 too.
I don't mean to add work to anyones plate, but this makes me wonder how more recent gcc compares to both gcc 4.5 and clang.

Comment 12

[John Schoenick [:johns]]

Another thing to investigate might be how clang LTO builds compare - I was able to get a working LTO build on a recent clang trunk with

> export MOZ_NATIVE_FFI=1
> ac_add_options --disable-crashreporter
> export LDFLAGS="$LDFLAGS -O4 -plugin /usr/lib/LLVMgold.so"
> export CFLAGS="$CFLAGS -O4"
> export CXXFLAGS="$CXXFLAGS -O4"

(You also need the gold linker instead of traditional ld)