Oh it's "documented" - great.. well that doesn't give any weight to if it works and how robust. Is there tests for these features or not? I know if I wanted to add or change *anything* a test would be required. On Mon, Oct 3, 2016 at 10:11 PM, Zachary Turner <zturner at google.com> wrote:> It's documented here > > http://clang.llvm.org/cxx_status.html > > On Mon, Oct 3, 2016 at 4:00 AM C Bergström <cbergstrom at pathscale.com> wrote: >> >> I see a lot of people talking about c++14 and *maybe* clang-N.N.N will >> support it, but is there any tests which can be used to >> actually/tangibly verify this? >> >> Is there tests for the features being proposed to take advantage of? >> It would be prudent to ensure there's tests available to verify on >> buildbots before any decision to switch is made. >> >> Break this into steps and it becomes a plan instead of just tossing >> opinions around. >> >> From what I read so far - I'd speculate that only old Linux and NetBSD >> will have an issue with the bump. Worst case those platforms need an >> extra step to bootstrap, but should that hold everything back? Either >> newer clang is good enough to replace the older version or it's not. >> However, testing as a pre-cursor and getting facts is important. >> >> #1 Tests for the features >> #2 Bug tracker to identify any regressions blocking updating >> #3 Buildbots to verify >> >> On Mon, Oct 3, 2016 at 6:49 PM, Dimitry Andric via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >> > I wasn't able to find that information on the distrowatch page you >> > linked, but I will assume that it is talking about the available ports, e.g. >> > packages external to the FreeBSD base system. In the FreeBSD ports >> > collection, we have clang 3.3 through 3.9 available, and a 4.0 trunk >> > snapshot as of 2016-08-24. >> > >> > On the other hand, the base system is a little different, in the sense >> > that we use clang to bootstrap the whole system, and use the FreeBSD build >> > system instead of llvm/clang's native build system. Also, we don't have all >> > the additional tools like llc, opt, and so on, by default. >> > >> > FreeBSD 10.3 currently has clang 3.4.1, with libc++ from around that >> > time, plus a bunch of patches. I think it will be able to do most of C++14, >> > except maybe some corner cases. >> > >> > FreeBSD 11.0 (which is going to ship any day now) has clang 3.8.0, with >> > libc++ 3.8.0. >> > >> > I'm currently working on importing clang 3.9.0 into FreeBSD 12 (the >> > development version) together with libc++ 3.9.0, compiler-rt 3.9.0 and so >> > on. These will hopefully land before the end of this month. After about a >> > month, I will merge it all into FreeBSD 11, so it will end up in FreeBSD >> > 11.1. >> > >> > -Dimitry >> > >> >> On 03 Oct 2016, at 05:43, Zachary Turner via llvm-dev >> >> <llvm-dev at lists.llvm.org> wrote: >> >> >> >> For anyone still on gcc 4.2.1, then I think this entire discussion is >> >> kind of irrelevant, because they are already having to build a new toolchain >> >> to compile LLVM, since the minimum is currently 4.7. So for those people, I >> >> would imagine 4.7 vs. 4.9 makes no difference? >> >> >> >> Maybe I'm misunderstanding the table of the distrowatch page, but if >> >> FreeBSD 11 has clang 3.8 as you say, why does distrowatch say FreeBSD 10 and >> >> 11 have clang 3.9? >> >> >> >> On Sun, Oct 2, 2016 at 7:10 PM Krzysztof Parzyszek via llvm-dev >> >> <llvm-dev at lists.llvm.org> wrote: >> >> On 10/2/2016 6:09 PM, Zachary Turner via llvm-dev wrote: >> >> > The BSDs don't seem as much of an issue. FreeBSD 10 and 11 both have >> >> > LLVM 3.9 and GCC 4.9. NetBSD 6.1.5 and 7.0 both have GCC 5.3 and >> >> > LLVM >> >> > 3.8. Open BSD has a very old GCC, but distrowatch claims that it >> >> > also >> >> > has LLVM 3.8. >> >> >> >> FreeBSD 11 has clang 3.8.0. There is gcc in the /usr/src/contrib, but >> >> that's 4.2.1. There are still platforms that FreeBSD supports that >> >> have >> >> not finished moving to clang (from gcc 4.2.1). >> >> >> >> -Krzysztof >> >> _______________________________________________ >> >> LLVM Developers mailing list >> >> llvm-dev at lists.llvm.org >> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> _______________________________________________ >> >> LLVM Developers mailing list >> >> llvm-dev at lists.llvm.org >> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > >> > >> > _______________________________________________ >> > LLVM Developers mailing list >> > llvm-dev at lists.llvm.org >> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >
On Mon, Oct 3, 2016 at 9:11 AM C Bergström <cbergstrom at pathscale.com> wrote:> Oh it's "documented" - great.. well that doesn't give any weight to if > it works and how robust. Is there tests for these features or not? I > know if I wanted to add or change *anything* a test would be required. >By the same logic, why wouldn't there be tests for these features? How would one go about adding core C++ language constructs to clang without adding tests for them? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161003/d59781c9/attachment.html>
----- Original Message -----> From: "C Bergström via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Zachary Turner" <zturner at google.com> > Cc: "LLVM Developers Mailing List" <llvm-dev at lists.llvm.org> > Sent: Monday, October 3, 2016 11:11:03 AM > Subject: Re: [llvm-dev] Using C++14 code in LLVM > > Oh it's "documented" - great.. well that doesn't give any weight to > if > it works and how robust. Is there tests for these features or not? I > know if I wanted to add or change *anything* a test would be > required.What kind of tests do you mean? Of course all of the individual features have regression tests, and as documented, we believe the feature set to be complete. We don't have any kind of omnibus C++14 test or a separate test directory just for C++14 conformance. -Hal> > On Mon, Oct 3, 2016 at 10:11 PM, Zachary Turner <zturner at google.com> > wrote: > > It's documented here > > > > http://clang.llvm.org/cxx_status.html > > > > On Mon, Oct 3, 2016 at 4:00 AM C Bergström > > <cbergstrom at pathscale.com> wrote: > >> > >> I see a lot of people talking about c++14 and *maybe* clang-N.N.N > >> will > >> support it, but is there any tests which can be used to > >> actually/tangibly verify this? > >> > >> Is there tests for the features being proposed to take advantage > >> of? > >> It would be prudent to ensure there's tests available to verify on > >> buildbots before any decision to switch is made. > >> > >> Break this into steps and it becomes a plan instead of just > >> tossing > >> opinions around. > >> > >> From what I read so far - I'd speculate that only old Linux and > >> NetBSD > >> will have an issue with the bump. Worst case those platforms need > >> an > >> extra step to bootstrap, but should that hold everything back? > >> Either > >> newer clang is good enough to replace the older version or it's > >> not. > >> However, testing as a pre-cursor and getting facts is important. > >> > >> #1 Tests for the features > >> #2 Bug tracker to identify any regressions blocking updating > >> #3 Buildbots to verify > >> > >> On Mon, Oct 3, 2016 at 6:49 PM, Dimitry Andric via llvm-dev > >> <llvm-dev at lists.llvm.org> wrote: > >> > I wasn't able to find that information on the distrowatch page > >> > you > >> > linked, but I will assume that it is talking about the available > >> > ports, e.g. > >> > packages external to the FreeBSD base system. In the FreeBSD > >> > ports > >> > collection, we have clang 3.3 through 3.9 available, and a 4.0 > >> > trunk > >> > snapshot as of 2016-08-24. > >> > > >> > On the other hand, the base system is a little different, in the > >> > sense > >> > that we use clang to bootstrap the whole system, and use the > >> > FreeBSD build > >> > system instead of llvm/clang's native build system. Also, we > >> > don't have all > >> > the additional tools like llc, opt, and so on, by default. > >> > > >> > FreeBSD 10.3 currently has clang 3.4.1, with libc++ from around > >> > that > >> > time, plus a bunch of patches. I think it will be able to do > >> > most of C++14, > >> > except maybe some corner cases. > >> > > >> > FreeBSD 11.0 (which is going to ship any day now) has clang > >> > 3.8.0, with > >> > libc++ 3.8.0. > >> > > >> > I'm currently working on importing clang 3.9.0 into FreeBSD 12 > >> > (the > >> > development version) together with libc++ 3.9.0, compiler-rt > >> > 3.9.0 and so > >> > on. These will hopefully land before the end of this month. > >> > After about a > >> > month, I will merge it all into FreeBSD 11, so it will end up in > >> > FreeBSD > >> > 11.1. > >> > > >> > -Dimitry > >> > > >> >> On 03 Oct 2016, at 05:43, Zachary Turner via llvm-dev > >> >> <llvm-dev at lists.llvm.org> wrote: > >> >> > >> >> For anyone still on gcc 4.2.1, then I think this entire > >> >> discussion is > >> >> kind of irrelevant, because they are already having to build a > >> >> new toolchain > >> >> to compile LLVM, since the minimum is currently 4.7. So for > >> >> those people, I > >> >> would imagine 4.7 vs. 4.9 makes no difference? > >> >> > >> >> Maybe I'm misunderstanding the table of the distrowatch page, > >> >> but if > >> >> FreeBSD 11 has clang 3.8 as you say, why does distrowatch say > >> >> FreeBSD 10 and > >> >> 11 have clang 3.9? > >> >> > >> >> On Sun, Oct 2, 2016 at 7:10 PM Krzysztof Parzyszek via llvm-dev > >> >> <llvm-dev at lists.llvm.org> wrote: > >> >> On 10/2/2016 6:09 PM, Zachary Turner via llvm-dev wrote: > >> >> > The BSDs don't seem as much of an issue. FreeBSD 10 and 11 > >> >> > both have > >> >> > LLVM 3.9 and GCC 4.9. NetBSD 6.1.5 and 7.0 both have GCC 5.3 > >> >> > and > >> >> > LLVM > >> >> > 3.8. Open BSD has a very old GCC, but distrowatch claims > >> >> > that it > >> >> > also > >> >> > has LLVM 3.8. > >> >> > >> >> FreeBSD 11 has clang 3.8.0. There is gcc in the > >> >> /usr/src/contrib, but > >> >> that's 4.2.1. There are still platforms that FreeBSD supports > >> >> that > >> >> have > >> >> not finished moving to clang (from gcc 4.2.1). > >> >> > >> >> -Krzysztof > >> >> _______________________________________________ > >> >> LLVM Developers mailing list > >> >> llvm-dev at lists.llvm.org > >> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >> >> _______________________________________________ > >> >> LLVM Developers mailing list > >> >> llvm-dev at lists.llvm.org > >> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >> > > >> > > >> > _______________________________________________ > >> > LLVM Developers mailing list > >> > llvm-dev at lists.llvm.org > >> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >> > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-- Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory
What concerns me the most is not “is this feature present?”, but rather “is it good enough to build trunk?”. The fact that clang-3.4 shipped with support for a specific feature does not mean the compiler couldn’t crash or miscompile under some very specific conditions when using this feature. So I don’t see much interested in a test that shows the feature “works” with (rather “is present in”) clang-3.4, I’m interested in continuously testing that clang-3.4 can build trunk, always. Even today, we claim to support building with clang-3.1 but are we testing it? Is there a bot building trunk with 3.1? — Mehdi> On Oct 3, 2016, at 9:11 AM, C Bergström via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Oh it's "documented" - great.. well that doesn't give any weight to if > it works and how robust. Is there tests for these features or not? I > know if I wanted to add or change *anything* a test would be required. > > On Mon, Oct 3, 2016 at 10:11 PM, Zachary Turner <zturner at google.com> wrote: >> It's documented here >> >> http://clang.llvm.org/cxx_status.html >> >> On Mon, Oct 3, 2016 at 4:00 AM C Bergström <cbergstrom at pathscale.com> wrote: >>> >>> I see a lot of people talking about c++14 and *maybe* clang-N.N.N will >>> support it, but is there any tests which can be used to >>> actually/tangibly verify this? >>> >>> Is there tests for the features being proposed to take advantage of? >>> It would be prudent to ensure there's tests available to verify on >>> buildbots before any decision to switch is made. >>> >>> Break this into steps and it becomes a plan instead of just tossing >>> opinions around. >>> >>> From what I read so far - I'd speculate that only old Linux and NetBSD >>> will have an issue with the bump. Worst case those platforms need an >>> extra step to bootstrap, but should that hold everything back? Either >>> newer clang is good enough to replace the older version or it's not. >>> However, testing as a pre-cursor and getting facts is important. >>> >>> #1 Tests for the features >>> #2 Bug tracker to identify any regressions blocking updating >>> #3 Buildbots to verify >>> >>> On Mon, Oct 3, 2016 at 6:49 PM, Dimitry Andric via llvm-dev >>> <llvm-dev at lists.llvm.org> wrote: >>>> I wasn't able to find that information on the distrowatch page you >>>> linked, but I will assume that it is talking about the available ports, e.g. >>>> packages external to the FreeBSD base system. In the FreeBSD ports >>>> collection, we have clang 3.3 through 3.9 available, and a 4.0 trunk >>>> snapshot as of 2016-08-24. >>>> >>>> On the other hand, the base system is a little different, in the sense >>>> that we use clang to bootstrap the whole system, and use the FreeBSD build >>>> system instead of llvm/clang's native build system. Also, we don't have all >>>> the additional tools like llc, opt, and so on, by default. >>>> >>>> FreeBSD 10.3 currently has clang 3.4.1, with libc++ from around that >>>> time, plus a bunch of patches. I think it will be able to do most of C++14, >>>> except maybe some corner cases. >>>> >>>> FreeBSD 11.0 (which is going to ship any day now) has clang 3.8.0, with >>>> libc++ 3.8.0. >>>> >>>> I'm currently working on importing clang 3.9.0 into FreeBSD 12 (the >>>> development version) together with libc++ 3.9.0, compiler-rt 3.9.0 and so >>>> on. These will hopefully land before the end of this month. After about a >>>> month, I will merge it all into FreeBSD 11, so it will end up in FreeBSD >>>> 11.1. >>>> >>>> -Dimitry >>>> >>>>> On 03 Oct 2016, at 05:43, Zachary Turner via llvm-dev >>>>> <llvm-dev at lists.llvm.org> wrote: >>>>> >>>>> For anyone still on gcc 4.2.1, then I think this entire discussion is >>>>> kind of irrelevant, because they are already having to build a new toolchain >>>>> to compile LLVM, since the minimum is currently 4.7. So for those people, I >>>>> would imagine 4.7 vs. 4.9 makes no difference? >>>>> >>>>> Maybe I'm misunderstanding the table of the distrowatch page, but if >>>>> FreeBSD 11 has clang 3.8 as you say, why does distrowatch say FreeBSD 10 and >>>>> 11 have clang 3.9? >>>>> >>>>> On Sun, Oct 2, 2016 at 7:10 PM Krzysztof Parzyszek via llvm-dev >>>>> <llvm-dev at lists.llvm.org> wrote: >>>>> On 10/2/2016 6:09 PM, Zachary Turner via llvm-dev wrote: >>>>>> The BSDs don't seem as much of an issue. FreeBSD 10 and 11 both have >>>>>> LLVM 3.9 and GCC 4.9. NetBSD 6.1.5 and 7.0 both have GCC 5.3 and >>>>>> LLVM >>>>>> 3.8. Open BSD has a very old GCC, but distrowatch claims that it >>>>>> also >>>>>> has LLVM 3.8. >>>>> >>>>> FreeBSD 11 has clang 3.8.0. There is gcc in the /usr/src/contrib, but >>>>> that's 4.2.1. There are still platforms that FreeBSD supports that >>>>> have >>>>> not finished moving to clang (from gcc 4.2.1). >>>>> >>>>> -Krzysztof >>>>> _______________________________________________ >>>>> LLVM Developers mailing list >>>>> llvm-dev at lists.llvm.org >>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>>> _______________________________________________ >>>>> LLVM Developers mailing list >>>>> llvm-dev at lists.llvm.org >>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>> >>>> >>>> _______________________________________________ >>>> LLVM Developers mailing list >>>> llvm-dev at lists.llvm.org >>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>> > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> writes:> What concerns me the most is not “is this feature present?”, but > rather “is it good enough to build trunk?”. > The fact that clang-3.4 shipped with support for a specific feature > does not mean the compiler couldn’t crash or miscompile under some > very specific conditions when using this feature. > > So I don’t see much interested in a test that shows the feature > “works” with (rather “is present in”) clang-3.4, I’m interested in > continuously testing that clang-3.4 can build trunk, always. > > Even today, we claim to support building with clang-3.1 but are we > testing it? Is there a bot building trunk with 3.1?The claim that we support building with clang 3.1 is a blatant lie. For example, that version of clang won't even allow the override keyword without also specifying virtual (which we explicitly choose not to do in LLVM style). Realistically, our actual minimum version of clang today is 3.3 or 3.4, and no, we aren't currently testing this at all.> — > Mehdi > > >> On Oct 3, 2016, at 9:11 AM, C Bergström via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >> >> Oh it's "documented" - great.. well that doesn't give any weight to if >> it works and how robust. Is there tests for these features or not? I >> know if I wanted to add or change *anything* a test would be required. >> >> On Mon, Oct 3, 2016 at 10:11 PM, Zachary Turner <zturner at google.com> wrote: >>> It's documented here >>> >>> http://clang.llvm.org/cxx_status.html >>> >>> On Mon, Oct 3, 2016 at 4:00 AM C Bergström <cbergstrom at pathscale.com> wrote: >>>> >>>> I see a lot of people talking about c++14 and *maybe* clang-N.N.N will >>>> support it, but is there any tests which can be used to >>>> actually/tangibly verify this? >>>> >>>> Is there tests for the features being proposed to take advantage of? >>>> It would be prudent to ensure there's tests available to verify on >>>> buildbots before any decision to switch is made. >>>> >>>> Break this into steps and it becomes a plan instead of just tossing >>>> opinions around. >>>> >>>> From what I read so far - I'd speculate that only old Linux and NetBSD >>>> will have an issue with the bump. Worst case those platforms need an >>>> extra step to bootstrap, but should that hold everything back? Either >>>> newer clang is good enough to replace the older version or it's not. >>>> However, testing as a pre-cursor and getting facts is important. >>>> >>>> #1 Tests for the features >>>> #2 Bug tracker to identify any regressions blocking updating >>>> #3 Buildbots to verify >>>> >>>> On Mon, Oct 3, 2016 at 6:49 PM, Dimitry Andric via llvm-dev >>>> <llvm-dev at lists.llvm.org> wrote: >>>>> I wasn't able to find that information on the distrowatch page you >>>>> linked, but I will assume that it is talking about the available >>>>> ports, e.g. >>>>> packages external to the FreeBSD base system. In the FreeBSD ports >>>>> collection, we have clang 3.3 through 3.9 available, and a 4.0 trunk >>>>> snapshot as of 2016-08-24. >>>>> >>>>> On the other hand, the base system is a little different, in the sense >>>>> that we use clang to bootstrap the whole system, and use the FreeBSD build >>>>> system instead of llvm/clang's native build system. Also, we >>>>> don't have all >>>>> the additional tools like llc, opt, and so on, by default. >>>>> >>>>> FreeBSD 10.3 currently has clang 3.4.1, with libc++ from around that >>>>> time, plus a bunch of patches. I think it will be able to do >>>>> most of C++14, >>>>> except maybe some corner cases. >>>>> >>>>> FreeBSD 11.0 (which is going to ship any day now) has clang 3.8.0, with >>>>> libc++ 3.8.0. >>>>> >>>>> I'm currently working on importing clang 3.9.0 into FreeBSD 12 (the >>>>> development version) together with libc++ 3.9.0, compiler-rt 3.9.0 and so >>>>> on. These will hopefully land before the end of this month. After about a >>>>> month, I will merge it all into FreeBSD 11, so it will end up in FreeBSD >>>>> 11.1. >>>>> >>>>> -Dimitry >>>>> >>>>>> On 03 Oct 2016, at 05:43, Zachary Turner via llvm-dev >>>>>> <llvm-dev at lists.llvm.org> wrote: >>>>>> >>>>>> For anyone still on gcc 4.2.1, then I think this entire discussion is >>>>>> kind of irrelevant, because they are already having to build a >>>>>> new toolchain >>>>>> to compile LLVM, since the minimum is currently 4.7. So for >>>>>> those people, I >>>>>> would imagine 4.7 vs. 4.9 makes no difference? >>>>>> >>>>>> Maybe I'm misunderstanding the table of the distrowatch page, but if >>>>>> FreeBSD 11 has clang 3.8 as you say, why does distrowatch say >>>>>> FreeBSD 10 and >>>>>> 11 have clang 3.9? >>>>>> >>>>>> On Sun, Oct 2, 2016 at 7:10 PM Krzysztof Parzyszek via llvm-dev >>>>>> <llvm-dev at lists.llvm.org> wrote: >>>>>> On 10/2/2016 6:09 PM, Zachary Turner via llvm-dev wrote: >>>>>>> The BSDs don't seem as much of an issue. FreeBSD 10 and 11 both have >>>>>>> LLVM 3.9 and GCC 4.9. NetBSD 6.1.5 and 7.0 both have GCC 5.3 and >>>>>>> LLVM >>>>>>> 3.8. Open BSD has a very old GCC, but distrowatch claims that it >>>>>>> also >>>>>>> has LLVM 3.8. >>>>>> >>>>>> FreeBSD 11 has clang 3.8.0. There is gcc in the /usr/src/contrib, but >>>>>> that's 4.2.1. There are still platforms that FreeBSD supports that >>>>>> have >>>>>> not finished moving to clang (from gcc 4.2.1). >>>>>> >>>>>> -Krzysztof >>>>>> _______________________________________________ >>>>>> LLVM Developers mailing list >>>>>> llvm-dev at lists.llvm.org >>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>>>> _______________________________________________ >>>>>> LLVM Developers mailing list >>>>>> llvm-dev at lists.llvm.org >>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>>> >>>>> >>>>> _______________________________________________ >>>>> LLVM Developers mailing list >>>>> llvm-dev at lists.llvm.org >>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>>> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev