r211420 - Driver: enhance MSC version compatibility

[Eric Christopher]

On Mon, Jun 23, 2014 at 1:02 PM, Reid Kleckner <rnk at google.com> wrote:
> On Sat, Jun 21, 2014 at 11:32 AM, Alp Toker <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.
>

I'm inclined to agree with this. We could also even deprecate the
original option and have the new option have exactly the semantics we
want. Aaron?

-eric

>>>
>>> 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.
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>