http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49746
--- Comment #7 from H.Merijn Brand <h.m.brand at xs4all dot nl> 2011-07-15 15:17:38 UTC --- On Fri, 15 Jul 2011 14:41:23 +0000, "dave.anglin at bell dot net" <gcc-bugzi...@gcc.gnu.org> wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49746 > > --- Comment #6 from dave.anglin at bell dot net 2011-07-15 14:41:19 UTC --- > On 7/15/2011 4:37 AM, h.m.brand at xs4all dot nl wrote: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49746 > > > > --- Comment #5 from H.Merijn Brand<h.m.brand at xs4all dot nl> 2011-07-15 > > 08:34:49 UTC --- > > On Thu, 14 Jul 2011 22:07:10 +0000, "dave.anglin at bell dot net" > > <gcc-bugzi...@gcc.gnu.org> wrote: > > > > $ gcc64 -v > > Reading specs from > > /wrk/pa20_64-4.6.1/bin/../lib/gcc/hppa64-hp-hpux11.11/3.4.6/specs > > Configured with: ../src/configure --enable-languages=c,c++ > > --prefix=/usr/local/pa20_64 --with-local-prefix=/usr/local/pa20_64 > > --with-gnu-as --with-as=/usr/local/pa20_64/bin/as --without-gnu-ld > > --with-ld=/usr/ccs/bin/ld --disable-shared --disable-nls > > --host=hppa64-hp-hpux11.11 > > Thread model: single > > gcc version 3.4.6 > > This looks ok. > > >> If you add -save-temps to the failing compile, this will save the > >> assembler output. This will allow inspection of the problematic > >> instructions. I would guess we are dealing with a bl or b instruction. > >> A b,l instruction would have a 21-bit range. > > To see what's wrong, the assembly code needs to be looked at. The > range that you showed is characteristic of a 17-bit pc-relative > branch. In PA 2.0, calls use 21-bit pc-relative branches. If the > .level directive is correct for the file, then the problem must > be due to an unconditional jump with an incorrect branch distance > calculation. I don't believe there are any major problems with > the branch distance calculations in 4.3 and latter (last releases). I'm currently building with the 4.2.4 build I had lying around that does not pass perl build/test. So far it goes much further. It is already running (building) for over 4 hours now. The older the architecture, the slower the machine :) > You might try working around this problem as follows: > > 1) Manually compile object that's failing with -O2. This will > reduce function sizes and probably avoid the out of range error. > Then, restart bootstrap. If build suceeds, install new compiler > and recheck that you can sucessfully bootstrap. I suggest > -O2 since various reorg bugs appear at -O1. This is simplest > work around. > > 2) The other alternative is to abandon your gcc64 and build a new > boostrap compiler with HP aCC or C (ANSI). I haven't tried this > in some time. I did. It seems to be more work that I like to spend on it > 3) I could provide you with a working bootstrap compiler. > Unfortunately, I can't make the file publicly available. > > If you get a working compiler going, it would be great if you > could post it on the net as you have done for some other builds. That is my plan, but I'll have most likely no internet access shortly for two weeks, so don't hold your breath ... I will make it available when it is done, but I'll still advice against using it when it doesn't pass the perl blead tests (where 3.4.6 passes) > Option 2 isn't that easy. I'm not even considering that option yet. > Dave
