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 >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits > > > > -- > Bruno Cardoso Lopes > http://www.brunocardoso.cc -- Bruno Cardoso Lopes http://www.brunocardoso.cc _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
