[cfe-dev] Command line compiler options

[Edward Diener]

On 6/17/2015 2:49 AM, Neumann, Adrian 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?

Or at the least specifying which version of gcc/msvc is being emulated 
for any specific version of clang. The gcc or msvc documentation for any 
version can be found online. But options and what values they accept do 
sometimes change between releases.

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