[llvm-dev] [cfe-dev] [Release-testers] [4.0.0 Release] Release Candidate 2 has been tagged
Hans Wennborg via llvm-dev
llvm-dev at lists.llvm.org
Fri Feb 10 14:23:27 PST 2017
On Fri, Feb 10, 2017 at 3:56 AM, Renato Golin <renato.golin at linaro.org> wrote:
> On 10 February 2017 at 11:38, Pavel Labath via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>> All I can say is these tests did not exist in 3.9, so I wouldn't call
>> this a regression. (Well... technically, a similar test existed, but
>> it was run by a different test runner which I believe is not hooked up
>> to the command you are running).
> We're on a similar state for libc++ / openmp / lld on ARM and AArch64.
> libc++ works well on ARM and AArch64, but some of the tests fail
> (always have), and I think Eric said it has to do with how we run them
> or which ones should be disabled.
> LLD works well on AArch64 but not yet on ARM (though there were no
> test failures this time). OpenMP kind of works, but there are many
> failures, which we won't look into this cycle.
> Regardless of that state, we though it was a good idea to ship it as
> an experimental status, so that people can try out and report bugs.
> All the components above are included in both ARM and AArch64
> Do you think we should have a table of production vs. experimental
> quality per target on the release notes, so that users know what to
> expect? Or should we just let users know that when they report bugs?
Good question, we're not doing a very good job of documenting this.
And I'm not sure what would be the best way to do it.
A reasonable thing to do would be to put a note on the relaese
downloads page. But I'm not even sure what to put there. "OpenMP kind
of works on AArch64", what does that mean to a user?
It also comes back to what the nature of the release is. For me, it's
a periodic best-effort-stability snapshot of what we've got, which
packagers and other downstream folks build on.
More information about the llvm-dev