> As for LLP64 long isn't 64-bit wide, we need to override it.

Except that we don't override it.  As written, every 64bit compile turns 
_lrotr into a 64bit operation, regardless of the actual size of a long.  
And calling _lrotr with a 32bit value and having it do a 64bit rotate 
does not yield the correct answer.

Despite my earlier statements, I now believe that the problem is in 
ia32intrin.h.  Instead of using __x86_64__ to determine whether to use 
the 64bit rotate, it should be using __LP64__, __SIZEOF_LONG__, or some 
such.

> please note that changing of these headers
> in gcc was already tried by me in the past and was rejected.

I assume your patch was something like this 
(http://pastebin.com/0KHDDXie)? Determining the length of a long using 
standard defines seems pretty basic.  What was the objection?

> So we need to work-a-round that.
> please tell how to resolve difference between gcc's and MS
> intrinsic-defintion.

If they absolutely refuse to make any change here, then we could replace 
our code with something like this:

#if __SIZEOF_LONG__ == 8

#pragma push_macro ("_lrotr")
#undef _lrotr
     __MACHINE(__MINGW_EXTENSION unsigned long long __cdecl 
_lrotr(unsigned long long,int))
#pragma pop_macro ("_lrotr")

#else

#undef _lrotr
     __MACHINE(unsigned __LONG32 __cdecl _lrotr(unsigned __LONG32,int))
#define _lrotr(a,b)        __rord((a), (b))

#endif

This will use the existing logic when longs are 8 bytes long (ie 
cygwin), and re-map the call to the correct function if it is 4 bytes 
(native windows).  This should work correctly for x86, x64, and cygwin.

> So I have strong doubts about the intend of your patch.

Sorry about that.  I missed the fact that all this was being done in 
ia32intrin.h.  Since a scan of the entire mingw-w64 tree didn't find any 
of these functions, I just assumed it was using msvcr*.dll for 
everything.  Hopefully I'm making more sense this time.

dw

------------------------------------------------------------------------------
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Reply via email to