[gentoo-dev] GCC 4.7 unmasking

[gentoo-dev] GCC 4.7 unmasking

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 624 bytes --]

I just added gcc-4.7.2 to the tree, and I'd like to unmask it in a couple
weeks.  I don't see anything I'd consider a blocker on the tracker*, but
95 open bugs is still a lot.  If you have a bug blocking the tracker please
take a look at it soon.  Many of these are trivial and could make good
bugsday projects (if we even do bugsdays anymore).

* https://bugs.gentoo.org/390247


PS. still looking for a gcc maintainer who isn't me.

-- 
gcc-porting
toolchain, wxwidgets          we were never more here, expanse getting broader
@ gentoo.org                          but bigger boats been done by less water

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] GCC 4.7 unmasking

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 393 bytes --]

I'm going to be unmasking 4.7.2 later this week.  There are still 47 open bugs
blocking the 4.7 tracker, so if any are yours now would be a good time
to take a look at them.

https://bugs.gentoo.org/390247


-- 
gcc-porting
toolchain, wxwidgets            learn a language baby, it's that kind of place
@ gentoo.org                   where low card is hunger and high card is taste

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] GCC 4.7 unmasking

[Alex Alexander]

[-- Attachment #1: Type: text/plain, Size: 414 bytes --]

On 25 Feb 2013 06:53, "Ryan Hill" <dirtyepic@gentoo.org> wrote:
>
> I'm going to be unmasking 4.7.2 later this week.  There are still 47 open
bugs
> blocking the 4.7 tracker, so if any are yours now would be a good time
> to take a look at them.
>
> https://bugs.gentoo.org/390247

Can't you just smell all those Gentoo systems gearing up for long emerge -e
sessions? xD

Thanks for working on this.

Alex | wired

[-- Attachment #2: Type: text/html, Size: 642 bytes --]

Re: [gentoo-dev] GCC 4.7 unmasking

[Matthew Thode]

[-- Attachment #1: Type: text/plain, Size: 576 bytes --]

On 02/24/13 23:45, Alex Alexander wrote:
> On 25 Feb 2013 06:53, "Ryan Hill" <dirtyepic@gentoo.org> wrote:
>>
>> I'm going to be unmasking 4.7.2 later this week.  There are still 47 open
> bugs
>> blocking the 4.7 tracker, so if any are yours now would be a good time
>> to take a look at them.
>>
>> https://bugs.gentoo.org/390247
> 
> Can't you just smell all those Gentoo systems gearing up for long emerge -e
> sessions? xD
> 
> Thanks for working on this.
> 
> Alex | wired
> 
Some of us are already on it :P

-- 
-- Matthew Thode (prometheanfire)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] GCC 4.7 unmasking

[Piotr Szymaniak]

[-- Attachment #1: Type: text/plain, Size: 673 bytes --]

On Sun, Feb 24, 2013 at 11:03:01PM -0600, Ryan Hill wrote:
> I'm going to be unmasking 4.7.2 later this week.  There are still 47 open bugs
> blocking the 4.7 tracker, so if any are yours now would be a good time
> to take a look at them.
> 
> https://bugs.gentoo.org/390247

There's an ugly bug [1] with -ffast-math discovered by mednafen
developer(s?).  Don't know if this is revelant for unmasking and if
-ffast-math is "supported".

[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56125


Piotr Szymaniak.
-- 
Mysle,  ze gdyby  diabel  nie istnial i mialby go stworzyc czlowiek, to
stworzylby go na swoj obraz i podobienstwo.
  -- Fiodor Dostojewski

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] GCC 4.7 unmasking

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1342 bytes --]

On Mon, 25 Feb 2013 21:58:08 +0100
Piotr Szymaniak <szarpaj@grubelek.pl> wrote:

> On Sun, Feb 24, 2013 at 11:03:01PM -0600, Ryan Hill wrote:
> > I'm going to be unmasking 4.7.2 later this week.  There are still
> > 47 open bugs blocking the 4.7 tracker, so if any are yours now
> > would be a good time to take a look at them.
> > 
> > https://bugs.gentoo.org/390247
> 
> There's an ugly bug [1] with -ffast-math discovered by mednafen
> developer(s?).  Don't know if this is revelant for unmasking and if
> -ffast-math is "supported".
> 
> [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56125
> 
> 
> Piotr Szymaniak.

-ffast-math on certain libs cause chrom(ium|e) to fail when scrolling
on certain sites (eg. Google News) and pages (Extensions and Settings),
this happened to me on GCC 4.7.2. Whether or not this is intended to
break due to the sacrifices this flag makes is questionable...

Though people that use -ffast-math / -fLTO / -fuse-linker-plugin should
be on their own, thus I drop -ffast-math because it breaks my browser;
but that doesn't mean that those ricer flags should stop stabilization.


With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] GCC 4.7 unmasking

[Rich Freeman]

On Mon, Feb 25, 2013 at 4:18 PM, Tom Wijsman <TomWij@gentoo.org> wrote:
> Though people that use -ffast-math / -fLTO / -fuse-linker-plugin should
> be on their own, thus I drop -ffast-math because it breaks my browser;
> but that doesn't mean that those ricer flags should stop stabilization.

If we're talking about for general use in CFLAGs clearly -ffast-math
isn't something that even could be supported if we wanted to.  The
flag is just not intended for general use.

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.

But, the way to track that sort of a thing is to log those as bugs
against appropriate use within individual apps and make them blockers.
 I'd consider things like this valid bugs - but whether they hold
things up should depend on real-world impact.  I'm not sure how bad
the impact on chromium actually is.

Rich

Re: [gentoo-dev] GCC 4.7 unmasking

[Diego Elio Pettenò]

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.

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

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.

So no, I don't care if -ffast-math "breaks" in the sense that stuff that
does not build with -ffast-math to begin with work even less with the
new version — 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".

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] GCC 4.7 unmasking

[Rich Freeman]

On Mon, Feb 25, 2013 at 4:37 PM, Diego Elio Pettenò
<flameeyes@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

Re: [gentoo-dev] GCC 4.7 unmasking

[Diego Elio Pettenò]

On 25/02/2013 22:57, Rich Freeman wrote:
> 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.

Did you not just say there:

"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."

or am I mistaken? If I'm not mistaken, that phrase is really not
understanding it.

The calculation that goes in painting on screen a scrollbar are hardly
something you expect -ffast-math to be designed for. Can you defend your
statement in any way?

> 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.  

Which is exactly what Tom complained about.

> -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.

Of course dealing with flags _per functions_ is not possible, as flags
apply at the very least to a translation unit...

> 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, ....

> If you're using it to do
> pointer arithmetic or something then you're just going to get
> segfaults.

Uh.. no. Pointer arithmetic is, by and of itself, integer arithmetic.
That's not going to be influenced by -ffast-math.

Vastly, -ffast-math deals with floating-point arithmetic, which can be
sped up significantly ignoring some of the rules imposed by
floating-point arithmetic by IEEE/ISO standards. Breaking which, though,
can lead to seriously messed up results.

> 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.

But if you add 1% error to hundreds of small calculations ... well, you
should get the point, don't you?

There are decent use cases for -ffast-math... none of which involve a
desktop system, in my opinion.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] GCC 4.7 unmasking

[Rich Freeman]

On Mon, Feb 25, 2013 at 5:11 PM, Diego Elio Pettenò
<flameeyes@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

Re: [gentoo-dev] GCC 4.7 unmasking

[Luca Barbato]

On 25/02/13 22:32, Rich Freeman wrote:
> On Mon, Feb 25, 2013 at 4:18 PM, Tom Wijsman <TomWij@gentoo.org> wrote:
>> Though people that use -ffast-math / -fLTO / -fuse-linker-plugin should
>> be on their own, thus I drop -ffast-math because it breaks my browser;
>> but that doesn't mean that those ricer flags should stop stabilization.
> 
> If we're talking about for general use in CFLAGs clearly -ffast-math
> isn't something that even could be supported if we wanted to.  The
> flag is just not intended for general use.

And if you stop here everything would be agreeable.

> 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.

Please check your facts. using -ffast-math could do anything from
nothing to cause severe security issues.

> But, the way to track that sort of a thing is to log those as bugs
> against appropriate use within individual apps and make them blockers.

No.

>  I'd consider things like this valid bugs - but whether they hold
> things up should depend on real-world impact.  I'm not sure how bad
> the impact on chromium actually is.

Absolutely not. Some code is _designed_ to work w/out caring about ieee
corner cases and some is _designed_ to work leveraging them.

NOT bug.

To reinstate: if you use -ffast-math or other
known-to-alter-the-standard-behaviour or, even worst, experimental flags
you are on your own.

lu

Re: [gentoo-dev] GCC 4.7 unmasking

[Luca Barbato]

On 25/02/13 23:21, Rich Freeman wrote:
> My point was just that:
> 1.  No, the fact that entire packages fail to build/operate using
> -ffast-math is not a valid bug.

From your email the message was the opposite, maybe a not got lost?

> 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.

That means that if the upstream cflags do not work (anymore?) with
certain compilers we should notify them. Seems sensible to do.

lu

Re: [gentoo-dev] GCC 4.7 unmasking

[Diego Elio Pettenò]

On 25/02/2013 23:21, Rich Freeman wrote:
> On Mon, Feb 25, 2013 at 5:11 PM, Diego Elio Pettenò
> <flameeyes@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.

Which is a different story altogether. By the way just so you know, as
you seem to talk a lot about things you understand only partially, if
you want performance so badly you want to use -ffast-math, you're not
going to split translation units so much.

> Maybe it wasn't a great example - I wasn't the one who first brought
> it up in the thread.

No, an example of _how building a whole package with -ffast-math_ was
brought up, and you turned it into "something that it should apply to"
(which is false, and stupid to say).

Note also how you can't defend your original statement, so I maintain my
point: you're speaking of things you don't know.

> 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.

On the distribution of errors introduced by -ffast-math I have no data.
On the other hand, I know that if you start changing 1% of the
calculation in a single piece of software, what you end up with is
rarely "within 1%" of the intended result.

Software does not work like a single equation. Ever heard of fuzzing?
You know why it works? Because a single different bit can have cascade
effects.

> 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.

This is arguable — I'm not going to dig down how many packages I found
with -O3 (or even worse -O9), just for the sake of being "faster" and
sometimes going slower than if built with -O2 (loops unrolling and
inlining are not always a good idea).

But, as you correctly say this time, right now we only have one _valid_
report: mednafen — which I'm surprised uses -ffast-math (given it's an
emulator). So the question is whether that's a showstopper for them or
not — and how serious is the performance difference between the two.

Anything else, is noise.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] GCC 4.7 unmasking

[Rich Freeman]

On Mon, Feb 25, 2013 at 5:30 PM, Luca Barbato <lu_zero@gentoo.org> wrote:
> On 25/02/13 23:21, Rich Freeman wrote:
>> My point was just that:
>> 1.  No, the fact that entire packages fail to build/operate using
>> -ffast-math is not a valid bug.
>
> From your email the message was the opposite, maybe a not got lost?

I think that I must be cursed with some kind of cloud of
misunderstanding when I write or something.

This is what I'm saying:
If you run CFLAGS="-ffast-math" emerge <foo> then you get to keep the pieces.

If you run emerge foo, and the upstream build system happens to use
-ffast-math on a single module and it has been working for 10 years
and GCC 4.7 breaks it, then maybe there is something to it.  Certainly
I support that this is something that the gcc team and the package
maintainer should work out - just because upstream does it doesn't
mean that it is right.

> That means that if the upstream cflags do not work (anymore?) with
> certain compilers we should notify them. Seems sensible to do.

I don't think we're really disagreeing here...

Rich

Re: [gentoo-dev] GCC 4.7 unmasking

[Rich Freeman]

On Mon, Feb 25, 2013 at 5:34 PM, Diego Elio Pettenò
<flameeyes@flameeyes.eu> wrote:
> No, an example of _how building a whole package with -ffast-math_ was
> brought up, and you turned it into "something that it should apply to"
> (which is false, and stupid to say).

Perhaps this is part of the issue then.  I didn't not read that email
and get the impression that the whole package was being built against
that flag.  If it ever worked I'd be quite impressed (and it would
likely be because the build system ignored it most of the time
anyway).

If that really was the example, then I can understand why my
referencing it suggested that I supported this kind of use of the
flag.

> Software does not work like a single equation. Ever heard of fuzzing?
> You know why it works? Because a single different bit can have cascade
> effects.

Hadn't really thought of it that way, but it makes sense.  Propagation
of error applies to random error when applied to integrable functions.
That breaks down as soon as you stick an if() in your code.  But hey,
fractals are pretty...

Rich