r211420 - Driver: enhance MSC version compatibility

[Alp Toker]

On 23/06/2014 23:02, Reid Kleckner wrote:
> On Sat, Jun 21, 2014 at 11:32 AM, Alp Toker <alp at nuanti.com 
> <mailto:alp at nuanti.com>> wrote:
>
>     Please split out and name the new dotted form something like
>     "-msc-full-version" to avoid ambiguity.
>
>
> I was inclinded to overload the option because it means we don't have 
> to diagnose this case: -fmsc-version -fmsc-full-version=17.00.0.  We 
> just do the obvious thing of "last one always wins".  Diagnosing the 
> conflict isn't too hard, though, so let's just split the options and 
> do exactly that in the driver.

Saleem,

Do you plan to make that change? If not I guess I can look into it..

The reason is that this blocks some other fixes I have related to 
-msc-ver and the diagnostic engine.


>
>         Due to
>         bitwidth limitations of the option, it is currently not
>         possible to define a
>         revision value.
>
>
>     What would be the practical burden of encoding this as 64-bits, or
>     two 32-bit fields (one representing _MSC_BUILD and another for the
>     rest)?
>
>     Or is there a different plan to resolve the 32-bit encoding FIXMEs
>     introduced in the commit? I suspect that getting the
>     representation right will simplify computations below for free.
>
>
> LangOptions are defined as unsigned bitfields, so we can't widen the 
> full version number to 64 bits without some disruptive changes.  Lots 
> of LangOpts shouldn't even be bitfields, for example.  If we supported 
> that, we could easily make the full version a 64-bit int.  Failing 
> that, we could split the build number into it's own option.

Yeah, that could work. I actually think the optimal representation may 
involve two separate 32-bit fields, because that's the boundary at which 
the Microsoft documentation and cl.exe appear to make the split. Will 
investigate both options if Saleem isn't already on the case.

Alp.

-- 
http://www.nuanti.com
the browser experts