llvm dev - Feb 2017 - [cfe-dev] [Release-testers] [4.0.0 Release] Release Candidate 2 has been tagged

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
releases.

Hans,

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?

cheers,
--renato

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
> releases.
>
> Hans,
>
> 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.

On 10 February 2017 at 22:23, Hans Wennborg <hans at chromium.org>
wrote:
> 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?
The idea was to just separate in two classes: supported/not supported.

> 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.
That's why I haven't bothered doing it, so far. What we can do is to
continue not doing it until someone really complains, than we try to
find a good solution.

cheers,
--renato