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

James Y Knight via cfe-dev cfe-dev at lists.llvm.org
Thu Mar 2 12:16:54 PST 2017


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 <
cfe-dev at lists.llvm.org> wrote:

>
> 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
> <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
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170302/4082f1e4/attachment.html>


More information about the cfe-dev mailing list