This is the second post about trying to build Firefox 4 with clang. In this post I talk about what had (or has) to be changed in Firefox for it build. The patches that are still pending can be found by following the open bugs that block bug 574346.

Inline assembly

This is bug 623129. It is not really clang specific, but I found it because clang was missing support for local register variables.

In order to call a function pointer with particular registers assigned particular values, firefox has code that looks like

register double d0 asm("xmm0");
...
register PRUint64 a0 asm("rdi");
...
// Ensure that assignments to SSE registers won't be optimized away
asm("" ::
       "x" (d0), "x" (d1), "x" (d2), "x" (d3),
       "x" (d4), "x" (d5), "x" (d6), "x" (d7));
methodAddress = ...
return methodAddress(a0, a1, a2, a3, a4, a5);

The problem with this is that according to the gcc manual, local register values are only guaranteed to actually be in the specified registers in asm statements that use it. In the above code, the double variables might only be assigned during the empty asm statement.

I first tried fixing this by writing the call in inline assembly. This is tricky, as you have to specify all that the ABI requires. Eventually I got it to work, but then noticed that the double variables were also being passed in the order specified by the ABI, so no inline assembly was needed at all!

Invalid lookup

In templated code, lookups should not find names in dependent base classes or at the place where the template is instantiated. Unfortunately, some versions of gcc accept both. Clang’s compatibility document explains the unqualified lookup and the dependent base classes problems.

Fortunately these bugs are easy to find and fix and I think they have all been fixed.

Exception specification

This is bug 601974. Clang is a bit more strict about making sure that exception specifications match. This can be a problem with the operator new. It can throw a std::bad_alloct or not depending on the option -fexceptions. If compiling with -fexceptions, clang will reject the code

#include <new>
void* operator new(size_t size) throw ();

The fix was to keep the -fexception and the macro that expands to the throw in sync.

Missing constructors

This is present in many components, but 623123 is likely the canonical bug.

The basic issue is that to default initialize a const instance, a non pod class needs a user declared constructor. This is explained in the clang compatibility document.

What is controversial in these bugs is that the classes had been declared without a constructor to try to avoid static initializes. This doesn’t look like a valid concern. For example in

struct foo {
  foo() {}
  virtual void f() const;
};
const struct foo b;
void g() {
  b.f();
}

gcc 4.2 will produce a static initializer with or without the user declared constructor. It is also (as is clang) able to optimize that away in both cases with -O1.

A note on the development process

It is interesting to note that while the changes in Firefox are simpler than the changes in llvm and clang, Firefox is the one with pending patches. I think that this is in part because of the development process of both projects.

Simple changes to llvm like adding support for the %H modifier were simply implemented and committed (with a test!). More complex ones like adding unnamed_addr which involved changes to the llvm IL, modifications to the existing constant merging logic and both front ends (clang and llvm-gcc) have an associated bug and were discussed on the list and irc. In total, the bug was closed 9 days after it was open. After 3 more days we were optimizing to set unnamed_addr when possible.

In Mozilla, changes always have to have a bug and code review is done in bugzilla with not all that intuitive flags for the various stages. A particular bug for a missing include was blocked on the “approval2.0″ stage for 10 days.

The next post should compare the results of building with clang and gcc.