From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5831 invoked by alias); 14 Dec 2001 17:56:01 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 5815 invoked by uid 71); 14 Dec 2001 17:56:00 -0000 Date: Fri, 14 Dec 2001 09:56:00 -0000 Message-ID: <20011214175600.5814.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Klaus Pedersen Subject: Re: target/5107: ICE when building an ARM/Thumb cross compiler for/on HP-UX. Reply-To: Klaus Pedersen X-SW-Source: 2001-12/txt/msg00834.txt.bz2 List-Id: The following reply was made to PR target/5107; it has been noted by GNATS. From: Klaus Pedersen 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).