Re: [gentoo-dev] GCC 4.7 unmasking

[Rich Freeman]

On Mon, Feb 25, 2013 at 4:37 PM, Diego Elio Pettenò
<flameeyes@×××××××××.eu> wrote:
> On 25/02/2013 22:32, Rich Freeman wrote:
>> That isn't the same as saying that we can just break it in cases where
>> it actually is appropriate.  Calculating scroll bar movement is
>> exactly the sort of thing that this flag was actually designed for -
>> you don't care if it is off by 1/100th of a pixel.
>
> Rich.. please... don't try to talk about things you don't understand.
>

A sword that cuts two ways - judging understanding by an email is a
dubious proposition, otherwise we wouldn't need job interviews.  :)
It is just as likely that we're simply miscommunicating.

> If Chromium is not building *by itself* on -ffast-math, we should *not*
> support building it with it. Full stop.

Define what you mean by "building *by itself*" - I don't want to
assume I understand what you're getting at here.  I certainly wasn't
suggesting that you could be able to run CFLAGS="-O2 -ffast-math"
emerge chromium and get anything usable.  -ffast-math is a flag that
should be applied to specific functions or even parts of functions
where there is an understood performance vs accuracy tradeoff.

> It's not that adding -ffast-math loses the 1/100th precision on a scroll
> bar pixel: it has a truckload of changes to the whole mathematics in the
> code, which _among other things_ will break that scrollbar, because the
> calculation used to display it add up to a huge difference.

If you're just using it to calculate how many pixels down it is, it
certainly shouldn't be that inaccurate.  If you're using it to do
pointer arithmetic or something then you're just going to get
segfaults.  There are arithmetic functions in computing that are
discrete/functional in nature, and there are those which relate more
to real-world measurements.  Adding a 0.001% error to a hash
calculation breaks a hash.  Adding 0.001% error to a scientific
calculation where all the components have 1% measurement error is
insignificant.

> I would be wondering about it if it broke stuff that
> already is designed to rely on it, but even in that case, it's hard to
> actually say that it "broke", it's just "different".

This is the case I'm concerned with only.  Agree somewhat on "broken"
being a loose term when the flag is intended to yield inaccurate
results.  However, it probably is not intended to yield
grossly-inaccurate results.  Then again, the bug cited things like 5
vs 7 and those are equivalent within an order of magnitude.

Rich