Bootstrapping the current 3.4 branch on IRIX 6.5 with GNU as from the binutils 2.15 branch fails due to what seems to be invalid assembler code: ../../xgcc -B../../ -c -g -O2 -W -Wall -gnatpg s-mastop.adb -o s-mastop.o -v -save-temps Reading specs from ../../specs Configured with: /.vol/gcc/src/gcc-3.4-branch-dist/configure --prefix=/.vol/gcc --with-local-prefix=/.vol/gcc --disable-nls --with-gnu-as --with-as=/homes/ro/bin/gas-2.14.91 --enable-libgcj Thread model: single gcc version 3.4.1 20040506 (prerelease) ../../gnat1 -quiet -dumpbase s-mastop.adb -g -gnatpg -O2 -W -Wall -gnatO s-mastop.o s-mastop.adb -o s-mastop.s /homes/ro/bin/gas-2.14.91 --traditional-format -EB -O2 -g -no-mdebug -v -n32 -mips3 -o s-mastop.o s-mastop.s GNU assembler version 2.14.91 (mips-sgi-irix6.5) using BFD version 2.14.91 20040506 s-mastop.s: Assembler messages: s-mastop.s:108: Error: illegal operands `ld' [...] The file assembles ok with GNU as 2.14.90 20040209, but the affected lines seem bogus nonetheless: ld $16, 16*8+ +16($4) I'm not sure if the second `+' is interpreted as a unary plus here. But (after removing several instances of .[ul]eb128, even the native assembler groks this file without problems. Environment: System: IRIX64 columba 6.5 10120104 IP27 host: mips-sgi-irix6.5 build: mips-sgi-irix6.5 target: mips-sgi-irix6.5 configured with: /.vol/gcc/src/gcc-3.4-branch-dist/configure --prefix=/.vol/gcc --with-local-prefix=/.vol/gcc --disable-nls --with-gnu-as --with-as=/homes/ro/bin/gas-2.14.91 --enable-libgcj How-To-Repeat: Bootstrap current 3.4 branch on IRIX 6.5 with Ada included as described above.
I would say this is valid asm to me it the + is just an unary plus as it would be in C, I think gas is wrong but then again I do not know MIPS asm that well.
Created attachment 6240 [details] patch Yeah, I'd noticed this too, and came up with the attached patch. Unfortunately, Ada seems to assume the native linker, so it's not going to be possible to use GNU ld even if this patch goes in. And I'm never too sure how useful the --with-gnu-as --without-gnu-ld combo is for n32 & n64. "gcc-bugzilla at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes: > The file assembles ok with GNU as 2.14.90 20040209, but the affected > lines seem bogus nonetheless: > > ld $16, 16*8+ +16($4) > > I'm not sure if the second `+' is interpreted as a unary plus here. > But (after removing several instances of .[ul]eb128, even the native > assembler groks this file without problems. The second '+' used to be interpreted as a unary, but this was deliberately changed by: http://sources.redhat.com/ml/binutils/2004-03/msg00400.html Richard
Subject: Re: Assembler error building gnatlib on IRIX 6.5 with GNU as 2.14.91 rsandifo at gcc dot gnu dot org writes: > Yeah, I'd noticed this too, and came up with the attached patch. Thanks, that worked for me. > Unfortunately, Ada seems to assume the native linker, so it's > not going to be possible to use GNU ld even if this patch goes in. True, although this is only an issue for mainline (and will not be as soon as tree-ssa is merged since Ada will stop working at this point): the 3.4 branch doesn't try to build the shared libgnat, so this issue doesn't come up. > And I'm never too sure how useful the --with-gnu-as --without-gnu-ld > combo is for n32 & n64. It used to work for me pretty well. When I tried to use gas and gld, many Ada testcases failed for me with linker errors, though I haven't yet started to investigate what's going on there. Rainer
Thanks for testing the patch. "ro at techfak dot uni-bielefeld dot de" <gcc-bugzilla@gcc.gnu.org> writes: >> Unfortunately, Ada seems to assume the native linker, so it's >> not going to be possible to use GNU ld even if this patch goes in. > > True, although this is only an issue for mainline (and will not be as soon > as tree-ssa is merged since Ada will stop working at this point): the 3.4 > branch doesn't try to build the shared libgnat, so this issue doesn't come > up. Ah, yes, you're right, I'd only tested mainline. I've now tried 3.4, and like you say, it builds fine with gld. >> And I'm never too sure how useful the --with-gnu-as --without-gnu-ld >> combo is for n32 & n64. > > It used to work for me pretty well. When I tried to use gas and gld, many > Ada testcases failed for me with linker errors, though I haven't yet > started to investigate what's going on there. Yeah, I'm seeing this too. It looks like some of the objects have no suffix and gld thinks they must be linker scripts. Haven't had a chance to look into it yet... Anyway, I'm about to submit the patch. I'll try my best to argue that this is a regression ;) Richard
Subject: Bug 15331 CVSROOT: /cvs/gcc Module name: gcc Changes by: rsandifo@gcc.gnu.org 2004-05-12 07:25:54 Modified files: gcc/ada : ChangeLog 5gmastop.adb Log message: PR target/15331 * 5gmastop.adb (Roff): Choose between '4' and '0', not '4' and ' '. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/ChangeLog.diff?cvsroot=gcc&r1=1.501&r2=1.502 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/5gmastop.adb.diff?cvsroot=gcc&r1=1.11&r2=1.12
Subject: Bug 15331 CVSROOT: /cvs/gcc Module name: gcc Branch: gcc-3_4-branch Changes by: rsandifo@gcc.gnu.org 2004-05-12 07:28:31 Modified files: gcc/ada : ChangeLog 5gmastop.adb Log message: PR target/15331 * 5gmastop.adb (Roff): Choose between '4' and '0', not '4' and ' '. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.428.2.7&r2=1.428.2.8 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/5gmastop.adb.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.8&r2=1.8.4.1
http://gcc.gnu.org/ml/gcc-patches/2004-05/msg00608.html
Subject: Re: Assembler error building gnatlib on IRIX 6.5 with GNU as 2.14.91 rsandifo at gcc dot gnu dot org writes: > Yeah, I'm seeing this too. It looks like some of the objects have > no suffix and gld thinks they must be linker scripts. Haven't had > a chance to look into it yet... Me neither. I'm currently running full bootstraps on irix5 and irix6 with all three combinations (native as/ld, gas/native ld, and gas/gld) and will see what I find. I'll mostly have to find some time to investigate and fix the results, though :-) > Anyway, I'm about to submit the patch. I'll try my best to argue > that this is a regression ;) Thanks alot for your help. Rainer