Hello dw, 2013/10/4 dw <[email protected]>: > Sorry for the delayed response on this topic, things got busy. To pick > this back up, this is where we stand now: > > - There's a bug in gcc's x86intrin.h. They assume that under x64, longs > are always 8 bytes. For native Windows (ie not cygwin), that's not > correct, and leads to incorrect results for the intrinsics _lrotr and > _lrotl. It's possible to do a work-around using undef + define. > - In addition to the bug in x86intrin, there are incorrect prototypes > for _lrotr and _lrotl in intrin.h, stdlib.h and winnt.h.
right, we do that. > I see 3 reasonable courses of action: > > 1) We could fix our prototypes plus add the work-around everywhere we > include x86intrin.h. This is what my previous patch did. However, as > Kai (correctly) points out, this puts the same code in a multiple > places. That's both inefficient, and harder to maintain. 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?!?! This has in my opinion two advantages. First is that we avoid multiple places doing the same thing again and again. Second on is that users don't need to think about it as long as they (as it has to be usually) including first the platform-headers for this. The only point we might need to think about is stdlib.h header, due it is CRT-only and not part of platform-headers. > 2) We could fix our prototypes plus put the work-around in a wrapper > file (ie x86intrin-fix.h). Then instead of including x86intrin.h, we'd > include x86intrin-fix.h in our headers (winnt.h & intrin.h). This fix > (as well as any future fixes for x86intrin) could be done in one place. > Also, when gcc fixes this problem in their code, we can put an #ifdef to > see if the fix is still needed in a single place. Well, the wrapper idea sounds far, but doesn't work reliable due include-order of those headers is controlled by gcc's frontend in an incompatible way. For native-compilers the gcc-internal directories are in include-order first, but for cross- they are after the sys-include (AFAIR). So to make this up proper, we could reuse the same mechanism we have right now for float.h etc. It might be a way ... not the nicest but doable. > 3) We could fix our prototypes, then open a ticket against gcc to fix > their bug in x86intrin.h. Again, we don't need to FIX OUR PROTOTYPES. This is wrong point of view here. We need to provide to users the PROPER prototypes as they expect to have by reading documentation of msdn. It is mainly a question of portability here. To address that in x86intrin.h header would be fine, but was rejected in the past already. So well, try again, I don't give you much hope here. > Neither #1 or #2 fix the problem if users include x86intrin.h directly. > Also, this problem has been there a long time, and I haven't seen anyone > (besides me) screaming for a fix. If we needed an immediate fix, I > could see going with #2, but the cleanest (and my current preference) is > #3. > > I'm prepared to write #2 or #3 (or #4 if someone has a better idea), but > before I spend the time, I'd like to know which would get approved. > > 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=60134071&iu=/4140/ostg.clktrk _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
