Setting default dialect to C++11

classic Classic list List threaded Threaded
67 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Re: Setting default dialect to C++11

James Y Knight via cfe-dev

> On Mar 2, 2017, at 7:35 AM, Robinson, Paul via cfe-dev <[hidden email]> wrote:
>
>
>
>> -----Original Message-----
>> From: cfe-dev [mailto:[hidden email]] On Behalf Of Joerg
>> Sonnenberger via cfe-dev
>> Sent: Thursday, March 02, 2017 4:02 AM
>> To: [hidden email]
>> Subject: Re: [cfe-dev] Setting default dialect to C++11
>>
>> On Wed, Mar 01, 2017 at 05:07:00PM -0800, Mehdi Amini via cfe-dev wrote:
>>> Right, I don’t think it is a good idea for clang as a project to have
>>> important default configuration flags that diverge between
>>> platform/target, like the default language. This is reducing portability
>>> and quite user hostile IMO.
>
> I don't understand how it is "user hostile”

I expect `clang myprogram` to treat my program sanely (i.e. not change the language standard behind my back without me knowing). Requiring me to specify that I’m OK using C++22 seems fine.


> to have our toolchain default
> to making "clang -c t.cpp" Do The Right Thing in the context of our SDK.

As you mentioned below, Xcode has default flags for clang that are always set. It does not mean that the clang supplied by Apple would change language default. I expect an SDK to help the user to setup the right flag. That different from changing the default inside the compiler.


> We provide the correct target triple; we point to the correct directory
> for our headers; we point to the correct directory for our libraries; we
> set the correct target and subtarget [there is only one]; we do a variety
> of other defaulting, as a service and convenience to our users.
>
>>
>> I somewhat disagree and that's why I didn't have a problem with the
>> change. As long as we silently miscompile C++03 code when enabling C++11
>> or later, I don't think it should be a general default. In a somewhat
>> more restricted environment like the Playstation toolchain, they are in
>> a much better position to judge wether those miscompiles will be
>> triggered by their userbase or not.
>>
>> Joerg
>>
>>> For example if a platform does not support exception, the driver can
>>> error if -fno-exceptions isn’t supplied, requiring an opt-in from the user.
>
> We *support* exceptions, it's just not our *default* (same as for Xcode).
> Erroring out on "clang -c t.cpp" seems incredibly user-hostile, but that
> is the burden you are proposing on all of our licensees.

I don’t see any burden here.

>
> Now let's look at it from the other side:  What are the advantages of having
> different defaults?  The primary advantage I see is increased test coverage.

I don’t buy this: setup your SDK environment to invoke clang with the right set of flags and setup bots to test more configuration.


> Internally we run lots of our tests in a pile of different configurations
> (different optimization levels, with/without -g, with/without LTO, etc)
> and this has proven to be very helpful in finding bugs.
>
> I don't have statistics off the top of my head but the C++11 default has
> found things; see for example PR32066.  This tells me there is value to
> avoiding a "configuration monoculture" and varying defaults is a good thing.

No it just means more testing coverage is good. Changing the default is not the right way to achieve this IMO.


Mehdi

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

Re: Setting default dialect to C++11

James Y Knight via cfe-dev

On Mar 2, 2017, at 10:37 AM, Mehdi Amini via cfe-dev <[hidden email]> wrote:


On Mar 2, 2017, at 7:35 AM, Robinson, Paul via cfe-dev <[hidden email]> wrote:



-----Original Message-----
From: cfe-dev [[hidden email]] On Behalf Of Joerg
Sonnenberger via cfe-dev
Sent: Thursday, March 02, 2017 4:02 AM
To: [hidden email]
Subject: Re: [cfe-dev] Setting default dialect to C++11

On Wed, Mar 01, 2017 at 05:07:00PM -0800, Mehdi Amini via cfe-dev wrote:
Right, I don’t think it is a good idea for clang as a project to have
important default configuration flags that diverge between
platform/target, like the default language. This is reducing portability
and quite user hostile IMO.

I don't understand how it is "user hostile”

I expect `clang myprogram` to treat my program sanely (i.e. not change the language standard behind my back without me knowing). Requiring me to specify that I’m OK using C++22 seems fine.


to have our toolchain default
to making "clang -c t.cpp" Do The Right Thing in the context of our SDK.

As you mentioned below, Xcode has default flags for clang that are always set. It does not mean that the clang supplied by Apple would change language default. I expect an SDK to help the user to setup the right flag. That different from changing the default inside the compiler.


We provide the correct target triple; we point to the correct directory
for our headers; we point to the correct directory for our libraries; we
set the correct target and subtarget [there is only one]; we do a variety
of other defaulting, as a service and convenience to our users.


I somewhat disagree and that's why I didn't have a problem with the
change. As long as we silently miscompile C++03 code when enabling C++11
or later, I don't think it should be a general default. In a somewhat
more restricted environment like the Playstation toolchain, they are in
a much better position to judge wether those miscompiles will be
triggered by their userbase or not.

Joerg

For example if a platform does not support exception, the driver can
error if -fno-exceptions isn’t supplied, requiring an opt-in from the user.

We *support* exceptions, it's just not our *default* (same as for Xcode).
Erroring out on "clang -c t.cpp" seems incredibly user-hostile, but that
is the burden you are proposing on all of our licensees.

I don’t see any burden here. 


Now let's look at it from the other side:  What are the advantages of having
different defaults?  The primary advantage I see is increased test coverage.

I don’t buy this: setup your SDK environment to invoke clang with the right set of flags and setup bots to test more configuration.


Internally we run lots of our tests in a pile of different configurations
(different optimization levels, with/without -g, with/without LTO, etc)
and this has proven to be very helpful in finding bugs.

I don't have statistics off the top of my head but the C++11 default has
found things; see for example PR32066.  This tells me there is value to
avoiding a "configuration monoculture" and varying defaults is a good thing.

No it just means more testing coverage is good. Changing the default is not the right way to achieve this IMO.

And as an example, since I just setup a bot for libc++ yesterday, it runs the tests with std=c++11, then with std=c++14, then with std=c++1z.


I believe designing testing this way is providing better coverage overall that changing some defaults in the compiler based on  SDK provider will.

— 
Mehdi


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

Re: Setting default dialect to C++11

James Y Knight via cfe-dev
I'd say +1 to raising the default c++ version for everyone now.

And, in general, to have a policy of raising the default language version whenever a new version has been well-supported and available to opt into for a reasonable period of time.

People who want to stick to an old language version can set that version explicitly in their builds.


On Thu, Mar 2, 2017 at 1:40 PM, Mehdi Amini via cfe-dev <[hidden email]> wrote:

On Mar 2, 2017, at 10:37 AM, Mehdi Amini via cfe-dev <[hidden email]> wrote:


On Mar 2, 2017, at 7:35 AM, Robinson, Paul via cfe-dev <[hidden email]> wrote:



-----Original Message-----
From: cfe-dev [[hidden email]] On Behalf Of Joerg
Sonnenberger via cfe-dev
Sent: Thursday, March 02, 2017 4:02 AM
To: [hidden email]
Subject: Re: [cfe-dev] Setting default dialect to C++11

On Wed, Mar 01, 2017 at 05:07:00PM -0800, Mehdi Amini via cfe-dev wrote:
Right, I don’t think it is a good idea for clang as a project to have
important default configuration flags that diverge between
platform/target, like the default language. This is reducing portability
and quite user hostile IMO.

I don't understand how it is "user hostile”

I expect `clang myprogram` to treat my program sanely (i.e. not change the language standard behind my back without me knowing). Requiring me to specify that I’m OK using C++22 seems fine.


to have our toolchain default
to making "clang -c t.cpp" Do The Right Thing in the context of our SDK.

As you mentioned below, Xcode has default flags for clang that are always set. It does not mean that the clang supplied by Apple would change language default. I expect an SDK to help the user to setup the right flag. That different from changing the default inside the compiler.


We provide the correct target triple; we point to the correct directory
for our headers; we point to the correct directory for our libraries; we
set the correct target and subtarget [there is only one]; we do a variety
of other defaulting, as a service and convenience to our users.


I somewhat disagree and that's why I didn't have a problem with the
change. As long as we silently miscompile C++03 code when enabling C++11
or later, I don't think it should be a general default. In a somewhat
more restricted environment like the Playstation toolchain, they are in
a much better position to judge wether those miscompiles will be
triggered by their userbase or not.

Joerg

For example if a platform does not support exception, the driver can
error if -fno-exceptions isn’t supplied, requiring an opt-in from the user.

We *support* exceptions, it's just not our *default* (same as for Xcode).
Erroring out on "clang -c t.cpp" seems incredibly user-hostile, but that
is the burden you are proposing on all of our licensees.

I don’t see any burden here. 


Now let's look at it from the other side:  What are the advantages of having
different defaults?  The primary advantage I see is increased test coverage.

I don’t buy this: setup your SDK environment to invoke clang with the right set of flags and setup bots to test more configuration.


Internally we run lots of our tests in a pile of different configurations
(different optimization levels, with/without -g, with/without LTO, etc)
and this has proven to be very helpful in finding bugs.

I don't have statistics off the top of my head but the C++11 default has
found things; see for example PR32066.  This tells me there is value to
avoiding a "configuration monoculture" and varying defaults is a good thing.

No it just means more testing coverage is good. Changing the default is not the right way to achieve this IMO.

And as an example, since I just setup a bot for libc++ yesterday, it runs the tests with std=c++11, then with std=c++14, then with std=c++1z.


I believe designing testing this way is providing better coverage overall that changing some defaults in the compiler based on  SDK provider will.

— 
Mehdi


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



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

Re: Setting default dialect to C++11

James Y Knight via cfe-dev
In reply to this post by James Y Knight via cfe-dev

And as an example, since I just setup a bot for libc++ yesterday, it runs the tests with std=c++11, then with std=c++14, then with std=c++1z.

 

http://lab.llvm.org:8080/green/view/Libcxx/job/libcxx_master_cmake/

 

I believe designing testing this way is providing better coverage overall that changing some defaults in the compiler based on  SDK provider will.

 

 

Not a very compelling example as libcxx is designed to be built using different language standards, so of course its testing allows that sort of thing.  Clang lit testing does not.

 

If you can arrange to make it straightforward to run Clang lit tests with different default dialects, that would be a different story.

--paulr

 


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

Re: Setting default dialect to C++11

James Y Knight via cfe-dev
In reply to this post by James Y Knight via cfe-dev


On Thu, Mar 2, 2017 at 10:37 AM, Mehdi Amini via cfe-dev <[hidden email]> wrote:

> On Mar 2, 2017, at 7:35 AM, Robinson, Paul via cfe-dev <[hidden email]> wrote:
>
>
>
>> -----Original Message-----
>> From: cfe-dev [mailto:[hidden email]] On Behalf Of Joerg
>> Sonnenberger via cfe-dev
>> Sent: Thursday, March 02, 2017 4:02 AM
>> To: [hidden email]
>> Subject: Re: [cfe-dev] Setting default dialect to C++11
>>
>> On Wed, Mar 01, 2017 at 05:07:00PM -0800, Mehdi Amini via cfe-dev wrote:
>>> Right, I don’t think it is a good idea for clang as a project to have
>>> important default configuration flags that diverge between
>>> platform/target, like the default language. This is reducing portability
>>> and quite user hostile IMO.
>
> I don't understand how it is "user hostile”

I expect `clang myprogram` to treat my program sanely (i.e. not change the language standard behind my back without me knowing). Requiring me to specify that I’m OK using C++22 seems fine.


> to have our toolchain default
> to making "clang -c t.cpp" Do The Right Thing in the context of our SDK.

As you mentioned below, Xcode has default flags for clang that are always set. It does not mean that the clang supplied by Apple would change language default. I expect an SDK to help the user to setup the right flag. That different from changing the default inside the compiler.


> We provide the correct target triple; we point to the correct directory
> for our headers; we point to the correct directory for our libraries; we
> set the correct target and subtarget [there is only one]; we do a variety
> of other defaulting, as a service and convenience to our users.
>
>>
>> I somewhat disagree and that's why I didn't have a problem with the
>> change. As long as we silently miscompile C++03 code when enabling C++11
>> or later, I don't think it should be a general default. In a somewhat
>> more restricted environment like the Playstation toolchain, they are in
>> a much better position to judge wether those miscompiles will be
>> triggered by their userbase or not.
>>
>> Joerg
>>
>>> For example if a platform does not support exception, the driver can
>>> error if -fno-exceptions isn’t supplied, requiring an opt-in from the user.
>
> We *support* exceptions, it's just not our *default* (same as for Xcode).
> Erroring out on "clang -c t.cpp" seems incredibly user-hostile, but that
> is the burden you are proposing on all of our licensees.

I don’t see any burden here.

>
> Now let's look at it from the other side:  What are the advantages of having
> different defaults?  The primary advantage I see is increased test coverage.

I don’t buy this: setup your SDK environment to invoke clang with the right set of flags and setup bots to test more configuration.

Where are you imagining "setup your SDK environment to invoke clang with the right set of flags" would happen?

If a user invokes `orbis-clang` (and that's the common use case, invoking it directly), they're calling clang directly.
Sure, the PS4 SDK could make it so that if you use the provided visual studio integration, then it automatically adds -std=gnu++11 to new projects, but not all users use that (in fact I think most don't). And IIRC the PS4 SDK only provides a C++11 standard library (it won't compile as C++98 IIRC).


So just to simplify this aspect of the discussion (portability across vendors for the default langauge standard), hypothetically consider this scenario:
- one vendor has a C++ standard library that only compiles as lang standard A
- one vendor has a C++ standard library that only compiles as lang standard B

Will the upstream clang project require one of the two vendors to keep a private patch so that `clang -c foo.cpp` will Just Work on their platform?


I do think that this C++11/C++98 decision should be made in the driver instead of cc1. That would more clearly isolate it as a point of vendor extensibility.

-- Sean Silva
 


> Internally we run lots of our tests in a pile of different configurations
> (different optimization levels, with/without -g, with/without LTO, etc)
> and this has proven to be very helpful in finding bugs.
>
> I don't have statistics off the top of my head but the C++11 default has
> found things; see for example PR32066.  This tells me there is value to
> avoiding a "configuration monoculture" and varying defaults is a good thing.

No it just means more testing coverage is good. Changing the default is not the right way to achieve this IMO.


Mehdi

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


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

Re: Setting default dialect to C++11

James Y Knight via cfe-dev

On Mar 2, 2017, at 6:53 PM, Sean Silva <[hidden email]> wrote:



On Thu, Mar 2, 2017 at 10:37 AM, Mehdi Amini via cfe-dev <[hidden email]> wrote:

> On Mar 2, 2017, at 7:35 AM, Robinson, Paul via cfe-dev <[hidden email]> wrote:
>
>
>
>> -----Original Message-----
>> From: cfe-dev [mailto:[hidden email]] On Behalf Of Joerg
>> Sonnenberger via cfe-dev
>> Sent: Thursday, March 02, 2017 4:02 AM
>> To: [hidden email]
>> Subject: Re: [cfe-dev] Setting default dialect to C++11
>>
>> On Wed, Mar 01, 2017 at 05:07:00PM -0800, Mehdi Amini via cfe-dev wrote:
>>> Right, I don’t think it is a good idea for clang as a project to have
>>> important default configuration flags that diverge between
>>> platform/target, like the default language. This is reducing portability
>>> and quite user hostile IMO.
>
> I don't understand how it is "user hostile”

I expect `clang myprogram` to treat my program sanely (i.e. not change the language standard behind my back without me knowing). Requiring me to specify that I’m OK using C++22 seems fine.


> to have our toolchain default
> to making "clang -c t.cpp" Do The Right Thing in the context of our SDK.

As you mentioned below, Xcode has default flags for clang that are always set. It does not mean that the clang supplied by Apple would change language default. I expect an SDK to help the user to setup the right flag. That different from changing the default inside the compiler.


> We provide the correct target triple; we point to the correct directory
> for our headers; we point to the correct directory for our libraries; we
> set the correct target and subtarget [there is only one]; we do a variety
> of other defaulting, as a service and convenience to our users.
>
>>
>> I somewhat disagree and that's why I didn't have a problem with the
>> change. As long as we silently miscompile C++03 code when enabling C++11
>> or later, I don't think it should be a general default. In a somewhat
>> more restricted environment like the Playstation toolchain, they are in
>> a much better position to judge wether those miscompiles will be
>> triggered by their userbase or not.
>>
>> Joerg
>>
>>> For example if a platform does not support exception, the driver can
>>> error if -fno-exceptions isn’t supplied, requiring an opt-in from the user.
>
> We *support* exceptions, it's just not our *default* (same as for Xcode).
> Erroring out on "clang -c t.cpp" seems incredibly user-hostile, but that
> is the burden you are proposing on all of our licensees.

I don’t see any burden here.

>
> Now let's look at it from the other side:  What are the advantages of having
> different defaults?  The primary advantage I see is increased test coverage.

I don’t buy this: setup your SDK environment to invoke clang with the right set of flags and setup bots to test more configuration.

Where are you imagining "setup your SDK environment to invoke clang with the right set of flags" would happen?

If a user invokes `orbis-clang` (and that's the common use case, invoking it directly), they're calling clang directly.

Then it is perfectly fine to me to require them to provide a flag to specify the language required if it is not the default.

Sure, the PS4 SDK could make it so that if you use the provided visual studio integration, then it automatically adds -std=gnu++11 to new projects, but not all users use that (in fact I think most don't). And IIRC the PS4 SDK only provides a C++11 standard library (it won't compile as C++98 IIRC).


So just to simplify this aspect of the discussion (portability across vendors for the default langauge standard), hypothetically consider this scenario:
- one vendor has a C++ standard library that only compiles as lang standard A
- one vendor has a C++ standard library that only compiles as lang standard B

Will the upstream clang project require one of the two vendors to keep a private patch so that `clang -c foo.cpp` will Just Work on their platform?

No, upstream-clang does not *require* that. The vendor makes this choice independently. It does not *have to* provide a clang such that `clang -c foo.cpp` behaves differently than upstream, refusing to compile is perfectly fine. This would *not* be “clang”  otherwise.

— 
Mehdi



I do think that this C++11/C++98 decision should be made in the driver instead of cc1. That would more clearly isolate it as a point of vendor extensibility.

-- Sean Silva
 


> Internally we run lots of our tests in a pile of different configurations
> (different optimization levels, with/without -g, with/without LTO, etc)
> and this has proven to be very helpful in finding bugs.
>
> I don't have statistics off the top of my head but the C++11 default has
> found things; see for example PR32066.  This tells me there is value to
> avoiding a "configuration monoculture" and varying defaults is a good thing.

No it just means more testing coverage is good. Changing the default is not the right way to achieve this IMO.


Mehdi

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


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

Re: Setting default dialect to C++11

James Y Knight via cfe-dev
In reply to this post by James Y Knight via cfe-dev
On 2 March 2017 at 08:37, Mehdi Amini via cfe-dev <[hidden email]> wrote:

> On Mar 2, 2017, at 7:35 AM, Robinson, Paul via cfe-dev <[hidden email]> wrote:
>
>
>
>> -----Original Message-----
>> From: cfe-dev [mailto:[hidden email]] On Behalf Of Joerg
>> Sonnenberger via cfe-dev
>> Sent: Thursday, March 02, 2017 4:02 AM
>> To: [hidden email]
>> Subject: Re: [cfe-dev] Setting default dialect to C++11
>>
>> On Wed, Mar 01, 2017 at 05:07:00PM -0800, Mehdi Amini via cfe-dev wrote:
>>> Right, I don’t think it is a good idea for clang as a project to have
>>> important default configuration flags that diverge between
>>> platform/target, like the default language. This is reducing portability
>>> and quite user hostile IMO.
>
> I don't understand how it is "user hostile”

I expect `clang myprogram` to treat my program sanely (i.e. not change the language standard behind my back without me knowing). Requiring me to specify that I’m OK using C++22 seems fine.

I'd also point out that Clang is a cross-compiler out of the box, by default. With a complete LLVM toolchain (and suitable system-specific headers/libs), I think it's highly desirable to be able to compile the same source code with the same flags (other than -target) and produce equivalent binaries for all supported targets. Target-specific defaults of any kind work against that.

Obviously in some cases target-specific defaults make a lot of sense -- for instance if we know that a target or its ABI or toolchain simply doesn't support some feature, or needs special support for something -- but in the absence of a strong reason, we should generally aim for all targets to behave roughly the same.

> to have our toolchain default
> to making "clang -c t.cpp" Do The Right Thing in the context of our SDK.

As you mentioned below, Xcode has default flags for clang that are always set. It does not mean that the clang supplied by Apple would change language default. I expect an SDK to help the user to setup the right flag. That different from changing the default inside the compiler.


> We provide the correct target triple; we point to the correct directory
> for our headers; we point to the correct directory for our libraries; we
> set the correct target and subtarget [there is only one]; we do a variety
> of other defaulting, as a service and convenience to our users.
>
>>
>> I somewhat disagree and that's why I didn't have a problem with the
>> change. As long as we silently miscompile C++03 code when enabling C++11
>> or later, I don't think it should be a general default. In a somewhat
>> more restricted environment like the Playstation toolchain, they are in
>> a much better position to judge wether those miscompiles will be
>> triggered by their userbase or not.
>>
>> Joerg
>>
>>> For example if a platform does not support exception, the driver can
>>> error if -fno-exceptions isn’t supplied, requiring an opt-in from the user.
>
> We *support* exceptions, it's just not our *default* (same as for Xcode).
> Erroring out on "clang -c t.cpp" seems incredibly user-hostile, but that
> is the burden you are proposing on all of our licensees.

I don’t see any burden here.

>
> Now let's look at it from the other side:  What are the advantages of having
> different defaults?  The primary advantage I see is increased test coverage.

I don’t buy this: setup your SDK environment to invoke clang with the right set of flags and setup bots to test more configuration.


> Internally we run lots of our tests in a pile of different configurations
> (different optimization levels, with/without -g, with/without LTO, etc)
> and this has proven to be very helpful in finding bugs.
>
> I don't have statistics off the top of my head but the C++11 default has
> found things; see for example PR32066.  This tells me there is value to
> avoiding a "configuration monoculture" and varying defaults is a good thing.

No it just means more testing coverage is good. Changing the default is not the right way to achieve this IMO.


Mehdi

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


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

Re: Setting default dialect to C++11

James Y Knight via cfe-dev

Obviously in some cases target-specific defaults make a lot of sense -- for instance if we know that a target or its ABI or toolchain simply doesn't support some feature, or needs special support for something -- but in the absence of a strong reason, we should generally aim for all targets to behave roughly the same.

 

And in our case, the PS4 target simply doesn't support dialects other than C++11, therefore the target-specific default makes sense.  (We might eventually support later dialects, if there is sufficient customer demand.)

--paulr

 


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

Re: Setting default dialect to C++11

James Y Knight via cfe-dev
In reply to this post by James Y Knight via cfe-dev
On Montag, 27. Februar 2017 21:02:56 CET Joerg Sonnenberger via cfe-dev wrote:
> On Sun, Feb 26, 2017 at 05:38:03PM -0800, David Majnemer via cfe-dev wrote:
> Pointing to GCC doesn't really change anything. They don't maintain
> those code bases either.

It does in the sense that clang claim it is a "drop-in" replacement for the
gcc command. Does that not imply the same defaults?

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

Re: Setting default dialect to C++11

James Y Knight via cfe-dev
In reply to this post by James Y Knight via cfe-dev

On Mar 2, 2017, at 10:57 PM, Robinson, Paul <[hidden email]> wrote:

Obviously in some cases target-specific defaults make a lot of sense -- for instance if we know that a target or its ABI or toolchain simply doesn't support some feature, or needs special support for something -- but in the absence of a strong reason, we should generally aim for all targets to behave roughly the same.
 

I gave an alternative view that shows that “it makes sense” is not obvious.

— 
Mehdi


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

Re: Setting default dialect to C++11

James Y Knight via cfe-dev
If we changed the default for all targets, we can stop debating whether it makes sense to change it only for PS4...at least for now... :)

On Fri, Mar 3, 2017 at 12:20 PM, Mehdi Amini via cfe-dev <[hidden email]> wrote:

On Mar 2, 2017, at 10:57 PM, Robinson, Paul <[hidden email]> wrote:

Obviously in some cases target-specific defaults make a lot of sense -- for instance if we know that a target or its ABI or toolchain simply doesn't support some feature, or needs special support for something -- but in the absence of a strong reason, we should generally aim for all targets to behave roughly the same.
 

I gave an alternative view that shows that “it makes sense” is not obvious.

— 
Mehdi


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



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

Re: Setting default dialect to C++11

James Y Knight via cfe-dev
In reply to this post by James Y Knight via cfe-dev
On Fri, Mar 3, 2017 at 9:20 AM, Mehdi Amini via cfe-dev <[hidden email]> wrote:
On Mar 2, 2017, at 10:57 PM, Robinson, Paul <[hidden email]> wrote:

Obviously in some cases target-specific defaults make a lot of sense -- for instance if we know that a target or its ABI or toolchain simply doesn't support some feature, or needs special support for something -- but in the absence of a strong reason, we should generally aim for all targets to behave roughly the same.
 

I gave an alternative view that shows that “it makes sense” is not obvious.

FWIW we already default to C++11 in an MSVC environment, regardless of the driver used, because it's required to compile the MSVC STL headers. It's pretty close to Paul's use case of "the PS4 target simply doesn't support dialects other than C++11". There's definitely prior art here.

+1 to what James said, we should just raise the language standard across the board.

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

Re: Setting default dialect to C++11

James Y Knight via cfe-dev
On Fri, Mar 3, 2017 at 7:57 AM, Reid Kleckner via cfe-dev
<[hidden email]> wrote:

> On Fri, Mar 3, 2017 at 9:20 AM, Mehdi Amini via cfe-dev
> <[hidden email]> wrote:
>>
>> On Mar 2, 2017, at 10:57 PM, Robinson, Paul <[hidden email]>
>> wrote:
>>
>> Obviously in some cases target-specific defaults make a lot of sense --
>> for instance if we know that a target or its ABI or toolchain simply doesn't
>> support some feature, or needs special support for something -- but in the
>> absence of a strong reason, we should generally aim for all targets to
>> behave roughly the same.
>>
>> And in our case, the PS4 target simply doesn't support dialects other than
>> C++11, therefore the target-specific default makes sense.
>>
>>
>> I gave an alternative view that shows that “it makes sense” is not
>> obvious.
>
>
> FWIW we already default to C++11 in an MSVC environment, regardless of the
> driver used, because it's required to compile the MSVC STL headers. It's
> pretty close to Paul's use case of "the PS4 target simply doesn't support
> dialects other than C++11". There's definitely prior art here.
>
> +1 to what James said, we should just raise the language standard across the
> board.

+1

~Aaron

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

Re: Setting default dialect to C++11

James Y Knight via cfe-dev
On 3 March 2017 at 08:06, Aaron Ballman <[hidden email]> wrote:
On Fri, Mar 3, 2017 at 7:57 AM, Reid Kleckner via cfe-dev
<[hidden email]> wrote:
> On Fri, Mar 3, 2017 at 9:20 AM, Mehdi Amini via cfe-dev
> <[hidden email]> wrote:
>>
>> On Mar 2, 2017, at 10:57 PM, Robinson, Paul <[hidden email]>
>> wrote:
>>
>> Obviously in some cases target-specific defaults make a lot of sense --
>> for instance if we know that a target or its ABI or toolchain simply doesn't
>> support some feature, or needs special support for something -- but in the
>> absence of a strong reason, we should generally aim for all targets to
>> behave roughly the same.
>>
>> And in our case, the PS4 target simply doesn't support dialects other than
>> C++11, therefore the target-specific default makes sense.
>>
>>
>> I gave an alternative view that shows that “it makes sense” is not
>> obvious.
>
>
> FWIW we already default to C++11 in an MSVC environment, regardless of the
> driver used, because it's required to compile the MSVC STL headers. It's
> pretty close to Paul's use case of "the PS4 target simply doesn't support
> dialects other than C++11". There's definitely prior art here.
>
> +1 to what James said, we should just raise the language standard across the
> board.

+1

Would raising the language standard to C++14 cause problems for PS4 or MSVC? Is the constraint there "at least C++11" (because, say, the system headers are written in C++11) or "exactly C++11" (and if so, why?)? 

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

Re: Setting default dialect to C++11

James Y Knight via cfe-dev
On Fri, Mar 3, 2017 at 1:15 PM, Richard Smith via cfe-dev <[hidden email]> wrote:
On 3 March 2017 at 08:06, Aaron Ballman <[hidden email]> wrote:
On Fri, Mar 3, 2017 at 7:57 AM, Reid Kleckner via cfe-dev
<[hidden email]> wrote:
> On Fri, Mar 3, 2017 at 9:20 AM, Mehdi Amini via cfe-dev
> <[hidden email]> wrote:
>>
>> On Mar 2, 2017, at 10:57 PM, Robinson, Paul <[hidden email]>
>> wrote:
>>
>> Obviously in some cases target-specific defaults make a lot of sense --
>> for instance if we know that a target or its ABI or toolchain simply doesn't
>> support some feature, or needs special support for something -- but in the
>> absence of a strong reason, we should generally aim for all targets to
>> behave roughly the same.
>>
>> And in our case, the PS4 target simply doesn't support dialects other than
>> C++11, therefore the target-specific default makes sense.
>>
>>
>> I gave an alternative view that shows that “it makes sense” is not
>> obvious.
>
>
> FWIW we already default to C++11 in an MSVC environment, regardless of the
> driver used, because it's required to compile the MSVC STL headers. It's
> pretty close to Paul's use case of "the PS4 target simply doesn't support
> dialects other than C++11". There's definitely prior art here.
>
> +1 to what James said, we should just raise the language standard across the
> board.

+1

Would raising the language standard to C++14 cause problems for PS4 or MSVC? Is the constraint there "at least C++11" (because, say, the system headers are written in C++11) or "exactly C++11" (and if so, why?)? 

I think clang-cl already defaults to C++14 (in MSVC2015 compat mode -- http://llvm-cs.pcc.me.uk/tools/clang/lib/Driver/Tools.cpp#4727). MSVC used to not have a flag like -std and cl used to always support the newest C++, with toggles for some language features that have compat implications. For 17, they did add a flag. We went over this on one of the former threads on this topic (http://lists.llvm.org/pipermail/cfe-dev/2016-June/049733.html) :-) 


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

Re: Setting default dialect to C++11

James Y Knight via cfe-dev
In reply to this post by James Y Knight via cfe-dev

Richard Smith asked:

Would raising the language standard to C++14 cause problems for PS4 or MSVC? Is the constraint there "at least C++11" (because, say, the system headers are written in C++11) or "exactly C++11" (and if so, why?)? 

 

A default dialect for a particular platform is not solely dependent on the toolchain; the platform must support the appropriate standard headers and libraries.  I have not investigated whether we have (or plan to have) what's needed for 14 or 17, although I can ask.  (Seems to me I've done this before but I can't find a record of it.)  Note that we do not use either libcxx or libstdc++.

--paulr

 


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

Re: Setting default dialect to C++11

James Y Knight via cfe-dev
In reply to this post by James Y Knight via cfe-dev
On Thu, Mar 02, 2017 at 05:53:47PM +0000, David Blaikie wrote:
> Often in small examples I hit it with library rather than language first -
> which can be a bit more confusing ("what do you mean you can't find
> unique_ptr, I totally included <memory>").

Which library? I don't think libc++ at least restricts it to full C++11
mode.

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

Re: Setting default dialect to C++11

James Y Knight via cfe-dev
libstdc++, I assume - on linux and haven't specified any non-defaults in that regard:

$ clang++-tot mem.cpp -c
mem.cpp:4:8: error: no member named 'unique_ptr' in namespace 'std'
  std::unique_ptr<int> u;
  ~~~~~^

(that's in a file with #include <memory>)


On Sun, Mar 5, 2017 at 11:49 AM Joerg Sonnenberger via cfe-dev <[hidden email]> wrote:
On Thu, Mar 02, 2017 at 05:53:47PM +0000, David Blaikie wrote:
> Often in small examples I hit it with library rather than language first -
> which can be a bit more confusing ("what do you mean you can't find
> unique_ptr, I totally included <memory>").

Which library? I don't think libc++ at least restricts it to full C++11
mode.

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

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

Re: Setting default dialect to C++11

James Y Knight via cfe-dev
In reply to this post by James Y Knight via cfe-dev
On Fri, Mar 03, 2017 at 05:30:33PM +0100, Olivier Goffart wrote:
> On Montag, 27. Februar 2017 21:02:56 CET Joerg Sonnenberger via cfe-dev wrote:
> > On Sun, Feb 26, 2017 at 05:38:03PM -0800, David Majnemer via cfe-dev wrote:
> > Pointing to GCC doesn't really change anything. They don't maintain
> > those code bases either.
>
> It does in the sense that clang claim it is a "drop-in" replacement for the
> gcc command. Does that not imply the same defaults?

I do not want to discuss GCC's policies with regard to breaking existing
code.

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

Re: Setting default dialect to C++11

James Y Knight via cfe-dev
I belive that users will expect to compile C++11 code on default because of GCC. I think moving to C++14 (with the Richard's policy from June) is a good choice, because of user experiance of developers (specially new). Is there a list of things that might break after switching to C++11? I wonder how much bugs could be found easily by clang-tidy (or to implement it as clang warning), so that prior to switch users would know what would break.

Piotr



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