<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2016-09-28 16:22 GMT+07:00 Joerg Sonnenberger via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, Sep 28, 2016 at 01:39:59PM +0700, Serge Pavlov via cfe-dev wrote:<br>
</span><span class="">> > Sorry for being late to the discussion,<br>
> ><br>
> > I think automatic user defaults are a bad idea: Right now when you invoke<br>
> > clang without any additional options you know that you are in a well known<br>
> > state. Build systems and projects rely on this having unknown compiler<br>
> > options active because the user put them into his configuration file is a<br>
> > recipe for disaster IMO! The example below "-std=c++14 -fcxx-exception"<br>
> > already illustrates a situation in which settings are used that can break<br>
> > the compilation of many projects!<br>
> ><br>
> ><br>
> In fact invocation of clang without additional argument does not provide a<br>
> well known state. Actual state is represented by options passed from clang<br>
> driver to clang compiler, but these options depend on used OS, CPU. In<br>
> theory a system upgrade could cause compilation change. Hardly bare driver<br>
> arguments can represent compilation options.<br>
<br>
</span>This is frankly FUD. While a compiler update can sometimes introduce new<br>
default warnings (or add them to -Wall), those are governed by pretty<br>
strict rules. The far majority of the options, especially the per-OS<br>
per-CPU configuration changes very rarely and few of those changes are<br>
user-visible in the sense that they break valid input.<br>
<span class=""><br></span></blockquote><div> </div><div>You are right, the mapping from driver options to compiler ones is relatively stable now.</div><div>My statement was inspired by ICC option -xHost, which selects options optimal</div><div>for the host processor. In any case the set of options passed from driver to compiler is</div><div>more robust characteristic and it differs from user supplied options substantially.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> Default config file is just a way to influence the magic of option<br>
> calculation made by driver. Config files can be used by clang based SDK<br>
> suppliers to customize clang without need to modify compiler sources. If<br>
> end user plays with default config files, he must know what he does.<br>
<br>
</span>But that's the point. Users often don't know or forget. There are long<br>
rants to be found by Google of people forcing -OMG -ffast-math for<br>
everything because they don't understand the implications. I strongly<br>
hope that any vendor shipping a customized default config puts a strong<br>
"Do not change this file without fully understanding what you are doing"<br>
comment in it. The important part is that others are the ones that pay<br>
the price.<br>
<br></blockquote><div><br></div><div> Absolutely agree!</div><div><br></div><div>Thanks,</div><div>--Serge</div><div><br></div></div></div></div>