[Bug gas/12180] gas: -mfido doesn't accept floating point instructions

[fthain at telegraphics dot com.au]

http://sourceware.org/bugzilla/show_bug.cgi?id=12180

--- Comment #9 from Finn Thain <fthain at telegraphics dot com.au> 2010-11-04 
01:01:26 UTC ---
(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.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.