On Feb 25, 2013, at 13:50, Carl Eugen Hoyos wrote: > René J.V. Bertin <rjvbertin@...> writes: > >>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203 >> >> Who cares, as long as they don't release versions >> that fail on too many kinds of code? > > What about the ~50 (?) releases since this report was opened? > > [...]
Have you seen the code snippet? It's a bit of inline assembly of the sort that shouldn't occur in the majority of projects. You really think it would have been open for so long if the issue had had more frequent/widespread effects? I've known cases where I had to switch off -ftracer or auto-vectorisation to avoid compiler errors, and I even have to do a manual compile of one lavc52 file with gcc-4.2 (not touching any options) instead of gcc-4.7 to get the most of my version of the FFusion codec for QuickTime. I've seen other weird gcc quirks with 2.x versions. But I can't recall any case where I had to drop all optimisation that was truly a compiler error. In fact, every time I thought I had found a gcc bug, it turned out to be something in my own code. > > >> Because I presume no one will be interested in patches >> that give a performance gain that's significant >> (reproducible) but completely irrelevant on the overall >> timescale of operations... > > This is simply plain wrong. OK, if by some quirk of chance I come up with something that gains me a couple of (milli)seconds on an operation that takes 2 hours to complete and even if it requires a complete rewrite of the build system (think rather post-processing the makefiles) I'll definitely figure out how to create a patch, submit it, and be upset if it doesn't get accepted as soon as I have managed to comply with all your formatting rules O:-) Supposing of course that I'll have made the investment to show that those couple of (milli)seconds are indeed a reproducible gain because somehow I'm not even sure I'd let the test run to completion once it passes the 115 minute mark. :) The only patch from my testing that we might discuss concerns the memalign-hack. If I understand correctly it's there for forcing the correct alignment on mswin, but I'm not sure it actually works. When I played with an auto-vectorised build, I had alignment related crashes until I resorted to using _aligned_malloc (through --malloc-prefix; in the old version I used this also required adding a test for _aligned_malloc in configure). (Note that it's possible I also had to compile with the costly -mstack-realign to ensure proper alignment of buffers not malloc'ed.) Is there a reason the memalign hack remains and is not replaced by using _aligned_malloc (or _mm_malloc)? R. _______________________________________________ Libav-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/libav-user
