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

Robinson, Paul via cfe-dev cfe-dev at lists.llvm.org
Thu Mar 2 07:35:37 PST 2017



> -----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" to have our toolchain default
to making "clang -c t.cpp" Do The Right Thing in the context of our SDK.
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.

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.
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.
--paulr

> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


More information about the cfe-dev mailing list