Last week I attended BlinkOn 18 in Sunnyvale Google offices. For the 5th time I presented the status of Chromium build using the GNU toolchain components: GCC compiler and libstdc++ standard library implementation.
This blog post recaps the current status in 2023, as it was presented in the conference.
Current status
First things first: GCC is still maintained, and working, on the official development releases! Though, as official build bots will not check that, fixes usually take a few extra days to land.
This is the result of the work from contributors of several companies (Igalia, LGE, Vewd and others). But most important, from individual contributors (last 2 years the main contributor, with more than 50% of the commit has been Stephan Hartmann from Gentoo).
GCC support
The work to support GCC is coordinated from the GCC Chromium meta bug.
Since I started tracking the GCC support we have been getting a quite stable number of contributions, 70-100 per year. Though in 2023 (even if we are counting only 8 months on this chart), we are way below 40.
What happened? I am not really sure. Though, I have some ideas. First, simply as we move to newer versions of GCC, the implementation of recent C++ standards have improved. But then, also, this is the result of the great work that has been done recently in both GCC and LLVM, and also in standarization process, to get more interoperable implementations.
Main GCC problems
Now, I will focus on the most frequent causes for build breakage affecting GCC since January 2022.
Variable clashes
The rules for visibility in C++ are slightly different in GCC. An example: if a class declares a getter with the same name of a declared type in current namespace, Clang will be mostly Ok with that. But GCC will fail with an error.
Bad:
using Foo = int;
class A {
...
Foo Foo();
...
}
A possible fix is renaming the accessor method name:
Foo GetFoo();
Or using a explicit namespace for the type:
::Foo GetFoo()
Ambiguous constructors
GCC may sometimes fail to resolve which constructor to use when there is an implicit type conversion. To avoid that, we can make that conversion explicit or use all braces initializers.
constexpr is more strict in GCC
In GCC a constexpr method declared as default demands all its parts to be also declared constexpr:
Bad
int MethodA() { ... };
constexpr MethodB() { ... MethodA() ... };
Two possible fixes: or dropping constexpr from the using method, or adding constexpr to all used methods.
noexcept strictness
noexcept strictness in GCC and Clang is the same when exceptions are enabled, requiring that all invoked functions used from a noexcept are also noexcept. Though, when exceptions are disabled using -fno-exception, Clang will ignore the errors. But GCC will still check the rules.
This works in Clang and not in GCC if -fno-exception is set:
class A {
...
virtual int Method();
};
class B {
...
int Method() noexcept override;
};
CPU intrinsics casts
Implicit casts of CPU intrinsic types will fail in GCC, requiring explicit conversion or cast.
As example:
int8_t input __attribute__((vector_size(16)));
uint16_t output = _mm_movemask_epi8(input);
If we see the declaration of the intrinsic call:
int _mm_movemask_epi8 (__m128i a);
GCC will not allow implicit casting from an int8_t __attribute__((vector_size(16))), though the storage is the same. In GCC we require a reinterpret_cast:
int8_t input __attribute__((vector_size(16)));
uint16_t output = _mm_movemask_epi8(reinterpret_cast<__m128i>(input));
Template specializations need to be in a namespace scope
Template specializations are not allowed in GCC if they are not in a namespace scope. Usually this error materializes with developers adding the template specialization in the templated class scope.
A failing example:
namespace a {
class A() {
template<typename T>
T Foo(const T&t ) {
...
}
template<>
size_ Foo(const size_t& t)
};
}
The fix is moving the template specialization to the namespace scope:
namespace a {
class A() {
template<typename T>
T Foo(const T&t ) {
...
}
};
template<>
size_ A::Foo(const size_t& t) {
...
}
}
libstdc++ support
Regarding the C++ standard library implementation from GNU project, the work is coordinated in the libstdc++ Chromium meta bug.
We have definitely observed a big increase of required fixes in 2022, and projection of 2023 is going to be similar.
In this case there are two possible reasons. One is that we are more exhaustively tracking the work using the meta bug.
Main libstdc++ problems
In the case of libstdc++, these are the most frequent causes for build breakage since January 2022.
Missing includes
The libc++ implementation is different from libstdc++. And that implies some library headers that could be indirectly included in libc++ are not in libstdc++.
STL containers not allowing const members
Let’s see this code:
std::vector<const int> v;
In Clang, this is allowed. Though, in GCC there is an explicit assert forbidding it: std::vector must have a non-const, non-volatile value_type.
This is not only specific to std::vector, but also to std::unordered:*, std::list, std::set, std::deque, std::forward_list or std::multiset.
The solution? Just do not use const as members:
std::vector<int> v;
Destructor of unique_ptr requires declaration of contained type
Assigning from nullptr to std::unique_ptr requires destructor declaration
class A;
std::unique_ptr<A> GetValue() {
return nullptr;
}
Usually it is just needed to include the full declaration of the class, as it needs the size of the type for the default destructor.
Yocto meta-chromium layer
In my case, to verify GCC and libstdc++ support, on top of building Chromium in Ubuntu using both, I am also maintaining a Yocto layer that builds Chromium development releases. I usually try to verify the build in less than a week after each release.
The layer is available at github.com/Igalia/meta-chromium
I am regularly testing the build using core-image-weston in both Raspberry PI 4 (64 bits) and Intel x86-64 (using Qemu). There I try both X11 and Wayland Ozone backends.
Wrapping up
I would still recommend people to move to use the officially supported Chromium toolchains: libc++ and Clang. With them, downstreams get a far more tested implementation, more security features, or better integration for sanitizers. But, meanwhile, I expect things will still be kept working as several downstreams and distributions will still ship Chromium on top of the GNU toolchains.
Even with the GNU toolchain not being officially supported in Chromium, the community has been successful providing support for both GCC and libstdc++. Thanks to all the contributors!