C++11 update

[Nico Weber]

Hi,

(if you don't care about C++11, you can stop reading now.)

most of our linux bots are on precise now, which was what we believed is what we need for switching to C++11. I looked at this a bit, here's a status update.

Summary:

How do we want to proceed with C++11 support in Chromium?

Enabling C++11 support in our toolchain still requires significant work in order to support all platforms. The toolchain is also less mature and waiting may give us more options to resolve certain quirks (namely by selective disabling C++11 warnings that are limited use).

There are 3 possible paths forward:

1. Full speed ahead, with gcc 4.6! Work around issues and and turn on C++11 ASAP.

2. Wait for gcc 4.8.  Allows selective disabling of C+111 warnings.

3. Drop gcc support, require clang. Also allows selective disabling of some C++11 warnings.

We will eventually have to enable C++11. The question is how much do we want the new features, and when do we put the effort into it making things work.

Comments? Opinions? Flames? Please respond to this thread.

Lovingly yours with cinnamon, sugar, and a cherry on top,

Nico (with copy editing help from Albert)

=== Very detailed discussion of current status below. ===

Background: What is C++11?

C++11 is the current revision of the C++ language standard. Enabling it in a code base requires

1. Compiler support for new language features (eg., auto, rvalue references, etc)

2. Updated Standard Library to support new features and language strictness.

There were a few threads about C++11 on chromium-dev [1]. The conclusion was that we’d want to wait until all our linux bots are on Ubuntu Precise, which ships with gcc 4.6. This has happened by now, so it’s time to look at things again.

How many Compilers and Standard Libraries do we really have?

Compilers

• windows: msvs2010, msvs2012

• mac: clang

• linux: gcc4.6, clang

• chromeos: gcc4.6 (?)

• android: gcc4.6, clang

• iOS: Xcode’s clang

Standard Libraries:

• windows: msvs2010, msvs2012

• mac: libstdc++ 4.2 (with clang)

• linux: libstdc++4.6 (with both gcc4.6 and clang)

• chromeos: libstdc++ 4.6 (?)

• android: stlport

• iOS: libc++ (?)

You’re kidding right?

no.

Standard Library support

Though most compilers by now support at least some C++11 features, several of the standard libraries do not.

• Mac: libc++ is not available on OS X 10.6. We are stuck with libstdc++ 4.2 which does not have C++11 features.

• Android: stlport does not have C++11 features. Slow progress is being made towards porting libc++ to android, but there is no timeframe.

Compiler support: MSVS

MSVS’s compiler just builds “C++” and support for newer language features is added over releases.

Both msvs 2010 and msvs2012 have support for basic C++11 language features.

Compiler support: Clang

All clang builds current enable C++11 support is enabled via the --std=gnu++11 flag (which is c++11 plus gnu extensions).

Clang is special because we update it more frequently. We track clang trunk and update our clang binary every ~2 weeks. All platforms except iOS use the same revision. This lets us deploy toolchain fixes much faster than we can with other compilers.  

Clang is used for the production build on Mac; on other platforms it is only used by developers.

Compiler support: Gcc

Gcc also enables C++11 support via the --std flag.  However, currently, we do NOT enable it.

Enabling --std=gnu++11 on gcc currently has a 4 large adverse effects.

1. Compile time slows down ~20%

2. A few cases where C++11-incompatibility with C++98 bite us

3. Toolchain immaturity seems to be a larger issue

4. Still gaining experience with C++11 apps

--Compile time slows down ~20% [2]--

This is mostly caused by the standard library including more files increasing parsing time in C++11 mode.

Clang suffers from this problem as well on platforms with libstdc++ >= 4.6 and libc++.

MSVS2012 also is slower than MSVS2010 for this reason.

There is not much we can do about this.

--We hit a few cases where C++11-incompatibility with C++98 bytes us.--

In particular, these two issues cause problems:

• Narrowing conversions

• User defined literals.

Details below.

Narrowing conversions:

The following lines are errors in C++11 but valid in C++98:

const char kData[] = { 0x05, 0xff, 0xa3 };

struct CGPoint { float x, y; } p;

struct Point { int x, y; } pi = { p.x, p.y };

Details here: http://www.stroustrup.com/C++11FAQ.html#narrowing

While this looks like a useful feature, in practice it has very little impact. In Chromium 5/5 flagged issues were false positives.

MSVS likely won’t enable this warning for a while to preserve backwards compatibility. Clang can selectively disable this warning. However gcc 4.6, and 4.7 treat this as a hard error; it is only a disableable warning as of gcc 4.8.

Fixing errors of this type can be annoying too. For example, CLD has a 700-line initializer, and gcc prints the diagnostic at the initializer's closing '}'.

If we enable C++11 while still using gcc-4.6, we will need to change a bunch of code to be less readable in order to avoid the error.

User-defined literals

C++11 allows you to write some code to have literals that look like `43_chromium`. You can then code what the literal means.

This sadly conflicts with C99’s inttypes.h header, which is offers predefined macros for portable printing of types like size_t:

 printf("xyz: %"PRIuS, size);  // PRIuS is from inttypes.h

In C++11, “xyz: %”PRIuS is now a user-defined literal. “xyz: %” is the literal and PRIuS the UD-suffix.

This is most notably used in NaCl.  The fix is to insert a space as follows:

 printf("xyz: %" PRIuS, size);  // PRIuS is from inttypes.h

Similar to Narrowing Conversions, MSVS likely won’t support this for a whille, clang allows you to disable it.

In gcc 4.6, this feature is not supported so it is not a problem. However, in gcc-4.7 it becomes a hard error, and in gcc 4.8 it gets degraded back to a disableable warning.

If we turn on C++11 with gcc 4.6, our code will break in gcc 4.7 and we will have to make a bunch of code less readable.

-- The toolchain is immature--

gcc 4.6.0 was released March 25, 2011. C++11 was approved 12 August 2011. The C++11 standard is newer than gcc 4.6, and some things are just buggy.

Example: The compiler-generated move constructor for bitfield enums is not valid, and gcc prints a hard to understand compile-time error about code it itself generated internally (http://pastie.org/8125050).

This happens in angle_dx11.  This is again resolved in gcc4.8.

If we turn on C++11 prior to gcc-4.8, we’ll have to change (small amounts of) code to work around toolchain issues.

-- There’s not a lot of experience with C++11 apps--

gcc 4.7.0 and gcc 4.7.1 contained a (mostly accidental) ABI change that made it impossible for so libraries built in C++11 mode to function with other so libraries built in C++98 mode:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49561

System libraries on Linux are usually built in C++98, so if we move Chromium to C++11 we have to make sure to never ship a binary that was built with gcc 4.7.0 or gcc 4.7.1. There might be other issues like this.

I don’t think this is an issue on Android, since that loads no system so libs written in C++ into your app (?).

I’m unsure about ChromeOS. If there are problems, we could in theory make sure the whole system is built in C++11 mode, but that might require some effort to do.

Conclusion

*sigh*

Footnotes

[1]

Apr 23, 2012 "what are the blockers for starting to use C++11" https://groups.google.com/a/chromium.org/forum/?fromgroups#!topic/chromium-dev/Pzk7jsrXKVQ

Summary: language vs stdlib;  |"asdf"NACL_PRId64"fdsa"|

ABI issues on linux: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49561 (gcc decided on abi stability) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45093 (someone says "won't be abi stable", but that's older than the first bug)

piman doesn't like rval refs

July 11, 2012 "[chromium-dev] C++11 support" https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/6BsXIAs5KIA

Summary: nothing new (android stlport won't get c++11 features)

Oct 12, 2012 "[chromium-dev] C++11 support in Chromium" https://groups.google.com/a/chromium.org/forum/#!msg/chromium-dev/Ph_YKV-rWFI/AuVa_Ibwv04J

(forked from "[chromium-dev] ANN: VS2008 deprecation happening now")

Summary: Want to use static_assert, override, LL and ULL; auto, for-each, >> in templates

[2]

         building chrome on linux in release (components build):

         clang: 19m

         clang/c++11: 24m10s

         (much later revision, from 7/7/13, with gcc4.6)

         gcc: 20m42s

         gcc/c++11: 25m22s

         (gcc4.8)

         gcc: 22m4s

         gcc/c++11: 28m47s

[Adam Barth]

On Tue, Jul 23, 2013 at 4:52 PM, Nico Weber <tha...@chromium.org> wrote:

Hi,

(if you don't care about C++11, you can stop reading now.)

most of our linux bots are on precise now, which was what we believed is what we need for switching to C++11. I looked at this a bit, here's a status update.

Summary:

How do we want to proceed with C++11 support in Chromium?

Enabling C++11 support in our toolchain still requires significant work in order to support all platforms. The toolchain is also less mature and waiting may give us more options to resolve certain quirks (namely by selective disabling C++11 warnings that are limited use).

There are 3 possible paths forward:

1. Full speed ahead, with gcc 4.6! Work around issues and and turn on C++11 ASAP.

2. Wait for gcc 4.8.  Allows selective disabling of C+111 warnings.

3. Drop gcc support, require clang. Also allows selective disabling of some C++11 warnings.

How realistic is option (3)?  Is there anything standing in our way of dropping gcc support in favor of clang?

Adam

 

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

[Dale Curtis]

On Android, not everything seems to work with clang:

https://code.google.com/p/chromium/issues/detail?id=260968

A comment there also mentions that there may be a performance hit since ARM has focused a lot on gcc optimization.

- dale

[Tom Gall]

On Tue, Jul 23, 2013 at 7:35 PM, Dale Curtis <dalec...@chromium.org> wrote:
> On Android, not everything seems to work with clang:
>
> https://code.google.com/p/chromium/issues/detail?id=260968
>
> A comment there also mentions that there may be a performance hit since ARM
> has focused a lot on gcc optimization.

That's correct. FWIW the Linaro and ARM Toolchain teams for the past
few years has been pouring the majority of effects into improving gcc
optimizations for ARM. Clang/llvm is something we've just recently
gotten involved with.

> - dale
>
>
> On Tue, Jul 23, 2013 at 5:31 PM, Adam Barth <aba...@chromium.org> wrote:
>>
>> On Tue, Jul 23, 2013 at 4:52 PM, Nico Weber <tha...@chromium.org> wrote:
>>>
>>> Hi,
>>>
>>> (if you don't care about C++11, you can stop reading now.)
>>>
>>> most of our linux bots are on precise now, which was what we believed is
>>> what we need for switching to C++11. I looked at this a bit, here's a status
>>> update.
>>>
>>> Summary:
>>>
>>> How do we want to proceed with C++11 support in Chromium?
>>>
>>>
>>> Enabling C++11 support in our toolchain still requires significant work
>>> in order to support all platforms. The toolchain is also less mature and
>>> waiting may give us more options to resolve certain quirks (namely by
>>> selective disabling C++11 warnings that are limited use).
>>>
>>>
>>> There are 3 possible paths forward:
>>>
>>>
>>> Full speed ahead, with gcc 4.6! Work around issues and and turn on C++11
>>> ASAP.
>>>
>>> Wait for gcc 4.8. Allows selective disabling of C+111 warnings.
>>>
>>> Drop gcc support, require clang. Also allows selective disabling of some
>>> C++11 warnings.
>>
>>
>> How realistic is option (3)? Is there anything standing in our way of
>> dropping gcc support in favor of clang?
>>
>> Adam

<snip>

--
Regards,
Tom

"Where's the kaboom!? There was supposed to be an earth-shattering
kaboom!" Marvin Martian
Tech Lead, Graphics Working Group | Linaro.org │ Open source software
for ARM SoCs
w) tom.gall att linaro.org
h) tom_gall att mac.com

[Paweł Hajdan, Jr.]

On Tue, Jul 23, 2013 at 4:52 PM, Nico Weber <tha...@chromium.org> wrote:

There were a few threads about C++11 on chromium-dev [1]. The conclusion was that we’d want to wait until all our linux bots are on Ubuntu Precise, which ships with gcc 4.6. This has happened by now, so it’s time to look at things again.

Just for reference: while most of what you can call the "main waterfall" (build.chromium.org) is indeed on Precise, there is still more to do, including e.g. NaCl waterfall and many other bots. Please follow https://code.google.com/p/chromium/issues/detail?id=170262 for updates. The bug will be closed when every single Lucid bot gets updated to Precise.

Of course it might be possible to start using C++11 before every single bot is on Precise, but there are no guarantees.

 

Clang is special because we update it more frequently. We track clang trunk and update our clang binary every ~2 weeks. All platforms except iOS use the same revision. This lets us deploy toolchain fixes much faster than we can with other compilers.  

I think this ability to update quickly (and possibly have custom patches at least for a while, right?) is very important. Once we start supporting C++11 features, they will be used in the codebase, making it unfeasible to go back, and a serious issue may appear at any time. Then we don't have that ability on Windows anyway...

And then being able to use vanilla gcc to compile is somewhat important too (e.g. for Linux distributions doing builds).

 

MSVS likely won’t enable this warning for a while to preserve backwards compatibility. Clang can selectively disable this warning. However gcc 4.6, and 4.7 treat this as a hard error; it is only a disableable warning as of gcc 4.8.

Fixing errors of this type can be annoying too. For example, CLD has a 700-line initializer, and gcc prints the diagnostic at the initializer's closing '}'.

If we enable C++11 while still using gcc-4.6, we will need to change a bunch of code to be less readable in order to avoid the error.

Things like this make me prefer using gcc-4.8 or clang. Note that Ubuntu Precise will continue to use gcc-4.6 (I don't think they'll change gcc version for a release), which means waiting for new Ubuntu LTS and upgrading all of infrastructure. Or using clang. Well, it may also be possible to backport gcc-4.8 to Precise, but then I don't think binaries produced with it would run on older systems, including "regular" Precise (libstdc++ dependency).

 

-- The toolchain is immature--

gcc 4.6.0 was released March 25, 2011. C++11 was approved 12 August 2011. The C++11 standard is newer than gcc 4.6, and some things are just buggy.

Example: The compiler-generated move constructor for bitfield enums is not valid, and gcc prints a hard to understand compile-time error about code it itself generated internally (http://pastie.org/8125050).

This happens in angle_dx11.  This is again resolved in gcc4.8.

If we turn on C++11 prior to gcc-4.8, we’ll have to change (small amounts of) code to work around toolchain issues.

-- There’s not a lot of experience with C++11 apps--

gcc 4.7.0 and gcc 4.7.1 contained a (mostly accidental) ABI change that made it impossible for so libraries built in C++11 mode to function with other so libraries built in C++98 mode:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49561

System libraries on Linux are usually built in C++98, so if we move Chromium to C++11 we have to make sure to never ship a binary that was built with gcc 4.7.0 or gcc 4.7.1. There might be other issues like this.

I don’t think this is an issue on Android, since that loads no system so libs written in C++ into your app (?).

I think at least system ICU is used on Android (not sure about C vs. C++ interface of ICU).

After above two point I don't think gcc-4.6 should be used as-is. Clang would be a better route.

Paweł

[Reid Kleckner]

Can we mix and match code compiled as C++98 and C++11?

If I read http://gcc.gnu.org/wiki/Cxx11AbiCompatibility#AbiChanges correctly, then it's supposed to be ABI compatible, minus the 4.7.0-1 bug.

If so, then you could isolate the troublesome files in CLD or elsewhere and use C++98 (or even straight C?) for them as a workaround.

[David Turner]

On Tue, Jul 23, 2013 at 4:52 PM, Nico Weber <tha...@chromium.org> wrote:

I don’t think this is an issue on Android, since that loads no system so libs written in C++ into your app (?).

Yep, just wanted to confirm this, everything is statically linked into libchromeview.so on Android.

And just to make it clear, I'm working on an Android libc++ port that would not require Clang, but also work properly with GCC 4.6 / 4.7 / 4.8.

Easier said than done though ;-)

- Digit

[Stuart Morgan]

2013/7/24 Nico Weber <tha...@chromium.org>

User-defined literals

[...]

This is most notably used in NaCl.  The fix is to insert a space as follows:

 printf("xyz: %" PRIuS, size);  // PRIuS is from inttypes.h

[...]

If we turn on C++11 with gcc 4.6, our code will break in gcc 4.7 and we will have to make a bunch of code less readable.

FWIW, I changed a bunch of these while getting the C++11 build flag flipped for iOS (before learning that it was a disable-able warning), and nobody seemed to find adding the space problematic. Since the " is already interposed, the readability difference between having the space and not is minimal.

-Stuart

[Sangwhan Moon]

On Wed, Jul 24, 2013 at 9:54 AM, Tom Gall <tom....@linaro.org> wrote:
> On Tue, Jul 23, 2013 at 7:35 PM, Dale Curtis <dalec...@chromium.org> wrote:
>> On Android, not everything seems to work with clang:
>>
>> https://code.google.com/p/chromium/issues/detail?id=260968
>>
>> A comment there also mentions that there may be a performance hit since ARM
>> has focused a lot on gcc optimization.
>
> That's correct. FWIW the Linaro and ARM Toolchain teams for the past
> few years has been pouring the majority of effects into improving gcc
> optimizations for ARM. Clang/llvm is something we've just recently
> gotten involved with.

I second this. While Clang/LLVM is a much cleaner/nicer compiler, for non-Intel
architectures is still quite behind in terms of performance (or
compatibility) as there
hasn't got as much attention as gcc has.

Out of curiosity, will this mean that support for compilers that
cannot handle C++11
be left behind? The main reasoning behind this is because I personally
have actually
never seen a toolchain that is more recent than gcc 4.5+ on
traditional embedded Linux
platforms I've been dealing with during the last couple years.

The ports we have been working on in Opera so far involve gcc 4.5.1 in
the best case,
meaning that if C++11 becomes a hard requirement we will have to do
some very creative
hacks or cross our fingers real hard and hope SoC vendors will upgrade
their toolchains.

(In my experience, this doesn't happen as frequently as we would want it to.)

--
Sangwhan Moon [Opera Software ASA]
Software Engineer | Tokyo, Japan

[Anton Vayvod]

What is the plan on using C++11 features once it's turned on? Are we going to allow all of it from the day one or gradually add a list of the features allowed to use in the style guide?

[Pavel Sergeev]

We can use subset approved in Google C++ Style Guide (http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml?showone=C++11#C++11) as a start point.

--
Pavel Sergeev

[Justin Schuh]

On Tue, Jul 23, 2013 at 4:52 PM, Nico Weber <tha...@chromium.org> wrote:

By default I think narrowing still triggers only warnings on MSVS. Depending on the nature of the conversion, I believe it's one of: c4244, c4267, c4305, or c4307.

That stated, some of these are legitimate bugs, particularly in 64-bit code where we're doing things like truncating size_t to an int. After the Win64 port is done I was planning on churning through these in all the cases where we have the MSVS warnings suppressed.

[David Michael]

How many Compilers and Standard Libraries do we really have?

Compilers

• windows: msvs2010, msvs2012

• mac: clang

• linux: gcc4.6, clang

• chromeos: gcc4.6 (?)

• android: gcc4.6, clang

• iOS: Xcode’s clang

Note that portions of the code are also built with the NaCl toolchain. It's based on GCC 4.3 :-(. That appears to eliminate some niceties like auto: http://gcc.gnu.org/projects/cxx0x.html.

In particular, we build parts of base, ipc, gpu, and ppapi with the NaCl toolchain. It might be possible to transition to using the PNaCl LLVM toolchain, with clang v3.3. But that would slow down build times and possibly also performance, so it's not a clear win.

*Most* of chromium, however, is unaffected by this issue.

 

[Victor Khimenko]

On Wed, Jul 24, 2013 at 7:16 PM, David Michael <dmic...@chromium.org> wrote:

How many Compilers and Standard Libraries do we really have?

Compilers

• windows: msvs2010, msvs2012

• mac: clang

• linux: gcc4.6, clang

• chromeos: gcc4.6 (?)

• android: gcc4.6, clang

• iOS: Xcode’s clang

Note that portions of the code are also built with the NaCl toolchain. It's based on GCC 4.3 :-(.

NaCl uses GCC 4.4, so auto is supported but many other different things are not. Of course NaCl toolchain is under our control thus we can upgrade to GCC 4.8 if we really want too.

 

That appears to eliminate some niceties like auto: http://gcc.gnu.org/projects/cxx0x.html.

In particular, we build parts of base, ipc, gpu, and ppapi with the NaCl toolchain. It might be possible to transition to using the PNaCl LLVM toolchain, with clang v3.3.

This will be change of similar magnitude.

[Peter Kasting]

I actually find the with-space version fractionally _more_ readable.  Personally I support Just Fixing This everywhere.

PK 

[Nico Weber]

I haven't heard anyone argue for using C++11 with gcc 4.6 so far.

Re Stuart & Peter's "let's just fix literals": Sounds good, removes one item. Doing this at https://crbug.com/263960

Re khim

> This will be change of similar magnitude.

Do you mean it's similarly complicated to a) upgrade nacl gcc to 4.8 b) let nacl use the pnacl toolchain? If so, the latter sounds like there'd be one compiler less, which is probably good? In any case, I guess the NaCl compilers will be updated to work with whatever we happen to decide is best.

Re "gcc is faster on arm": Possible, but iOS uses clang on arm, so it's probably not terrible.

Re smoon

> Out of curiosity, will this mean that support for compilers that

> cannot handle C++11 be left behind? The main reasoning behind this is because I personally

> have actually never seen a toolchain that is more recent than gcc 4.5+ on

> traditional embedded Linux

Eventually we'll require C++11. Android and iOS have C++11-capable compilers as far as I know. Which embedded systems are you supporting? Why isn't a gcc newer than 4.5 available there?

Re rnk

> Can we mix and match code compiled as C++98 and C++11?

I think that's possible, but probably not worth the hassle since devs need to remember which files are in which mode, .h files couldn't use C++11 at all (else you'd have to downgrade them if include them in a c++98 file)?

Re Pawel

> I think this ability to update quickly (and possibly have custom patches at least for a while, right?) is very important.

We don't have downstream patches in "our" clang binaries.

Re Adam

> How realistic is option (3)?  Is there anything standing in our way of dropping gcc support in favor of clang?

Not sure. On Linux, it should be doable. On ChromeOS, I think we rely on profile-guided optimization quite a bit, which I believe clang can't do yet. Android apparently sees some bugs with clang (but even if those are compiler bugs and not our bugs, we could fix them in the compiler and then update our compiler on a time span of weeks).

[Victor Khimenko]

On Thu, Jul 25, 2013 at 1:23 AM, Nico Weber <tha...@chromium.org> wrote:

I haven't heard anyone argue for using C++11 with gcc 4.6 so far.

Re Stuart & Peter's "let's just fix literals": Sounds good, removes one item. Doing this at https://crbug.com/263960

Re khim

> This will be change of similar magnitude.

Do you mean it's similarly complicated to a) upgrade nacl gcc to 4.8 b) let nacl use the pnacl toolchain?

Yes. GCC and LLVM currently have different native ABIs (GCC uses CPU-native ABI and LLVM uses generic ABI suitable for cross-platform .pexe file) and GCC supports both while LLVM only supports one of these. To build Chrome with LLVM we'll need to add support for cross-platform ABIs to LLVM. It's not too complicated (this support is in native LLVM, it's just not used in PNaCl), mostly we'll just need to add test coverage, but then upgrade for nacl gcc is of similar complexity (and, again, it's mostly testing).

 

If so, the latter sounds like there'd be one compiler less, which is probably good?

No, GCC will still be around because you still can not compile GLibC with clang.

 

In any case, I guess the NaCl compilers will be updated to work with whatever we happen to decide is best.

Only if someone will actually dedicate time to do that. We've had plans to upgrade NaCl's compiler. Two years ago. We still have these plans, you see, yet NaCl compilers are not upgraded.

 

Re "gcc is faster on arm": Possible, but iOS uses clang on arm, so it's probably not terrible.

It's faster for Android, but slower for iOS. GCC 4.3+ uses GPLv3 which means that Apple can only ever use GCC 4.2. Not only GCC 4.2 is slower then LLVM trunk, it's dead-end WRT ARMv8, etc. Thus Apple have no choice.

 

[Paweł Hajdan, Jr.]

On Wed, Jul 24, 2013 at 2:23 PM, Nico Weber <tha...@chromium.org> wrote:

Re Pawel

> I think this ability to update quickly (and possibly have custom patches at least for a while, right?) is very important.

We don't have downstream patches in "our" clang binaries.

Alright. Staying close to upstream is great, so I'm glad this is the case.

 

Re Adam

> How realistic is option (3)?  Is there anything standing in our way of dropping gcc support in favor of clang?

Not sure. On Linux, it should be doable. On ChromeOS, I think we rely on profile-guided optimization quite a bit, which I believe clang can't do yet. Android apparently sees some bugs with clang (but even if those are compiler bugs and not our bugs, we could fix them in the compiler and then update our compiler on a time span of weeks).

 I'd prefer the code to be still compilable using gcc, at least supported on a best-effort basis (i.e. may break from time to time but patches to fix things would generally be accepted).

Paweł

[Albert J. Wong (王重傑)]

If we make a complete clang flipover for our release binaries, I rather explicitly drop support for gcc. Supporting extra toolchains + platforms adds significant complexity.

Having said that, it doesn't sound like we're at all close enough to "drop gcc" yet that it's worth arguing the finer points.  However, when we get to that bridge (probably in a few years) do expect to hear pushback from me for continuing to support extra toolchains. :)

-Albert

 

Paweł

[Mark Seaborn]

On 24 July 2013 15:13, Victor Khimenko <kh...@chromium.org> wrote:

On Thu, Jul 25, 2013 at 1:23 AM, Nico Weber <tha...@chromium.org> wrote:

Re khim

> This will be change of similar magnitude.

Do you mean it's similarly complicated to a) upgrade nacl gcc to 4.8 b) let nacl use the pnacl toolchain?

Yes. GCC and LLVM currently have different native ABIs (GCC uses CPU-native ABI and LLVM uses generic ABI suitable for cross-platform .pexe file) and GCC supports both while LLVM only supports one of these. To build Chrome with LLVM we'll need to add support for cross-platform ABIs to LLVM. It's not too complicated (this support is in native LLVM, it's just not used in PNaCl), mostly we'll just need to add test coverage, but then upgrade for nacl gcc is of similar complexity (and, again, it's mostly testing).

We're actually planning on switching the x86-64 version of the NaCl IRT to being built with the PNaCl toolchain as part of security hardening PNaCl (see https://code.google.com/p/nativeclient/issues/detail?id=3577).

Doing the same for x86-32 wouldn't be too difficult if the PPAPI proxy code needs to use new compiler features.  It might turn out to be worth doing anyway, because the PNaCl/LLVM toolchain lets us do link-time optimisation which might reduce the IRT executable's size.

Cheers,
Mark

[David Michael]

On Wed, Jul 24, 2013 at 4:13 PM, Victor Khimenko <kh...@chromium.org> wrote:

On Thu, Jul 25, 2013 at 1:23 AM, Nico Weber <tha...@chromium.org> wrote:

I haven't heard anyone argue for using C++11 with gcc 4.6 so far.

Re Stuart & Peter's "let's just fix literals": Sounds good, removes one item. Doing this at https://crbug.com/263960

Re khim

> This will be change of similar magnitude.

Do you mean it's similarly complicated to a) upgrade nacl gcc to 4.8 b) let nacl use the pnacl toolchain?

Yes. GCC and LLVM currently have different native ABIs (GCC uses CPU-native ABI and LLVM uses generic ABI suitable for cross-platform .pexe file) and GCC supports both while LLVM only supports one of these. To build Chrome with LLVM we'll need to add support for cross-platform ABIs to LLVM. It's not too complicated (this support is in native LLVM, it's just not used in PNaCl), mostly we'll just need to add test coverage, but then upgrade for nacl gcc is of similar complexity (and, again, it's mostly testing).

 

If so, the latter sounds like there'd be one compiler less, which is probably good?

No, GCC will still be around because you still can not compile GLibC with clang.

The IRT uses newlib, and that's what links in chrome base/, ipc/, ppapi/, and gpu/ code. I think the only portion of code that would still need to be built with GLibC in the chrome tree would be tests. Those are already a little "special", and we could leave out C++11 support for those for a while, I think.

That said, I'm concerned about the performance (mostly compile-time) that we'd lose by using the PNaCl toolchain to build any significant part of chrome. If it was a straight LLVM-based NaCl toolchain, that would probably work great for chrome. But I suspect going to .pexe first and then through the translator would be annoyingly slow.

[Victor Khimenko]

On Thu, Jul 25, 2013 at 6:51 AM, David Michael <dmic...@chromium.org> wrote:

On Wed, Jul 24, 2013 at 4:13 PM, Victor Khimenko <kh...@chromium.org> wrote:

On Thu, Jul 25, 2013 at 1:23 AM, Nico Weber <tha...@chromium.org> wrote:

I haven't heard anyone argue for using C++11 with gcc 4.6 so far.

Re Stuart & Peter's "let's just fix literals": Sounds good, removes one item. Doing this at https://crbug.com/263960

Re khim

> This will be change of similar magnitude.

Do you mean it's similarly complicated to a) upgrade nacl gcc to 4.8 b) let nacl use the pnacl toolchain?

Yes. GCC and LLVM currently have different native ABIs (GCC uses CPU-native ABI and LLVM uses generic ABI suitable for cross-platform .pexe file) and GCC supports both while LLVM only supports one of these. To build Chrome with LLVM we'll need to add support for cross-platform ABIs to LLVM. It's not too complicated (this support is in native LLVM, it's just not used in PNaCl), mostly we'll just need to add test coverage, but then upgrade for nacl gcc is of similar complexity (and, again, it's mostly testing).

 

If so, the latter sounds like there'd be one compiler less, which is probably good?

No, GCC will still be around because you still can not compile GLibC with clang.

The IRT uses newlib, and that's what links in chrome base/, ipc/, ppapi/, and gpu/ code. I think the only portion of code that would still need to be built with GLibC in the chrome tree would be tests. Those are already a little "special", and we could leave out C++11 support for those for a while, I think.

As Mark pointed out x86-64 IRT will use LLVM soon for other reasons and x86-32 should not be all that hard, too. GCC will still be used to build GLibC, but it'll not used to build Chrome.

 

That said, I'm concerned about the performance (mostly compile-time) that we'd lose by using the PNaCl toolchain to build any significant part of chrome. If it was a straight LLVM-based NaCl toolchain, that would probably work great for chrome. But I suspect going to .pexe first and then through the translator would be annoyingly slow.

This will be straight LLVM AFAICS: .pexe by it's very nature is cross-platform and IRT includes small amount of code with platfrom-specific ABI. Plus it really makes no sense to build IRT as .pexe: we know exactly what platform we need to support because IRT is bundled with browser and we have no plans to create cross-platform browser binary any time soon.

[Derek Schuff]

Just to clear up some PNaCl-related stuff:

PNaCl's LLVM does have code-generation support to use "native" ABIs (I say "native" in quotes because it's the nacl-gcc ABI and not the unsandboxed gcc ABI, but it's almost the same). It doesn't yet have native versions of the libraries required for the NaCl IRT (newlib, libstdc++); it has portable bitcode versions which can't be used to generate nacl-gcc-compatible code, but fixing that is straightforward. Whether the build is separated into PNaCl-like stages of "build bitcode object files", "link them together", "run LTO" and "translate to native" is an unimportant implementation detail. (Well, it could affect the speed of the build, which is still important... building the IRT with PNaCl will still unfortunately be slower, at least in the near term). 

In terms of C++11, PNaCl is based on clang 3.3 so it has good support for C++11 *language* features, but its C++ library is a bit out of date, so it doesn't have great C++11 library support (this is something we want to fix very soon after the first release). If we go the PNaCl route for its C++11 support we probably wouldn't want to open the floodgates until that's fixed, but from the rest of this thread it sounds like that would likely get taken care of before some of the other potential blockers mentioned.

[Sangwhan Moon]

On Thu, Jul 25, 2013 at 6:23 AM, Nico Weber <tha...@chromium.org> wrote:
> Re smoon
>> Out of curiosity, will this mean that support for compilers that
>> cannot handle C++11 be left behind? The main reasoning behind this is
>> because I personally
>> have actually never seen a toolchain that is more recent than gcc 4.5+ on
>> traditional embedded Linux
>
> Eventually we'll require C++11. Android and iOS have C++11-capable compilers
> as far as I know. Which embedded systems are you supporting? Why isn't a gcc
> newer than 4.5 available there?

We are supporting old school embedded Linux systems (no X11, no
desktop environment) for various SoCs. (mostly targeted at TVs,
Blu-ray players, Set-top boxes)

The release cycle for kernel/compiler/libc updates are much slower on
these platforms compared to ones that have a more rapid release cycle
(e.g. Android) for stability (and probably maintenance cost) reasons.

[Mike Frysinger]

On Tue, Jul 23, 2013 at 7:52 PM, Nico Weber <tha...@chromium.org> wrote:

How many Compilers and Standard Libraries do we really have?

Compilers

• windows: msvs2010, msvs2012

• mac: clang

• linux: gcc4.6, clang

• chromeos: gcc4.6 (?)

CrOS has been on gcc-4.7 since Nov 2012, so we've been shipping since at least R25 with it.  we've hit a few issues (including narrowing warnings you documented later on here) ahead of the Chromium tree due to us moving ahead of the version most Linux devs use.

we have clang available, but we only use it for debug/diagnostic builds (like ASAN).  and iirc, the cross-compiling behavior is ... buggy.  it'll take some time to sort that all out.

-- There’s not a lot of experience with C++11 apps--

gcc 4.7.0 and gcc 4.7.1 contained a (mostly accidental) ABI change that made it impossible for so libraries built in C++11 mode to function with other so libraries built in C++98 mode:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49561

System libraries on Linux are usually built in C++98, so if we move Chromium to C++11 we have to make sure to never ship a binary that was built with gcc 4.7.0 or gcc 4.7.1. There might be other issues like this.

I don’t think this is an issue on Android, since that loads no system so libs written in C++ into your app (?).

I’m unsure about ChromeOS. If there are problems, we could in theory make sure the whole system is built in C++11 mode, but that might require some effort to do.

every CrOS release is built from source, so that should be feasible for us to do if needed

-mike

[Sébastien Marchand]

Resurrecting an old thread to check if some blocking things have changed since last summer... Maybe we should put those information in a document ? This'll be easier to update (I don't mind doing it but I'll need an update on the compilers/libraries that we use first).

On Mon, Jul 29, 2013 at 3:25 PM, Mike Frysinger <vap...@chromium.org> wrote:

On Tue, Jul 23, 2013 at 7:52 PM, Nico Weber <tha...@chromium.org> wrote:

How many Compilers and Standard Libraries do we really have?

Compilers

• windows: msvs2010, msvs2012

• mac: clang

• linux: gcc4.6, clang

• chromeos: gcc4.6 (?)

On Windows we've switched to VS2013, which seems to have a better support for  c++11 features. Anything new on Linux and ChromeOS ?

 

CrOS has been on gcc-4.7 since Nov 2012, so we've been shipping since at least R25 with it.  we've hit a few issues (including narrowing warnings you documented later on here) ahead of the Chromium tree due to us moving ahead of the version most Linux devs use.

we have clang available, but we only use it for debug/diagnostic builds (like ASAN).  and iirc, the cross-compiling behavior is ... buggy.  it'll take some time to sort that all out.

-- There’s not a lot of experience with C++11 apps--

gcc 4.7.0 and gcc 4.7.1 contained a (mostly accidental) ABI change that made it impossible for so libraries built in C++11 mode to function with other so libraries built in C++98 mode:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49561

System libraries on Linux are usually built in C++98, so if we move Chromium to C++11 we have to make sure to never ship a binary that was built with gcc 4.7.0 or gcc 4.7.1. There might be other issues like this.

I don’t think this is an issue on Android, since that loads no system so libs written in C++ into your app (?).

I’m unsure about ChromeOS. If there are problems, we could in theory make sure the whole system is built in C++11 mode, but that might require some effort to do.

every CrOS release is built from source, so that should be feasible for us to do if needed

-mike

--

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

--

Sébastien Marchand |

Software Developer |

sebma...@google.com

[Nico Weber]

Not a lot has changed.

Some things are currently happening (chrome/android's moving to gcc4.8 (http://crbug.com/359106), some of us have worked on bringing libc++ to android (but switching to that is a ways out), windows is now on msvs2013. Linux is still on gcc 4.6 – I'm planning to switch linux to clang over this weekend to collect some perf data. So there's some movement, but as of today, things are mostly the same as they were.

[Sébastien Marchand]

Thanks, I've opened a meta bug to track this: crbug.com/360096 , feel free to update the "Blocked on" list.

[Alexey]

"I'm planning to switch linux to clang over this weekend to collect some perf data."

Any news/updates?

[Dana Jansens]

Android landed but has some issues: https://code.google.com/p/chromium/issues/detail?id=427718#c74

It appears it was only reverted for M44 at this time, though.

Mac needs someone to spend some time, it hasn't been really started yet. If you're interested in helping with this, thakis has some thoughts in a document somewhere.

That's all that's left now AFAIK.

[Nico Weber]

On Thu, Jun 18, 2015 at 11:16 PM, Alexey <lo...@chromium.org> wrote:

"I'm planning to switch linux to clang over this weekend to collect some perf data."

Any news/updates?

Yes. This is a very old thread. We switched chrome/linux to clang long ago and C++11 language features are allowed in chromium (the announcement was https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/xMscQuYBwyc

http://chromium-cpp.appspot.com/ lists the language features that are allowed.