<div dir="ltr"><div><div>Of course another problem for example with -std=X is that "full support for X is not implied by X being a valid choice" - -std=c++11 would be available as a valid option for quite some time before the actual C++11 standard support was complete - because people were working TOWARDS complete support. Similarly, using clang to compile CL2.0 is allowed with -cl-std=CL2.0, but that doesn't mean that the current trunk branch is supporting all features of CL2.0 - but you can't offer the support at all, if you don't have a way to specify it, and it gets rather messing having to add an option -std=c++11-incomplete, and then when it's complete, change that into c++11 (in particular, there may be 100s of tests that need to be updated for this]<br><br></div>I have no suggestion as to how to solve this.<br><br></div><div>Auto-generated support is probably more maintainable than relying on people writing separate documentation, but it is still relying on the people writing the code to accept the option to write good descriptions that make sense  [and those reviewing it spotting when it's not up to date]. <br><br>Of course, you also have to keep those descriptions up to date when things change - e.g. optimization settings may change over time, so the listing of "-O2 enables <list of optimisation passes>" would have to be kept up to date. That sort of information is often a bit tricky to find.<br><br>--<br></div><div>Mats<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 17 June 2015 at 07:49, Neumann, Adrian <span dir="ltr"><<a href="mailto:adrian.neumann@siemens.com" target="_blank">adrian.neumann@siemens.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Couldn't this problem be avoided by linking to the appropriate spots in the<br>
GCC/MSVC documentation whenever clang provides a features that is supposed to<br>
be exactly the same as the corresponding feature in the other compilers?<br>
<div class="HOEnZb"><div class="h5"><br>
I can't find the bugzilla where I described this, but there's actually another<br>
problem, which is potentially more serious. Even if we did magically have a<br>
large body of documentation that covered a lot of these gaps, it's not a sure<br>
thing that we would want to incorporate this content into our docs [1]. The<br>
issue is that many of our options are specifically there for GCC or MSVC<br>
compatibility, so providing an independent (duplicated) description of the<br>
option opens the door to divergence. Our current rough "policy" of documenting<br>
features of clang that are not compatibility features (or where they are<br>
incompatible in some way) is actually pretty economical and in line with<br>
SPOT/DRY principles. It also means that all of our bug reports are "bug in<br>
compatibility with GCC/MSVC" and we can asymptotically approach compatibility<br>
(i.e. fixable with patches). Compare this to "I, a user of your compiler,<br>
relied on a feature that you documented as behaving in a particular way, and<br>
now you are changing it" which leaves us between a rock and a hard place: stay<br>
incompatible with the other compilers or break our own compatibility promises<br>
(not fixable with patches; we are now in the realm of social/political<br>
issues). It's an open question whether the open-source project wants to risk<br>
that support problem, or whether there is a safe set of options we can<br>
document without worrying about this; but arbitrarily thorough documentation<br>
essentially turns any existing compatibility bugs (or misunderstandings of a<br>
GCC/MSVC option on the part of the documenter) into potentially "forever"<br>
support costs.<br>
</div></div><br>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br></div>