Re: [Mingw-w64-public] [Patch] intrsinsic _lrotl

2013-09-12 Thread Kai Tietz
2013/9/13 dw : > _lrotr, _lrotl: Fix bug caused by ia32intrin.h when longs are 4 bytes long. > > The problem here is that ia32intrin.h always maps _lrotr to __rorq for x64. > This is correct in linux world, but not for Windows where longs are only 4 > bytes long. > > If someone were on good terms w

Re: [Mingw-w64-public] libwinpthreads mutexes

2013-09-12 Thread Vadim
On Thu, Sep 12, 2013 at 4:59 PM, John E. / TDM wrote: > On 9/12/2013 12:50 PM, K. Frank wrote: > > Hi Vadim! > > > > On Thu, Sep 12, 2013 at 11:16 AM, Vadim <> wrote: > *snip* > >> Before we embark on that, I'd like to clarify a couple more things: > >> > >> 1. Have you guys considered adopting/f

Re: [Mingw-w64-public] libwinpthreads mutexes

2013-09-12 Thread John E. / TDM
On 9/12/2013 12:50 PM, K. Frank wrote: > Hi Vadim! > > On Thu, Sep 12, 2013 at 11:16 AM, Vadim <> wrote: *snip* >> Before we embark on that, I'd like to clarify a couple more things: >> >> 1. Have you guys considered adopting/forking phtreads-win32? I believe this >> is what the regular mingw uses

[Mingw-w64-public] [Patch] intrsinsic _lrotl

2013-09-12 Thread dw
_lrotr, _lrotl: Fix bug caused by ia32intrin.h when longs are 4 bytes long. The problem here is that ia32intrin.h always maps _lrotr to __rorq for x64. This is correct in linux world, but not for Windows where longs are only 4 bytes long. If someone were on good terms with the gcc team, a pa

Re: [Mingw-w64-public] libwinpthreads mutexes

2013-09-12 Thread Vadim
On Thu, Sep 12, 2013 at 9:32 AM, K. Frank wrote: > Hello Kai and Vadim! > > On Wed, Sep 11, 2013 at 10:39 PM, Kai Tietz <> wrote: > > Hi, > > > > 2013/9/12 Vadim <>: > >> Hi, > >> I am investigating performance problems in binary compiled with > mingw-w64, > >> and libwinpthreads mutex comes at t

Re: [Mingw-w64-public] mingw-w64 v3 release calling for testers

2013-09-12 Thread JonY
On 9/13/2013 04:51, Erik van Pienbroek wrote: > JonY schreef op ma 09-09-2013 om 20:32 [+0800]: >>> mingw-tk-8.5.13-3 >>> Build logs: >>> http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130909/mingw-tk-8.5.13-3 >>> >> >> tkWinSend.c:758:9: error: 'VARIANT' has no member named 'vt' >>

Re: [Mingw-w64-public] mingw-w64 v3 release calling for testers

2013-09-12 Thread Erik van Pienbroek
JonY schreef op ma 09-09-2013 om 20:32 [+0800]: > > mingw-tk-8.5.13-3 > > Build logs: > > http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130909/mingw-tk-8.5.13-3 > > > > tkWinSend.c:758:9: error: 'VARIANT' has no member named 'vt' > vCmd.vt = VT_BSTR; > > Kai, does oaidl.h nee

Re: [Mingw-w64-public] mingw-w64 v3 release calling for testers

2013-09-12 Thread Erik van Pienbroek
With r6277 the wine-gecko and wine-mono failures are resolved. As mentioned earlier the qt5-qtbase build failure was already resolved by patching qt5-qtbase. The qt5-qtsystems issue turned out to be caused by a local patch we were carrying in qt5-qtbase because of compatibility issues with DBus.

Re: [Mingw-w64-public] libwinpthreads mutexes

2013-09-12 Thread K. Frank
Hi Vadim! On Thu, Sep 12, 2013 at 11:16 AM, Vadim <> wrote: > On Thu, Sep 12, 2013 at 9:32 AM, K. Frank <> wrote: >> >> Hello Kai and Vadim! >> ... >> > 2013/9/12 Vadim <>: >> >> Hi, >> >> I am investigating performance problems in binary compiled with >> >> mingw-w64, >> >> and libwinpthreads mut

[Mingw-w64-public] [Patch] intrinsics _umul128

2013-09-12 Thread dw
_umul128 & _mul128: Moved these intrinsics from library-only to intrin-impl. dw Index: mingw-w64-crt/intrincs/_mul128.c === --- mingw-w64-crt/intrincs/_mul128.c (revision 6265) +++ mingw-w64-crt/intrincs/_mul128.c (working copy) @@ -

Re: [Mingw-w64-public] [patch] add xaudio2_8, xinput1_4, xinput9_1_0 defs

2013-09-12 Thread Kai Tietz
Hello Ozkan, def files and rest of patch are ok thanks, Kai 2013/9/12 Ozkan Sezer : > This adds lib[32|64] defs for audio2_8, xinput1_4, xinput9_1_0. > Defs are attached, makefile patch isinlined below. > > OK to push? > > Index: lib32/Makefile.am > ==

Re: [Mingw-w64-public] [Patch] intrinsics _umul128

2013-09-12 Thread Kai Tietz
Thanks, patch is ok. Please apply. Thanks Kai Am 12.09.2013 21:01 schrieb "dw" : > _umul128 & _mul128: Moved these intrinsics from library-only to > intrin-impl. > > dw > > > -- > How ServiceNow helps IT people transform

[Mingw-w64-public] [patch] add xaudio2_8, xinput1_4, xinput9_1_0 defs

2013-09-12 Thread Ozkan Sezer
This adds lib[32|64] defs for audio2_8, xinput1_4, xinput9_1_0. Defs are attached, makefile patch isinlined below. OK to push? Index: lib32/Makefile.am === --- lib32/Makefile.am (revision 6276) +++ lib32/Makefile.am (working copy

Re: [Mingw-w64-public] [patch] add xaudio2_8, xinput1_4, xinput9_1_0 defs

2013-09-12 Thread Ozkan Sezer
On 9/12/13, Kai Tietz wrote: > Hello Ozkan, > > def files and rest of patch are ok > > thanks, > Kai > Pushed. > 2013/9/12 Ozkan Sezer : >> This adds lib[32|64] defs for audio2_8, xinput1_4, xinput9_1_0. >> Defs are attached, makefile patch isinlined below. >> >> OK to push? >> >> Index: lib32/

Re: [Mingw-w64-public] libwinpthreads mutexes

2013-09-12 Thread K. Frank
Hello Kai and Vadim! On Wed, Sep 11, 2013 at 10:39 PM, Kai Tietz <> wrote: > Hi, > > 2013/9/12 Vadim <>: >> Hi, >> I am investigating performance problems in binary compiled with mingw-w64, >> and libwinpthreads mutex comes at the top of my profile. >> Looking at the code, it appears as if mutexes

Re: [Mingw-w64-public] mingw-w64 v3 release calling for testers

2013-09-12 Thread Erik van Pienbroek
Koehne Kai schreef op do 12-09-2013 om 06:51 [+]: > > As there are no macros inside > > mingw-w64 which identify the svn revision all I could came up with is a > > '__MINGW64_VERSION_MAJOR < 3' conditional as best possible solution. > > So which toolchains / Mingw-w64 versions would still bre

Re: [Mingw-w64-public] [Patch] intrinsics __shiftleft128 __shiftright128

2013-09-12 Thread Kai Tietz
Hello dw, Patch is ok. Please apply. Thanks, Kai 2013/9/11 dw : > __shiftright128 & __shiftleft128: Re-written as asm, moved from library-only > to intrin-impl.h. > > Note that the code that is being replaced would not always return the same > results as MS's intrinsics. This patch resolves th