bin/137869: cc --fast-math leads to nan% CPU consumption in ps and top

Peter Vereshagin peter at
Mon Aug 17 09:50:05 UTC 2009

>Number:         137869
>Category:       bin
>Synopsis:       cc --fast-math leads to nan% CPU consumption in ps and top
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Aug 17 09:50:04 UTC 2009
>Originator:     Peter Vereshagin
>Release:        RELENG_7_2 as of early August, 2009
FreeBSD somehost 7.2-RELEASE-p3 FreeBSD 7.2-RELEASE-p3 #2: Mon Aug  3 12:36:59 MSD 2009     root at somehost:/var/src/sys/i386/compile/MKERN  i386
I built and installed world and kernel with this optimisations in my make.conf:
CFLAGS=-O2 -pipe -funit-at-a-time -fpeel-loops -ftracer -funswitch-loops -mmmx -msse -msse2 -march=pentium4 -mtune=pentium4 -ffast-math 
COPTFLAGS=-O2 -pipe  -funit-at-a-time -fpeel-loops -ftracer -funswitch-loops -mmmx -msse -msse2 -march=pentium4 -mtune=pentium4 -ffast-math 
Every little thing was great till I noticed the top and the ps -u show the nan% in the CPU% column.
The workaround was to disable -ffast-math in make.conf and
cd /usr/src/usr.bin/top
make clean all install
cd /usr/src/bin/ps
make clean all install
Indeed I disabled all the optimizations first and rebuilt-reinstalled world first. Then on portupgrade I noticed few of my ports failed to compile with -ffast-math, at least the postgresql-client.
Thus I rebuilt and reinstalled  my world and kernel with every of those optimizations turned on and recompiled top and ps only without fast-math.
So this works fine now but I guess it should be better to do something with ps and top in particular, because the whole rest of the world is quite patient to the fast-math.
compile top and ps with -ffast-math option for the gcc.
There should be warnings on the buildworld process about -ffast-math if it is not compatible with it, so world either should work with this gcc feature or shouldn't at all. It obfuscates a lot about where the trouble is, it's possible to be located in the kernel, the debugging of the kernel is not appropriate for production use, where gcc optimizations are high demand.


More information about the freebsd-bugs mailing list