r284060 - Implement MS _BitScan intrinsics
Duncan P. N. Exon Smith via cfe-commits
cfe-commits at lists.llvm.org
Mon Jun 12 13:54:31 PDT 2017
> 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.
> 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.
More information about the cfe-commits