On Mon, Jun 23, 2014 at 1:02 PM, Reid Kleckner <[email protected]> wrote: > On Sat, Jun 21, 2014 at 11:32 AM, Alp Toker <[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. >
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 > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits > _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
