On 23/06/2014 23:02, Reid Kleckner wrote:
On Sat, Jun 21, 2014 at 11:32 AM, Alp Toker <[email protected]
<mailto:[email protected]>> 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
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
