23 Mar
2016
23 Mar
'16
11:17 a.m.
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
--
Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/
Nouvelle version : les anciens bogues ont été remplacés par de nouveaux.
23 Mar
23 Mar
12:20 p.m.
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
1:05 p.m.
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 <fgouget(a)free.fr> http://fgouget.free.fr/
War doesn't determine who's right. War determines who's left.
2:02 p.m.
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.
--
Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/
Before you criticize someone, walk a mile in his shoes.
That way, if he gets angry, he'll be a mile away - and barefoot.
25 Mar
25 Mar
3:27 a.m.
Hello,
Am 23.03.2016 um 14:05 schrieb Francois Gouget:
On Wed, 23 Mar 2016, Francois Gouget 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.
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.
* 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.
7:46 a.m.
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 <fgouget(a)free.fr> http://fgouget.free.fr/
You can have my guns when you pry them from my kids cold, dead hands.
30 Mar
30 Mar
7:46 a.m.
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 :-(
--
Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/
You can have my guns when you pry them from my kids cold, dead hands.
8:37 a.m.
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:
[...]
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
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 :-(
24 Apr
24 Apr
6:30 p.m.
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 <fgouget(a)free.fr> http://fgouget.free.fr/
1 + e ^ ( i * pi ) = 0
7:12 p.m.
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.
--
Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/
A particle is an irreducible representation of the Poincaré Group - Eugene Wigner
3 May
3 May
5:35 p.m.
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?
26 Jun
26 Jun
3:31 p.m.
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
10 Jul
10 Jul
6:40 p.m.
Am 26.06.2016 um 17:31 schrieb André Hentschel:
Am 24.04.2016 um 21:12 schrieb Francois Gouget:
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
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
17 Jul
17 Jul
7:02 p.m.
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=ff2a5adaa72fef87cac689a40…
ff2a5adaa72fef87cac689a40c23258a30b304c8 is the first bad commit
commit ff2a5adaa72fef87cac689a40c23258a30b304c8
Author: hubicka <hubicka@138bc75d-0d04-0410-961f-82ee72b054a4>
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
27 Jul
27 Jul
12:36 a.m.
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=ff2a5adaa72fef87cac689a40…
ff2a5adaa72fef87cac689a40c23258a30b304c8 is the first bad commit
commit ff2a5adaa72fef87cac689a40c23258a30b304c8
Author: hubicka <hubicka@138bc75d-0d04-0410-961f-82ee72b054a4>
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
7 Aug
7 Aug
12:49 p.m.
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!
2825
days inactive
2962
days old
15 comments
5 participants
participants (5)
-
André Hentschel -
Bernhard Übelacker -
Bernhard Übelacker -
Francois Gouget -
Michael Stefaniuc