Breaks all of wine, no easy workaround -> blocker.

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

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)

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

CFLAGS were -g -O2.

Confirming -O0 doesn't reproduce the issue.

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

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

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

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

same on opensuse, probably with -O2.
any updates?

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

did you identify the actual function that is miscompiled? or at least the object file?

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

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

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.

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.

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

(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.
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66845

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.

(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.
> > 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66845
> 
> 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

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

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

The fixes will only be in gcc 5.3, yes

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. :/

(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

Looks like it is fixed with GCC 5.3.0.

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

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

And closing, now that it's in an upstream release.