Setting default dialect to C++11

Clang Frontend
#21

From: cfe-dev [mailto:cfe-dev-bounces@lists.llvm.org] On Behalf Of Joerg
Sonnenberger via cfe-dev
Sent: Thursday, March 02, 2017 4:02 AM
To: cfe-dev@lists.llvm.org
Subject: Re: [cfe-dev] Setting default dialect to C++11

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.

#22

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.

#23

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.

#24

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

#25

>
>
>
>> From: cfe-dev [mailto:cfe-dev-bounces@lists.llvm.org] On Behalf Of
Joerg
>> Sonnenberger via cfe-dev
>> Sent: Thursday, March 02, 2017 4:02 AM
>> To: cfe-dev@lists.llvm.org
>> Subject: Re: [cfe-dev] Setting default dialect to C++11
>>
>>> 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

#26

From: cfe-dev [mailto:cfe-dev-bounces@lists.llvm.org] On Behalf Of Joerg
Sonnenberger via cfe-dev
Sent: Thursday, March 02, 2017 4:02 AM
To: cfe-dev@lists.llvm.org
Subject: Re: [cfe-dev] Setting default dialect to C++11

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.

#27

>
>
>
>> From: cfe-dev [mailto:cfe-dev-bounces@lists.llvm.org] On Behalf Of
Joerg
>> Sonnenberger via cfe-dev
>> Sent: Thursday, March 02, 2017 4:02 AM
>> To: cfe-dev@lists.llvm.org
>> Subject: Re: [cfe-dev] Setting default dialect to C++11
>>
>>> 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.

#28

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

#29

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?

#30

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

#31

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… :slight_smile:

#32

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.

#33

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

#34

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?)?

#35

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)
:slight_smile:

#36

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

#37

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

Joerg

#38

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 u;


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

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

Joerg

#40

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