Adding Brian and Tomasz. I'm pretty sure we have the Windows SDK intrinsics headers. I'm not sure which method we'd prefer, so I'll walk down the hall and ask them. Tomasz is our header maestro (because we play crazy #include_next games so we can use both Windows and macOS SDKs!)
We'll get back to you ASAP. Schwieb -----Original Message----- From: Bruno Cardoso Lopes [mailto:bruno.card...@gmail.com] Sent: Thursday, June 15, 2017 4:41 PM To: Erik Schwiebert <eri...@microsoft.com> Cc: dexonsm...@apple.com; Reid Kleckner <r...@google.com>; cfe-commits <cfe-commits@lists.llvm.org> Subject: Re: r284060 - Implement MS _BitScan intrinsics On Tue, Jun 13, 2017 at 8:13 PM, Bruno Cardoso Lopes <bruno.card...@gmail.com> wrote: > On Mon, Jun 12, 2017 at 2:01 PM, Erik Schwiebert via cfe-commits > <cfe-commits@lists.llvm.org> wrote: >> SGTM too. Regarding Duncan's last question -- I can't think of any such >> customer. :) If you all think the right thing for clang to do is to infer >> LLP64 behavior on LP64 (Darwin) + ms_extensions, then that is fine with me! Thinking more about this; what if we mark such builtins as unsupported for "LP64 (Darwin) + ms_extensions" and then you provide the definitions via intrin.h (we can generate a compiler macro for this scenario and conditionalize the include_next as we do for _MSC_VER)? Do you use this header at all? Are there any other MS related flags that get passed to the compiler? > SGTM as well! > >> >> Thanks all! >> Schwieb >> >> -----Original Message----- >> From: dexonsm...@apple.com [mailto:dexonsm...@apple.com] >> Sent: Monday, June 12, 2017 1:55 PM >> To: Reid Kleckner <r...@google.com> >> Cc: Saleem Abdulrasool <compn...@compnerd.org>; Albert Gutowski >> <agutow...@google.com>; David Majnemer <david.majne...@gmail.com>; >> cfe-commits <cfe-commits@lists.llvm.org>; Erik Schwiebert >> <eri...@microsoft.com> >> Subject: Re: r284060 - Implement MS _BitScan intrinsics >> >> >>> On Jun 12, 2017, at 12:44, Reid Kleckner <r...@google.com> wrote: >>> >>>> On Wed, Jun 7, 2017 at 7:31 PM, Saleem Abdulrasool <compn...@compnerd.org> >>>> wrote: >>>> I'm worried about changing this signature all the time. I suspect that it >>>> will cause the following to be emitted for valid code: >>>> >>>> warning: incompatible pointer types passing 'unsigned long *' to parameter >>>> of type 'unsigned int *' [-Wincompatible-pointer-types] >>>> >>>> Switching the signature on LP64 sounds much better to me. >>> >>> Right, we have to do this. It needs to be `long` on Windows. >> >> SGTM. We'll go that way. > > +1 here! > >>> On Jun 8, 2017, at 12:21, Erik Schwiebert <eri...@microsoft.com> wrote: >>> >>> It’s probably also better to not try to infer our weird desired behavior. >>> It should probably be controlled by a specific driver directive, like >>> “-fms-extensions-lp64-intrinsics” or something like that. Using a new >>> directive means that nobody can accidentally get this behavior if they for >>> some reason do want LLP64 behavior with Windows intrinsics. >> >> This seems overly complicated. Is there a customer that: >> - is on LP64, >> - is using -fms-extensions, >> - is using these intrinsics, and >> - wants them to be 64-bit longs instead of 32-bit ints? >> Put another way: who would use these intrinsics on LP64 and *not* want to >> mimic LLP64? >> >> If everyone using the intrinsics on LP64 is going to have to specify >> -fms-extensions-lp64-intrinsics, then we should just imply it. >> _______________________________________________ >> cfe-commits mailing list >> cfe-commits@lists.llvm.org >> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.llvm.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fcfe-commits&data=02%7C01%7Ceriksc%40microsoft.com%7Cba4835eb4a1b438793d508d4b4481355%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636331669036098946&sdata=iWTF3jpX71tU%2B6aq%2BEpv8VD8IFfeDKMHvZd40%2FK64aE%3D&reserved=0 > > > > -- > Bruno Cardoso Lopes > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.brunocardoso.cc&data=02%7C01%7Ceriksc%40microsoft.com%7Cba4835eb4a1b438793d508d4b4481355%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636331669036098946&sdata=O01DYn4W3JN54%2B6wwAgCLAkq63PUtUBy4mQ9RMN833s%3D&reserved=0 -- Bruno Cardoso Lopes https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.brunocardoso.cc&data=02%7C01%7Ceriksc%40microsoft.com%7Cba4835eb4a1b438793d508d4b4481355%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636331669036098946&sdata=O01DYn4W3JN54%2B6wwAgCLAkq63PUtUBy4mQ9RMN833s%3D&reserved=0 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
