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

Richard Smith via cfe-dev cfe-dev at lists.llvm.org
Thu Mar 2 22:06:07 PST 2017


On 2 March 2017 at 08:37, 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.


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.

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


More information about the cfe-dev mailing list