"C. Bergström"
2013-Oct-29 00:06 UTC
[LLVMdev] [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers
On 10/29/13 06:52 AM, Chandler Carruth wrote:> > On Mon, Oct 28, 2013 at 4:47 PM, "C. Bergström" > <cbergstrom at pathscale.com <mailto:cbergstrom at pathscale.com>> wrote: > > For those driving c++11 in clang/llvm - Would it generally be > acceptable to have a "sunrise" period where the preliminary > evaluation has been done (buildbots, compiler evaluate.. etc) and > the 1st actual c++11 commit hits the repo. (30-60 days?) > > > I really don't think we need this level of complexity to the planning. > I think we can give a heads up at a high level (as already discussed), > check the build bots are updated, and flip the switch.fuzzy://How much "heads up"> > ------------- > My concern/thoughts - When we swap out STDCXX for libc++ - We > aren't able to self host clang. > > > No part of this relies on using libc++ on Linux instead of libstdc++. > That's an orthogonal issue which I'm not even attempting to address. > > Certainly, the platforms with only libc++ are self hosting clang > successfully today.Hmm....> > This could be entirely *our* fault, but it hasn't been > investigated extensively. (We also see Perennial C++ testsuite > regressions which appear to come from libc++, but also not > investiaged/confirmed) Having a sunrise period would allow us to > investigate this as well as report any potentially blocking problems. > > Having a gnu-free self hosting[1] policy attached to this would > also be great - that makes a potentially easier backup solution to > anyone on [linux] with older gnu compilers > > > Absolutely not. I really don't want to tie this to more things. If you > think we should pursue such a goal, fine, but it is independent of the > decision about using C++11, and not something I'm currently striving for.-1 If we do it - we should do it properly. --------- I'm strongly against anything which forces this to rely on gnu runtime and libs. --------- Further - While c++11 is the best thing ever - Is there actually a driving use case where using c++11 features will significantly improve the quality of the codebase? implementation perspective or performance? Are there coding style guidelines which should be updated - I've seen code (ab)using auto where it was mostly author preference and not really necessary. You really push for this, but the underlying motivation still seems unclear. (Show me the c++11 code in the subproject which is the root cause please)
Chandler Carruth
2013-Oct-29 00:27 UTC
[LLVMdev] [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers
On Mon, Oct 28, 2013 at 5:06 PM, "C. Bergström" <cbergstrom at pathscale.com>wrote:> fuzzy://How much "heads up"One full release cycle, so approximately 6 months before a release incorporating this. In addition, probably several weeks to a month between the initial branch for the 3.4 release and the commits that make this so. Still more weeks between when we put it into the release notes for 3.4 and blog about it.> -1 > If we do it - we should do it properly. >We're not talking about doing it improperly, but about doing two independent things independently.> --------- > I'm strongly against anything which forces this to rely on gnu runtime and > libs. >You are not being forced to rely on anything. Many people have successfully bootstrapped with libc++, and if you find issues with your setup doing such a bootstrap, patches to fix that would be very welcome. And moreover, a requirement to not use GNU runtimes or libraries in the bootstrap would be totally novel for the project. LLVM and Clang require xlC and MSVC to bootstrap on certain platforms, and you're OK with that? There are plenty of platforms with no Clang port at all but where GCC works fine, and we rely on a GCC host there. This is not new, and not something we should burden the discussion about C++11 features with.> --------- > Further - While c++11 is the best thing ever - Is there actually a driving > use case where using c++11 features will significantly improve the quality > of the codebase?Yes. See my first email for some of them. See numerous other discussions. Have you tried writing any code with C++11?> implementation perspective or performance?We get most of this already today, but it would be cleaner if we just admitted we rely on it.> Are there coding style guidelines which should be updated - I've seen code > (ab)using auto where it was mostly author preference and not really > necessary.Yes, and we have code review for this. If you would like to help review patches for high quality usage of C++11 constructs, that would be welcome.> You really push for this, but the underlying motivation still seems > unclear. (Show me the c++11 code in the subproject which is the root cause > please) >I don't know how it could be unclear. I spelled out reasons in my first email. There was a more thorough discussion in past threads on this subject. I'm not going to repeat myself here. And it should be quite obvious that LLD is actively using C++11 code to good effect? That was discussed extensively when the project was added. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131028/8e2b8988/attachment.html>
"C. Bergström"
2013-Oct-29 01:07 UTC
[LLVMdev] [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers
On 10/29/13 07:27 AM, Chandler Carruth wrote:> On Mon, Oct 28, 2013 at 5:06 PM, "C. Bergström" > <cbergstrom at pathscale.com <mailto:cbergstrom at pathscale.com>> wrote: > > fuzzy://How much "heads up" > > > One full release cycle, so approximately 6 months before a releaseIf it's 3-6 months from *today* before something hits clang svn trunk that should be enough time to address any problems. (Such as testing libc++ more extensively and or sending any patches if necessary) I don't know the 3.4 release timeline and if you want to adopt this immediately after that has branched. [My other points below can be ignored if this is true] ---------------------------------> incorporating this. In addition, probably several weeks to a month > between the initial branch for the 3.4 release and the commits that > make this so. Still more weeks between when we put it into the release > notes for 3.4 and blog about it. > > -1 > If we do it - we should do it properly. > > > We're not talking about doing it improperly, but about doing two > independent things independently. > > --------- > I'm strongly against anything which forces this to rely on gnu > runtime and libs. > > > You are not being forced to rely on anything. Many people have > successfully bootstrapped with libc++, and if you find issues with > your setup doing such a bootstrap, patches to fix that would be very > welcome. > > And moreover, a requirement to not use GNU runtimes or libraries in > the bootstrap would be totally novel for the project. LLVM and Clang > require xlC and MSVC to bootstrap on certain platforms, and you're OK > with that? There are plenty of platforms with no Clang port at all but > where GCC works fine, and we rely on a GCC host there. This is not > new, and not something we should burden the discussion about C++11 > features with.On linux amd64/intel64 is what I meant by "regression". The other platforms you reference are still work-in-progress. It wasn't my intention to include them as a blocker - (just to clarify)> > --------- > Further - While c++11 is the best thing ever - Is there actually a > driving use case where using c++11 features will significantly > improve the quality of the codebase? > > > Yes. See my first email for some of them. See numerous other > discussions. Have you tried writing any code with C++11?Cherry picking the points from your original email.> > Some notable features we would get to use: > > - r-value references, move semantics, etc > - auto > - range for loops > - lambdas > - static_assert > - nullptr > - std::unique_ptr, std::tuple, some other nice library stuff > >I'd love to see/review an updated style guideline before anything hits SVN trunk so that it's super clear on what's allowed. Maybe I'm too conservative, but it's still fuzzy on how using some of those features would benefit the compiler internally. Usage of c++11 code in applications (chrome) and the compiler are 2 different worlds to me. You ask if I write c++11 codes - No, but increasingly I do see it being used in production and forced to deal with it. Sometimes it makes sense and sometimes I think meh or wtf - If it doesn't make the code: a. easier to read b. easier to write c. higher performance it has no value or negative value. -------------------------- I don't mean to nit-pick||troll and I'm not opposed to this idea at all - I just like to have specifics and facts. (Please feel free to ignore these questions below)> It also would have the benefit of removing divergence between LLVM > sub-projects already using C++11 featuresWhich sub-projects would this benefit?> > There is increasing pressure for LLVM to make use of new C++ language > and library features.pressure from where? (sub-projects, google.. ?)> > I have historically been more conservative on this topic, but > listening to many people and looking at some of the C++ features we > are missingwatercooler or mailing list?> > > These days, this list seems increasingly worth the cost of forcing > users to get a modern toolchain onto their systems. >I'm all for modern toolchains, but a modern toolchain requirement and depending on c++11 features are independent issues. You could make a policy that ______ doesn't care about building and supporting gcc-3.x on ________ old ${platform} - I'm cool with that, but it doesn't mean we must rely on c++11 in the process.
Kristof Beyls
2013-Oct-29 14:54 UTC
[LLVMdev] [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers
I agree that a reasonable amount of notice should be given before making the switch on top-of-trunk. Quite a few out-of-tree projects try to stay close to top-of-trunk, and I think that’s a good thing, since it provides quick detection & feedback on regressions breaking out-of-tree projects. To increase the likelihood that out-of-tree projects keep on following top-of-trunk closely, I think it’s necessary to also clearly announce (on this list) well in advance (e.g. at least one month, ideally more) when the minimum requirements on tools needed to build LLVM change. Thanks, Kristof From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Chandler Carruth Sent: 29 October 2013 00:27 To: C. Bergström Cc: clang-dev Developers; LLVM Developers Mailing List Subject: Re: [LLVMdev] [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers On Mon, Oct 28, 2013 at 5:06 PM, "C. Bergström" <cbergstrom at pathscale.com> wrote: fuzzy://How much "heads up" One full release cycle, so approximately 6 months before a release incorporating this. In addition, probably several weeks to a month between the initial branch for the 3.4 release and the commits that make this so. Still more weeks between when we put it into the release notes for 3.4 and blog about it. -1 If we do it - we should do it properly. We're not talking about doing it improperly, but about doing two independent things independently. --------- I'm strongly against anything which forces this to rely on gnu runtime and libs. You are not being forced to rely on anything. Many people have successfully bootstrapped with libc++, and if you find issues with your setup doing such a bootstrap, patches to fix that would be very welcome. And moreover, a requirement to not use GNU runtimes or libraries in the bootstrap would be totally novel for the project. LLVM and Clang require xlC and MSVC to bootstrap on certain platforms, and you're OK with that? There are plenty of platforms with no Clang port at all but where GCC works fine, and we rely on a GCC host there. This is not new, and not something we should burden the discussion about C++11 features with. --------- Further - While c++11 is the best thing ever - Is there actually a driving use case where using c++11 features will significantly improve the quality of the codebase? Yes. See my first email for some of them. See numerous other discussions. Have you tried writing any code with C++11? implementation perspective or performance? We get most of this already today, but it would be cleaner if we just admitted we rely on it. Are there coding style guidelines which should be updated - I've seen code (ab)using auto where it was mostly author preference and not really necessary. Yes, and we have code review for this. If you would like to help review patches for high quality usage of C++11 constructs, that would be welcome. You really push for this, but the underlying motivation still seems unclear. (Show me the c++11 code in the subproject which is the root cause please) I don't know how it could be unclear. I spelled out reasons in my first email. There was a more thorough discussion in past threads on this subject. I'm not going to repeat myself here. And it should be quite obvious that LLD is actively using C++11 code to good effect? That was discussed extensively when the project was added. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131029/ecb42423/attachment.html>
Maybe Matching Threads
- [LLVMdev] [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers
- [LLVMdev] [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers
- [LLVMdev] [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers
- [LLVMdev] [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers
- [LLVMdev] [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers