[llvm-dev] LLVM C++14/C++17 BoF - Summary

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

[llvm-dev] LLVM C++14/C++17 BoF - Summary

David Jones via llvm-dev
For those of you who were not able to attend the LLVM Developer Meeting (and as a recap for those who were), we had a productive BoF about enabling C++14 or C++17 in LLVM.  The outcome of this can be generally summarized as:

* There were no major objections to moving to C++14 / C++17 "as soon as possible"
* "As soon as possible" is not immediately, but we are currently targeting March of 2019 due to some downstream contributors' needing to resolve some blockages before it can be possible.
* There did not seem to be a strong sentiment that we should only move to C++14, so for the sake of this discussion we're assuming 17 unless someone presents a strong argument why 17 is *less* desirable than 14.

Minimum Compiler Versions for "Reasonable C++17 Support" (Mostly everything minus CTAD)
GCC - Version 7 [1]  (Version 8 for CTAD)
Clang - Version 4 [2]  (Version 5 for CTAD)
MSVC - 2017 Update 5 [3] (Update 7 for CTAD)

We plan to add a CMake warning if your compiler version is below these versions soon.  Around January, we will promote this to a CMake error which you must manually override by passing -DCMAKE_ALLLOW_DEPRECATED_COMPILER.

If I'm forgetting anything or misrepresenting anything that was said at the BoF please feel free to correct me.


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [cfe-dev] LLVM C++14/C++17 BoF - Summary

David Jones via llvm-dev

Thanks for the update Zachary!

I indeed missed the LLVM-Dev meeting, so this is a welcome bit of news for me! 

 

I’m glad we decided to go with the cmake-warning mechanism.  Was there ever any discussion about a rolling warning system as I proposed here? https://reviews.llvm.org/D47073

 

It had received positive feedback on the mailing list, though Chandler had/has some reservations.  IMO, it is a way of going about this that prevents this discussion from being so contentious in the future.

 

-Erich

 

From: cfe-dev [mailto:[hidden email]] On Behalf Of Zachary Turner via cfe-dev
Sent: Friday, October 19, 2018 9:58 AM
To: llvm-dev <[hidden email]>; Clang Dev <[hidden email]>
Subject: [cfe-dev] LLVM C++14/C++17 BoF - Summary

 

For those of you who were not able to attend the LLVM Developer Meeting (and as a recap for those who were), we had a productive BoF about enabling C++14 or C++17 in LLVM.  The outcome of this can be generally summarized as:

 

* There were no major objections to moving to C++14 / C++17 "as soon as possible"

* "As soon as possible" is not immediately, but we are currently targeting March of 2019 due to some downstream contributors' needing to resolve some blockages before it can be possible.

* There did not seem to be a strong sentiment that we should only move to C++14, so for the sake of this discussion we're assuming 17 unless someone presents a strong argument why 17 is *less* desirable than 14.

 

Minimum Compiler Versions for "Reasonable C++17 Support" (Mostly everything minus CTAD)

GCC - Version 7 [1]  (Version 8 for CTAD)

Clang - Version 4 [2]  (Version 5 for CTAD)

MSVC - 2017 Update 5 [3] (Update 7 for CTAD)

 

We plan to add a CMake warning if your compiler version is below these versions soon.  Around January, we will promote this to a CMake error which you must manually override by passing -DCMAKE_ALLLOW_DEPRECATED_COMPILER.

 

If I'm forgetting anything or misrepresenting anything that was said at the BoF please feel free to correct me.

 


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [cfe-dev] LLVM C++14/C++17 BoF - Summary

David Jones via llvm-dev


On Oct 19, 2018, at 10:03 AM, Keane, Erich via llvm-dev <[hidden email]> wrote:

Thanks for the update Zachary!
I indeed missed the LLVM-Dev meeting, so this is a welcome bit of news for me! 
 
I’m glad we decided to go with the cmake-warning mechanism.  Was there ever any discussion about a rolling warning system as I proposed here? https://reviews.llvm.org/D47073
 
It had received positive feedback on the mailing list, though Chandler had/has some reservations.  IMO, it is a way of going about this that prevents this discussion from being so contentious in the future.

We talked about going with exactly your patch, modulo bikeshed on timeline and exact compiler versions. Chandler’s concerns (IIUC) are handled by Zachary.


-Erich
From: cfe-dev [[hidden email]] On Behalf Of Zachary Turner via cfe-dev
Sent: Friday, October 19, 2018 9:58 AM
To: llvm-dev <[hidden email]>; Clang Dev <[hidden email]>
Subject: [cfe-dev] LLVM C++14/C++17 BoF - Summary
 
For those of you who were not able to attend the LLVM Developer Meeting (and as a recap for those who were), we had a productive BoF about enabling C++14 or C++17 in LLVM.  The outcome of this can be generally summarized as:
 
* There were no major objections to moving to C++14 / C++17 "as soon as possible"
* "As soon as possible" is not immediately, but we are currently targeting March of 2019 due to some downstream contributors' needing to resolve some blockages before it can be possible.
* There did not seem to be a strong sentiment that we should only move to C++14, so for the sake of this discussion we're assuming 17 unless someone presents a strong argument why 17 is *less* desirable than 14.
 
Minimum Compiler Versions for "Reasonable C++17 Support" (Mostly everything minus CTAD)
GCC - Version 7 [1]  (Version 8 for CTAD)
Clang - Version 4 [2]  (Version 5 for CTAD)
MSVC - 2017 Update 5 [3] (Update 7 for CTAD)

As we discussed, going to 17 seems ambitious but I’m happy if we do it! We’ll need to ban a few library features from C++17 because they’re not fully supported in those versions.


We plan to add a CMake warning if your compiler version is below these versions soon.  Around January, we will promote this to a CMake error which you must manually override by passing -DCMAKE_ALLLOW_DEPRECATED_COMPILER.
 
If I'm forgetting anything or misrepresenting anything that was said at the BoF please feel free to correct me.
 
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [cfe-dev] LLVM C++14/C++17 BoF - Summary

David Jones via llvm-dev
In reply to this post by David Jones via llvm-dev

So, there was agreement that the default gcc for recent-but-not-latest distros was not important? That is, it's okay to require people to upgrade their tools in order to work with LLVM?

 

In my team's case, a lot of us are on Ubuntu 16.04 which comes with gcc 5.4, which is not gcc 7.  And currently for Windows we're on MSVC 2015.

I suppose by March we can persuade our IT to upgrade all the people and bots to Ubuntu 18.04 (gcc 7.3?) and deploy MSVC 2017.  But it's something we need to plan for.

(I suppose I should thank the Google folks for being such slugs J about being ready to switch, because it will give us time to get things organized for ourselves.)

--paulr

 

From: cfe-dev [mailto:[hidden email]] On Behalf Of Zachary Turner via cfe-dev
Sent: Friday, October 19, 2018 9:58 AM
To: llvm-dev; Clang Dev
Subject: [cfe-dev] LLVM C++14/C++17 BoF - Summary

 

For those of you who were not able to attend the LLVM Developer Meeting (and as a recap for those who were), we had a productive BoF about enabling C++14 or C++17 in LLVM.  The outcome of this can be generally summarized as:

 

* There were no major objections to moving to C++14 / C++17 "as soon as possible"

* "As soon as possible" is not immediately, but we are currently targeting March of 2019 due to some downstream contributors' needing to resolve some blockages before it can be possible.

* There did not seem to be a strong sentiment that we should only move to C++14, so for the sake of this discussion we're assuming 17 unless someone presents a strong argument why 17 is *less* desirable than 14.

 

Minimum Compiler Versions for "Reasonable C++17 Support" (Mostly everything minus CTAD)

GCC - Version 7 [1]  (Version 8 for CTAD)

Clang - Version 4 [2]  (Version 5 for CTAD)

MSVC - 2017 Update 5 [3] (Update 7 for CTAD)

 

We plan to add a CMake warning if your compiler version is below these versions soon.  Around January, we will promote this to a CMake error which you must manually override by passing -DCMAKE_ALLLOW_DEPRECATED_COMPILER.

 

If I'm forgetting anything or misrepresenting anything that was said at the BoF please feel free to correct me.

 


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [cfe-dev] LLVM C++14/C++17 BoF - Summary

David Jones via llvm-dev


On Oct 19, 2018, at 11:27 AM, via llvm-dev <[hidden email]> wrote:

So, there was agreement that the default gcc for recent-but-not-latest distros was not important? That is, it's okay to require people to upgrade their tools in order to work with LLVM?
 
In my team's case, a lot of us are on Ubuntu 16.04 which comes with gcc 5.4, which is not gcc 7.  And currently for Windows we're on MSVC 2015.
I suppose by March we can persuade our IT to upgrade all the people and bots to Ubuntu 18.04 (gcc 7.3?) and deploy MSVC 2017.  But it's something we need to plan for.
(I suppose I should thank the Google folks for being such slugs J about being ready to switch, because it will give us time to get things organized for ourselves.)

The discussion from folks using Linux as well as from Linux vendors was that distros which come with older versions of GCC also provide easy ways to install newer versions of GCC, without upgrading the distro.

There was little discussion of MSVC, besides praising its C++17 support in the latest version.


--paulr
From: cfe-dev [[hidden email]] On Behalf Of Zachary Turner via cfe-dev
Sent: Friday, October 19, 2018 9:58 AM
To: llvm-dev; Clang Dev
Subject: [cfe-dev] LLVM C++14/C++17 BoF - Summary
 
For those of you who were not able to attend the LLVM Developer Meeting (and as a recap for those who were), we had a productive BoF about enabling C++14 or C++17 in LLVM.  The outcome of this can be generally summarized as:
 
* There were no major objections to moving to C++14 / C++17 "as soon as possible"
* "As soon as possible" is not immediately, but we are currently targeting March of 2019 due to some downstream contributors' needing to resolve some blockages before it can be possible.
* There did not seem to be a strong sentiment that we should only move to C++14, so for the sake of this discussion we're assuming 17 unless someone presents a strong argument why 17 is *less* desirable than 14.
 
Minimum Compiler Versions for "Reasonable C++17 Support" (Mostly everything minus CTAD)
GCC - Version 7 [1]  (Version 8 for CTAD)
Clang - Version 4 [2]  (Version 5 for CTAD)
MSVC - 2017 Update 5 [3] (Update 7 for CTAD)
 
We plan to add a CMake warning if your compiler version is below these versions soon.  Around January, we will promote this to a CMake error which you must manually override by passing -DCMAKE_ALLLOW_DEPRECATED_COMPILER.
 
If I'm forgetting anything or misrepresenting anything that was said at the BoF please feel free to correct me.
 
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [cfe-dev] LLVM C++14/C++17 BoF - Summary

David Jones via llvm-dev

Thanks, I'm glad we don't necessarily have to upgrade OS to get upgraded compilers. I've never been too clear on these Unix sys-admin sorts of things.

 

I'm happy this is going forward, I'm happy there is a plan, and I am *especially* happy that we have a reasonable amount of time to get ready for it.  If there's some place that someone is going to write down the general desire/policy for future advances in the minimum language standard used by the project, please make sure that statement includes reasonable advance notice to allow everyone time to go through acquisition, validation, and deployment steps.  Which has to include time for corporate procurement and IT engagement.  I'd say 3 months is definitely a minimum lead time, and some contributors might need more.

 

Are all the bot owners on board?

--paulr

 

From: [hidden email] [mailto:[hidden email]]
Sent: Friday, October 19, 2018 2:37 PM
To: Robinson, Paul
Cc: [hidden email]; [hidden email]
Subject: Re: [llvm-dev] [cfe-dev] LLVM C++14/C++17 BoF - Summary

 

 



On Oct 19, 2018, at 11:27 AM, via llvm-dev <[hidden email]> wrote:

 

So, there was agreement that the default gcc for recent-but-not-latest distros was not important? That is, it's okay to require people to upgrade their tools in order to work with LLVM?

 

In my team's case, a lot of us are on Ubuntu 16.04 which comes with gcc 5.4, which is not gcc 7.  And currently for Windows we're on MSVC 2015.

I suppose by March we can persuade our IT to upgrade all the people and bots to Ubuntu 18.04 (gcc 7.3?) and deploy MSVC 2017.  But it's something we need to plan for.

(I suppose I should thank the Google folks for being such slugs J about being ready to switch, because it will give us time to get things organized for ourselves.)

 

The discussion from folks using Linux as well as from Linux vendors was that distros which come with older versions of GCC also provide easy ways to install newer versions of GCC, without upgrading the distro.

 

There was little discussion of MSVC, besides praising its C++17 support in the latest version.

 



--paulr

 

From: cfe-dev [[hidden email]] On Behalf Of Zachary Turner via cfe-dev
Sent: Friday, October 19, 2018 9:58 AM
To: llvm-dev; Clang Dev
Subject: [cfe-dev] LLVM C++14/C++17 BoF - Summary

 

For those of you who were not able to attend the LLVM Developer Meeting (and as a recap for those who were), we had a productive BoF about enabling C++14 or C++17 in LLVM.  The outcome of this can be generally summarized as:

 

* There were no major objections to moving to C++14 / C++17 "as soon as possible"

* "As soon as possible" is not immediately, but we are currently targeting March of 2019 due to some downstream contributors' needing to resolve some blockages before it can be possible.

* There did not seem to be a strong sentiment that we should only move to C++14, so for the sake of this discussion we're assuming 17 unless someone presents a strong argument why 17 is *less* desirable than 14.

 

Minimum Compiler Versions for "Reasonable C++17 Support" (Mostly everything minus CTAD)

GCC - Version 7 [1]  (Version 8 for CTAD)

Clang - Version 4 [2]  (Version 5 for CTAD)

MSVC - 2017 Update 5 [3] (Update 7 for CTAD)

 

We plan to add a CMake warning if your compiler version is below these versions soon.  Around January, we will promote this to a CMake error which you must manually override by passing -DCMAKE_ALLLOW_DEPRECATED_COMPILER.

 

If I'm forgetting anything or misrepresenting anything that was said at the BoF please feel free to correct me.

 

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

 


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [cfe-dev] LLVM C++14/C++17 BoF - Summary

David Jones via llvm-dev


On Oct 19, 2018, at 6:04 PM, [hidden email] wrote:


This is where it should all happen:

If you have concerns, that patch is where we should fix them. 


Are all the bot owners on board?

--paulr

 

From: [hidden email] [[hidden email]]
Sent: Friday, October 19, 2018 2:37 PM
To: Robinson, Paul
Cc: [hidden email]; [hidden email]
Subject: Re: [llvm-dev] [cfe-dev] LLVM C++14/C++17 BoF - Summary

 

 



On Oct 19, 2018, at 11:27 AM, via llvm-dev <[hidden email]> wrote:

 

So, there was agreement that the default gcc for recent-but-not-latest distros was not important? That is, it's okay to require people to upgrade their tools in order to work with LLVM?

 

In my team's case, a lot of us are on Ubuntu 16.04 which comes with gcc 5.4, which is not gcc 7.  And currently for Windows we're on MSVC 2015.

I suppose by March we can persuade our IT to upgrade all the people and bots to Ubuntu 18.04 (gcc 7.3?) and deploy MSVC 2017.  But it's something we need to plan for.

(I suppose I should thank the Google folks for being such slugs J about being ready to switch, because it will give us time to get things organized for ourselves.)

 

The discussion from folks using Linux as well as from Linux vendors was that distros which come with older versions of GCC also provide easy ways to install newer versions of GCC, without upgrading the distro.

 

There was little discussion of MSVC, besides praising its C++17 support in the latest version.

 



--paulr

 

From: cfe-dev [[hidden email]] On Behalf Of Zachary Turner via cfe-dev
Sent: Friday, October 19, 2018 9:58 AM
To: llvm-dev; Clang Dev
Subject: [cfe-dev] LLVM C++14/C++17 BoF - Summary

 

For those of you who were not able to attend the LLVM Developer Meeting (and as a recap for those who were), we had a productive BoF about enabling C++14 or C++17 in LLVM.  The outcome of this can be generally summarized as:

 

* There were no major objections to moving to C++14 / C++17 "as soon as possible"

* "As soon as possible" is not immediately, but we are currently targeting March of 2019 due to some downstream contributors' needing to resolve some blockages before it can be possible.

* There did not seem to be a strong sentiment that we should only move to C++14, so for the sake of this discussion we're assuming 17 unless someone presents a strong argument why 17 is *less* desirable than 14.

 

Minimum Compiler Versions for "Reasonable C++17 Support" (Mostly everything minus CTAD)

GCC - Version 7 [1]  (Version 8 for CTAD)

Clang - Version 4 [2]  (Version 5 for CTAD)

MSVC - 2017 Update 5 [3] (Update 7 for CTAD)

 

We plan to add a CMake warning if your compiler version is below these versions soon.  Around January, we will promote this to a CMake error which you must manually override by passing -DCMAKE_ALLLOW_DEPRECATED_COMPILER.

 

If I'm forgetting anything or misrepresenting anything that was said at the BoF please feel free to correct me.

 

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

 


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [cfe-dev] LLVM C++14/C++17 BoF - Summary

David Jones via llvm-dev
In reply to this post by David Jones via llvm-dev


On Fri, Oct 19, 2018, 4:36 PM JF Bastien via llvm-dev <[hidden email]> wrote:


On Oct 19, 2018, at 11:27 AM, via llvm-dev <[hidden email]> wrote:

So, there was agreement that the default gcc for recent-but-not-latest distros was not important? That is, it's okay to require people to upgrade their tools in order to work with LLVM?
 
In my team's case, a lot of us are on Ubuntu 16.04 which comes with gcc 5.4, which is not gcc 7.  And currently for Windows we're on MSVC 2015.
I suppose by March we can persuade our IT to upgrade all the people and bots to Ubuntu 18.04 (gcc 7.3?) and deploy MSVC 2017.  But it's something we need to plan for.
(I suppose I should thank the Google folks for being such slugs J about being ready to switch, because it will give us time to get things organized for ourselves.)

The discussion from folks using Linux as well as from Linux vendors was that distros which come with older versions of GCC also provide easy ways to install newer versions of GCC, without upgrading the distro.


Does it help if we build llvm+clang release tarballs for more Linux distros?   If so, I'm willing to help out there. 



_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [cfe-dev] LLVM C++14/C++17 BoF - Summary

David Jones via llvm-dev


On Oct 20, 2018, at 7:37 AM, Brian Cain <[hidden email]> wrote:



On Fri, Oct 19, 2018, 4:36 PM JF Bastien via llvm-dev <[hidden email]> wrote:


On Oct 19, 2018, at 11:27 AM, via llvm-dev <[hidden email]> wrote:

So, there was agreement that the default gcc for recent-but-not-latest distros was not important? That is, it's okay to require people to upgrade their tools in order to work with LLVM?
 
In my team's case, a lot of us are on Ubuntu 16.04 which comes with gcc 5.4, which is not gcc 7.  And currently for Windows we're on MSVC 2015.
I suppose by March we can persuade our IT to upgrade all the people and bots to Ubuntu 18.04 (gcc 7.3?) and deploy MSVC 2017.  But it's something we need to plan for.
(I suppose I should thank the Google folks for being such slugs J about being ready to switch, because it will give us time to get things organized for ourselves.)

The discussion from folks using Linux as well as from Linux vendors was that distros which come with older versions of GCC also provide easy ways to install newer versions of GCC, without upgrading the distro.


Does it help if we build llvm+clang release tarballs for more Linux distros?   If so, I'm willing to help out there. 

Maybe? Nobody chimed in saying that they were bootstrapping LLVM and would have liked an easy download instead. Not that there isn’t need! It simply wasn’t voiced in the rather small audience.


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [cfe-dev] LLVM C++14/C++17 BoF - Summary

David Jones via llvm-dev


> On 23 Oct 2018, at 03:23, JF Bastien via llvm-dev <[hidden email]> wrote:
>
>
>
>> On Oct 20, 2018, at 7:37 AM, Brian Cain <[hidden email]> wrote:
>>
>>
>>
>> On Fri, Oct 19, 2018, 4:36 PM JF Bastien via llvm-dev <[hidden email]> wrote:
>>
>>
>>> On Oct 19, 2018, at 11:27 AM, via llvm-dev <[hidden email]> wrote:
>>>
>>> So, there was agreement that the default gcc for recent-but-not-latest distros was not important? That is, it's okay to require people to upgrade their tools in order to work with LLVM?
>>>  
>>> In my team's case, a lot of us are on Ubuntu 16.04 which comes with gcc 5.4, which is not gcc 7.  And currently for Windows we're on MSVC 2015.
>>> I suppose by March we can persuade our IT to upgrade all the people and bots to Ubuntu 18.04 (gcc 7.3?) and deploy MSVC 2017.  But it's something we need to plan for.
>>> (I suppose I should thank the Google folks for being such slugs J about being ready to switch, because it will give us time to get things organized for ourselves.)
>>
>> The discussion from folks using Linux as well as from Linux vendors was that distros which come with older versions of GCC also provide easy ways to install newer versions of GCC, without upgrading the distro.
>>
>>
>> Does it help if we build llvm+clang release tarballs for more Linux distros?   If so, I'm willing to help out there.
>
> Maybe? Nobody chimed in saying that they were bootstrapping LLVM and would have liked an easy download instead. Not that there isn’t need! It simply wasn’t voiced in the rather small audience.
>

I would have loved to be in that conversation, but once we’ve moved to a monorepo, then bootstrapping could be a matter of writing a script that comes with the git repository, which could build clang+llvm+… from a set of tags “known good”, which will do a two-step bootstrapped build of the compiler(s).

Saying that, I’m happy with the outcome of this discussion and look forward to being able to use C++17 features in the project (and potentially auto-converting some code to use C++17 idioms too)!

Cheers

-- Dean

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev