I've attached the complete output of the error. I'm compiling newlib-1.11.0, gcc-3.2.2 and binutils 2.13.2.1 on cygwin for the m68k-elf architecture. I've attached the complete output of the error but to summarize: I'm unable to build libiberty/regex.c. The error is an invalid instruction for this architecture: needs 68020 ... Release: unknown Environment: I'm building the the m68k-elf cross compiler on cygwin. How-To-Repeat: -mkdir -p ${BUILD_DIR_NAME}/gcc cd ${BUILD_DIR_NAME}/gcc; ../../../${GCC_TOOL}/configure \ --target=${TARGET} --prefix=${PREFIX} \ --enable-languages=c,c++ --with-included-gettext --enable-shared \ --enable-threads --with-newlib -v
From: Mark_Hamilton@3com.com To: <gcc-gnats@gcc.gnu.org>, <gcc-bugs@gcc.gnu.org>, <nobody@gcc.gnu.org>, <gcc-prs@gcc.gnu.org>, Mark Hamilton <mark_lee_hamilton@worldnet.att.net> Cc: Subject: Re: libstdc++/9697: invalid instruction Date: Mon, 17 Feb 2003 14:04:53 -0800 I may have fixed my own bug. Is someone interested in verifying my fix. I'm not much of an assembly person. I've attached the files that I modified. To summarize the 68000 and 5200 processors do not support bsr.l. That I've verified from the appropriate manuals. The gcc m68k.md and m68k.h didn't take these into account. I modified m68k.md and m68k.h from the gcc-3.2.2 tar ball to check for 68000 and 5200. If so then jsr is used instead of bsr.l. The jsr instruction take an absolute value where as the bsr takes a relative address. The m68k.h needs to use the appropriate assembly for both PIC and non-PIC code. I posted a bug on this 9697. http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&p r=9697
From: Mark_Hamilton@3com.com To: <gcc-gnats@gcc.gnu.org>, <gcc-bugs@gcc.gnu.org>, <nobody@gcc.gnu.org>, <gcc-prs@gcc.gnu.org> Cc: Subject: Re: target/9697: [m68k]invalid instruction when building m68k cross in libiberty Date: Tue, 25 Feb 2003 16:45:58 -0800 I'm hoping some one can validate my fix for bug 9697. Any takers? -Mark Hamilton http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&p r=9697
From: Dara Hazeghi <dhazeghi@yahoo.com> To: gcc-gnats@gcc.gnu.org, mark_lee_hamilton@worldnet.att.net Cc: Subject: Re: target/9697: [m68k]invalid instruction when building m68k cross in libiberty Date: Fri, 9 May 2003 17:14:49 -0700 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit- trail&database=gcc&pr=9697 Hello, can you confirm that this bug is still present on gcc 3.2.3 or 3.3 cvs branch? If so, can you submit a preprocessed copy of the source generating the bad assembly (that way it will be easy to very that the bug is still occurring later on...)? Thanks, Dara
State-Changed-From-To: open->feedback State-Changed-Why: See Dara's question.
Mark, just a reminder that this bug is awaiting feedback. Would it be possible for you to check whether this problem is fixed with gcc 3.3? Thanks, Draa
Confirmed with mainline (20030620) and cvs binutils and newlib. I hit this same problem building muldi3.o in libgcc... /tmp/srcobj/gcc/xgcc -B/tmp/srcobj/gcc/ -nostdinc -B/tmp/srcobj/m68k-elf/newlib/ -isystem /tmp/srcobj/m68k-elf/newlib/targ-include -isystem /tmp/src/newlib/libc/include -B/tmp/dara/ m68k/m68k-elf/bin/ -B/tmp/dara/m68k/m68k-elf/lib/ -isystem /tmp/dara/m68k/m68k-elf/ include -isystem /tmp/dara/m68k/m68k-elf/sys-include -L/tmp/srcobj/ld -O2 -DIN_GCC - DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../src/gcc - I../../src/gcc/. -I../../src/gcc/config -I../../src/gcc/../include -m68000 -DL_muldi3 -c ../../src/ gcc/libgcc2.c -o libgcc/m68000/_muldi3.o /tmp/cc0CN4Qh.s: Assembler messages: /tmp/cc0CN4Qh.s:30: Error: invalid instruction for this architecture; needs 68020 or 68030 or 68040 or 68060 or cpu32 or 5200 or 5206e or 5307 or 5407 -- statement `mulu.l %d3,%d0:%d7' ignored make[2]: *** [libgcc/m68000/_muldi3.o] Error 1
Created attachment 4256 [details] libgcc2.i
Created attachment 4257 [details] reduced testcase.i
Workaround is to disable multilibs.
Checked with gcc 3.3, and build worked fine. Note, this is because different inline assembly is used for _muldi3 in 3.3, using the same code as produce in 3.4 will produce the same (correct) error. This has to do with changes to the macro __umulsidi3. Will investigate more later. Meanwhile, this is a build regression on 3.4
Actually it looks like TARGET_CPU_CPP_BUILTINS in m68k/m68k.h is wrong and is defining __mc68020__ which it should not if -m68000 is passed to gcc. This regression is caused by: 2003-05-17 Neil Booth <neil@daikokuya.co.uk> * config/m68k/hp320.h, config/m68k/linux.h, config/m68k/m68k-none.h, config/m68k/m68k.h, config/m68k/m68kemb.h, config/m68k/m68kv4.h, config/m68k/openbsd.h, config/m68k/rtemself.h: Remove CPP_PREDEFINES, use TARGET_OS_CPP_BUILTINS and TARGET_CPU_CPP_BUILTINS instead.
Neil, it looks like your conversion of m68k to TARGET_CPU_CPP_PREDEFINES went pretty smoothly except on m68k-elf. It seems that mc68020 is no being unconditionally defined, and this is breaking multilibs for m68k-elf. Would you mind having a look into this? Thanks, Dara
Subject: Re: [3.4 regression] wrong assembly emitted for m68000 __umulsidi3 dhazeghi at yahoo dot com wrote:- > PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org. > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9697 > > > dhazeghi at yahoo dot com changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |neil at gcc dot gnu dot org > > > ------- Additional Comments From dhazeghi at yahoo dot com 2003-06-28 00:53 ------- > Neil, > > it looks like your conversion of m68k to TARGET_CPU_CPP_PREDEFINES went pretty smoothly > except on m68k-elf. It seems that mc68020 is no being unconditionally defined, and this is > breaking multilibs for m68k-elf. Would you mind having a look into this? Thanks, > > Dara It appears that the original bug report is from last Feb and about 3.2, so it can't have anything to do with my later patches in 3.4. Neil.
The original one yes. But the current bug starts at comment #6 on, and is present only on mainline (not on gcc 3.2 or 3.3), and is, I suspect, related to the conversion. If it would make things clearer, I can open this as a new bug... Thanks, Dara
Subject: Re: [3.4 regression] wrong assembly emitted for m68000 __umulsidi3 dhazeghi at yahoo dot com wrote:- > PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org. > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9697 > > > > ------- Additional Comments From dhazeghi at yahoo dot com 2003-06-28 06:58 ------- > The original one yes. But the current bug starts at comment #6 on, and is present only on mainline > (not on gcc 3.2 or 3.3), and is, I suspect, related to the conversion. If it would make things clearer, > I can open this as a new bug... Thanks, In 3.3, it appears that m68k-elf includes m68020-elf.h: tm_file="m68k/m68k-none.h m68k/m68kelf.h dbxelf.h elfos.h m68k/m68kemb.h m68k/m68020-elf.h" and in 3.4. Naming conventions on this port seem to be a bit confused. Anyway, does this fix it? Neil. * config/m68k/m68k.h (TARGET_CPU_CPP_BUILTINS): Predicate __mc68020__ on TARGET_68020. Index: m68k.h =================================================================== RCS file: /cvs/gcc/gcc/gcc/config/m68k/m68k.h,v retrieving revision 1.90 diff -u -p -r1.90 m68k.h --- m68k.h 19 Jun 2003 21:47:15 -0000 1.90 +++ m68k.h 28 Jun 2003 07:30:53 -0000 @@ -29,7 +29,8 @@ Boston, MA 02111-1307, USA. */ do \ { \ builtin_define ("__mc68000__"); \ - builtin_define ("__mc68020__"); \ + if (TARGET_68020) \ + builtin_define ("__mc68020__"); \ builtin_define ("__m68k__"); \ builtin_assert ("cpu=m68k"); \ builtin_assert ("machine=m68k"); \
Oops, forgot to update this. Neil's patch fixed the problem with the m68000 multilib, but I've hit another snag (with mainline 20030705): /home/dara/mainline/objdir/gcc/xgcc -B/home/dara/mainline/objdir/gcc/ -nostdinc -B/home/ dara/mainline/objdir/m68k-elf/newlib/ -isystem /home/dara/mainline/objdir/m68k-elf/newlib/ targ-include -isystem /home/dara/mainline/src/newlib/libc/include -B/usr/local/m68k-elf/bin/ -B/usr/local/m68k-elf/lib/ -isystem /usr/local/m68k-elf/include -isystem /usr/local/m68k-elf/ sys-include -L/home/dara/mainline/objdir/ld -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall - Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../src/gcc -I../../src/gcc/. -I../../src/gcc/ config -I../../src/gcc/../include -I../intl -mcpu32 -DL_ffsdi2 -c ../../src/gcc/libgcc2.c -o libgcc/ mcpu32/_ffsdi2.o /tmp/ccwrpIQI.s:32: Error: invalid instruction for this architecture; needs 68020 or higher -- statement `bfffo %d1{#0:#0},%d0' ignored make[2]: *** [libgcc/mcpu32/_ffssi2.o] Error 1 make[2]: *** [libgcc/mcpu32/_ffsdi2.o] Error 1 make[2]: Leaving directory `/home/dara/mainline/objdir/gcc' Seems as if the header rewrite created another mismatch, but that's as much as I can tell...
*** Bug 11777 has been marked as a duplicate of this bug. ***
Updating summary to more accurately reflect the problem.
Created attachment 4556 [details] PATCH: exclude optimized version of count_leading_zeros() for __mcpu32__ See PR11777 for patch discussion.
Could someone review and apply the patch? This is the last bug preventing mainline from bootstrapping on m68k-elf.
It was approved <http://gcc.gnu.org/ml/gcc-patches/2003-08/msg00178.html> If someone else does not committed in the next two days, I will.
I meant this: <http://gcc.gnu.org/ml/gcc-patches/2003-08/msg00294.html>.
Subject: Bug 9697 CVSROOT: /cvs/gcc Module name: gcc Changes by: pinskia@gcc.gnu.org 2003-08-08 19:58:58 Modified files: gcc : ChangeLog longlong.h Log message: +2003-08-08 Bernardo Innocenti <bernie@develer.com> + + PR target/9697 + PR target/11777 + * longlong.h (count_leading_zeros): Exclude on __mcpu32__. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.741&r2=2.742 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/longlong.h.diff?cvsroot=gcc&r1=1.37&r2=1.38
Now m68k-elf should be able to build on the mainline.