Re: RFT: Please help testing the llvm/clang 3.5.0 import

This is excellent news Dimitry!

> On Dec 16, 2014, at 12:36 PM, Dimitry Andric <dim_at_freebsd.org> wrote:
> 
> On 28 Nov 2014, at 22:03, Dimitry Andric <dim_at_FreeBSD.org> wrote:
>> 
>> We're working on updating llvm, clang and lldb to 3.5.0 in head.  This
>> is quite a big update again, and any help with testing is appreciated.
>> 
>> To try this out, ensure you have good backups or snapshots, then build
>> world and kernel from the projects/clang350-import branch [1].  Please
>> use a Subversion mirror [2], if you are able to.
> 
> Here are some updates about the status of the 3.5.0 import.
> 
> * i386 and amd64 have been tested through make universe, and everything
>  should compile and run.
> * Little-endian ARM builds should now compile and run, thanks to Andrew
>  Turner for putting in lots of work.
> * Big-endian ARM is apparently supposed to work, but I'm not sure if
>  Andrew managed to test it on real hardware.

I know Andrew doesn’t have the right arm gear to do this test, and emulation
environments that run FreeBSD have had poor big-endian support for arm.

> * PowerPC64 should mostly work, thanks to Justin Hibbits.
> * PowerPC32 might start working soon; it really needs some backporting
>  of fixes to clang 3.4.1, which is now in head, so there is an easier
>  upgrade path for PowerPC users.
> * Sparc64 still does not work, and I don't see any quick solutions to it
>  for now.  It should probably stay with gcc.
> * Mips will only have a chance with the upcoming clang 3.6.0, but that
>  is way too late for this import.  It will probably require external
>  toolchain support to get it working.

For native builds yes. For cross builds, clang 3.6 can be built on an
x86 host.

> * Another ports exp-run was done [3], after fixing the problem with
>  lang/gcc, which lead to many skipped dependent ports.
> * The second exp-run had much better results: the failure with the
>  highest number of dependencies is devel/mingw32-gcc, but this seems
>  to be due to a problem with makeinfo, not clang.  The next highest on
>  the list is java/openjdk6, for which ports r374780 [4] was very
>  recently committed.

Will users of our stable branch have code similar to the code that caused
problems? One warning flag about your upgrade to the stable branch
would be if there’s a significant number of user-written programs that
suddenly become uncompilable with the new clang using the environment
that they have today. We know of some items that are issues, so careful
attention here is needed. Unless we go proactively looking for these,
there’s a good chance we won’t find them until users hit them and start
to complain (by which point it is likely too late). Could you post a summary
of the issues that ports have hit and the fixes necessary? We may need
to have that in the release notes and/or UPDATING file to help prepare
our users for the bumps and give them solutions over them.

> I would really like to merge this branch to head in about a week,
> pending portmgr approvall; I don't expect the base system (outside of
> llvm/clang) to need any further updates.

I think there’s good reason to do this, but we should chat about the
build issues below before doing it. They are minor, but an important
detail. I’ll see if I can find a few minutes to pull the branch and send
patches.

> Lastly, to clear things up about the requirements for this branch (and
> thus for head, in a while); to build it, you need to have:
> * A C++11 capable "host" compiler, e.g. clang >= 3.3 or later, or gcc
>> = 4.8 (I'm not 100% sure if gcc 4.7 will work, reports welcome)
> * A C++11 standard library, e.g. libc++, or libstdc++ from gcc >= 4.8.
> 
> So from any earlier standard 10.x or 11.x installation, you should be
> good, unless you explicitly disabled clang or libc++.  In that case,
> you must build and install both of those first.

This is true only on i386, amd64, and arm hosts. Given that some people
do try to do weird things, tightening up how you present this will get the
word out a little better.

> On a 9.x installation, you will have clang by default, but not libc++,
> so libc++ should be built and installed first, before attempting to
> build the clang350-import branch.

Can you make sure that the UPDATING entry you are writing for this
contains explicit instructions.

> On 8.x an earlier, you need to upgrade to at least 9.x first, follow
> the previous instruction.

We should remove building on 8 support then, unless there external
toolchain stuff is up to the task (e.g. build gcc 4.9, libstc++, etc).

> As for MFC'ing, I plan on merging clang 3.5.x to 10.x in a while
> (roughly a month), but this will cause upgrades from 9.x to 10.x to
> start requiring the build of libc++, as described above.  I don't think
> we can merge clang 3.5.x to 9.x, unless clang becomes the default
> compiler there (but that is very unlikely).

Let’s see how it goes, and what the upgrade issues wind up being
before doing this merge back. New “major” compilers on stable branches
traditionally haven’t been done, but if clang is better about being ABIly
identical to prior releases than gcc was, it might not have the same issues
associated with it.

Warner