https://bugs.winehq.org/show_bug.cgi?id=38653
Bug ID: 38653 Summary: Wine doesn't run when compiled with GCC 5.1 Product: Wine Version: 1.7.44 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: adys.wh@gmail.com Distribution: ---
More details in https://bugs.wine-staging.com/show_bug.cgi?id=270
I'm getting various errors compiling it with GCC 5.1. The build process itself doesn't error, but starting apps (even wineboot) is broken.
https://bugs.winehq.org/show_bug.cgi?id=38653
Jerome Leclanche adys.wh@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.wine-staging.c | |om/show_bug.cgi?id=270
https://bugs.winehq.org/show_bug.cgi?id=38653
Jerome Leclanche adys.wh@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=38653
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sebastian@fds-team.de
https://bugs.winehq.org/show_bug.cgi?id=38653
Jerome Leclanche adys.wh@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |blocker
--- Comment #1 from Jerome Leclanche adys.wh@gmail.com --- Breaks all of wine, no easy workaround -> blocker.
https://bugs.winehq.org/show_bug.cgi?id=38653
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|blocker |critical
--- Comment #2 from Austin English austinenglish@gmail.com --- (In reply to Jerome Leclanche from comment #1)
Breaks all of wine, no easy workaround -> blocker.
Given that it's very possibly a GCC regression (and easily worked around by using a different GCC version), I think blocker is inappropriate.
https://bugs.winehq.org/show_bug.cgi?id=38653
--- Comment #3 from Austin English austinenglish@gmail.com --- Also, I can't reproduce this in 1.7.44 with Fedora 22's gcc:
[austin@localhost wine-git]$ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/5.1.1/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --disable-libgcj --with-default-libstdcxx-abi=c++98 --with-isl --enable-libmpx --enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 5.1.1 20150422 (Red Hat 5.1.1-1) (GCC)
https://bugs.winehq.org/show_bug.cgi?id=38653
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |focht@gmx.net
--- Comment #4 from Anastasius Focht focht@gmx.net --- Hello Austin,
--- quote --- Also, I can't reproduce this in 1.7.44 with Fedora 22's gcc: --- quote ---
That's probably due to default gcc optimization level being used which should work well in any case. You could try with higher optimization level, such as '-O2'.
AFAIK various distros have their own "optimized" settings when building packages. On Fedora you could check with 'rpm --eval %{optflags}'. Since you are building without package build system those are not active.
Jerome didn't provide information about compiler options being active (gcc defaults? distro defaults? own CFLAGS overrides?) so its hard to guess but probably mis-optimization related.
Regards
https://bugs.winehq.org/show_bug.cgi?id=38653
--- Comment #5 from Jerome Leclanche adys.wh@gmail.com --- CFLAGS were -g -O2.
https://bugs.winehq.org/show_bug.cgi?id=38653
--- Comment #6 from Jerome Leclanche adys.wh@gmail.com --- Confirming -O0 doesn't reproduce the issue.
https://bugs.winehq.org/show_bug.cgi?id=38653
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Wine doesn't run when |GCC 5.1 breaks -O2 |compiled with GCC 5.1 |optimization with 64-bit | |Wine Severity|critical |major
--- Comment #7 from Anastasius Focht focht@gmx.net --- Hello Jerome,
I'm lowering the priority here since it's only a problem when changing gcc default optimization level. Also refining the summary.
Regards
https://bugs.winehq.org/show_bug.cgi?id=38653
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, source, win64
--- Comment #8 from Austin English austinenglish@gmail.com --- (In reply to Anastasius Focht from comment #4)
Hello Austin,
--- quote --- Also, I can't reproduce this in 1.7.44 with Fedora 22's gcc: --- quote ---
That's probably due to default gcc optimization level being used which should work well in any case. You could try with higher optimization level, such as '-O2'.
Actually, it was that I was testing with a 32-bit wine compile. With 64-bit, I can reproduce the issue.
https://bugs.winehq.org/show_bug.cgi?id=38653
--- Comment #9 from Austin English austinenglish@gmail.com --- (In reply to Austin English from comment #8)
(In reply to Anastasius Focht from comment #4)
Hello Austin,
--- quote --- Also, I can't reproduce this in 1.7.44 with Fedora 22's gcc: --- quote ---
That's probably due to default gcc optimization level being used which should work well in any case. You could try with higher optimization level, such as '-O2'.
Actually, it was that I was testing with a 32-bit wine compile. With 64-bit, I can reproduce the issue.
FYI, I'm bisecting gcc for this issue.
https://bugs.winehq.org/show_bug.cgi?id=38653
--- Comment #10 from Austin English austinenglish@gmail.com --- Introduced by: [austin@localhost gcc]$ git bisect bad 96c09a553634967a94b5fd4ec3c46b58ffca1700 is the first bad commit commit 96c09a553634967a94b5fd4ec3c46b58ffca1700 Author: uros uros@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Sun Sep 21 15:13:14 2014 +0000
* config/i386/i386.c (ix86_expand_call): Generate MS->SYSV extra clobbered registers using clobber_reg. Remove UNSPEC decoration. * config/i386/i386.md (unspec) <UNSPEC_MS_TO_SYSV_CALL>: Remove. (*call_rex64_ms_sysv): Remove. (*call_value_rex64_ms_sysv): Ditto. * config/i386/predicates.md (call_rex64_ms_sysv_operation): Remove.
testsuite/ChangeLog:
* gcc.target/i386/avx-vzeroupper-16.c (dg-final): Remove check for call_value_rex64_ms_sysv. * gcc.target/i386/avx-vzeroupper-17.c (dg-final): Ditto. * gcc.target/i386/avx-vzeroupper-18.c (dg-final): Remove check for call_rex64_ms_sysv.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@215428 138bc75d-0d04-0410-961f-82ee72b054a4
:040000 040000 106752531e7926ba25b0617448d4ba45911c9dad 83a0c6ad4d406be569059bf7b59320804024d1c3 M gcc
still present in HEAD: [austin@localhost gcc]$ git show --oneline 7c62dfb PR c/66220: Fix false positive from -Wmisleading-indentation
https://bugs.winehq.org/show_bug.cgi?id=38653
Felix Yan felixonmars@archlinux.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |felixonmars@archlinux.org
https://bugs.winehq.org/show_bug.cgi?id=38653
Alasdair Sinclair alasdairsinc@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |alasdairsinc@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=38653
jbh@alchemy.lu changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jbh@alchemy.lu
https://bugs.winehq.org/show_bug.cgi?id=38653
Xavier Vachon xvachon@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |xvachon@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=38653
antony.kikaxa@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |antony.kikaxa@gmail.com
--- Comment #11 from antony.kikaxa@gmail.com --- same on opensuse, probably with -O2. any updates?
https://bugs.winehq.org/show_bug.cgi?id=38653
Marcus Meissner marcus@jet.franken.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |marcus@jet.franken.de
https://bugs.winehq.org/show_bug.cgi?id=38653
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://gcc.gnu.org/bugzill | |a/show_bug.cgi?id=66782
--- Comment #12 from Austin English austinenglish@gmail.com --- (In reply to antony.kikaxa from comment #11)
same on opensuse, probably with -O2. any updates?
I filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66782 upstream.
https://bugs.winehq.org/show_bug.cgi?id=38653
--- Comment #13 from Marcus Meissner marcus@jet.franken.de --- did you identify the actual function that is miscompiled? or at least the object file?
https://bugs.winehq.org/show_bug.cgi?id=38653
--- Comment #14 from Austin English austinenglish@gmail.com --- (In reply to Marcus Meissner from comment #13)
did you identify the actual function that is miscompiled? or at least the object file?
I haven't yet. I may try to later today.
https://bugs.winehq.org/show_bug.cgi?id=38653
--- Comment #15 from Marcus Meissner marcus@jet.franken.de --- For me even wineboot 64bit triggers a crash.
this seems to happen in dlls/setupapi/fakedll.c
adding 2 FIXME lines makes it work again, so there is weird optimization between the memcpy and strcpys going on.
memcpy( new_buffer, manifest, arch.ptr - manifest ); FIXME("after 1st memcpy\n"); strcpy( new_buffer + (arch.ptr - manifest), current_arch); FIXME("after 2nd strcpy\n"); memcpy( new_buffer + strlen(new_buffer), arch.ptr, len - (arch.ptr - manifest) );
https://bugs.winehq.org/show_bug.cgi?id=38653
--- Comment #16 from Marcus Meissner marcus@jet.franken.de --- The GCC bug is progressing.
I have however debugged only my "wineboot 64bit immediately crashes" issue.
Not sure if the 32bit Word issue is the same.
https://bugs.winehq.org/show_bug.cgi?id=38653
--- Comment #17 from antony.kikaxa@gmail.com --- the upstream gcc bug is marked as "fixed".
not sure what you mean with "32 bit word issue", for me x86 wine works as before.
https://bugs.winehq.org/show_bug.cgi?id=38653
--- Comment #18 from Marcus Meissner marcus@jet.franken.de --- The wine staging bug references as first comment a 32bit backtrace.
I have found the next crash during 64bit startup, in rpcrt4 and reported it to gcc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66845
https://bugs.winehq.org/show_bug.cgi?id=38653
--- Comment #19 from Austin English austinenglish@gmail.com --- (In reply to Marcus Meissner from comment #18)
The wine staging bug references as first comment a 32bit backtrace.
I have found the next crash during 64bit startup, in rpcrt4 and reported it to gcc.
Thanks Marcus. I attempted to test this fix last night, but noticed that gcc from SVN (trunk, not 5.1 branch) causes wineboot to segfault on start. Applying the patch on top of the original broken commit (again, in trunk branch) failed to build.
https://bugs.winehq.org/show_bug.cgi?id=38653
Michael Cronenworth mike@cchtml.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mike@cchtml.com
https://bugs.winehq.org/show_bug.cgi?id=38653
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://gcc.gnu.org/bugzill | |a/show_bug.cgi?id=66865
--- Comment #20 from Austin English austinenglish@gmail.com --- (In reply to Austin English from comment #19)
(In reply to Marcus Meissner from comment #18)
The wine staging bug references as first comment a 32bit backtrace.
I have found the next crash during 64bit startup, in rpcrt4 and reported it to gcc.
Thanks Marcus. I attempted to test this fix last night, but noticed that gcc from SVN (trunk, not 5.1 branch) causes wineboot to segfault on start. Applying the patch on top of the original broken commit (again, in trunk branch) failed to build.
I bisected the segfault and filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66865
https://bugs.winehq.org/show_bug.cgi?id=38653
--- Comment #21 from Xavier Vachon xvachon@gmail.com --- Created attachment 51916 --> https://bugs.winehq.org/attachment.cgi?id=51916 Terminal output winecfg
Some terminal output when I try to run winecfg on a fresh prefix in current git and gcc 5.2
https://bugs.winehq.org/show_bug.cgi?id=38653
--- Comment #22 from antony.kikaxa@gmail.com --- (In reply to Xavier Vachon from comment #21)
Created attachment 51916 [details] Terminal output winecfg
Some terminal output when I try to run winecfg on a fresh prefix in current git and gcc 5.2
gcc 5.2 doesn't includes one of the fixes.
https://bugs.winehq.org/show_bug.cgi?id=38653
Marcus Meissner marcus@jet.franken.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|GCC 5.1 breaks -O2 |GCC 5.0,5.1,5.2 break -O2 |optimization with 64-bit |optimization with 64-bit |Wine |Wine
--- Comment #23 from Marcus Meissner marcus@jet.franken.de --- The fixes will only be in gcc 5.3, yes
https://bugs.winehq.org/show_bug.cgi?id=38653
--- Comment #24 from Sebastian Lackner sebastian@fds-team.de --- I don't know if this is already covered by the existing gcc bug reports, but I noticed yesterday that even 32-bit wine compiled with gcc5.1 causes test failures in d3dx9_36/mesh tests. It doesn't happen when Wine is compiled with gcc4.9.
Could someone please check if this issue is still present after applying the gcc fixes? In the worst case its another regression which has to be bisected. :/
https://bugs.winehq.org/show_bug.cgi?id=38653
--- Comment #25 from Austin English austinenglish@gmail.com --- (In reply to Sebastian Lackner from comment #24)
I don't know if this is already covered by the existing gcc bug reports, but I noticed yesterday that even 32-bit wine compiled with gcc5.1 causes test failures in d3dx9_36/mesh tests. It doesn't happen when Wine is compiled with gcc4.9.
Could someone please check if this issue is still present after applying the gcc fixes? In the worst case its another regression which has to be bisected. :/
With a couple week old checkout of gcc (that has the 64-bit fixes applied), d3dx_36/mesh works on my machine.
commit da5e6421269c9683f17fb5e6e3bacfec50f22239 Author: mikael mikael@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Fri Jul 17 20:02:38 2015 +0000
gcc/testsuite/ * gfortran.dg/coarray_collectives_16.f90: Fix pattern as follow-up to r225930.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@225965 138bc75d-0d04-0410-961f-82ee72b054a4
https://bugs.winehq.org/show_bug.cgi?id=38653
ax 34noff otaku@rambler.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |otaku@rambler.ru
https://bugs.winehq.org/show_bug.cgi?id=38653
swswine@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |swswine@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=38653
--- Comment #26 from Felix Yan felixonmars@archlinux.org --- Looks like it is fixed with GCC 5.3.0.
https://bugs.winehq.org/show_bug.cgi?id=38653
Andrew Eikum aeikum@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |aeikum@codeweavers.com
--- Comment #27 from Andrew Eikum aeikum@codeweavers.com --- (In reply to Felix Yan from comment #26)
Looks like it is fixed with GCC 5.3.0.
Yes, this looks fixed to me using gcc 5.3.0 from Arch Linux.
https://bugs.winehq.org/show_bug.cgi?id=38653
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |NOTOURBUG
--- Comment #28 from Austin English austinenglish@gmail.com --- (In reply to Andrew Eikum from comment #27)
(In reply to Felix Yan from comment #26)
Looks like it is fixed with GCC 5.3.0.
Yes, this looks fixed to me using gcc 5.3.0 from Arch Linux.
K, thanks.
https://bugs.winehq.org/show_bug.cgi?id=38653
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #29 from Austin English austinenglish@gmail.com --- And closing, now that it's in an upstream release.