<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 2, 2017 at 10:37 AM, Mehdi Amini via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On Mar 2, 2017, at 7:35 AM, Robinson, Paul via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br>
><br>
><br>
><br>
>> -----Original Message-----<br>
>> From: cfe-dev [mailto:<a href="mailto:cfe-dev-bounces@lists.llvm.org">cfe-dev-bounces@lists.<wbr>llvm.org</a>] On Behalf Of Joerg<br>
>> Sonnenberger via cfe-dev<br>
>> Sent: Thursday, March 02, 2017 4:02 AM<br>
>> To: <a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
>> Subject: Re: [cfe-dev] Setting default dialect to C++11<br>
>><br>
>> On Wed, Mar 01, 2017 at 05:07:00PM -0800, Mehdi Amini via cfe-dev wrote:<br>
>>> Right, I don’t think it is a good idea for clang as a project to have<br>
>>> important default configuration flags that diverge between<br>
>>> platform/target, like the default language. This is reducing portability<br>
>>> and quite user hostile IMO.<br>
><br>
</span>> I don't understand how it is "user hostile”<br>
<br>
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.<br>
<span class=""><br>
<br>
> to have our toolchain default<br>
> to making "clang -c t.cpp" Do The Right Thing in the context of our SDK.<br>
<br>
</span>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.<br>
<span class=""><br>
<br>
> We provide the correct target triple; we point to the correct directory<br>
> for our headers; we point to the correct directory for our libraries; we<br>
> set the correct target and subtarget [there is only one]; we do a variety<br>
> of other defaulting, as a service and convenience to our users.<br>
><br>
>><br>
>> I somewhat disagree and that's why I didn't have a problem with the<br>
>> change. As long as we silently miscompile C++03 code when enabling C++11<br>
>> or later, I don't think it should be a general default. In a somewhat<br>
>> more restricted environment like the Playstation toolchain, they are in<br>
>> a much better position to judge wether those miscompiles will be<br>
>> triggered by their userbase or not.<br>
>><br>
>> Joerg<br>
>><br>
>>> For example if a platform does not support exception, the driver can<br>
>>> error if -fno-exceptions isn’t supplied, requiring an opt-in from the user.<br>
><br>
> We *support* exceptions, it's just not our *default* (same as for Xcode).<br>
> Erroring out on "clang -c t.cpp" seems incredibly user-hostile, but that<br>
> is the burden you are proposing on all of our licensees.<br>
<br>
</span>I don’t see any burden here.<br>
<span class=""><br>
><br>
> Now let's look at it from the other side:  What are the advantages of having<br>
> different defaults?  The primary advantage I see is increased test coverage.<br>
<br>
</span>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.<br></blockquote><div><br></div><div>Where are you imagining "setup your SDK environment to invoke clang with the right set of flags" would happen?</div><div><br></div><div>If a user invokes `orbis-clang` (and that's the common use case, invoking it directly), they're calling clang directly.</div><div>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).</div><div><br></div><div><br></div><div>So just to simplify this aspect of the discussion (portability across vendors for the default langauge standard), hypothetically consider this scenario:</div><div>- one vendor has a C++ standard library that only compiles as lang standard A</div><div>- one vendor has a C++ standard library that only compiles as lang standard B</div><div><br></div><div>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?</div><div><br></div><div><br></div><div>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.</div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
<br>
> Internally we run lots of our tests in a pile of different configurations<br>
> (different optimization levels, with/without -g, with/without LTO, etc)<br>
> and this has proven to be very helpful in finding bugs.<br>
><br>
> I don't have statistics off the top of my head but the C++11 default has<br>
> found things; see for example PR32066.  This tells me there is value to<br>
> avoiding a "configuration monoculture" and varying defaults is a good thing.<br>
<br>
</span>No it just means more testing coverage is good. Changing the default is not the right way to achieve this IMO.<br>
<br>
—<br>
Mehdi<br>
<div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br></div></div>