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

[Mehdi Amini via cfe-dev]

> On Mar 2, 2017, at 6:53 PM, Sean Silva <chisophugis at gmail.com> wrote:
> 
> 
> 
> On Thu, Mar 2, 2017 at 10:37 AM, Mehdi Amini via cfe-dev <cfe-dev at lists.llvm.org <mailto: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 <mailto:cfe-dev at lists.llvm.org>> wrote:
> >
> >
> >
> >> -----Original Message-----
> >> From: cfe-dev [mailto:cfe-dev-bounces at lists.llvm.org <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 <mailto: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.
> 
> 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
> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev <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/f0067562/attachment.html>