2013/10/19 dw <[email protected]>: > > Well, why including x86intrin.h header within our platform-headers? > Why not including instead - as we did in the past - including intrin.h > header instead?!?! > > "In the past", we DID include x86intrin.h. Back before I even started with > the project (r5579), winnt.h was already including x86intrin.h. Sure, it was for cygwin-case AFAIR. As before we were including intrin.h for other platforms, and therefore the was no need to include x86intrin.h there ...
> Ideally, I'd like to remove x86intrin.h from winnt.h too. The only reason I > didn't do this at the same time as I removed intrin.h was that winnt.h needs > implementations for _mm_lfence, _mm_mfence, _mm_sfence, _mm_pause, and > _mm_prefetch, which all come from that include. And I couldn't just copy > these implementations into winnt.h and/or intrin.h, because they would have > conflicted with x86intrin.h if it got included later. Right, this intrinsic functions are part of the gcc-variants. So by including intrin.h all those (and much more) intrinsics are there. Advantage of this is that user can include afterwards any intrinsic-header it likes, as it has no effect, due it was already included before. So we had a way (I admit not the best, but working nicely) to avoid such double-definining, double-placing, user-include-order-dependent, etc issues. > intrin.h also includes a dozen other include files which define hundreds > (thousands?) of other functions. Aside from the possibility of introducing > conflicts, including this much additional code has an impact on compile > times. And of course it is inconsistent with what the MS PSDK does. See above. IMHO this was a feature, not a bug at all. > > Again, we don't need to FIX OUR PROTOTYPES. This is wrong point of > view here. > > > I disagree. Here's the existing code: > > #ifdef __x86_64__ > __MINGW_EXTENSION unsigned long long __cdecl _lrotl(unsigned long long > _Val,int _Shift); > __MINGW_EXTENSION unsigned long long __cdecl _lrotr(unsigned long long > _Val,int _Shift); > #else > unsigned long __cdecl _lrotl(unsigned long _Val,int _Shift); > unsigned long __cdecl _lrotr(unsigned long _Val,int _Shift); > #endif > > What is the purpose of the #if here? It appears it is intended to change > the prototype based on the size of longs, which it assumes will change based > on whether __x86_64__ is defined. However, that assumption is false. Using > msvc (or gcc built for native windows), longs are 32bits for both x86 and > x64. Forcing the prototype to "unsigned long long" just because __x86_64__ > is defined is the incorrect solution. > A slightly improved version might look like this: > > #if __SIZEOF_LONG__ == 8 > __MINGW_EXTENSION unsigned long long __cdecl _lrotl(unsigned long long > _Val,int _Shift); > __MINGW_EXTENSION unsigned long long __cdecl _lrotr(unsigned long long > _Val,int _Shift); > #else > unsigned long __cdecl _lrotl(unsigned long _Val,int _Shift); > unsigned long __cdecl _lrotr(unsigned long _Val,int _Shift); > #endif > > But (as you have pointed out before) the "__SIZEOF_LONG__" macro may not be > supported by all compilers. However, there is an even simpler declaration > that works correctly for x86, x64, cygwin, cygwin64, IA64, etc: > > unsigned long __cdecl _lrotl(unsigned long _Val,int _Shift); > unsigned long __cdecl _lrotr(unsigned long _Val,int _Shift); > > Using these definitions, if "longs" are 4 bytes, this prototype will give 4 > byte definitions. If longs are 8 bytes, this will give 8 byte definitions. > No #if required. > > > We need to provide to users the PROPER prototypes as they > expect to have by reading documentation of msdn. > > I agree. Which is exactly what I did. Accoring to http://msdn.microsoft.com/en-us/library/a0w705h5.aspx is the prototype a long. The issue we have is that in ia32intrin.h header _lrotl and _lrotr are defines of __rolq/__rorq for 64-bit, and __rold/__rord for 32-bit. To solve this, we need to redefine thos two macros after ia32intrin.h header is included. Better way to solve this would be of course to fix header in 64-bit case for Windows mingw target (LLP64). > > To address that in x86intrin.h header > would be fine, but was rejected in the past already. Would be the wrong place. it needs to be addressed in ia32intrin.h header. > > Do you have a link to the last discussion? Before I try to convince them, > it might help to see why this wasn't accepted last time. Hmm, I searched it, and could find it in archives ... was some years ago ... > dw Kai ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
