<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Jun 21, 2014 at 11:32 AM, Alp Toker <span dir="ltr"><<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Please split out and name the new dotted form something like "-msc-full-version" to avoid ambiguity.</blockquote><div><br></div><div>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.<br>
</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Due to<br>
bitwidth limitations of the option, it is currently not possible to define a<br>
revision value.<br>
</blockquote>
<br></div>
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)?<br>
<br>
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.</blockquote><div><br></div><div>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.</div>
</div></div></div>