r211420 - Driver: enhance MSC version compatibility
Alp Toker
alp at nuanti.com
Mon Jun 30 14:10:59 PDT 2014
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
More information about the cfe-commits
mailing list