See the upstream (gcc) bug. Probably just a mater of picking up the patch.
Created attachment 427368 [details, diff] adds framepointer when saving SSE registers at function call or something
Would you please provide an ebuild (in the toolchain overlay ) for the GIT version of the gcc-5 branch. Many thanks, Helmut
Created attachment 427558 [details, diff] wine-1.9.3-gcc-5_3_0-disable-force-alignment.patch @Helmut Jarausch You know that you can still build the latest versions of wine (>=1.9.3) with gcc 5.3.0 - right?? Building a Git toolchain sounds like a bit of drastic measure... Vs. a (nearly) one line alteration to the Wine configuration file! I've attached the patch I use for wine versions 1.9.3, 1.9.4, 1.9.5 - in my Layman Overlay (bobwya). I use a sed replacement for the live 9999 ebuild in the Overlay (to allow building from earlier commits).
*** Bug 576560 has been marked as a duplicate of this bug. ***
*** Bug 576602 has been marked as a duplicate of this bug. ***
*** Bug 576606 has been marked as a duplicate of this bug. ***
*** Bug 576668 has been marked as a duplicate of this bug. ***
There's already a couple of gcc patches but it's much easier to just compile wine with -fno-omit-frame-pointer as a workaround until the gcc fix is out.
*** Bug 576838 has been marked as a duplicate of this bug. ***
It does not compile because of gcc-5.3 bug: https://gcc.gnu.org/ml/gcc-bugs/2016-01/msg00205.html Resolution: install gcc-6 from toolchain overlay (works for me, set USE=-gcj -objc* to save space and time), gcc-config, emerge wine, get back to stable gcc) wine-1.9.5 has the same effect on gcc-5.3, but I will file a new bug with ebuild patch in a minute, so one can use a newest version.
I'm sorry, it was a comment to wine bug :-(
*** Bug 576898 has been marked as a duplicate of this bug. ***
Problem is fixed by GCC team in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69140 Following patches are required: 1. https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/config/i386/i386.c?r1=232111&r2=232110&pathrev=232111 2. https://gcc.gnu.org/viewcvs/gcc/branches/gcc-5-branch/gcc/config/i386/i386.c?r1=232528&r2=232527&pathrev=232528 I tested by adding those patches in /etc/portage/patches/sys-devel/gcc and recompiling gcc-5.3.0.
@comment 13: Please, don't spam.
The same issue happens with wine-1.9.5.
(In reply to Juergen Rose from comment #15) > The same issue happens with wine-1.9.5. How is that comment useful in the slightest...? I've already posted a patch (see comment 3) that illustrates how to disable forced stack alignment for the wine package (a "feature" that was added in wine-1.9.3).
(In reply to Bob Wya from comment #16) > (In reply to Juergen Rose from comment #15) > > The same issue happens with wine-1.9.5. > > How is that comment useful in the slightest...? I've already posted a patch > (see comment 3) that illustrates how to disable forced stack alignment for > the wine package (a "feature" that was added in wine-1.9.3). Thanks Bob, your patch of comment 3 helps again.
The fix for this bug (which is now in tree) appears to break compilation on my machine (~amd64): >>> Running pre-merge checks for app-emulation/wine-1.9.5 * Checking for gcc-5-3 stack realignment compiler bug ... /usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/../../../../lib64/crt1.o: In function `_start': (.text+0x20): undefined reference to `main' collect2: error: ld returned 1 exit status My CFLAGS for wine are: CFLAGS="-O2 -gdwarf-2 -fno-omit-frame-pointer -mstackrealign -march=native -mfpmath=sse -floop-interchange -floop-strip-mine -floop-block -pipe" (-gdwarf-2 and -fno-omit-frame-pointer are to be able to somewhat meaningfully debug .exe crashes; -mstackrealign is for to https://www.winehq.org/pipermail/wine-bugs/2011-July/283269.html , although I'm not sure why I changed it from -mincoming-stack-boundary=2 to -mstackrealign - if one is obviously more correct than the other, please do advise me!) Note that even 'sudo CFLAGS="" emerge wine' fails with the same error. 'emerge -vp --nodeps wine gcc' says: [ebuild U ] app-emulation/wine-1.9.5::gentoo [1.9.4::gentoo] USE="X alsa cups custom-cflags dos fontconfig gecko gsm jpeg lcms mono mp3 ncurses nls openal opencl opengl osmesa png prelink pulseaudio run-exes s3tc samba ssl staging threads truetype udisks vaapi xcomposite xinerama xml -capi -gphoto2 -gstreamer -ldap -netapi -odbc -oss -pcap -perl -pipelight -realtime -scanner (-selinux) {-test} -v4l" ABI_X86="32 64 (-x32)" LINGUAS="en nl -ar -bg -ca -cs -da -de -el -en_US -eo -es -fa -fi -fr -he -hi -hr -hu -it -ja -ko -lt -ml -nb_NO -or -pa -pl -pt_BR -pt_PT -rm -ro -ru -sk -sl -sr_RS@cyrillic -sr_RS@latin -sv -te -th -tr -uk -wa -zh_CN -zh_TW" 146295 KiB [ebuild R ] sys-devel/gcc-5.3.0:5::gentoo USE="cxx fortran gcj graphite (multilib) nls nptl openmp (-altivec) (-awt) -cilk -debug -doc (-fixed-point) -go (-hardened) -jit (-libssp) (-multislot) -nopie -nossp -objc -objc++ -objc-gc -regression-test -sanitize -vanilla" 94687 KiB
(In reply to Cesko Voeten from comment #18) > The fix for this bug (which is now in tree) appears to break compilation on > my machine (~amd64) ... It's not a "fix" for anything - it's merely a TEST for the presence of the gcc 5.3.0 stack alignment bug. See https://bugs.gentoo.org/show_bug.cgi?id=577306 (corrected version of the gcc stack alignment test).
(In reply to Bob Wya from comment #19) > (In reply to Cesko Voeten from comment #18) > > The fix for this bug (which is now in tree) appears to break compilation on > > my machine (~amd64) ... > > It's not a "fix" for anything - it's merely a TEST for the presence of the > gcc 5.3.0 stack alignment bug. > > See https://bugs.gentoo.org/show_bug.cgi?id=577306 (corrected version of the > gcc stack alignment test). I think the point comment #18 making is that even the test is flawed. It does not provide any error message as to why it failed as seems to be the intention of the ebuild code immediately after 'die'. It's not as easy as just doing 'CFLAGS="${CFLAGS} -fno-omit-frame-pointer" emerge wine' anymore. This test in ebuild must now also be disabled first for wine to emerge.
(In reply to Rick Harris from comment #20) > > I think the point comment #18 making is that even the test is flawed. > > It does not provide any error message as to why it failed as seems to be the > intention of the ebuild code immediately after 'die'. > > It's not as easy as just doing 'CFLAGS="${CFLAGS} -fno-omit-frame-pointer" > emerge wine' anymore. > This test in ebuild must now also be disabled first for wine to emerge. I'm not a Gentoo Developer... but well technically I agree :-) . The test fails - because the gcc developer who wrote it never intended it to be "run". It is designed to fail at compile time - for an i386 build (on an amd64 machine). However it won't even compile without a main() function. That's C 101... :-) So the wine 1.9.5 ebuild was pushed out - without a single build test... Because if it had been tested... It would be immediately obvious that the build would "die" immediately on any architecture - with or without the gcc patches. Because the test won't even compile (and was never intended to be "runable")... The test detects a minor COMPILE time glitch - which has a known workaround... (1) The test should test for "amd64" only (currently it's globally enabled - why??) (2) It would a lot simpler to set a variable / flag for affected gcc and warn the user that stack alignment is to force-ably disabled... (3) ... Then just force enable the CFLAGS (you mentioned) for the i386 build wine... I'll be adding, the updated test, to my Layman ebuilds of Wine (bobwya). Which still work btw :-) But the wine ebuild's should not fail for a minor compile time issue - with a simple, known workaround...
(In reply to Bob Wya from comment #21) > (In reply to Rick Harris from comment #20) > > > > I think the point comment #18 making is that even the test is flawed. > > > > It does not provide any error message as to why it failed as seems to be the > > intention of the ebuild code immediately after 'die'. > > > > It's not as easy as just doing 'CFLAGS="${CFLAGS} -fno-omit-frame-pointer" > > emerge wine' anymore. > > This test in ebuild must now also be disabled first for wine to emerge. > > I'm not a Gentoo Developer... but well technically I agree :-) . > > The test fails - because the gcc developer who wrote it never intended it to > be "run". It is designed to fail at compile time - for an i386 build (on an > amd64 machine). However it won't even compile without a main() function. > That's C 101... :-) > Mea culpa on that one. I assumed that someone posting a piece of test code had a main function, and given that the previous one that we have in our ebuild does, I assumed the gcc devs always included one. Testing the ebuild here doesn't make much difference because it only happens with gcc-5.3, and I don't have it installed presently. > So the wine 1.9.5 ebuild was pushed out - without a single build test... > Because if it had been tested... It would be immediately obvious that the > build would "die" immediately on any architecture - with or without the gcc > patches. Because the test won't even compile (and was never intended to be > "runable")... > > The test detects a minor COMPILE time glitch - which has a known > workaround... > (1) The test should test for "amd64" only (currently it's globally enabled - > why??) > (2) It would a lot simpler to set a variable / flag for affected gcc and > warn the user that stack alignment is to force-ably disabled... > (3) ... Then just force enable the CFLAGS (you mentioned) for the i386 build > wine... > I'm both a busy guy, and I am not perfect :P But if you see a bug, please submit a patch. They are always welcome. > I'll be adding, the updated test, to my Layman ebuilds of Wine (bobwya). > Which still work btw :-) But the wine ebuild's should not fail for a minor > compile time issue - with a simple, known workaround...
Created attachment 428274 [details, diff] wine-1.9.5_gcc53-fix.diff Attached is a patch to the current wine-1.9.5.ebuild to append '-fno-omit-frame-pointer' to CFLAGS if the currently selected gcc is 5.3. Removed the compile tests in the patch as the problems with these versions are known so just acted on gcc versions detected. Just an idea anyway, hope it helps :)
(In reply to Bob Wya from comment #16) > (In reply to Juergen Rose from comment #15) > > The same issue happens with wine-1.9.5. > > How is that comment useful in the slightest...? I've already posted a patch > (see comment 3) that illustrates how to disable forced stack alignment for > the wine package (a "feature" that was added in wine-1.9.3). It seems me, that this patch is now not enough. Using this patch with wine-1.9.5, 'emerge wine' fails now with: >>> Running pre-merge checks for app-emulation/wine-1.9.5 * Checking for gcc-5-3 stack realignment compiler bug ... /usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/../../../../lib64/crt1.o: In function `_start': (.text+0x20): undefined reference to `main' collect2: error: ld returned 1 exit status * ERROR: app-emulation/wine-1.9.5::x-portage failed (pretend phase):
(In reply to Rick Harris from comment #23) > Created attachment 428274 [details, diff] [details, diff] > wine-1.9.5_gcc53-fix.diff > > Attached is a patch to the current wine-1.9.5.ebuild to append > '-fno-omit-frame-pointer' to CFLAGS if the currently selected gcc is 5.3. > > Removed the compile tests in the patch as the problems with these versions > are known so just acted on gcc versions detected. > > Just an idea anyway, hope it helps :) I applied your wine-1.9.5_gcc53-fix.diff and the patch of comment 3, but 'emerge wine' fails with: * Checking for gcc-5-3 stack realignment compiler bug ... /usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/../../../../lib64/crt1.o: In function `_start': (.text+0x20): undefined reference to `main' collect2: error: ld returned 1 exit status * ERROR: app-emulation/wine-1.9.5::x-portage failed (pretend phase): * (no error message)
Created attachment 428280 [details, diff] wine-1.9.5_gcc53-fix.diff (In reply to Juergen Rose from comment #25) > (In reply to Rick Harris from comment #23) > > Created attachment 428274 [details, diff] [details, diff] [details, diff] > > wine-1.9.5_gcc53-fix.diff > > > > Attached is a patch to the current wine-1.9.5.ebuild to append > > '-fno-omit-frame-pointer' to CFLAGS if the currently selected gcc is 5.3. > > > > Removed the compile tests in the patch as the problems with these versions > > are known so just acted on gcc versions detected. > > > > Just an idea anyway, hope it helps :) > > I applied your wine-1.9.5_gcc53-fix.diff and the patch of comment 3, but > 'emerge wine' fails with: > > * Checking for gcc-5-3 stack realignment compiler bug ... > /usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/../../../../lib64/crt1.o: In function > `_start': > (.text+0x20): undefined reference to `main' > collect2: error: ld returned 1 exit status > * ERROR: app-emulation/wine-1.9.5::x-portage failed (pretend phase): > * (no error message) The patch was more meant for NP-Hardass in aiding for a fix but am happy to help get the patch applied properly. I've re-uploaded the ebuild patch to be certain the patch is correct. I'm not using the patch from comment #3, just a different approach. So to apply the patch: cd /usr/portage/app-emulation/wine patch wine-1.9.5.ebuild < /path/to/wine-1.9.5_gcc53-fix.diff ebuild wine-1.9.5.ebuild digest emerge wine
(In reply to Rick Harris from comment #26) > So to apply the patch: > cd /usr/portage/app-emulation/wine > patch wine-1.9.5.ebuild < /path/to/wine-1.9.5_gcc53-fix.diff > ebuild wine-1.9.5.ebuild digest > emerge wine Rick, please see: https://bugs.gentoo.org/show_bug.cgi?id=577306 I've supplied patches that fix the i386 stack alignment test. 1) It has to compile - all C code needs a main() somewhere!! 2) It was not designed to ever be executed (as the issue is an i386 compile time failure) You can't really blanket apply extra unnecessary C build flags... So the test case is needed before adding "-fno-omit-frame-pointer" (which is the behaviour I plan to add to my Layman wine builds). After all it's easy enough to apply (user) patches to gcc - with Gentoo. I've checked out my revised version of the test (see patch in above) - both with an unpatched gcc 5.3.0 and a patched gcc 5.3.0... It failures on the unpatched gcc 5.3.0 (as before) and succeeds on a patched gcc 5.3.0 (as expected). Ditto for the gcc <=5.2.0 tests. They're there for a good reason! The test won't fail for a suitably patched version of gcc. After all you're welcome to remove whatever you want from an ebuild - in your own local overlay :-)
(In reply to NP-Hardass from comment #22) > Mea culpa on that one. I assumed that someone posting a piece of test code > had a main function, and given that the previous one that we have in our > ebuild does, I assumed the gcc devs always included one. Testing the ebuild > here doesn't make much difference because it only happens with gcc-5.3, and > I don't have it installed presently. Ahhh. Yes that's a thing... I didn't think of that! Whoops... > I'm both a busy guy, and I am not perfect :P But if you see a bug, please > submit a patch. They are always welcome. Sorry, I was being a bit OTT with my comments... Who doesn't like to join a "frenzied mob" on the Internet though??!! 8-> I've got some thoughts about the live wine (9999) ebuild. I could maybe bring them up in separate bug report. Or is irc (I've quasselcore client running on my NAS Server), the Gentoo forums, or email better for you? Bugzilla is rubbish for generally chatting about an issue - because of the lack of threading, re-editing posts, etc....
(In reply to Bob Wya from comment #28) > I've got some thoughts about the live wine (9999) ebuild. I could maybe > bring them up in separate bug report. Or is irc (I've quasselcore client > running on my NAS Server), the Gentoo forums, or email better for you? > Bugzilla is rubbish for generally chatting about an issue - because of the > lack of threading, re-editing posts, etc.... Email or IRC is fine. I'm always idling in #gentoo-wine, and am available generally most days until midnight US EST.
(In reply to Rick Harris from comment #23) > Created attachment 428274 [details, diff] [details, diff] > wine-1.9.5_gcc53-fix.diff > > Attached is a patch to the current wine-1.9.5.ebuild to append > '-fno-omit-frame-pointer' to CFLAGS if the currently selected gcc is 5.3. > > Removed the compile tests in the patch as the problems with these versions > are known so just acted on gcc versions detected. > > Just an idea anyway, hope it helps :) Thanks for the patch/suggestion. I'd rather not blanket disable frame pointers across the entire wine build because of a single compilation bug.
(In reply to NP-Hardass from comment #30) > Thanks for the patch/suggestion. I'd rather not blanket disable frame > pointers across the entire wine build because of a single compilation bug. No problem, but I thought '-fno-omit-frame-pointer' did the opposite. ie. Blocks the use of '-fomit-frame-pointer' and only on buggy GCC versions in this instance. Still I guess the ebuild compile tests could come in handy if it becomes Gentoo's intention to backport the gcc patches at some stage in the future. Cheers :)
(In reply to NP-Hardass from comment #30) > Thanks for the patch/suggestion. I'd rather not blanket disable frame > pointers across the entire wine build because of a single compilation bug. That doesn't make sense, quoting the gcc manual: *** -fomit-frame-pointer Don't keep the frame pointer in a register for functions that don't need one. This avoids the instructions to save, set up and restore frame pointers; it also makes an extra register available in many functions. It also makes debugging impossible on some machines. ... Enabled at levels -O, -O2, -O3, -Os. *** And the default for CFLAGS on the stage3(at least for amd64 ) is: CFLAGS="-O2 -pipe" So frame pointers are 'blanket disabled' by default on Gentoo, and the solution would be to enable them and it's harmless and fixes the problem until upstream(s) fix it.
(In reply to Ianislav Trendafilov from comment #13) > Problem is fixed by GCC team in > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69140 > > Following patches are required: > 1. > https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/config/i386/i386. > c?r1=232111&r2=232110&pathrev=232111 > 2. > https://gcc.gnu.org/viewcvs/gcc/branches/gcc-5-branch/gcc/config/i386/i386. > c?r1=232528&r2=232527&pathrev=232528 > > I tested by adding those patches in /etc/portage/patches/sys-devel/gcc and > recompiling gcc-5.3.0. Applying those patches and rebuilding gcc solves the issue for wine-1.9.5 for me. The pre-merge check succeeds and the merge goes through just fine. Thank you very much for linking the patches!
(In reply to Sven Eden from comment #33) > (In reply to Ianislav Trendafilov from comment #13) > > Problem is fixed by GCC team in > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69140 > > > > Following patches are required: > > 1. > > https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/config/i386/i386. > > c?r1=232111&r2=232110&pathrev=232111 > > 2. > > https://gcc.gnu.org/viewcvs/gcc/branches/gcc-5-branch/gcc/config/i386/i386. > > c?r1=232528&r2=232527&pathrev=232528 > > > > I tested by adding those patches in /etc/portage/patches/sys-devel/gcc and > > recompiling gcc-5.3.0. > > Applying those patches and rebuilding gcc solves the issue for wine-1.9.5 > for me. The pre-merge check succeeds and the merge goes through just fine. > > Thank you very much for linking the patches! The links https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/config/i386/i386 are broken.
Created attachment 428646 [details] gcc-5.3.0-save_require_frame-pointer_when_stack_misaligned.patch @Juergen Rose I've attached a unified patch that fixes the gcc-5.3.0 issue (straight out of my User patches folder) - from Upstream. The gcc developers have probably just committed the previous patch links.
(In reply to Juergen Rose from comment #34) > (In reply to Sven Eden from comment #33) > > (In reply to Ianislav Trendafilov from comment #13) > > > Following patches are required: > > > 1. > > > https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/config/i386/i386. > > > c?r1=232111&r2=232110&pathrev=232111 > > > 2. > > > https://gcc.gnu.org/viewcvs/gcc/branches/gcc-5-branch/gcc/config/i386/i386. > > > c?r1=232528&r2=232527&pathrev=232528 > > The links https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/config/i386/i386 are > broken. The links were wrapped by a mail client. You're missing .c and the rest of the line which will make the link work.
There is known patch for the gcc in this very thread for almost a month. How come it is not added to sys-devel/gcc yet so we can close this bug and get on with our lives?
The proper fix is to get gcc updated. The interim solution is to patch the wine build to work around the problem. It's completely inappropriate to hard-fail the wine build all the time, which for some insane reason is what we have now. GCC upstream bugfix has been available for 3 months, it's pathetic that a crucial fix to a core component is still not patched after this long.
(In reply to faminebadger from comment #38) > The proper fix is to get gcc updated. > > The interim solution is to patch the wine build to work around the problem. > > It's completely inappropriate to hard-fail the wine build all the time, > which for some insane reason is what we have now. > > GCC upstream bugfix has been available for 3 months, it's pathetic that a > crucial fix to a core component is still not patched after this long. None of the proposed patches to wine are acceptable. I'm not going to repeat the reasons over and over. The only resolution is patching GCC. Either wait patiently for the toolchain team to patch GCC, or patch your own GCC locally.
FYI, upstream enables -fno-omit-frame-pointer by defalut on x86: https://source.winehq.org/git/wine.git/blob/ad7cb436571ec66ae7a5687568fca2f5318c7e76:/configure.ac#l1788 which is needed by some copy protections, see: https://bugs.winehq.org/show_bug.cgi?id=27349 https://bugs.winehq.org/show_bug.cgi?id=27686 https://bugs.winehq.org/show_bug.cgi?id=28753 So far nothing has needed it on x86_64 that we know of, so I'm not sure if it makes sense or not to enable that on wine64, I'll have to check with some other upstream people.
(In reply to Austin English from comment #40) > FYI, upstream enables -fno-omit-frame-pointer by defalut on x86: > https://source.winehq.org/git/wine.git/blob/ > ad7cb436571ec66ae7a5687568fca2f5318c7e76:/configure.ac#l1788 > > which is needed by some copy protections, see: > https://bugs.winehq.org/show_bug.cgi?id=27349 > https://bugs.winehq.org/show_bug.cgi?id=27686 > https://bugs.winehq.org/show_bug.cgi?id=28753 > Well, wine upstream isn't always right, as the case of handling string collation shows. They also disable the (pretty standard by now) _FORTIFY_SOURCE scheme in glibc due to some kind of race there, but (at least from the outside) don't seem to press all that hard for a real fix in glibc. That gcc handles some of the optimizations (strict aliasing being prime example) in a bit too unsafe way is besides the point. But as it was said in one of the bugs: > > It was their [gcc upstream] decision to change the default behaviour for frame pointer optimizations starting with 4.6 series. > It's very, very unlikely that the gcc folks will revert this for the sake of Wine. > > If Wine depends on the previous behaviour ... it has to take care of this. > The generated code is perfectly legal with changed default. As for SafeDisc, I don't recall the details, but didn't Microsoft axed it recently due to security concerns ? ...OK, that's almost off topic...
...more on topic, what NP-Hardass said in comment 39 was pretty much the intention of filing this bug.
So, with all the respect to the discussion, how to build wine?
(In reply to Lubos Kolouch from comment #43) > So, with all the respect to the discussion, how to build wine? tl;dr ;-) Just apply the combined (Upstream) patch I've posted above - to your: =sys-devel/gcc-5.3.0 build ... https://574044.bugs.gentoo.org/attachment.cgi?id=428646 or if that's "too hard" there is a well known workaround (which is applied to wine builds in my overlay ::bobwya). So you're welcome to examine that as well...
(In reply to Bob Wya from comment #44) > (In reply to Lubos Kolouch from comment #43) > > So, with all the respect to the discussion, how to build wine? > https://574044.bugs.gentoo.org/attachment.cgi?id=428646 > > or if that's "too hard" ... Here is a guide for a complete idiot like me. This assumes you're on current gcc (5.3.0); follow these steps: 1. Make a directory for portage to pick up the patch for gcc. sudo mkdir -p /etc/portage/patches/sys-devel/gcc-5.3.0 2. Download the patch file and put it into the patch folder. curl "https://574044.bugs.gentoo.org/attachment.cgi?id=428646" | sudo tee /etc/portage/patches/sys-devel/gcc-5.3.0/wine-fix.patch 3. Re-compile gcc. sudo emerge -1 gcc-5.3.0 4. Re-compile wine. sudo emerge -1u wine Hopefully gcc-5.3.1 picks up this patch. If not: sudo mkdir -p /etc/portage/patches/sys-devel/gcc-5.3.1 curl "https://574044.bugs.gentoo.org/attachment.cgi?id=428646" | sudo tee /etc/portage/patches/sys-devel/gcc-5.3.1/wine-fix.patch (adapt as required until patch is shipped with package.)
comment #10 claims this is fixed in GCC 6. Bug #581434 is tracking the version bump to sys-devel/gcc-6.1.0. I suggest that being added as a blocker of this bug.
No, if we have upstream patches for 5.3 we should apply them. 6 won't be in ~arch for several months.
Comment on attachment 428646 [details] gcc-5.3.0-save_require_frame-pointer_when_stack_misaligned.patch This patch is wrong. The second hunk should not be included.
(In reply to Ryan Hill from comment #48) > Comment on attachment 428646 [details] [details, diff] > gcc-5.3.0-save_require_frame-pointer_when_stack_misaligned.patch > > This patch is wrong. The second hunk should not be included. Ryan is correct, per https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69140#c18 Correct patch is Attachment 427368 [details, diff] ( https://bugs.gentoo.org/attachment.cgi?id=427368&action=diff ) which matches the upstream bug patch.
Comment on attachment 428646 [details] gcc-5.3.0-save_require_frame-pointer_when_stack_misaligned.patch Oops... tl;dr :-) Is this the correct Upstream patch?? https://gcc.gnu.org/viewcvs/gcc/branches/gcc-5-branch/gcc/config/i386/i386.c?view=patch&r1=232528&r2=232527&pathrev=232528
Fixed in 5.3.0 p1.1. Sync up and rebuild gcc.
(In reply to Ryan Hill from comment #51) > Fixed in 5.3.0 p1.1. Sync up and rebuild gcc. Thank you so much! I will try that tonight!
Is gcc going to get a revbump for this? Closing the bug is going to make this fix hard to find if portage doesn't want to update gcc.
No we don't revbump gcc unless it's something major affecting everyone. This affects one package.
(In reply to Ryan Hill from comment #51) > Fixed in 5.3.0 p1.1. Sync up and rebuild gcc. Works!
