Fido1100 has no co-processor support, like MC68000, MC68010 and CPU32. However, unlike the others, Fido1100 does not accept -m68881 or -m68882. $ m68k-linux-gnu-as x.s -m68000 -m68882 $ m68k-linux-gnu-as x.s -m68010 -m68882 $ m68k-linux-gnu-as x.s -mcpu32 -m68882 $ m68k-linux-gnu-as x.s -mfido -m68882 x.s: Assembler messages: x.s:2: Error: selected processor does not have all features of selected architecture x.s:2: Error: invalid instruction for this architecture; needs 68020 [68k, 68ec020], 68030 [68ec030], 68040 [68ec040], 68060 [68ec060], cpu32 [68330, 68331, 68332, 68333, 68334, 68336, 68340, 68341, 68349, 68360], 547x [5470, 5471, 5472, 5473, 5474, 5475], 548x [5480, 5481, 5482, 5483, 5484, 5485] -- statement `fmove.l %d1,%fpcr' ignored $ cat x.s .text fmove.l %d1, %fpcr Also, -mfido should probably default to enabling the math co-processor (like CPU32), since it also supports emulation through the use of unimplemented instructions exceptions*. As the gas man page explains: The default is to assume a coprocessor for 68020, 68030, and cpu32. Although the basic 68000 is not compatible with the 68881, a combination of the two can be specified, since it's possible to do emulation of the coprocessor instructions with the main processor. * http://www.innovasic.com/images/stories/fidoTechDocs/fido1100_user_guide.pdf
Also, the "fmoveml" test is presently disabled for fidoa and should be reinstated when the bug is fixed and math instructions are permitted: http://www.cygwin.com/ml/binutils/2007-05/msg00045.html
Some background can be found here (libfortran build failure): http://lists.debian.org/debian-68k/2010/11/msg00003.html
If it’s really required, I can get command lines, sources and build logs, but it’ll take me a couple of days of continuous compiling (three-stage gcc bootstrap then multilib compile – 68040 68060 cpu32 fidoa – of all runtimes). <math.h> picks up mathinline.h which contains inline assembly for FPU stuff, which gas chokes on on fidoa (fortran RTL is only where this happened to me; the current Debian gcc-4.4 package disables multiarch and multilib, to make it build at all).
I was able to reproduce the libgfortran problem with a cross-compiler. It turns out that with gcc-4.5-20101021 (binutils-2.20.51.201024), the CPU32 build for libgfortran fails as well (I didn't try debian gcc 4.4 yet). libtool: compile: /Volumes/btc-0.12/build/gcc-m68k-linux-gnu-3/./gcc/xgcc -B/Volumes/btc-0.12/build/gcc-m68k-linux-gnu-3/./gcc/ -B/Volumes/btc-0.12/gcc-4/m68k-linux-gnu/bin/ -B/Volumes/btc-0.12/gcc-4/m68k-linux-gnu/lib/ -isystem /Volumes/btc-0.12/gcc-4/m68k-linux-gnu/include -isystem /Volumes/btc-0.12/gcc-4/m68k-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../../../../gcc-4.5-20101021/libgfortran -iquote../../../../gcc-4.5-20101021/libgfortran/io -I../../../../gcc-4.5-20101021/libgfortran/../gcc -I../../../../gcc-4.5-20101021/libgfortran/../gcc/config -I../../.././gcc -D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -fcx-fortran-rules -ffunction-sections -fdata-sections -g -O2 -mcpu=fidoa -MT set_exponent_r4.lo -MD -MP -MF .deps/set_exponent_r4.Tpo -c ../../../../gcc-4.5-20101021/libgfortran/generated/set_exponent_r4.c -save-temps -v -fPIC -DPIC -o .libs/set_exponent_r4.o ../../../../gcc-4.5-20101021/libgfortran/generated/set_exponent_r4.c: In function 'set_exponent_r4': /Volumes/btc-0.12/gcc-4/m68k-linux-gnu/sysroot/usr/include/bits/mathinline.h:275:749: error: impossible constraint in 'asm' For CPU32, the solution is to add -m68881 to the compiler flags. However, that doesn't work for fido: libtool: compile: /Volumes/btc-0.12/build/gcc-m68k-linux-gnu-3/./gcc/xgcc -B/Volumes/btc-0.12/build/gcc-m68k-linux-gnu-3/./gcc/ -B/Volumes/btc-0.12/gcc-4/m68k-linux-gnu/bin/ -B/Volumes/btc-0.12/gcc-4/m68k-linux-gnu/lib/ -isystem /Volumes/btc-0.12/gcc-4/m68k-linux-gnu/include -isystem /Volumes/btc-0.12/gcc-4/m68k-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../../../../gcc-4.5-20101021/libgfortran -iquote../../../../gcc-4.5-20101021/libgfortran/io -I../../../../gcc-4.5-20101021/libgfortran/../gcc -I../../../../gcc-4.5-20101021/libgfortran/../gcc/config -I../../.././gcc -D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -fcx-fortran-rules -ffunction-sections -fdata-sections -g -O2 -mcpu=fidoa -m68881 -MT set_exponent_r4.lo -MD -MP -MF .deps/set_exponent_r4.Tpo -c ../../../../gcc-4.5-20101021/libgfortran/generated/set_exponent_r4.c -fPIC -DPIC -o .libs/set_exponent_r4.o /tmp/cc16Y0PJ.s: Assembler messages: /tmp/cc16Y0PJ.s:22: Error: selected processor does not have all features of selected architecture /tmp/cc16Y0PJ.s:38: Error: invalid instruction for this architecture; needs M68K fpu (68020 [68k, 68ec020], 68030 [68ec030], 68040 [68ec040], 68060 [68ec060], cpu32 [68330, 68331, 68332, 68333, 68334, 68336, 68340, 68341, 68349, 68360]) -- statement `fscale.l 12(%fp),%fp0' ignored
You are using the wrong target. m68k-linux is only compatible with m68k-linux.
> You are using the wrong target. m68k-linux is only compatible with m68k-linux. (Neglecting FPU emulation for fido-elf: someone else can worry about this bug as I don't have time or inclination...) If I understand correctly, you are saying that fido is solely an elf target, and hence no m68k-linux multilib variant should be built for fido. But since CPU32 is a uClinux platform, the libgfortran variant for CPU32 should use "-mcpu32 -m68881". If I'm right about the above (?) then we can look at fixing GCC.
fido doesn't have an MMU to my knowledge, nor an FPU. Trying to build Linux for it is a bit silly. I don't believe CPU32 can run Linux either, so there's no point trying to build glibc for it.
Interesting, as fidoa is FL_MMU in gcc. Thanks for the discussion though. I don’t know if there is something to be done in binutils, but I will build multi{arch,lib} in Debian/m68k only for the “classic Linux” targets 680{2,4,6}0 and exclude cpu32 and fidoa (like rtems, by whitelisting). This solves my initial problem. Anything further in binutils and gcc should probably still be discussed among the relevant porters, as it looks to me as if there is something not in sync with each other, nor with reality?
(In reply to comment #7) > fido doesn't have an MMU to my knowledge, nor an FPU. Trying to build Linux > for it is a bit silly. I don't know of a Linux port for fido either. The fido-elf issue in binutils is academic (FPU emulation). So, I think we agree that a GCC targeting m68k-linux should not build fido multilib variants. > I don't believe CPU32 can run Linux either, so there's no point trying to build > glibc for it. Well, CPU32 is supported by the m68knommu Linux kernel, and apparently glibc has been built for m68k-uclinux: "It has been done, but in practice no one uses it." said Greg Ungerer in ftp://ftp.au.debian.org/pub/linux.conf.au/2004/papers/16-greg-ungerer-uClinux.pdf Perhaps the issue with libgfortran on CPU32 is also academic. But academic or not, binutils needs to be fixed for CPU32 because gas behaviour doesn't agree with the man page (adding -m68881 should not be necessary). This appears to be a regression. (In reply to comment #8) > Interesting, as fidoa is FL_MMU in gcc. > > Thanks for the discussion though. I don’t know if there is something to be > done in binutils, but I will build multi{arch,lib} in Debian/m68k only for > the “classic Linux” targets 680{2,4,6}0 and exclude cpu32 and fidoa (like > rtems, by whitelisting). This solves my initial problem. The solution is to disable fido and not CPU32, if (as you say) the binutils you are using is able to build libgfortran for CPU32. Mainline GCC needs to be fixed to omit fido multilib variants from m68k-linux builds.
(In reply to comment #9) > Perhaps the issue with libgfortran on CPU32 is also academic. But academic or > not, binutils needs to be fixed for CPU32 because gas behaviour doesn't agree > with the man page (adding -m68881 should not be necessary). This appears to be > a regression. Sorry, I got confused. The problem is not binutils. "impossible constraint in asm" comes from gcc, of course. (Which leaves my wondering how Thorsten was able to build libgfortran for CPU32...)
(In reply to comment #10) > Which leaves my wondering how Thorsten was able to build libgfortran for CPU32... Did you build without optimization? That would explain why it builds for you. (But begs the question why does Debian disable optimization?)
No, I didn’t do anything special to build, I just ran dpkg-buildpackage, and it does a three-stage bootstrap then uses the stage3 compiler to build the RTL with I think default (-O2 -g probably) optimisation. Unfortunately, I do not have a build log from that. I guess not building cpu32 for Debian is the right way to do it though, as the native Debian package only needs multi{arch,lib} for things that are expected to be run (like i386/i486/i686/amd64). For gcc of course, cpu32 should be kept enabled probably. I wonder, while reading the comments: I use -mfidoa you use -mfido, is there a difference?
(In reply to comment #12) > I guess not building cpu32 for Debian is the right way to do it though, as > the native Debian package only needs multi{arch,lib} for things that are > expected to be run (like i386/i486/i686/amd64). I don't think we need to special-case native or cross. > I wonder, while reading the comments: I use -mfidoa you use -mfido, is > there a difference? Indeed there is! For some reason I was under the impression that they behave the same, but they don't. It turns out that "-mfido -m68881" fails, but "-mfidoa -m68881" works. So the bug is completely invalid. My apologies. We can discuss the GCC issue in a more appropriate forum...