On Mon, Jan 09, 2012 at 01:41:04PM -0800, Ronald S. Bultje wrote: > On Mon, Jan 9, 2012 at 1:29 PM, Reinhard Tartler <[email protected]> wrote: > > 2012/1/9 Måns Rullgård <[email protected]>: > >> "Ronald S. Bultje" <[email protected]> writes: > >>> 2012/1/9 Måns Rullgård <[email protected]>: > >>>> "Ronald S. Bultje" <[email protected]> writes: > >>>> > >>>>> I'll eventually move this code to yasm and it will disappear. All > >>>>> inputs are done, only output and this fast-scaler is left, so it won't > >>>>> be awfully long. > >>>> > >>>> That argument goes both ways. > >>> > >>> Agreed - I'm just trying to do it without losing functionality, no > >>> matter how brief. > >> > >> Since it doesn't currently work, there is no loss of functionality. > > > > It does work in 32bit. The proposed workaround makes it behave in > > 64bit more similarly to the 32bit (i.e., it doesn't crash). That's > > quite an improvement. And given that it won't make porting to yasm any > > harder, what are the drawbacks or problems with the hack? > > Again, this isn't accurate. To the best of my knowledge, the 64bit > code works fine until gcc-4.5 or gcc-4.6 (I forgot where it breaks). > Only 4.6 or 4.7 breaks it.
Either way, the temporary workaround's benefit - not crashing with gcc 4.6+ - is IMO well worth the uglification that will go away shortly. Diego _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
