On Mon, Feb 25, 2013 at 5:11 PM, Diego Elio Pettenò <flamee...@flameeyes.eu> wrote: > Of course dealing with flags _per functions_ is not possible, as flags > apply at the very least to a translation unit...
A translation unit can contain a single function, or a bunch of functions that you want to apply the flag to. > >> If you're just using it to calculate how many pixels down it is, it >> certainly shouldn't be that inaccurate. > > But you're not just calculating how many pixels down to draw it... > you're calculating a bunch of parameters, including shades, shadows, > sub-pixel positioning, .... Maybe it wasn't a great example - I wasn't the one who first brought it up in the thread. However, if the optimization were appropriate to apply to some things and not to others, then you'd only apply it to those things. > But if you add 1% error to hundreds of small calculations ... well, you > should get the point, don't you? If you add a randomly distributed 1% error to hundreds of small calculations you end up with a 1% error in the result, roughly speaking. The exact impact can in fact be calculated using propagation of error. Of course, if -ffast-math introduces a non-uniform bias and the calculations are sensitive to that then that could carry things further off. > > There are decent use cases for -ffast-math... none of which involve a > desktop system, in my opinion. Likely not. In which case, we won't have any blockers reported, will we? My point was just that: 1. No, the fact that entire packages fail to build/operate using -ffast-math is not a valid bug. 2. If individual packages DO carefully use -ffast-math and that breaks, it might be a valid bug, and may or may not be a blocker depending on real-world impact. That doesn't mean users sticking it in their CFLAGS - it means the ebuild or upstream build system carefully applied the flag appropriately. Whether any instances of #2 exist, I cannot say. Rich
