Re: target/5107: ICE when building an ARM/Thumb cross compiler for/on HP-UX.

[Klaus Pedersen <klaus.k.pedersen@nokia.com>]

The following reply was made to PR target/5107; it has been noted by GNATS.

From: Klaus Pedersen <klaus.k.pedersen@nokia.com>
To: Richard.Earnshaw@arm.com
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: target/5107: ICE when building an ARM/Thumb cross compiler  for/on 
 HP-UX.
Date: Fri, 14 Dec 2001 18:50:28 +0100

 ext Richard Earnshaw wrote:
 > It's most likely in a "split_all_insns" pass, which should turn the
 > pseudo instruction
 > 
 >         set r2 = 65536
 > 
 > into the real thumb instructions
 > 
 >         set r2 = 128
 >         set r2 = r2 << 9
 
 Yes, it seems you are right, I tried this program:
 
 	long __muldi3(void)
 	{
 		return 65536;
 	}
 
 with
 	 ./xgcc -c -mthumb -B. test.c
 
 - and even this simple program generates the ICE.
 
 Does the error have any connection to these warnings that is generated
 when parsing the arm.md file? (there are some references to 
 define_split)
 ---
 ./genrecog ../../gcc-20011203/gcc/config/arm/arm.md > tmp-recog.c
 ../../gcc-20011203/gcc/config/arm/arm.md:595: warning: constraints not
 supported in define_peephole2
 ../../gcc-20011203/gcc/config/arm/arm.md:595: warning: constraints not
 supported in define_peephole2
 ../../gcc-20011203/gcc/config/arm/arm.md:595: warning: constraints not
 supported in define_peephole2
 ../../gcc-20011203/gcc/config/arm/arm.md:595: warning: constraints not
 supported in define_peephole2
 ../../gcc-20011203/gcc/config/arm/arm.md:2333: warning: constraints not
 supported in define_split
 ../../gcc-20011203/gcc/config/arm/arm.md:2333: warning: constraints not
 supported in define_split
 ../../gcc-20011203/gcc/config/arm/arm.md:2333: warning: constraints not
 supported in define_split
 ../../gcc-20011203/gcc/config/arm/arm.md:2333: warning: constraints not
 supported in define_split
 ../../gcc-20011203/gcc/config/arm/arm.md:2333: warning: constraints not
 supported in define_split
 ---
 
 
 
 [...]
  
 > What *native* compiler where you using to build your cross-compiler?
 > gcc?
 > if so, which version?  I used the HP compiler and as mentioned, didn't
 > see a problem (but that can't build the c++ compiler).
 
 How do I force configure to use the native compiler? Is it enough to
 set the CC enviroment variable before configuring?
 
 OK, it seems that we don't have a native ANSI compiler, the "bundled C
 compiler" stops at the first ANSI construct, function prototypes!
 
 ---
 /bin/cc -c -DCROSS_COMPILE -DIN_GCC    -g   -DHAVE_CONFIG_H    -I. -I.
 -I../../gcc-20011203/gcc -I../../gcc-20011203/gcc/.
 -I../../gcc-20011203/gcc/config -I../../gcc-20011203/gcc/../include \
         ../../gcc-20011203/gcc/config/arm/arm.c -o arm.o
 (Bundled) cc: warning 480: The -g option is available only with the
 C/ANSI C product; ignored.
 (Bundled) cc: "../../gcc-20011203/gcc/config/arm/arm.c", line 1057:
 error 1705: Function prototypes are an ANSI feature.
 [...]
 gmake[1]: *** [arm.o] Error 1
 ---
 
 How can HP get away with that?
 It looks as if I am going to find a native ANSI C compiler.
 So I guess that this means that there are a serious problem in the
 HP backend (this might explain why our emacs and xemacs sometimes
 crash!).
 
 Besides this try, I have only used gcc. This is a selection:
 
 ---
 Reading specs from
 /opt/net/local/gcc2953/lib/gcc-lib/hppa1.1-hp-hpux11.00/2.95.3/specs
 gcc version 2.95.3 20010315 (TWW)
 ---
 Reading specs from
 /opt/net/local/gcc302/lib/gcc-lib/hppa1.1-hp-hpux11.00/3.0.2/specs
 Configured with: ../configure --enable-haifa --with-gnu-as
 --with-included-gettext --enable-shared --enable-languages=c,c++,f77
 --enable-threads=posix --prefix=/opt/net/local/gcc302
 --with-local-prefix=/opt/net/local/gcc302
 Thread model: posix
 gcc version 3.0.2
 ---
 (this crashes in other ways)
 Reading specs from
 /users/contrib/pkgs/gcc/gcc-2.8.1/HP-UX/B.11.00/lib/gcc-lib/hppa1.1-hp-hpux11.00/2.8.1/specs
 gcc version 2.8.1
 ---
 Reading specs from
 /users/contrib/pkgs/gcc/gcc-2.95.2/HP-UX/B.10.20/lib/gcc-lib/hppa1.1-hp-hpux10.20/2.95.2/specs
 gcc version 2.95.2 19991024 (release)
 ---
 Reading specs from
 /opt/net/local/gcc30/lib/gcc-lib/hppa1.1-hp-hpux11.00/3.0/specs
 Configured with: ../configure --enable-haifa --with-gnu-as
 --with-included-gettext --enable-shared --enable-languages=c,c++,f77
 --enable-threads=posix --prefix=/opt/net/local/gcc30
 --with-local-prefix=/opt/net/local/gcc30
 Thread model: posix
 gcc version 3.0
 ---
 and the current snapshot.
 ---
 
 
 BR, Klaus
 
 ext Richard Earnshaw wrote:
 > 
 > > I am trying to build an ARM/THUMB cross compiler on HP-UX 11 and
 > > HP-UX 10.20. It doesn't work, even with the latest snapshot.
 > 
 > Hmm, I built just the C compiler on our HPUX-11 machine and didn't see
 > this problem...
 > 
 > > When xgcc is building the "thumb libgcc2" version of muldi3 it
 > > stops with an internal error:
 > >
 > > -------------
 > > ../../gcc-20011203/gcc/libgcc2.c: In function `__muldi3':
 > > ../../gcc-20011203/gcc/libgcc2.c:367: could not split insn
 > >
 > > (insn 175 70 72 (set (reg:SI 2 r2)
 > >         (const_int 65536 [0x10000])) 176 {*thumb_movsi_insn} (nil)
 > >     (nil))
 > 
 > The compiler certainly has a define_split that should match this (and
 > that
 > is indeed what happens on the Sun dump you posted).
 > 
 > > When you compare the dumps from the machines side-by-side, you
 > > will notice that there are not a single pair that are equal !
 > > -------------
 > > coicxxx -> diff hp-dumps/libgcc2.i.00.rtl sun-dumps/libgcc2.i.00.rtl
 > > 16c16
 > > < (note 9 7 15 7bf703c0 NOTE_INSN_BLOCK_BEG)
 > > ---
 > > > (note 9 7 15 4003c0 NOTE_INSN_BLOCK_BEG)
 > > 26c26
 > > < (note 19 17 22 7bf70380 NOTE_INSN_BLOCK_BEG)
 > > ---
 > > > (note 19 17 22 400380 NOTE_INSN_BLOCK_BEG)
 > > [...]
 > 
 > These are pointers (don't know why they are useful, and yes, they do
 > make
 > comparing across machines a pain).  So there isn't a problem here.  The
 > problem first shows up in dump 23 (ie some between postreload and
 > flow2).
 > It's most likely in a "split_all_insns" pass, which should turn the
 > pseudo
 > instruction
 > 
 >         set r2 = 65536
 > 
 > into the real thumb instructions
 > 
 >         set r2 = 128
 >         set r2 = r2 << 9
 > 
 > > My configure string:
 > > -------------
 > > ../gcc-20011203/configure \
 > >      --prefix=/opt/arm-elf-gcc --target=arm-elf --nfp \
 > >      --enable-languages=c,c++ --with-dwarf2 --enable-target-optspace \
 > >      --with-as=/opt/arm-elf-gcc/bin/arm-elf-as \
 > >      --with-ld=/opt/arm-elf-gcc/bin/arm-elf-ld
 > 
 > What *native* compiler where you using to build your cross-compiler?
 > gcc?
 > if so, which version?  I used the HP compiler and as mentioned, didn't
 > see
 > a problem (but that can't build the c++ compiler).