Created attachment 472408 [details] Failing Buildlog kde-frameworks/kjs fails to compile due to using "-Ofast" in CXXFLAGS/CFLAGS "KJS does not work correctly with -ffast-math" The ebuild is very short and basic, so it probably only needs a src_configure() { replace-flags -Ofast -O2 } stuck at the bottom. I've only edited a few ebuilds, so I could very well be wrong that it's "that simple". I'll attach a "patch" for the ebuild anyway, though. THANK YOU! M.
Created attachment 472410 [details, diff] proposed ebuild patch
I can't speak for the maintainer of this, but a *lot* of stuff is broken with -ffast-math, and therefore with -Ofast. Its description is... -Ofast Disregard strict standards compliance. -Ofast enables all -O3 optimizations. It also enables optimizations that are not valid for all standard-compliant programs. It turns on -ffast-math and the Fortran- specific -fno-protect-parens and -fstack-arrays. In other words, it generates invalid code sometimes. It would be a huge waste of time to put CFLAGS guard in every ebuild for every unsafe flag that you could come up with. It's easier to just say "don't do that." So I'll go ahead and say it =) Don't use -ffast-math. This is its description from the GCC wiki: In addition GCC offers the -ffast-math flag which is a shortcut for several options, presenting the least conforming but fastest math mode. It enables -fno-trapping-math, -funsafe-math-optimizations, -ffinite-math-only, -fno-errno-math, -fno-signaling-nans, -fno-rounding-math, -fcx-limited-range and -fno-signed-zeros. Each of these flags violates IEEE in a different way. -ffast-math also may disable some features of the hardware IEEE implementation such as the support for denormals or flush-to-zero behavior.
Hey! I just thought I'd add that while I understand -Ofast isn't "usual" or "safe", I ran into this because I installed a totally-from-scratch Gentoo x86_64. After redoing @system with -Ofast, I did emerge -q plasma-workspace - which is a hell of a lot of packages - and it was only this little one that didn't like -Ofast - and specifically said so. Everything else complies fine, and (so far...) works fine. This is why I filed the "bug". I totally get that adding a "replace-flags" to every single package in the entire portage tree for every single "bad" flag is impossible. I am not suggesting that. That would be crazy. I ran into this one small package that seemingly needs only one little tweak. M.
I agree with Michael. If you want to go that way, you are free to maintain a package.env to make packages build fine with sane flags.
