On Jun 30, 2014, at 3:33 PM, Alp Toker <[email protected]> wrote: > > On 01/07/2014 01:28, Saleem Abdulrasool wrote: >> 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 proposal was -msc-full-version because it aligns at least a little with > the documentation on MSDN. > >> >>> 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. > > What does -ex signify? Not familiar with that naming scheme.
Extended. Its a play off of Windows API naming conventions :-). > Anyway, it seems best to go with the working name -msc-full-version unless > something better comes along. Except that this would also define _MSC_VER so it is slightly misleading. > Alp. > >> >>>> 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 > > -- > https://urldefense.proofpoint.com/v1/url?u=http://www.nuanti.com/&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=CchYc4lrV44%2BZqxZADw0BQ%3D%3D%0A&m=uS6tc6Kpb6G0TJZ7L%2BzXxFMKmWnN%2FWtSVvEk4dOowRI%3D%0A&s=2a41880c267356cdb70484821cef9f014dc0ab23b5672e7d9306340e07f850a1 > the browser experts > -- Saleem Abdulrasool abdulras (at) fb (dot) com _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
