[cfe-dev] Setting default dialect to C++11

[Mehdi Amini via cfe-dev]

> On Mar 2, 2017, at 10:37 AM, Mehdi Amini via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> 
>> 
>> On Mar 2, 2017, at 7:35 AM, Robinson, Paul via cfe-dev <cfe-dev at lists.llvm.org> wrote:
>> 
>> 
>> 
>>> -----Original Message-----
>>> From: cfe-dev [mailto:cfe-dev-bounces at lists.llvm.org] On Behalf Of Joerg
>>> Sonnenberger via cfe-dev
>>> Sent: Thursday, March 02, 2017 4:02 AM
>>> To: cfe-dev at lists.llvm.org
>>> 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.

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.

— 
Mehdi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170302/55cb7d32/attachment.html>