Justin Holewinski
2013-Jan-11 13:02 UTC
[LLVMdev] Using C++'11 language features in LLVM itself
Alright, trying to get this conversation back on track... It seems as though the question to ask is: do the benefits of the C++11 features we want outweigh the cost of alienating users of older compilers? For Mac, the question seems almost moot since clang is a fully-supported compiler. On Linux, it is most often (always?) possible to bootstrap clang or a newer GCC, so a baseline like 4.5/4.6 does not seem unreasonable. Seems like the same should be true for the BSDs. It may be a bit of work to set up, but it should be a one-time deal. Once a clang 3.1/3.2 binary is available, all is well. The problem child, so to speak, is Windows. I strongly suggest that support for MSVC *not* be dropped. There are many users out there relying on this support. That said, I think MSVC 2010 is a reasonable target, at least for 3.3. And then perhaps move to MSVC 2012 for 3.4. That should allow for enough time for users to upgrade. So, can we limit ourselves to MSVC 2010-level support for 3.3? On Thu, Jan 10, 2013 at 6:45 PM, Óscar Fuentes <ofv at wanadoo.es> wrote:> "Daniels, Marcus G" <mdaniels at lanl.gov> writes: > > [snip] > > It is obvious that you don't develop C++ software on Windows for a > living. > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-- Thanks, Justin Holewinski -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130111/6c5f5131/attachment.html>
Michael Spencer
2013-Jan-11 13:21 UTC
[LLVMdev] Using C++'11 language features in LLVM itself
On Fri, Jan 11, 2013 at 5:02 AM, Justin Holewinski <justin.holewinski at gmail.com> wrote:> Alright, trying to get this conversation back on track... > > It seems as though the question to ask is: do the benefits of the C++11 > features we want outweigh the cost of alienating users of older compilers? > For Mac, the question seems almost moot since clang is a fully-supported > compiler. On Linux, it is most often (always?) possible to bootstrap clang > or a newer GCC, so a baseline like 4.5/4.6 does not seem unreasonable. > Seems like the same should be true for the BSDs. It may be a bit of work to > set up, but it should be a one-time deal. Once a clang 3.1/3.2 binary is > available, all is well. The problem child, so to speak, is Windows. I > strongly suggest that support for MSVC *not* be dropped. There are many > users out there relying on this support. That said, I think MSVC 2010 is a > reasonable target, at least for 3.3. And then perhaps move to MSVC 2012 for > 3.4. That should allow for enough time for users to upgrade. > > So, can we limit ourselves to MSVC 2010-level support for 3.3?I'm happy with this overall. It will let us get started now, we don't need to jump as far as possible right away. And I don't believe anyone said that they can't at least use 2010. We just need a hard decision on minimum supported gcc so we can figure out _exactly_ what features we can use. - Michael Spencer> > > On Thu, Jan 10, 2013 at 6:45 PM, Óscar Fuentes <ofv at wanadoo.es> wrote: >> >> "Daniels, Marcus G" <mdaniels at lanl.gov> writes: >> >> [snip] >> >> It is obvious that you don't develop C++ software on Windows for a >> living. >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > > -- > > Thanks, > > Justin Holewinski > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
Andrew Lenharth
2013-Jan-11 13:43 UTC
[LLVMdev] Using C++'11 language features in LLVM itself
On Fri, Jan 11, 2013 at 7:21 AM, Michael Spencer <bigcheesegs at gmail.com> wrote:> > On Fri, Jan 11, 2013 at 5:02 AM, Justin Holewinski > <justin.holewinski at gmail.com> wrote: > > Alright, trying to get this conversation back on track... > > > > It seems as though the question to ask is: do the benefits of the C++11 > > features we want outweigh the cost of alienating users of older compilers? > > For Mac, the question seems almost moot since clang is a fully-supported > > compiler. On Linux, it is most often (always?) possible to bootstrap clang > > or a newer GCC, so a baseline like 4.5/4.6 does not seem unreasonable. > > Seems like the same should be true for the BSDs. It may be a bit of work to > > set up, but it should be a one-time deal. Once a clang 3.1/3.2 binary is > > available, all is well. The problem child, so to speak, is Windows. I > > strongly suggest that support for MSVC *not* be dropped. There are many > > users out there relying on this support. That said, I think MSVC 2010 is a > > reasonable target, at least for 3.3. And then perhaps move to MSVC 2012 for > > 3.4. That should allow for enough time for users to upgrade. > > > > So, can we limit ourselves to MSVC 2010-level support for 3.3? > > I'm happy with this overall. It will let us get started now, we don't > need to jump as far as possible right away. And I don't believe anyone > said that they can't at least use 2010. > > We just need a hard decision on minimum supported gcc so we can figure > out _exactly_ what features we can use.Any Redhat derivative will be running 4.4, and I tend to run into redhat derivatives (centos and scientific linux) fairly often at universities. Ubuntu 10.04 (LTS) also seems to be 4.4 as does Debian stable. Andrew> > - Michael Spencer > > > > > > > On Thu, Jan 10, 2013 at 6:45 PM, Óscar Fuentes <ofv at wanadoo.es> wrote: > >> > >> "Daniels, Marcus G" <mdaniels at lanl.gov> writes: > >> > >> [snip] > >> > >> It is obvious that you don't develop C++ software on Windows for a > >> living. > >> > >> _______________________________________________ > >> LLVM Developers mailing list > >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > > > > > > > -- > > > > Thanks, > > > > Justin Holewinski > > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Óscar Fuentes
2013-Jan-11 15:53 UTC
[LLVMdev] Using C++'11 language features in LLVM itself
Justin Holewinski <justin.holewinski at gmail.com> writes: [snip]> The problem child, so to speak, is Windows. I > strongly suggest that support for MSVC *not* be dropped.Oh! thank you! :-) Seriously, I don't see LLVM dropping MSVC support as long as the project exists.> There are many users out there relying on this support. That said, I > think MSVC 2010 is a reasonable target, at least for 3.3. And then > perhaps move to MSVC 2012 for 3.4. That should allow for enough time > for users to upgrade. > > So, can we limit ourselves to MSVC 2010-level support for 3.3?Make that 3.4, at least (that's a year from now.) Sorry for my blunt response on my previous message, but it seems that some *nix types think that upgrading VS versions is more or less the same as going from GCC 4.x to 4.x+1, and that MinGW is a viable replacement for every Windows C++ project. They are so wrong on both accounts.
Brooks Davis
2013-Jan-11 16:35 UTC
[LLVMdev] Using C++'11 language features in LLVM itself
On Fri, Jan 11, 2013 at 08:02:22AM -0500, Justin Holewinski wrote:> Alright, trying to get this conversation back on track... > > It seems as though the question to ask is: do the benefits of the C++11 > features we want outweigh the cost of alienating users of older compilers? > For Mac, the question seems almost moot since clang is a fully-supported > compiler. On Linux, it is most often (always?) possible to bootstrap clang > or a newer GCC, so a baseline like 4.5/4.6 does not seem unreasonable. > Seems like the same should be true for the BSDs. It may be a bit of work > to set up, but it should be a one-time deal. Once a clang 3.1/3.2 binary > is available, all is well. The problem child, so to speak, is Windows. I > strongly suggest that support for MSVC *not* be dropped. There are many > users out there relying on this support. That said, I think MSVC 2010 is a > reasonable target, at least for 3.3. And then perhaps move to MSVC 2012 > for 3.4. That should allow for enough time for users to upgrade.It's a bit more complex for FreeBSD (and probably the others) due to assumptions in our build system. If a version of LLVM does not compile with gcc 4.2.1 then the previous release will be the last version in the FreeBSD 9.x branch. That branch should last at least another three years. It is possible that FreeBSD 10.x (release probably a year away) could require a more modern compiler, but there are a number of build system change that would be required to make bootstrapping reasonably smooth. Right now we'd have to force anyone building on a non-x86 platform to install an external toolchain since clang 3.2 doesn't yet reliably target anything else for us. When you do move forward with C++11 features, it would be helpful if you made a long term commitment to limiting the feature set to those features in 3.2 or whatever ever release is the last with the current feature set. That way we can be assured that FreeBSD 9.<latest> users can build 10.x which is something we've guaranteed for a very long time. There will certainly be some fallout if we remove support for building from 8.x and 7.x without installing extra tools, but I think that will be manageable. Requiring C++11 library support would really hurt since we don't build it by default on 9. We could probably fix for at least x86 that, but it won't be trivial. From my perspective, I'd prefer to see one more llvm release that builds with gcc 4.2.1 because we've very close to having ARM be self-hosting and having that on 9 would be a good thing. -- Brooks -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130111/4185bf77/attachment.sig>
Chris Lattner
2013-Jan-11 18:46 UTC
[LLVMdev] Using C++'11 language features in LLVM itself
On Jan 11, 2013, at 8:35 AM, Brooks Davis <brooks at freebsd.org> wrote:> On Fri, Jan 11, 2013 at 08:02:22AM -0500, Justin Holewinski wrote: >> That said, I think MSVC 2010 is a reasonable target.Just MHO, but I think it is far too early to drop support for MSVC 2010.> It's a bit more complex for FreeBSD (and probably the others) due to > assumptions in our build system.That's what I figured. :-( I also really don't want to inconvenience FreeBSD right when you guys have switched to Clang!> When you do move forward with C++11 features, it would be helpful if > you made a long term commitment to limiting the feature set to those > features in 3.2 or whatever ever release is the last with the current > feature set.Yes, makes sense. We want to have a stated goal that we build with some specific minimum compiler versions.> From my perspective, I'd prefer to see one more llvm release that builds > with gcc 4.2.1 because we've very close to having ARM be self-hosting and > having that on 9 would be a good thing.I think that is perfectly reasonable. Based on the discussion in this thread my proposal is this: - LLVM 3.3 (~April/May 2013) has no C++'11 in it. - Limited C++'11 language features becomes ok after the 3.3 release branches. - We limit ourselves to the intersection of features supported by MSVC 2010, GCC 4.5, and Clang 3.1. - Down the road we can reevaluate and bump up the minimums when it makes sense. Does that seem reasonable - or at least acceptable - for everyone? -Chris
Possibly Parallel Threads
- [LLVMdev] Using C++'11 language features in LLVM itself
- [LLVMdev] Using C++'11 language features in LLVM itself
- [LLVMdev] Using C++'11 language features in LLVM itself
- [LLVMdev] Using C++'11 language features in LLVM itself
- [LLVMdev] Using C++'11 language features in LLVM itself