<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 2 March 2017 at 08:37, 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.</blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> 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>
<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>