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

[Sean Silva via cfe-dev]

On Thu, 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.
>

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
> 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/968ef7ab/attachment.html>