Re: [gentoo-dev] GCC 4.7 unmasking
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 signature.asc Description: Digital signature
Re: [gentoo-dev] GCC 4.7 unmasking
On Mon, 25 Feb 2013 21:58:08 +0100 Piotr Szymaniak szar...@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 : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] GCC 4.7 unmasking
On Mon, Feb 25, 2013 at 4:18 PM, Tom Wijsman tom...@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
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 flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] GCC 4.7 unmasking
On Mon, Feb 25, 2013 at 4:37 PM, Diego Elio Pettenò flamee...@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
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 flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] GCC 4.7 unmasking
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
Re: [gentoo-dev] GCC 4.7 unmasking
On 25/02/13 22:32, Rich Freeman wrote: On Mon, Feb 25, 2013 at 4:18 PM, Tom Wijsman tom...@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
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
On 25/02/2013 23:21, Rich Freeman wrote: 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. 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 flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] GCC 4.7 unmasking
On Mon, Feb 25, 2013 at 5:30 PM, Luca Barbato lu_z...@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
On Mon, Feb 25, 2013 at 5:34 PM, Diego Elio Pettenò flamee...@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
[gentoo-dev] GCC 4.7 unmasking
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, wxwidgetslearn a language baby, it's that kind of place @ gentoo.org where low card is hunger and high card is taste signature.asc Description: PGP signature
Re: [gentoo-dev] GCC 4.7 unmasking
On 25 Feb 2013 06:53, Ryan Hill dirtye...@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
Re: [gentoo-dev] GCC 4.7 unmasking
On 02/24/13 23:45, Alex Alexander wrote: On 25 Feb 2013 06:53, Ryan Hill dirtye...@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) signature.asc Description: OpenPGP digital signature
[gentoo-dev] GCC 4.7 unmasking
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 signature.asc Description: PGP signature
