🚀 go-pugleaf

  I have been helping Rick Rankin (rick@mel1.geg.mot.com) to get GNU gcc-2.1 up
on an RS/6000. He does not have news access, so I am posting this for him.

Platform: IBM RS/6000 Model 320 (original, not 320H)
          32 MB RAM
          128 MB swap space
          640 MB internal hard disk, 1.2 GB external

          AIX Version 3.1.5 (lslpp -h bos.obj = 03.01.0005.0012)
          XLC Version 01.01.0005.0010 according to "lslpp -h xlccmp.obj"
            Version 01.01.0008.0017 according to "what /usr/lpp/xlc/bin/xlcentry"

          as with APAR IX22829

  Rick has applied all the patches, made the "ASM_SPEC" change, and the 
"REAL_NM_FILE_NAME" to "/usr/ucb/nm".

  The error he gets is during the build of the stage2 compiler:

stage1/gcc    -g -Bstage1/   -o genextract genextract.o rtl.o ` case
"obstack.o" in ?*) echo obstack.o ;; esac ` ` case
"stage1/gcc"@"alloca.o" in "cc"@?*) echo alloca.o ;; esac ` ` case ""
in ?*) echo  ;; esac ` -lm -lld
./genextract md > tmp-extract.c
./move-if-change tmp-extract.c insn-extract.c
touch stamp-extract
stage1/gcc    -g -Bstage1/     -I. -I. -I./config -c insn-extract.c
Assembler:
/usr/tmp/ccX94D71.s: line 88: branch address out of range
make: *** [insn-extract.o] Error 1

  Rick went so far as to capture the assembly file that is giving problems, and
I assembled it on an RS/6000 550, AIX 3.1.6, 128Mb, 1024Mb swap, 2.5Gb internal,
same XLC, using the patched as (IX22829). I get an error:

thunder> as insn-extract.s
Assembler:
insn-extract.s: line 88: 1252-088 The branch address is out of range.
        The target address cannot exceed the ability
        of the instruction to represent the bit size of
        the branch address value.


  Based on other errors that Rick has had during the build process, I am of the
opinion that the problem is related to memory allocation. This would account for
the branch address being out of range, for instance. If this is true, I am
concerned that something specific to Rick's 320H configuration is to blame. Is
it the 640 MB internal hard disk? Is it the fact he has 320's instead of 320H's?
I have tried to duplicate this problem on a "similar" 320H, AIX 3.1.6, 869Mbyte
disk, with no problems. Unfortunately I could not get exactly the configuration
of AIX and patches that he has, and I have 320H's, not 320's.

  He has tried putting the "mallopt (1,0);" malloc fix in all the programs with
a "main ()", without success. I have suggested that he get AIX 3.1.6, since that
seems to be more common, but I don't have a lot of hope that it will cure his
problem.

  Any suggestions?

    Cheers,

    Tom McConnell
--
 Tom McConnell          |     Internet: tmcconne@sedona.intel.com
 Intel, Corp. C3-21     |     Phone: (602)-554-8229
 5000 W. Chandler Blvd. | The opinions expressed are my own. No one in 
 Chandler, AZ  85226    | their right mind would claim them.