[cfe-dev] Command line compiler options

[mats petersson]

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]

I have no suggestion as to how to solve this.

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].

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.

--
Mats

On 17 June 2015 at 07:49, Neumann, Adrian <adrian.neumann at siemens.com>
wrote:

> Couldn't this problem be avoided by linking to the appropriate spots in the
> GCC/MSVC documentation whenever clang provides a features that is supposed
> to
> be exactly the same as the corresponding feature in the other compilers?
>
> I can't find the bugzilla where I described this, but there's actually
> another
> problem, which is potentially more serious. Even if we did magically have a
> large body of documentation that covered a lot of these gaps, it's not a
> sure
> thing that we would want to incorporate this content into our docs [1]. The
> issue is that many of our options are specifically there for GCC or MSVC
> compatibility, so providing an independent (duplicated) description of the
> option opens the door to divergence. Our current rough "policy" of
> documenting
> features of clang that are not compatibility features (or where they are
> incompatible in some way) is actually pretty economical and in line with
> SPOT/DRY principles. It also means that all of our bug reports are "bug in
> compatibility with GCC/MSVC" and we can asymptotically approach
> compatibility
> (i.e. fixable with patches). Compare this to "I, a user of your compiler,
> relied on a feature that you documented as behaving in a particular way,
> and
> now you are changing it" which leaves us between a rock and a hard place:
> stay
> incompatible with the other compilers or break our own compatibility
> promises
> (not fixable with patches; we are now in the realm of social/political
> issues). It's an open question whether the open-source project wants to
> risk
> that support problem, or whether there is a safe set of options we can
> document without worrying about this; but arbitrarily thorough
> documentation
> essentially turns any existing compatibility bugs (or misunderstandings of
> a
> GCC/MSVC option on the part of the documenter) into potentially "forever"
> support costs.
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150617/60480f03/attachment.html>