Announcing 3.1 Release Branch Date!

IMPORTANT! IMPORTANT! IMPORTANT!

We will be branching for the 3.1 release on April 16th! :slight_smile: This gives us a little over two weeks to get the trees into the most stable condition we can.

What this means for you:

All major features for the 3.1 release should be finished or near completion by the April 16th. After April 16th, we will accept only bug fixes and patches which do not change the functionality of LLVM and Clang in a significant way. I.e., if your feature isn't finished, then it may have to be turned off by default (unless the patch is small and not-too-invasive).

It will be up to the code maintainers to approve any patches after the branching date. But the final decision will be mine.

Schedule:

There will be a tentative schedule following within the next few days.

Testers:

Several people have expressed an interest in being testers. Many thanks to them! If you would like to be a tester, please email me and I can add you.

By the way, we are looking for ARM testers. There was a lot of interest in the 3.0 release for an ARM release. We will try to do one this release on a trial basis. We are looking for ARMv7 cortex-a8 and cortex-a9 on Linux.

Share and enjoy!
-bw

IMPORTANT! IMPORTANT! IMPORTANT!

[...]

By the way, we are looking for ARM testers. There was a lot of interest in the 3.0 release for an ARM release. We will try to do one this release on a trial basis. We are looking for ARMv7 cortex-a8 and cortex-a9 on Linux.

If you are interested, I can upload the current trunk version into the
Debian archive in the experimental suites with the unitary tests
activated.
I already uploaded the current trunk of llvm in experimental [1]. It is
in the NEW queue but I am planning to upload the trunk of clang as soon
as it get accepted. I was not planning to enable the test suite (the 12
Debian archs is a huge work) but if you want to get feedback, I can
enable it...

Cheers,
Sylvestre
[1] http://ftp-master.debian.org/new/llvm-3.1_3.1~svn153453-1.html

By the way, we are looking for ARM testers. There was a lot of interest in the 3.0 release for an ARM release. We will try to do one this release on a trial basis. We are looking for ARMv7 cortex-a8 and cortex-a9 on Linux.

  We have two pandard board (ARMv7 cortex-a9) and perhaps one ARMv6
4-cores board. Do we do a native compile or cross compile for the ARM
platform?

Regards,
chenwj

Hi,

The buildbot farm has a native C-A9 build (on pandaboard) - we (ARM) also build LLVM on pandaboard occasionally and it builds from clean in 2.5 hours and runs make check-all in 20 mins.

The test suite (with TEST=simple) takes 6-7 hours to run, including SPECCPU2000.

My personal preference is to prioritize qualifying as a cross compiler first and a hosted compiler second. I have no problems with doing both other than the additional testing resources required, though.

-Jim

I agree with Jim. While having a native ARM compiler might be nice, it's not something I want to embark on for this release.

-bw

For what it's worth, I've been using clang self-hosted on a Freescale i.MX515 (Cortex A8) for about six months. Aside from ARM exceptions being completely broken, it works nicely. I've not updated it very often, because recompiling LLMV + clang is an overnight job on that poor little machine. It's a bit better on a dual-core Snapdragon...

David

-- Sent from my Apple II

> My personal preference is to prioritize qualifying as a cross compiler first and a hosted compiler second. I have no problems with doing both other than the additional testing resources required, though.
>
I agree with Jim. While having a native ARM compiler might be nice, it's not something I want to embark on for this release.

  From James's experience, a native build would take a long time.
But I am afarid of a cross build might not suit a compiler testing
(i.e., cross build might not expose lurking bugs), that's why I have
this question. :slight_smile:

Regards,
chenwj

The most useful thing you can do, if you are cross building, is cross-compile your own code with clang and report any miscompilations, ideally with reduced test cases.

David

Replying to myself.

I enabled test suite in the package creation for clang and llvm.

Log are available for clang r154769
https://buildd.debian.org/status/package.php?p=clang&suite=experimental
and LLVM r154766
https://buildd.debian.org/status/package.php?p=llvm-3.1&suite=experimental

Grep for "Unexpected Failures" to find the result

For example, under armel, I get for LLVM [1] :
  Expected Passes : 5812
  Expected Failures : 59
  Unsupported Tests : 10
  Unexpected Passes : 12
  Unexpected Failures: 1

and clang [2]:
  Expected Passes : 4484
  Expected Failures : 29
  Unsupported Tests : 3
  Unexpected Passes : 1
  Unexpected Failures: 30

I am available to upload on request new revision of LLVM and/or Clang in
Debian build systems.
I have also access to the debian porterbox on all Debian supported
architectures [3].

Hope this helps,
Sylvestre

[1]
Unexpected Passing Tests (12):
    LLVM :: ExecutionEngine/2003-01-04-ArgumentBug.ll
    LLVM :: ExecutionEngine/2003-01-04-LoopTest.ll
    LLVM :: ExecutionEngine/2003-01-15-AlignmentTest.ll
    LLVM :: ExecutionEngine/2003-05-06-LivenessClobber.ll
    LLVM :: ExecutionEngine/2003-05-07-ArgumentTest.ll
    LLVM :: ExecutionEngine/2003-08-21-EnvironmentTest.ll
    LLVM ::
ExecutionEngine/2003-10-18-PHINode-ConstantExpr-CondCode-Failure.ll
    LLVM :: ExecutionEngine/hello.ll
    LLVM :: ExecutionEngine/hello2.ll
    LLVM :: ExecutionEngine/simpletest.ll
    LLVM :: ExecutionEngine/stubs.ll
    LLVM :: ExecutionEngine/test-call-no-external-funcs.ll