# emerge -va1t =sys-devel/gcc-4.7.4 These are the packages that would be merged, in reverse order: Calculating dependencies... done! [ebuild U ] sys-devel/gcc-4.7.4:4.7 [4.7.3-r1:4.7] USE="cxx fortran go graphite hardened (multilib) nptl objc objc++ objc-gc openmp (-altivec) -awt -doc (-fixed-point) -gcj (-libssp) -mudflap (-multislot) -nls -nopie -nossp -regression-test -vanilla" 0 kB Total: 1 package (1 upgrade), Size of downloads: 0 kB Would you like to merge these packages? [Yes/No] Yes (..) * 90_all_gcc-4.7-x32.patch ... * Failed Patch: 90_all_gcc-4.7-x32.patch ! * ( /var/tmp/portage/sys-devel/gcc-4.7.4/work/patch/90_all_gcc-4.7-x32.patch ) * * Include in your bugreport the contents of: * * /var/tmp/portage/sys-devel/gcc-4.7.4/temp/90_all_gcc-4.7-x32.patch.out * ERROR: sys-devel/gcc-4.7.4::gentoo failed (prepare phase): * Failed Patch: 90_all_gcc-4.7-x32.patch! * * Call stack: * ebuild.sh, line 93: Called src_prepare * environment, line 3738: Called toolchain_src_prepare * environment, line 4851: Called epatch '/var/tmp/portage/sys-devel/gcc-4.7.4/work/patch' * environment, line 1480: Called die * The specific snippet of code: * die "Failed Patch: ${patchname}!"; Full log attached and emerge --info Reproducible: Always
Created attachment 379194 [details] build.log
Created attachment 379196 [details] emerge --info
Created attachment 379198 [details] 90_all_gcc-4.7-x32.patch.out
we're going to drop the x32 patches as soon as gcc-4.8.x (or newer) goes stable. so the question is whether we expect 4.7.4 to go stable before that. otherwise i'd say this is a WONTFIX.
4.7.4 will go stable in 30 days. 4.8.3 probably soon after. Half the archs haven't keyworded 4.8 yet though (hint hint nudge nudge) so I don't know if there's any problems lurking. I'll see how hard it'll be to rebase this patch.
(In reply to Ryan Hill from comment #5) > 4.7.4 will go stable in 30 days. 4.8.3 probably soon after. Half the archs > haven't keyworded 4.8 yet though (hint hint nudge nudge) so I don't know if > there's any problems lurking. > > I'll see how hard it'll be to rebase this patch. I'll attach a version I cooked up. Lots of stuff still applies with normal "patch" (epatch seems stricter these days) or is just whitespace trouble, but this does contain several instances of "monkey-merges" (by which I mean, I preserved code deltas in conflicted places where I didn't understand the code in the slightest). I don't really use gcc-4.7.x anymore, and I only keep x32 around in order to test ebuilds, so I mostly never run the generated executables, except the occasional src_test ebuild phase, so my this should be considered largely untested and potentially harmful. Even so, it compiles, at least, and, IIRC, although x32 tests don't all pass, they fail in approximately the same constellation as they do to for x86_64.
Created attachment 380018 [details, diff] modified_gcc_474_90_all_gcc-4.7-x32.patch
thanks, i've updated the 4.7.4 ebuild with that now
Created attachment 381932 [details] build.log Maybe this is not related, but now the following error occurs : /var/tmp/portage/sys-devel/gcc-4.7.4/work/build/./gcc/xgcc -B/var/tmp/portage/sys-devel/gcc-4.7.4/work/build/./gcc/ -B/usr/x86_64-pc-linux-gnux32/bin/ -B/usr/x86_64-pc-linux-gnux32/lib/ -isystem /usr/x86_64-pc-linux-gnux32/include -isystem /usr/x86_64-pc-linux-gnux32/sys-include -g -march=native -O2 -pipe -O2 -g -march=native -O2 -pipe -DIN_GCC -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fpic -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fpic -I. -I. -I../.././gcc -I/var/tmp/portage/sys-devel/gcc-4.7.4/work/gcc-4.7.4/libgcc -I/var/tmp/portage/sys-devel/gcc-4.7.4/work/gcc-4.7.4/libgcc/. -I/var/tmp/portage/sys-devel/gcc-4.7.4/work/gcc-4.7.4/libgcc/../gcc -I/var/tmp/portage/sys-devel/gcc-4.7.4/work/gcc-4.7.4/libgcc/../include -I/var/tmp/portage/sys-devel/gcc-4.7.4/work/gcc-4.7.4/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -o bid_binarydecimal.o -MT bid_binarydecimal.o -MD -MP -MF bid_binarydecimal.dep -c /var/tmp/portage/sys-devel/gcc-4.7.4/work/gcc-4.7.4/libgcc/config/libbid/bid_binarydecimal.c /var/tmp/portage/sys-devel/gcc-4.7.4/work/gcc-4.7.4/libgcc/config/libbid/bid_binarydecimal.c: In function '__bid128_to_binary128': /var/tmp/portage/sys-devel/gcc-4.7.4/work/gcc-4.7.4/libgcc/config/libbid/bid_binarydecimal.c:145524:1: error: unrecognizable insn: (insn 1618 1617 1447 39 (set (reg:DI 0 ax) (subreg:DI (plus:SI (reg:SI 39 r10) (mult:SI (reg:SI 0 ax [orig:112 c$w$1 ] [112]) (const_int 4 [0x4]))) 0)) /var/tmp/portage/sys-devel/gcc-4.7.4/work/gcc-4.7.4/libgcc/config/libbid/bid_binarydecimal.c:145418 -1 (nil)) /var/tmp/portage/sys-devel/gcc-4.7.4/work/gcc-4.7.4/libgcc/config/libbid/bid_binarydecimal.c:145524:1: internal compiler error: in extract_insn, at recog.c:2123 Please submit a full bug report, with preprocessed source if appropriate. See <https://bugs.gentoo.org/> for instructions. Makefile:618: recipe for target 'bid_binarydecimal.o' failed make[3]: *** [bid_binarydecimal.o] Error 1 make[3]: Leaving directory '/var/tmp/portage/sys-devel/gcc-4.7.4/work/build/x86_64-pc-linux-gnux32/libgcc' Makefile:12507: recipe for target 'all-stage1-target-libgcc' failed make[2]: *** [all-stage1-target-libgcc] Error 2 make[2]: Leaving directory '/var/tmp/portage/sys-devel/gcc-4.7.4/work/build' Makefile:17615: recipe for target 'stage1-bubble' failed make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory '/var/tmp/portage/sys-devel/gcc-4.7.4/work/build' Makefile:17914: recipe for target 'bootstrap-lean' failed make: *** [bootstrap-lean] Error 2 * ERROR: sys-devel/gcc-4.7.4::gentoo failed (compile phase): * emake failed Attached full build.log
(In reply to Bertrand Jacquin from comment #9) i'm guessing that "by now" you mean it didn't build at all before. i'm really not interested in tracking down ICEs in x32 code in 4.7.x. just use 4.8+ already.
(In reply to SpanKY from comment #10) > (In reply to Bertrand Jacquin from comment #9) > > i'm guessing that "by now" you mean it didn't build at all before. true for 4.7.4 as 4.7.3 was building correctly. > i'm > really not interested in tracking down ICEs in x32 code in 4.7.x. just use > 4.8+ already. This is what I already do, I'm OK with that. I was initially reporting this as SLOT=4.7 is not masked for x32.
(In reply to Bertrand Jacquin from comment #9) > Created attachment 381932 [details] > build.log > > Maybe this is not related, but now the following error occurs : I don't doubt that this is "my fault" in the sense that my patch was somehow at fault. I have considerably different use flags than you, Bertrand, and those type of insn's were amongst the merge conflicts.... if you look at my patch and the resulting code carefully enough, you might be able to figure out what I did wrong and fix it, without needing to fully understand what it all means, since it appears to be a syntax error, not a logic error. Not sure if it's worth the effort though.
