> 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. > 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
