Fwd: [blink-dev] linux currently uses clang by default (+ revert instructions)

[Paweł Hajdan, Jr.]

FYI, I ran into this with 38.0.2096.0.

Please consider commenting on https://groups.google.com/a/chromium.org/d/msg/chromium-dev/6OwjiZXGTVs/W_VURycXuREJ

Paweł

---------- Forwarded message ----------
From: Nico Weber <tha...@chromium.org>
Date: Thu, Jul 10, 2014 at 7:20 AM
Subject: [blink-dev] linux currently uses clang by default (+ revert instructions)
To: Chromium-dev <chromi...@chromium.org>, blink-dev <blin...@chromium.org>

Hi,

r282246 switched OS=linux builds (i.e. desktop chrome/linux, and desktop chrome/linux with chromeos=1, but NOT chrome/android or "real" chrome/chromeos builds) to use clang as its compiler by default. You can explicitly set clang=0 in your gyp defines if you don't want this. For now, this is very likely temporary to collect some performance data and to find problems, but it'll very likely be permanent at some point. I'll have more to say about the switch when that happens.

For now: The waterfall looks decent as far as I can tell. r282261 contains updated sizes expectations and updates shared library expectations for Google Chrome Linux, so that and the two Linux clobber bots will hopefully cycle green. The memory.fyi waterfall cycles slowly, so I don't know about the state of that yet.

If you see something that's broken, please leave a comment on http://crbug.com/360311 If you must, the change is safe to revert (you need to revert r282261 too, to update expectations). But if just a handful tests fail on just 32bit bots, consider just leaving a comment on the bug and leave me some time to look thursday morning.

Thanks,

Nico

[Paweł Hajdan, Jr.]

Related one, original thread https://groups.google.com/a/chromium.org/d/msg/chromium-dev/2RzwrIxnvqM/-o1V7fdTArcJ

As of 38.0.2101.0 it doesn't compile with gcc-4.7 out of the box (and does compile successfully with gcc-4.8). I'm sure it can be made to work with some patches. See https://codereview.chromium.org/385743002 for more info.

Paweł

---------- Forwarded message ----------
From: Nico Weber <tha...@chromium.org>
Date: Fri, Jul 11, 2014 at 2:05 AM
Subject: [blink-dev] clang/linux update, updated revert instructions
To: Chromium-dev <chromi...@chromium.org>, blink-dev <blin...@chromium.org>

Hi,

things are looking pretty good after turning on clang by default on linux yesterday [1]. There's a few minor issues, most of them marked as blockers of http://crbug.com/360311 , but overall it looks pretty good. The perf impact of the change is visible here: https://chromeperf.appspot.com/group_report?rev=282246 Some things got slower, but some things (typical_25, top_10, startup.cold.blank_page) are faster too, and the binary are smaller.

So I'd like to keep this in the tree for now, ship a dev channel with it, and see how that goes.

I'm away for the next few days, returning Wednesday. If something comes up that doesn't work, I've prepared a revert here: https://codereview.chromium.org/383913004/ Just fill in a good reason, and hit cq.

Going forward, I'm hoping that we can require either gcc4.8+ or clang as compiler. For non-host builds, the chromium bots currently meet this requirement. This would allow us to use C++11 language features soon-ish (assuming the change sticks) – but still no library features for now, and host compilers still aren't quite there yet. (But most targets aren't build for the host.) (Since it's still possible that this change will be reverted, do not add any C++11 code yet!)

Nico

ps: The clang binary is 64-bit only. Since linking in 4GB is already challenging, I'm hoping that's ok for everyone. All the chromium 32bit bots have 64bit kernels and a 32bit userland. If you can't run 64bit binaries, you can run ``tools/clang/update.sh —force-local-build --gcc-toolchain ~/path/to-gcc-4.7-or-newer` to build a local 32bit binary, but you'll need a gcc 4.7+ to compile clang. (If your regular system gcc is new enough, you don't need the --gcc-toolchain flag.) If there's demand for this, we can change the update.sh script to do something more friendly for folks with a 32bit kernel. I'd prefer not to, though.

1: https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/6OwjiZXGTVs

[Saikrishna Arcot]

Is there a required version of clang that has to be used? Clang 3.0 (the default clang in Ubuntu Precise) seems to implement most of the C++11 standard.

--
You received this message because you are subscribed to the Google Groups "chromium-packagers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-packag...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-packagers/CAATLsPb1FYDjqh%3D_e3wOK3WnEPfWRe6OAeSAhCnHueOv1gH-%2Bg%40mail.gmail.com.

--

Saikrishna Arcot

[Paweł Hajdan, Jr.]

Nico, could you help answer this?

Thanks

Paweł

[Nico Weber]

On Tue, Jul 29, 2014 at 5:04 AM, Paweł Hajdan, Jr. <phajd...@chromium.org> wrote:

Nico, could you help answer this?

Thanks

Paweł

On Wed, Jul 23, 2014 at 3:21 PM, Saikrishna Arcot <saiar...@gmail.com> wrote:

Is there a required version of clang that has to be used? Clang 3.0 (the default clang in Ubuntu Precise) seems to implement most of the C++11 standard.

Yes, we bundle a version of clang with chromium and require that to be used. It should be downloaded and used automatically as part of the build.

[Paweł Hajdan, Jr.]

On Tue, Jul 29, 2014 at 5:39 PM, Nico Weber <tha...@chromium.org> wrote:

Yes, we bundle a version of clang with chromium and require that to be used. It should be downloaded and used automatically as part of the build.

Thanks. Note that Linux distros avoid using bundled software, especially binary-only one.

Does chromium clang have custom patches, even only occasionally? Is there a policy to avoid that, and land patches in clang upstream first?

I've noticed https://code.google.com/p/chromium/wiki/UpdatingClang and one test-only patch in src/tools/clang/scripts/update.sh

Looks like we should be OK wrt custom patches, but if Chromium requires very recent clang I'm not sure if distros will be able to keep up (well, one solution could be to create a separate clang package just for chromium). I know this is not an important factor for Chromium, and I'm fine with that. This is mostly an attempt to answer Saikrishna's question.

Paweł

[Nico Weber]

Jakob: Can you file a bug with that list?

With that, and with kbr's gdb perf issue from a few days ago, it sounds like we need to disable fission for a now :-/

On Tue, Jul 29, 2014 at 9:12 AM, Paweł Hajdan, Jr. <phajd...@chromium.org> wrote:

On Tue, Jul 29, 2014 at 5:39 PM, Nico Weber <tha...@chromium.org> wrote:

Yes, we bundle a version of clang with chromium and require that to be used. It should be downloaded and used automatically as part of the build.

Thanks. Note that Linux distros avoid using bundled software, especially binary-only one.

They can pass --force-local-build to tools/clang/scripts/update.sh, then the script will build a clang binary that's identical to the one we bundle. (Not binary-identical due to the llvm build embedding timestamps etc, but behaviorally identical.)

 

Does chromium clang have custom patches, even only occasionally?

Of the 82 binaries we've pushed so far ( http://commondatastorage.googleapis.com/chromium-browser-clang/index.html?path=Linux_x64/ ), one had a few minor patches. That one case was an exception since we hadn't had updated clang in a long time and lots of folks were waiting for a new version, but clang head had other blocking bugs. Even then, the local diff in that case were just merges of newer clang revisions.

The more recent zip files (newer than 2 years?) all contain a "buildlog.txt" that contains the output of `svn diff`. (One llvm test file is patched locally as that test doesn't pass with the configure options we use, but that doesn't affect the compiled, err, compiler.)

 

Is there a policy to avoid that, and land patches in clang upstream first?

Yes.