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