clang/linux update, updated revert instructions

163 views
Skip to first unread message

Nico Weber

unread,
Jul 10, 2014, 8:06:24 PM7/10/14
to Chromium-dev, blink-dev
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.

Albert J. Wong (王重傑)

unread,
Jul 10, 2014, 8:33:22 PM7/10/14
to Nico Weber, Chromium-dev, blink-dev
Now that our toolchain is getting closer to being C++11 capable, I'll throw a caution out that we should be fairly careful about how we adopt features such as rvalue references.

Should we have a whitelist of allowed features for at least the cross-over period where we have C++11 language support, but not runtime library support?

-Albert

Alex Vakulenko

unread,
Jul 10, 2014, 8:38:09 PM7/10/14
to ajw...@chromium.org, Nico Weber, Chromium-dev, blink-dev
Wouldn't it make sense to stay consistent with the official google coding style? It still forbids using rvalue references and so should Chromium code base....


--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

Vincent Scheib

unread,
Jul 10, 2014, 10:14:48 PM7/10/14
to Nico Weber, Chromium-dev, blink-dev
On Thu, Jul 10, 2014 at 5:05 PM, Nico Weber <tha...@chromium.org> wrote:
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!)

What is a "non-host build", "host compiler"? 

Nico Weber

unread,
Jul 10, 2014, 11:02:25 PM7/10/14
to Vincent Scheib, Chromium-dev, blink-dev
On Thu, Jul 10, 2014 at 7:13 PM, Vincent Scheib <sch...@chromium.org> wrote:



On Thu, Jul 10, 2014 at 5:05 PM, Nico Weber <tha...@chromium.org> wrote:
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!)

What is a "non-host build", "host compiler"? 

Oh, sorry! If the platform you're building on isn't the same you're building for (think compiling on x86 linux, building an arm android binary), the platform you're building on is called host, and the platform you're building for is called target. Some helper binaries needed during the build need to be built for the host architecture (for example protoc, to compile protobuffer definitions, or bits of v8, to compute the snapshot containing precompiled javascript builtins). In gyp, this is expressed via the 'toolsets' attribute, see examples here: https://code.google.com/p/chromium/codesearch#search/&q=%5C'toolsets%5C'%20file:%5C.gyp&sq=package:chromium&type=cs By default, a gyp target is only built for the target platform. Targets that are built only for the host have 'toolsets': ['host'], targets that are needed for both host and target (example: the protobuf library, needed on the host to build protoc, and needed on the target so that chrome can process protobuffers) have 'toolsets': ['host', 'target']. These toolsets are only processed if host and target are different. (If you're building on linux for linux, there's no need to build them more than once, since host and target are the same.)

With "non-host builds", I mean builds where host and target are the same. The host compiler is the compiler used to compile host targets. For the four platforms where we crosscompile:
* chrome/android: By default, uses system gcc as host compiler (on precise, that's 4.6) and android ndk gcc4.8 as target compiler.
* chromeos: By default, uses system gcc as host compiler and some gcc 4.8 as target compiler
* chromium webview in the aosp build: On Mac, uses gcc 4.2 (!) as host compiler. On Linux, I think it's gcc4.6. Both uses gcc4.8 from the Android build as target compiler.
* chrome/ios: Uses Xcode clang for both host and target.

chrome/ios is in good shape. For chrome/android (and possibly chromeos), my plan is to use "our" clang as host compiler but keep the target compiler what it currently is for the foreseeable future (clang codegen for ARM isn't competitive with gcc yet). For the webview build, I think the team plans to use a relatively recent clang (but not "our"s) that's available on an opt-in level in the Android build as host compiler (and keep their current target compiler) (http://crbug.com/377684).

James Cook

unread,
Jul 11, 2014, 12:08:13 PM7/11/14
to Nico Weber, Vincent Scheib, Chromium-dev, blink-dev
Is https://code.google.com/p/chromium/wiki/LinuxBuild32On64 still correct? (I'm guessing no?)

If not, is there a simple recipe to build 32-bit Linux on gPrecise?

(Asking because 3-4 weeks ago we had a 32-bit-only breakage on the main waterfall and of the 3 people on my team who tried to set up a 32-bit build I was the only one who succeeded. And goma didn't work. That was a very slow bisect. :-)

James


--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

Nico Weber

unread,
Jul 11, 2014, 2:43:43 PM7/11/14
to James Cook, Vincent Scheib, Chromium-dev, blink-dev

The chroot steps in that page look roughly correct to me; that's what our 32bit bots do too.

Reply all
Reply to author
Forward
0 new messages