Bugzilla Bug 19523

The ebuild dev-libs/fftw wont build with "-mfpmath=sse" in the CFLAGS

There are no problems with compiling when "-mfpmath=sse" is removed.
Stuff like "-msse" is no problem and works well.


Sucessfull compile test was done with:
CFLAGS="-march=i686 -mmmx -msse -falign-functions=4 -ffast-math
-fomit-frame-pointer -O3 -pipe"


ERROR triggered with:
CFLAGS="-march=i686 -mmmx -msse -mfpmath=sse -falign-functions=4 -ffast-math
-fomit-frame-pointer -O3 -pipe"


Reproducible: Always
Steps to Reproduce:
1. emerge dev-libs/fftw with "-mfpmath=sse" in CFLAGS

Actual Results:  
Compilation fails.


GCC output:

fftw_test.c: In function `array_scale':
fftw_test.c:234: unable to find a register to spill in class `SSE_REGS'
fftw_test.c:234: this is the insn:
(insn 31 29 32 (set (reg:SF 21 exmm0 [63])
         (mult:SF (subreg:SF (reg/v:DI 0 rax [62]) 0)
             (subreg:SF (reg/v:DI 29 rmm0 [59]) 0))) 527 {*fop_sf_comm_sse}
(insn_list 29 (nil))
     (nil))


I suggest that the CFLAGS should be filtered/replaced.

please paste
#emerge info

Portage 2.0.47-r10 (default-x86-1.4, gcc-3.2.2, glibc-2.3.1-r4)
=================================================================
System uname: 2.4.20-gentoo-r2 i686 Mobile Intel(R) Pentium(R) 4 - M CPU 1.80GHz
GENTOO_MIRRORS="http://sunsite.cnlab-switch.ch/ftp/mirror/gentoo http://www.ibiblio.org/pub/Linux/distributions/gentoo"
CONFIG_PROTECT="/etc /var/qmail/control /usr/share/config /usr/kde/2/share/config /usr/kde/3/share/config /usr/X11R6/lib/X11/xkb"
CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d"
PORTDIR="/usr/portage"
DISTDIR="/usr/portage/distfiles"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR_OVERLAY="/usr/local/portage"
USE="x86 3dnow crypt cups gif jpeg libg++ libwww mikmod mmx mpeg ncurses nls pdflib png qt quicktime spell truetype xml2 xmms xv zlib gdbm berkdb readline java guile gpm tcpd pam ssl python oggvorbis opengl X gtk gtk2 gnome bonobo -alsa aalib acpi apm -arts avi cdr dga dvd -emacs encode esd fbcon gd gtkhtml imap imlib ipv6 -kde matrox mbox -motif mozilla oss pcmcia perl -slang pnp -svga samba sdl sse tiff usb"
COMPILER="gcc3"
CHOST="i686-pc-linux-gnu"
CFLAGS="-march=i686 -mmmx -msse -mfpmath=sse -falign-functions=4 -ffast-math -fomit-frame-pointer -O3 -pipe"
CXXFLAGS="-march=i686 -mmmx -msse -mfpmath=sse -falign-functions=4 -ffast-math -fomit-frame-pointer -O3 -pipe"
ACCEPT_KEYWORDS="x86"
MAKEOPTS="-j2"
AUTOCLEAN="yes"
SYNC="rsync://rsync9.de.gentoo.org/gentoo-portage"
FEATURES="sandbox ccache"

Hi Chris.

Thanks for a report. I have added appropriate filter to the ebuild. 
Please test.

Also, how processor specific this is? Does this work on pure pentium-4 for example? Or some other family? As I could google -fpmath=sse implies sse2 instruction set, so thi might be limited to pentium-4 only then..

George

I don't think -mfpmath=sse requires a SSE2 capable CPU. Some people use
"-march=athlon-xp -mfpmath=sse" and those CPUs have only SSE 1. And on
Pentium3 systems it should work as well.

So, the situation is just like I suspected. Then the ebuild should be modified
to check for the processor model.
Do you know if this prooblem appears only on pentium-4 M, or does any other
model (that supports sse) have it?

George

I don't think it depends on the machine you compile it. It's only a matter of
the
CFLAGS. I could build this on a i386 and get the same error. It's a compile
error
not a runtime one. I currently can't check this because my other gentoo
machines
are all sparcs. But it really looks like only a build/compile and not a runtime
problem. 

The only big pain would happen if -mfpmath=sse is included in some -march
settings
automaticaly. That would make filtering really bad. As long as it's a
standalone
CFLAGS it's easy.

Hi Chris.

>I don't think it depends on the machine you compile it. It's only a matter of the
>CFLAGS. I could build this on a i386 and get the same error. It's a compile error
Well, I could expect this to fail on i386, especially since this:
>fftw_test.c: In function `array_scale':
>fftw_test.c:234: unable to find a register to spill in class `SSE_REGS'
looks semi-runtime, - gcc is trying to do certain optimizations, checking for the available registers.

But I checked it with this flag on my P-III and could reproduce this problem. Also  I was able to use -fpmath=sse to compile other packages. Thus I conclude that this is indeed a package and not arch specific problem. Therefore no arch checking is necessary, so the fix I made to ebuild is final.
Closing this bug now.

Thanks for traising this!

George

PS
>The only big pain would happen if -mfpmath=sse is included in some -march >settings automaticaly. That would make filtering really bad. 
I don't think this is that common, at least this is the first time I see this problem mentioned ;). Thus this fix should be sufficient for most of the time. If this problem does recur with the scenario you described I'll look into what can be done..

But... This is almost certainly a compiler bug isn't it?  I checked in
fftw-single and I didn't see any asm code that would interfere with register
assignment.  Does this problem occur with gcc-3.2.3 or gcc-3.3?  I would think
you would *want* fftw to use SSE, and my understanding is that GCC won't
generate SSE instructions without -mfpmath=sse, nomatter whether you say -msse
or not.  (Check the man page and the forums.)

This is probably a more generic portage issue, but shouldn't this filtering be
*compiler version* specific instead of march or mcpu specific?  If this port
filters out -mfpmath now, what mechanism is there to get this re-enabled for
compilers that don't have this (suspected) problem.  I worry that a lot of
ebuilds are masking this flag and throwing away performance due to a compiler
bug in a single version of a compiler.

Hi Robert

> This is probably a more generic portage issue, but shouldn't this filtering
> be *compiler version* specific instead of march or mcpu specific?  If this
Good point and I wasn't that glad about disabling this option package-wide either, as you can see by me trying to narrow the issue.
This was tested with 3.2.x (3.2.2 by Chris as you can see and I had 3.2.3 atm). 3.3 wasn't really available and from what I heard not all issues are sorted out yet. 

Would you be willing to test the package with -fpmath=sse (and possibly 387,sse?) and wiht gcc-3.3 when it gets at least into the testing profile ;)?
Personal request - if you do so, or even if you don't (then as a way to remind me) could you please reopen this bug? Otherwise I have to search for your message in the long list of emails (with a high chance of forgetting about the issue if I don't act immediately) and then reopen the bug anway?
Also, if you want to be getting autogenerated responses from bugzilla you might want to add you to CC ;).

George