On Jun 30, 2014, at 2:10 PM, Alp Toker <[email protected]> wrote: > > 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..
Yes, I was waiting for a response to my last message about what we want to call the option. > The reason is that this blocks some other fixes I have related to -msc-ver > and the diagnostic engine. Ill call it -fmsc-version-ex then for now and we can bike shed it later if we want. > >> >> 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. > > -- > https://urldefense.proofpoint.com/v1/url?u=http://www.nuanti.com/&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=CchYc4lrV44%2BZqxZADw0BQ%3D%3D%0A&m=EeMVGsbHKXIgB8SD08%2BWl%2BFX%2F%2BRXJCxU2hPPg2SqMzQ%3D%0A&s=23c0413d37aace07c97e4f68ae58f9501c3c38ef42d84f04ea2317f2b158f3e7 > the browser experts > > _______________________________________________ > cfe-commits mailing list > [email protected] > https://urldefense.proofpoint.com/v1/url?u=http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=CchYc4lrV44%2BZqxZADw0BQ%3D%3D%0A&m=EeMVGsbHKXIgB8SD08%2BWl%2BFX%2F%2BRXJCxU2hPPg2SqMzQ%3D%0A&s=cbfe3346795a5f2236a51b67cac8e94a8d044ff0b89685a3b504ce211c1a2593 -- Saleem Abdulrasool abdulras (at) fb (dot) com _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
