r284060 - Implement MS _BitScan intrinsics

[Bruno Cardoso Lopes via cfe-commits]

On Tue, Jun 13, 2017 at 8:13 PM, Bruno Cardoso Lopes
<bruno.cardoso at gmail.com> wrote:
> On Mon, Jun 12, 2017 at 2:01 PM, Erik Schwiebert via cfe-commits
> <cfe-commits at 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: dexonsmith at apple.com [mailto:dexonsmith at apple.com]
>> Sent: Monday, June 12, 2017 1:55 PM
>> To: Reid Kleckner <rnk at google.com>
>> Cc: Saleem Abdulrasool <compnerd at compnerd.org>; Albert Gutowski <agutowski at google.com>; David Majnemer <david.majnemer at gmail.com>; cfe-commits <cfe-commits at lists.llvm.org>; Erik Schwiebert <eriksc at microsoft.com>
>> Subject: Re: r284060 - Implement MS _BitScan intrinsics
>>
>>
>>> On Jun 12, 2017, at 12:44, Reid Kleckner <rnk at google.com> wrote:
>>>
>>>> On Wed, Jun 7, 2017 at 7:31 PM, Saleem Abdulrasool <compnerd at 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 <eriksc at 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 at 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