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 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