The bootstrap failure reported in http://gcc.gnu.org/ml/gcc/2007-09/msg00147.html is still present in revision 128385.
libgomp is also broken for powerpc*-linux-gnu. It times out.
*** Bug 33411 has been marked as a duplicate of this bug. ***
--disable-checking succeeded with rev 128389.
I think this is the same issue as PR 33348. The shared RTX are the same and the original RTX is the same type of RTX (I forgot to paste it into the bug though). -- Pinski
I see now the same, --enable-checking is used now.
Is anyone working on this bug? I ask because Apple's regress server has effectively stopped showing testresults because of this bug. Also, I am a tad confused by the comments that -enable-checking is now used. Does this imply that this bug has been latent in prior gcc releases and that the new default use of -enable-checking has exposed it? Also would I be able to suppress this problem with --disable-checking? I was hoping to test the new vectorization changes in gcc branch without disabling the java build on powerpc Darwin. Lastly, if this is the same bug that is breaking the libgomp build on powerpc64 linux, those testresults are now all being posted with libgomp disabled.
I won't comment about the incredible activity on this bug!-( > Lastly, if this is the same bug that is breaking the libgomp build on powerpc64 > linux, those testresults are now all being posted with libgomp disabled. I think this bug is different and has been fixed: === libgomp Summary for unix === # of expected passes 1131 # of unexpected failures 8 # of unsupported tests 62 === libgomp Summary for unix/-m64 === # of expected passes 1131 # of unexpected failures 8 # of unsupported tests 62 === libgomp Summary === # of expected passes 2262 # of unexpected failures 16 # of unsupported tests 124 the failures coming from libgomp.fortran/crayptr2.f90. Note that I am now only building gcc and gfortran. It's faster and it works. I won't give any attempt to build other languages untill regress is back to work.
enable-checking is always used on development trees which trunk belongs to. I usually do build with disable-checking. And with disable-checking you do not see the bug. In comment #5 I only wanted to state that now I see the break as well. It is impossible to get some preprocessed source from this break since it does not preprocess anything. It is a .class to .o compilation. I'll try my best to get some more details.
> It is impossible to get some preprocessed source from this break since it does > not preprocess anything. It is a .class to .o compilation. May be you could have a look at the reduced code in PR 33348.
The proposed patch to fix PR rtl-optimization/26449... http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01303.html ...eliminates the bootstrap problems with java on powerpc-apple-darwin9.
Subject: Re: [4.3 Regression] At revision 128385 Bootstraping PPC Darwin still fail in Java Did you try to bootstrap with Java with the one line patch in: http://gcc.gnu.org/ml/gcc-bugs/2007-09/msg01311.html It fixes the Fortran failure.
Subject: Bug 33406 Author: hubicka Date: Mon Sep 17 15:12:10 2007 New Revision: 128547 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128547 Log: PR middle-end/33348 PR target/33406 * loop-invariant.c (move_invariant_reg): Unshare sequence. Modified: trunk/gcc/ChangeLog trunk/gcc/loop-invariant.c
Fixed