19523 2003-04-17 20:23 0000 dev-libs/fftw fails to compile with -mfpmath=sse 2003-05-27 20:07:51 0000 1 1 1 Unclassified Gentoo Linux Ebuilds 1.4_rc1 All Linux RESOLVED FIXED P2 normal --- 1 joker@gentoo.org george@gentoo.org witr@rwwa.com joker@gentoo.org 2003-04-17 20:23:58 0000 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. mholzer@gentoo.org 2003-04-18 07:47:42 0000 please paste #emerge info joker@gentoo.org 2003-04-18 09:07:27 0000 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" george@gentoo.org 2003-05-07 18:45:48 0000 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 joker@gentoo.org 2003-05-07 22:11:49 0000 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. george@gentoo.org 2003-05-08 05:13:34 0000 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 joker@gentoo.org 2003-05-08 06:51:06 0000 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. george@gentoo.org 2003-05-11 22:23:54 0000 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.. witr@rwwa.com 2003-05-27 10:01:58 0000 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. george@gentoo.org 2003-05-27 20:07:51 0000 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