[PATCH] clang-cl: Make /Za disable oldnames.lib dependency

Reid Kleckner rnk at google.com
Thu Aug 8 13:23:07 PDT 2013


OK, I went ahead and reverted this so we have the old behavior of emitting:
clang-cl.exe: warning: argument unused during compilation: '/Za'


On Thu, Aug 8, 2013 at 11:25 AM, Chandler Carruth <chandlerc at google.com>wrote:

> I would at least warn from the driver on its use and clarify that it
> doesn't have the same semantics as CL's flag.
> On Aug 8, 2013 11:10 AM, "Reid Kleckner" <rnk at google.com> wrote:
>
>> On Thu, Aug 8, 2013 at 9:55 AM, Hans Wennborg <hans at chromium.org> wrote:
>>
>>> On Wed, Aug 7, 2013 at 11:44 PM, Charles Davis <cdavis5x at gmail.com>
>>> wrote:
>>> >
>>> >   This flag should be doing more stuff. This flag is supposed to
>>> request strict ANSI conformance (according to Microsoft's, uh... "unique"
>>> interpretation of that). That means at least (in GCC terms)
>>> `-fno-ms-extensions`, in addition to not auto-linking `OLDNAMES.LIB`. (The
>>> `/Ze` flag undoes the effects of `/Za`.)
>>> >
>>> >   I seem to recall someone from MS on `cfe-dev` (and yes, they do
>>> exist!) saying that `/Za` is broken and shouldn't be used (cf. "/Za
>>> considered harmful" or some such). Are you sure you want to implement it,
>>> given that?
>>>
>>> Right. It's not obvious what we should do for /Za. We can't disable
>>> -fms-compatibility for instance, because then we couldn't parse some
>>> template code that cl.exe would accept under /Za, etc.
>>>
>>> However, since I just added the oldnames.lib thing in a previous
>>> patch, I think it makes sense to hook up this flag as way of turning
>>> that off.
>>>
>>
>> Yeah, I agree there's no real reason to implement all of /Za.  Before
>> this change there was a vague comment saying "there's a cl.exe flag that
>> turns this off", when we could just go right ahead and put it in the code.
>>
>> I could be convinced that it's better to rip this out and make /Za
>> explicitly unsupported.
>>
>> _______________________________________________
>> cfe-commits mailing list
>> cfe-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130808/f69fb09c/attachment.html>


More information about the cfe-commits mailing list