Date: Mon, 17 Aug 2009 18:04:13 +0500 From: Peter Vereshagin <peter@vereshagin.org> To: gavin@FreeBSD.org Cc: peter@vereshagin.org, freebsd-bugs@FreeBSD.org Subject: Re: bin/137869: cc --fast-math leads to nan% CPU consumption in ps and top Message-ID: <20090817130413.GA3314@screwed.box> In-Reply-To: <200908171137.n7HBbYPW005869@freefall.freebsd.org> References: <200908171137.n7HBbYPW005869@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
We all come down to Monterey, gavin! Those are the minimal gcc-related settings I can repeat this now: === CPUTYPE=pentium4 CFLAGS=-funsafe-math-optimizations -fno-math-errno === I know these features are unstable but every other thing in the buildworld works with them and almost everything in the ports, too. It's far from being a true research approach to try to switch knobs on and off, isn't it? But seems I got the thing in it: the issue of nan% CPU disappears just as I remove the CPUTYPE or any of those CFLAGS. I know such the setting may be unsupported, my question is unobscurity and unobviousity of such a thing during the system 'world' upgrade, so this can scare any admin like me, just wanted to footprint for those who can follow the same way and may get stuck. So I'd wish a warning to be while buildworld process that this particular feature is that unstable and hidden danger is to be met on that way. Because I can prove there was someone else who was in the same exact trouble before I got it. (and was lazy to file a PR ;-) 2009/08/17 11:37:34 +0000 gavin@FreeBSD.org => To peter@vereshagin.org : > Perhaps you could spend some time and figure out which of these options are > breaking top and ps? > > Although, the man page also says about -ffast-math: > . This option [...] can result in incorrect output for programs which depend on > . an exact implementation of IEEE or ISO rules/specifications for math functions. > so it may well just because top and ps depend on the math functions being > accurate. So I should better make noise around gcc, right? My trouble is: I don't know C. I use to build worlds here and there, but C is the different knowledge area for me. > Lastly, compiling with unusual optimisation settings isn't supported, so it > may be that this bug isn't fixed unless there is a real underlying problem. Yes, this may even not to be a ps/top/world_src bug at all, but when fixed (what can be done) or at least noted (what I do here), this can save lots of considerations and lifetime for freebsd users ;-) 73! Peter -- http://vereshagin.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090817130413.GA3314>