r211420 - Driver: enhance MSC version compatibility

Saleem Abdulrasool abdulras at fb.com
Mon Jun 30 15:53:01 PDT 2014


On Jun 30, 2014, at 3:33 PM, Alp Toker <alp at nuanti.com> wrote:

> 
> On 01/07/2014 01:28, Saleem Abdulrasool wrote:
>> On Jun 30, 2014, at 2:10 PM, Alp Toker <alp at nuanti.com> wrote:
>> 
>>> 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..
>> 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
>>> cfe-commits at cs.uiuc.edu
>>> 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









More information about the cfe-commits mailing list