gcc (GCC) 3.3.3 20040217 (Gentoo Linux 3.3.3, propolice-3.3-7) development-sources 2.6.7 on a SparcStation 5. During make, compile bombs out with "internal compiler failure." This is a known bug in GCC, apparently. See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15693 Reproducible: Always Steps to Reproduce: 1. Using GCC version above 2. Compile Kernel Actual Results: LD usr/built-in.o CC mm/fremap.o mm/fremap.c: In function `install_page': mm/fremap.c:95: error: unrecognizable insn: (insn 843 71 844 2 0x5077f690 (set (reg:SI 255) (zero_extract:SI (reg:SI 139) (const_int 1 [0x1]) (const_int 31 [0x1f]))) -1 (nil) (expr_list:REG_DEAD (reg:SI 139) (nil))) mm/fremap.c:95: internal compiler error: in extract_insn, at recog.c:2175 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://bugs.gentoo.org/> for instructions. Preprocessed source stored into /tmp/ccnIqM29.out file, please attach this to your bugreport make[1]: *** [mm/fremap.o] Error 1 make: *** [mm] Error 2 Expected Results: Normal compile.
Tested out this patch on both sparc32 and sparc64 using gcc-3.3.3-r5 gcc-porting folks, could we get the patch from the link in the description included in the gcc ebuilds for sparc?
gcc-porting has nothing to do with gcc itself, just porting stuff to new versions of gcc... re-assigning to toolchain
It is already fixed in 3.3.4 ...
Right, but chances are most people aren't going to be stablizing 3.3.4 any time soon. As this is causing kernel compilation issues, can we get it into a 3.3.3?
You want a new revision, or just add to last stable ?
Actually, Solar, anything you guys want to get added from hardened side?
*** Bug 57800 has been marked as a duplicate of this bug. ***
Guys, I don't know what to do with this - sparc is still on gcc-3.3.3, and none of the -r* is even ~ KEYWORDed ... Can I just add this to -r6, and mark ~ for sparce? You want me to remove the real -r1, cp -r0 to it and add the patch there and mark stable for sparc only? The sparc devs have to help out here - I am not sure if any of you even tried the later revisions, and if this is due to lack of testing, or because of issues?
Sorry for the late reply. Definitely add to gcc-3.3.3 and up to and including -r5 (both 3.3.3 and 3.3.3-r5 should have sparc keywords). As for -r6, it doesn't have a sparc keyword as of yet. As pappy has been working on getting the hardened useflags going on sparc, I'm not sure if we should add it to -r6 and ~sparc it yet or just go with ~sparc'ing 3.3.4-r1. I need to double check with him first as I'd think 3.3.4-r1 might be a better choice than 3.3.3-r6 (though if it isn't please let me know)
3.3.3-r6 should work fine and is the desireable gcc to switch to. What's not in 3.3.3-r6 is extra hardened support. But that's ok -r7 or another can add it. Or better yet >=3.3.4-r1 if that can go ~sparc as well.
My inclination is to ~sparc 3.3.4-r1 myself. After testing it out this weekend, I didn't see anything that stuck out. Since the work pappy had asked me to test specifically asked for gcc-3.3.3-r6, I was going to check with him on that, but I guess this really doesn't apply to this bug. So for now, I guess we can apply this patch to gcc-3.3.3 as that is the current stable gcc on sparc. Additionally, we may need to add it to some of the gcc-3.3.3-r's in the event that we need to stablize one before a gcc-3.3.4* could be considered for stable.
Ok, I commited gcc-3.3.3-r1 with KEYWORDS="-* ~sparc". Verify it and just bump it to stable - then you guys can test 3.3.4-r1 on your time.
Can we get it added to gcc-3.3.3-r0 for those already on stable but using a 2.6 kernel? Also is gcc-3.3.3-r1 better to look towards for future stablization over gcc-3.3.3-r5 (which is the current gcc on ~sparc)? As I replied to your testing email on Monday, sparc is good to go for gcc-3.3.4-r1, so feel free to ~sparc it (or I will if there are no objections).
>Can we get it added to gcc-3.3.3-r0 for those already on stable but > using a 2.6 kernel? Also is gcc-3.3.3-r1 better to look towards for > future stablization over gcc-3.3.3-r5 (which is the current gcc on > ~sparc)? > The theory is that gcc-3.3.3-r1 _is_ gcc-3.3.3-r1 _with_ the patch, and if you can just check that it unpacks (I checked this), compiles, and fixes this bug, you can mark it stable, and will be forced on all sparc users. Problem with applying to -r0, is that many will hit the bug still as they will not know to remerge gcc ... I was asking earlier more for comments as I did not know if you guys was testing -r5/6 and might be contemplating adding to stable soon (and thus making that the better build to add it) ... > As I replied to your testing email on Monday, sparc is good to go > for gcc-3.3.4-r1, so feel free to ~sparc it (or I will if there are > no objections). > Except if you have any specific reasons why not, I'd rather that a sparc dev ~ it. I do not think anybody would or should scream murder if a arch dev ~ or mark stable a package that they maintain for that arch (as they - the arch devs - are the guys testing it, and generally might know better), except if they know about a specific reason not to ... and then rather then scream discuss it with the arch dev, and deside together if its fatal enough if there is no fix available ...
Bah, this: The theory is that gcc-3.3.3-r1 _is_ gcc-3.3.3-r1 _with_ the patch should be The theory is that gcc-3.3.3-r1 _is_ gcc-3.3.3-r0 _with_ the patch
Is there anyway we can clean up the 3.3.3-rX so that only 3.3.3-r6 in the remaining gcc-3.3.3 to choose from so we can actually aim to start removing some of the extra -rX ebuilds for gcc? There have been fundamental changes in our gcc's with USE flags and it would be nice to get sparc on the same playing field.
Ok, gcc-3.3.4-r1 just went stable on sparc. Can you test after upgrading gcc? I'll close this as TEST-REQUEST, feel free to reopen otherwise. Thanks.
