WineHQ upgrade breaking dinput8:dinput?

[Francois Gouget]

This is a truly weird one. dinput8:dinput start failing on the 17th, the 
day after WineHQ was upgraded:
https://test.winehq.org/data/tests/dinput8:dinput.html

What makes this weird is that:
 * There has been no change to these tests between bd332f53f2d7 and 
   966a07149a02. In fact the last patch goes back to 2013.
   So it's not a bad patch.

* The failures happen on every 32 bit test environment, from XP to 
   Windows 10, VM or not, TestBot or not. Only 64 bit is spared.

* I compiled a dinput8_crosstest.exe binary bd332f53f2d7 which 
   was not failing according to the test.winehq.org results. But all I 
   got is failures:
   - 887b445bb878, 8th, 0 test.winehq.org failures, 13 here:
     https://testbot.winehq.org/JobDetails.pl?Key=21611
   - bd332f53f2d7, 16th, 0 test.winehq.org failures, 13 here:
     https://testbot.winehq.org/JobDetails.pl?Key=21610
   - 329dfee70c35, 22nd, 13 test.winehq.org failures, 13 here
     https://testbot.winehq.org/JobDetails.pl?Key=21609
   My MinGW compiler is more recent than the one WineHQ was using before 
   the upgrade however. So I think this points to a compiler-related 
   issue.

The official WineTest binaries are build on WineHQ so I suspect the 
MinGW upgrade is somehow responsible for the new failures.

However I don't know if the old compiler was masking them, of if the new 
one is causing them.

Any ideas?

For reference:
 * Debian Testing (my environment):
   $ i686-w64-mingw32-gcc --version
   i686-w64-mingw32-gcc (GCC) 5.3.1 20160205

* Debian 7 (close to former WineHQ environment):
   $ i686-w64-mingw32-gcc --version
   i686-w64-mingw32-gcc (GCC) 4.9.1

[Michael Stefaniuc]

On 03/23/2016 12:17 PM, Francois Gouget wrote:
> This is a truly weird one. dinput8:dinput start failing on the 17th, the 
> day after WineHQ was upgraded:
> https://test.winehq.org/data/tests/dinput8:dinput.html
>
> What makes this weird is that:
> -
>
> There has been no change to these tests between bd332f53f2d7 and 
> 966a07149a02. In fact the last patch goes back to 2013.
> So it's not a bad patch.
> -
>
> The failures happen on every 32 bit test environment, from XP to 
> Windows 10, VM or not, TestBot or not. Only 64 bit is spared.
> -
>
> I compiled a dinput8_crosstest.exe binary bd332f53f2d7 which 
> was not failing according to the test.winehq.org results. But all I 
> got is failures:
> - 887b445bb878, 8th, 0 test.winehq.org failures, 13 here:
> https://testbot.winehq.org/JobDetails.pl?Key=21611
> - bd332f53f2d7, 16th, 0 test.winehq.org failures, 13 here:
> https://testbot.winehq.org/JobDetails.pl?Key=21610
> - 329dfee70c35, 22nd, 13 test.winehq.org failures, 13 here
> https://testbot.winehq.org/JobDetails.pl?Key=21609
>
> My MinGW compiler is more recent than the one WineHQ was using before 
> the upgrade however. So I think this points to a compiler-related 
> issue.
>
> The official WineTest binaries are build on WineHQ so I suspect the 
> MinGW upgrade is somehow responsible for the new failures.

Well, it wasn't just a version upgrade but a change from mingw to the
mingw-w64 fork. Afaik those two diverged quite a bit.

bye
    michael

[Francois Gouget]

On Wed, 23 Mar 2016, Francois Gouget wrote:
[...]
> - I compiled a dinput8_crosstest.exe binary bd332f53f2d7 which 
> was not failing according to the test.winehq.org results. But all I 
> got is failures:
> - 887b445bb878, 8th, 0 test.winehq.org failures, 13 here:
> https://testbot.winehq.org/JobDetails.pl?Key=21611
> - bd332f53f2d7, 16th, 0 test.winehq.org failures, 13 here:
> https://testbot.winehq.org/JobDetails.pl?Key=21610
> - 329dfee70c35, 22nd, 13 test.winehq.org failures, 13 here
> https://testbot.winehq.org/JobDetails.pl?Key=21609
> My MinGW compiler is more recent than the one WineHQ was using before 
> the upgrade however. So I think this points to a compiler-related 
> issue.

Recompiling the crosstest with -O0 gets rid of the failures:
 - bd332f53 -O0 dinput8:dinput test
   https://testbot.winehq.org/JobDetails.pl?Key=21616

So it does look like a compiler issue.

[Francois Gouget]

It looks like usp10:usp10 is impacted too, but only for 64 bit builds, 
and only since the 18th instead of the 17th which is strange.

Still compiling with -O0 instead of -O2 seems to fix the new failures:
 * 329dfee70c35 -O2 usp10:usp10 test
   1 to 10 failures on Vista-Win8 in test.winehq.org, 1 here
   https://testbot.winehq.org/JobDetails.pl?Key=21620

* 329dfee70c35 -O0 usp10:usp10 test
   0 failures
   https://testbot.winehq.org/JobDetails.pl?Key=21621

* bd332f53f2d7 -O2 usp10:usp10 test
   0 failures on Vista-Win8 in test.winehq.org, 1 here
   https://testbot.winehq.org/JobDetails.pl?Key=21622

* bd332f53f2d7 -O0 usp10:usp10 test
   0 failures
   https://testbot.winehq.org/JobDetails.pl?Key=21623

The last victim is wininet:url but only on some Windows XP VMs. Again 
compiling the test with -O0 fixes the failures. 
https://test.winehq.org/data/tests/wininet:url.html

As far as I can tell these are the only tests that still have issues 
following the upgrade.

[Bernhard Übelacker]

Hello,

Am 23.03.2016 um 14:05 schrieb Francois Gouget:
> On Wed, 23 Mar 2016, Francois Gouget wrote:
> [...]
> > - I compiled a dinput8_crosstest.exe binary bd332f53f2d7 which
> > was not failing according to the test.winehq.org results. But all I
> > got is failures:
> > - 887b445bb878, 8th, 0 test.winehq.org failures, 13 here:
> > https://testbot.winehq.org/JobDetails.pl?Key=21611
> > - bd332f53f2d7, 16th, 0 test.winehq.org failures, 13 here:
> > https://testbot.winehq.org/JobDetails.pl?Key=21610
> > - 329dfee70c35, 22nd, 13 test.winehq.org failures, 13 here
> > https://testbot.winehq.org/JobDetails.pl?Key=21609
> > My MinGW compiler is more recent than the one WineHQ was using before
> > the upgrade however. So I think this points to a compiler-related
> > issue.
>
> Recompiling the crosstest with -O0 gets rid of the failures:
> - bd332f53 -O0 dinput8:dinput test
> https://testbot.winehq.org/JobDetails.pl?Key=21616
>
> So it does look like a compiler issue.

one point that could be related is the usage of function local static 
variables. When all of these got the "static" removed, I do not get the 
failures anymore. However I could not prove this with testbot as an 
empty patch did also succeed.

Kind regards,
Bernhard

https://testbot.winehq.org/JobDetails.pl?Key=21671
https://testbot.winehq.org/JobDetails.pl?Key=21672

My local versions:
- package gcc-mingw-w64-i686 4.9.1-19+14.3
- Debian Jessie 8.3.

[Francois Gouget]

On Fri, 25 Mar 2016, Bernhard Übelacker wrote:
[...]
> one point that could be related is the usage of function local static
> variables. When all of these got the "static" removed, I do not get the
> failures anymore. However I could not prove this with testbot as an empty
> patch did also succeed.

The TestBot's build machine is still on Debian 7 (though it should be 
upgraded at some point). That would explain the difference.

[Francois Gouget]

On Fri, 25 Mar 2016, Francois Gouget wrote:

On Fri, 25 Mar 2016, Bernhard Übelacker wrote:
[...]
> one point that could be related is the usage of function local static
> variables. When all of these got the "static" removed, I do not get the
> failures anymore. However I could not prove this with testbot as an empty
> patch did also succeed.

I have not found static directives that I could remove to fix the 
dinput8 failures. Which test did it make a difference for? Could you 
send a diff?

All I could find to fix this is to add 'CFLAGS = -d -O0' in the test's 
Makefile.in but that does seem like a nice workaround :-(

[Bernhard Übelacker]

Hello Francois,

Am 30.03.2016 um 09:46 schrieb Francois Gouget:
> On Fri, 25 Mar 2016, Francois Gouget wrote:
>
> On Fri, 25 Mar 2016, Bernhard Übelacker wrote:
> [...]
> > one point that could be related is the usage of function local static
> > variables. When all of these got the "static" removed, I do not get the
> > failures anymore. However I could not prove this with testbot as an empty
> > patch did also succeed.
>
> I have not found static directives that I could remove to fix the
> dinput8 failures. Which test did it make a difference for? Could you
> send a diff?
>
> All I could find to fix this is to add 'CFLAGS = -d -O0' in the test's
> Makefile.in but that does seem like a nice workaround :-(

I attached a diff to this mail or see
https://testbot.winehq.org/JobDetails.pl?Key=21671

In my tests it started to fail in a vm when just one of these "statics" 
was left.

Kind regards,
Bernhard

[Francois Gouget]

I have rechecked this to make sure the test does not have a subtle bug 
that causes it to depend on the stack layout.

In the process I have reduced the test to the minimum set necessary to 
reproduce the bug (see attachment). But in the end I did not find 
anything wrong so it does look like a compiler bug.

I don't know how to proceed from there.

* I think it would be better if someone more knowlegeable than me 
  reported this bug to the MinGW guys. Maybe someone who could undertand 
  what happens in the assembly code?

* On the Wine side it would really be nice to get this test (and 
  the three others that are impacted) to stop failing. But removing all 
  the static directives really does not feel right. Would it be better 
  to arrange for these tests to be compiled with -O0? Any other cleaner 
  workaround.

So I'm really hoping someone can step up and move this forward.

Here are the relevant bugs:
* dinput8:dinput regression caused by new compiler
  https://bugs.winehq.org/show_bug.cgi?id=40384

* usp10:usp10 regression caused by new cross-compiler
  https://bugs.winehq.org/show_bug.cgi?id=40385

* wininet:url regression caused by new cross-compiler
  https://bugs.winehq.org/show_bug.cgi?id=40386

* Unexplained new random comctl32:header failure (cross-compiler issue?)
  https://bugs.winehq.org/show_bug.cgi?id=40442

[Francois Gouget]

I have added binaries compiled with my MinGW with -O2 and -O0, and 
compiled with the TestBot compiler. I also added assembly files and 
compiler version information. All of this is available at:

http://fgouget.free.fr/tmp/dinput8-dinput.tar.xz

For immediate reference:
My compiler is the Debian Testing compiler (buggy):
  $ i686-w64-mingw32-gcc --version
  i686-w64-mingw32-gcc (GCC) 5.3.1 20160205
  Copyright (C) 2015 Free Software Foundation, Inc.
  This is free software; see the source for copying conditions.  There is NO
  warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

The TestBot compiler is the Debian 7.4 compiler (not buggy):
  $ i686-w64-mingw32-gcc --version
  i686-w64-mingw32-gcc (GCC) 4.6.3
  Copyright (C) 2011 Free Software Foundation, Inc.
  This is free software; see the source for copying conditions.  There is NO
  warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

And the WineTest.exe binary is compiled with the Debian 8 compiler 
which is presumably close to the current Debian Testing one.

[André Hentschel]

Am 24.04.2016 um 21:12 schrieb Francois Gouget:
> I have added binaries compiled with my MinGW with -O2 and -O0, and 
> compiled with the TestBot compiler. I also added assembly files and 
> compiler version information. All of this is available at:
>
> http://fgouget.free.fr/tmp/dinput8-dinput.tar.xz
>
> For immediate reference:
> My compiler is the Debian Testing compiler (buggy):
>   $ i686-w64-mingw32-gcc --version
>   i686-w64-mingw32-gcc (GCC) 5.3.1 20160205
>   Copyright (C) 2015 Free Software Foundation, Inc.
>   This is free software; see the source for copying conditions.  There is NO
>   warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> The TestBot compiler is the Debian 7.4 compiler (not buggy):
>   $ i686-w64-mingw32-gcc --version
>   i686-w64-mingw32-gcc (GCC) 4.6.3
>   Copyright (C) 2011 Free Software Foundation, Inc.
>   This is free software; see the source for copying conditions.  There is NO
>   warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> And the WineTest.exe binary is compiled with the Debian 8 compiler 
> which is presumably close to the current Debian Testing one.

Any update on this? Downgrade the compiler? Fix it upstream and compile mingw-w64 from scratch?

[André Hentschel]

Am 24.04.2016 um 21:12 schrieb Francois Gouget:
> I have added binaries compiled with my MinGW with -O2 and -O0, and 
> compiled with the TestBot compiler. I also added assembly files and 
> compiler version information. All of this is available at:
>
> http://fgouget.free.fr/tmp/dinput8-dinput.tar.xz
>
> For immediate reference:
> My compiler is the Debian Testing compiler (buggy):
>   $ i686-w64-mingw32-gcc --version
>   i686-w64-mingw32-gcc (GCC) 5.3.1 20160205
>   Copyright (C) 2015 Free Software Foundation, Inc.
>   This is free software; see the source for copying conditions.  There is NO
>   warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> The TestBot compiler is the Debian 7.4 compiler (not buggy):
>   $ i686-w64-mingw32-gcc --version
>   i686-w64-mingw32-gcc (GCC) 4.6.3
>   Copyright (C) 2011 Free Software Foundation, Inc.
>   This is free software; see the source for copying conditions.  There is NO
>   warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> And the WineTest.exe binary is compiled with the Debian 8 compiler 
> which is presumably close to the current Debian Testing one.

What happens if we compile it using Clang? (totally easy to do so by using wclang [1] to generate a wrapper around clang and mingw-w64)
Or for me to try it, what's the best way to verify? does it depend on the wine version somewhat?

[1] https://github.com/tpoechtrager/wclang

[André Hentschel]

Am 26.06.2016 um 17:31 schrieb André Hentschel:
> Am 24.04.2016 um 21:12 schrieb Francois Gouget:
> > I have added binaries compiled with my MinGW with -O2 and -O0, and 
> > compiled with the TestBot compiler. I also added assembly files and 
> > compiler version information. All of this is available at:
> >
> > http://fgouget.free.fr/tmp/dinput8-dinput.tar.xz
> >
> > For immediate reference:
> > My compiler is the Debian Testing compiler (buggy):
> >   $ i686-w64-mingw32-gcc --version
> >   i686-w64-mingw32-gcc (GCC) 5.3.1 20160205
> >   Copyright (C) 2015 Free Software Foundation, Inc.
> >   This is free software; see the source for copying conditions.  There is NO
> >   warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> >
> > The TestBot compiler is the Debian 7.4 compiler (not buggy):
> >   $ i686-w64-mingw32-gcc --version
> >   i686-w64-mingw32-gcc (GCC) 4.6.3
> >   Copyright (C) 2011 Free Software Foundation, Inc.
> >   This is free software; see the source for copying conditions.  There is NO
> >   warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> >
> > And the WineTest.exe binary is compiled with the Debian 8 compiler 
> > which is presumably close to the current Debian Testing one.
>
> What happens if we compile it using Clang? (totally easy to do so by using wclang [1] to generate a wrapper around clang and mingw-w64)
> Or for me to try it, what's the best way to verify? does it depend on the wine version somewhat?
>
> [1] https://github.com/tpoechtrager/wclang

I noticed that my mingw-w64 has the same issue, so it was easy to try it out and it works!
Could someone install wclang on that machine and make wine using it please?

It's as easy as running configure like:
./configure CROSSCC=i686-w64-mingw32-clang ...
or
./configure --host=i686-w64-mingw32 CC=i686-w64-mingw32-clang host_alias=i686-w64-mingw32 ...

I compiled with (just exchanged i686-w64-mingw32-gcc with i686-w64-mingw32-clang):
i686-w64-mingw32-clang -c -o device.cross.o ../../../../dlls/dinput8/tests/device.c -I. -I../../../../dlls/dinput8/tests \
  -I../../../include -I../../../../include -D__WINESRC__ -DWINE_CROSSTEST -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0
i686-w64-mingw32-clang -c -o dinput.cross.o ../../../../dlls/dinput8/tests/dinput.c -I. -I../../../../dlls/dinput8/tests \
  -I../../../include -I../../../../include -D__WINESRC__ -DWINE_CROSSTEST -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0
i686-w64-mingw32-clang -c -o testlist.cross.o testlist.c -I. -I../../../../dlls/dinput8/tests -I../../../include \
  -I../../../../include -D__WINESRC__ -DWINE_CROSSTEST -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0
../../../tools/winegcc/winegcc -o dinput8_crosstest.exe -b i686-w64-mingw32 -B../../../tools/winebuild \
  --lib-suffix=.cross.a device.cross.o dinput.cross.o testlist.cross.o \
  ../../../dlls/dinput8/libdinput8.cross.a ../../../dlls/ole32/libole32.cross.a \
  ../../../dlls/user32/libuser32.cross.a ../../../dlls/advapi32/libadvapi32.cross.a

[Bernhard Übelacker]

Hello,
just tried to find out when this started exactly.

First by using old packages from snapshot.debian.org.
That revealed it started between packages:
  gcc-mingw-w64-i686_4.6.4-4+9_i386.deb
  gcc-mingw-w64-i686_4.8.2-5+10_i386.deb

A git bisect of gcc history points to this commit:
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=ff2a5adaa72fef87cac689a40c...

ff2a5adaa72fef87cac689a40c23258a30b304c8 is the first bad commit
commit ff2a5adaa72fef87cac689a40c23258a30b304c8
Author: hubicka 
Date:   Sun Apr 22 21:28:07 2012 +0000

* lto-symtab.c (lto_varpool_replace_node): Do not merge needed flags.
(...much longer commit message...)

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@186687 138bc75d-0d04-0410-961f-82ee72b054a4

:040000 040000 d706bdeafbddb9f5f02474e39a245dca08f3334a 508082a31919fe9e907f70b3b3278d4f8d953fac M      gcc

Testbot runs:
Good: (gcc 62c34bf, last one before ff2a5ad)
  https://testbot.winehq.org/JobDetails.pl?Key=24283
Bad:  (gcc ff2a5ad)
  https://testbot.winehq.org/JobDetails.pl?Key=24280

Hope this could be of any help to identify the issue.

Kind regards,
Bernhard

Notes:
- Did not install gcc build system wide. Instead set the PATH
  that i686-w64-mingw32-gcc was taken from there.
- Initial wine configure step was done using Jessie default
  gcc-mingw-w64-i686 4.9.1-19+14.3.
  Then the iterations were just done by removing objects
  from dlls/dinput8/tests and make dinput8_crosstest.exe.
- GCC history before 1e37e371 did segfault while building,
  therefore started from there.

Am 24.04.2016 um 20:30 schrieb Francois Gouget:
> I have rechecked this to make sure the test does not have a subtle bug 
> that causes it to depend on the stack layout.
>
> In the process I have reduced the test to the minimum set necessary to 
> reproduce the bug (see attachment). But in the end I did not find 
> anything wrong so it does look like a compiler bug.
>
> I don't know how to proceed from there.
> -
>
> I think it would be better if someone more knowlegeable than me 
> reported this bug to the MinGW guys. Maybe someone who could undertand 
> what happens in the assembly code?
> -
>
> On the Wine side it would really be nice to get this test (and 
> the three others that are impacted) to stop failing. But removing all 
> the static directives really does not feel right. Would it be better 
> to arrange for these tests to be compiled with -O0? Any other cleaner 
> workaround.
>
> So I'm really hoping someone can step up and move this forward.
>
> Here are the relevant bugs:
> -
>
> dinput8:dinput regression caused by new compiler
> https://bugs.winehq.org/show_bug.cgi?id=40384
> -
>
> usp10:usp10 regression caused by new cross-compiler
> https://bugs.winehq.org/show_bug.cgi?id=40385
> -
>
> wininet:url regression caused by new cross-compiler
> https://bugs.winehq.org/show_bug.cgi?id=40386
> -
>
> Unexplained new random comctl32:header failure (cross-compiler issue?)
> https://bugs.winehq.org/show_bug.cgi?id=40442

[Bernhard Übelacker]

Hello Francois,
"DirectX Software Development Kit" offers in
"DirectX Control Panel" to increase the
"Debug Output Level".

That way one can get another hint from dinput:
DINPUT8: ERROR IDirectInput8::EnumDevicesBySemantics: arg 2: invalid UNICODE string

First I tried to build a dinput8.dll that just dumps the
data it gets from dinput-mini.exe, but could not
find any difference.

So I did some tests with DIACTIONA.lptszActionName member.

When the two last characters get replaced by \0 no fault
is reported anymore.
That way a succeeding exe and the failing differ (nearly)
just in the two replaced bytes in lptszActionName.

Therefore can we assume that it is not the compilers
fault, instead it uncovered a hidden bug either in
the test or dinput?

Kind regards,
Bernhard

dinput.c:
-  { 4, DIMOUSE_YAXIS,                               0, { "Y Axis" }  }
+  { 4, DIMOUSE_YAXIS,                               0, { "Y Ax\0\0" }  }

Am 17.07.2016 um 21:02 schrieb Bernhard Übelacker:
> Hello,
> just tried to find out when this started exactly.
>
> First by using old packages from snapshot.debian.org.
> That revealed it started between packages:
>   gcc-mingw-w64-i686_4.6.4-4+9_i386.deb
>   gcc-mingw-w64-i686_4.8.2-5+10_i386.deb
>
> A git bisect of gcc history points to this commit:
> https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=ff2a5adaa72fef87cac689a40c...
>
> ff2a5adaa72fef87cac689a40c23258a30b304c8 is the first bad commit
> commit ff2a5adaa72fef87cac689a40c23258a30b304c8
> Author: hubicka 
> Date:   Sun Apr 22 21:28:07 2012 +0000
>     * lto-symtab.c (lto_varpool_replace_node): Do not merge needed flags.
>
> (...much longer commit message...)
> git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@186687 138bc75d-0d04-0410-961f-82ee72b054a4
>
> :040000 040000 d706bdeafbddb9f5f02474e39a245dca08f3334a 508082a31919fe9e907f70b3b3278d4f8d953fac M      gcc
>
> Testbot runs:
> Good: (gcc 62c34bf, last one before ff2a5ad)
>   https://testbot.winehq.org/JobDetails.pl?Key=24283
> Bad:  (gcc ff2a5ad)
>   https://testbot.winehq.org/JobDetails.pl?Key=24280
>
> Hope this could be of any help to identify the issue.
>
> Kind regards,
> Bernhard
>
> Notes:
> - Did not install gcc build system wide. Instead set the PATH
> that i686-w64-mingw32-gcc was taken from there.
> - Initial wine configure step was done using Jessie default
> gcc-mingw-w64-i686 4.9.1-19+14.3.
> Then the iterations were just done by removing objects
> from dlls/dinput8/tests and make dinput8_crosstest.exe.
> - GCC history before 1e37e371 did segfault while building,
> therefore started from there.
>
> Am 24.04.2016 um 20:30 schrieb Francois Gouget:
> > I have rechecked this to make sure the test does not have a subtle bug 
> > that causes it to depend on the stack layout.
> >
> > In the process I have reduced the test to the minimum set necessary to 
> > reproduce the bug (see attachment). But in the end I did not find 
> > anything wrong so it does look like a compiler bug.
> >
> > I don't know how to proceed from there.
> > -
> >
> > I think it would be better if someone more knowlegeable than me 
> > reported this bug to the MinGW guys. Maybe someone who could undertand 
> > what happens in the assembly code?
> > -
> >
> > On the Wine side it would really be nice to get this test (and 
> > the three others that are impacted) to stop failing. But removing all 
> > the static directives really does not feel right. Would it be better 
> > to arrange for these tests to be compiled with -O0? Any other cleaner 
> > workaround.
> >
> > So I'm really hoping someone can step up and move this forward.
> >
> > Here are the relevant bugs:
> > -
> >
> > dinput8:dinput regression caused by new compiler
> > https://bugs.winehq.org/show_bug.cgi?id=40384
> > -
> >
> > usp10:usp10 regression caused by new cross-compiler
> > https://bugs.winehq.org/show_bug.cgi?id=40385
> > -
> >
> > wininet:url regression caused by new cross-compiler
> > https://bugs.winehq.org/show_bug.cgi?id=40386
> > -
> >
> > Unexplained new random comctl32:header failure (cross-compiler issue?)
> > https://bugs.winehq.org/show_bug.cgi?id=40442

[André Hentschel]

Am 27.07.2016 um 02:36 schrieb Bernhard Übelacker:
> Hello Francois,
> "DirectX Software Development Kit" offers in
> "DirectX Control Panel" to increase the
> "Debug Output Level".
>
> That way one can get another hint from dinput:
> DINPUT8: ERROR IDirectInput8::EnumDevicesBySemantics: arg 2: invalid UNICODE string
>
> First I tried to build a dinput8.dll that just dumps the
> data it gets from dinput-mini.exe, but could not
> find any difference.
>
> So I did some tests with DIACTIONA.lptszActionName member.
>
> When the two last characters get replaced by \0 no fault
> is reported anymore.
> That way a succeeding exe and the failing differ (nearly)
> just in the two replaced bytes in lptszActionName.
>
> Therefore can we assume that it is not the compilers
> fault, instead it uncovered a hidden bug either in
> the test or dinput?
>
> Kind regards,
> Bernhard

Well, seems like 86cdf0b1cb7a15cb43dd0c600b66f6665aea87d2 indeed fixed it.
Thanks!