We can al On Jul 10, 2011 9:28 AM, "Måns Rullgård" <[email protected]> wrote: > > "Ronald S. Bultje" <[email protected]> writes: > > > Hi, > > > > 2011/7/10 Måns Rullgård <[email protected]>: > >> "Ronald S. Bultje" <[email protected]> writes: > >>> 2011/7/10 Måns Rullgård <[email protected]>: > >>>> "Ronald S. Bultje" <[email protected]> writes: > >>>>> 2011/7/10 Måns Rullgård <[email protected]>: > >>>>>> "Ronald S. Bultje" <[email protected]> writes: > >>>>>> > >>>>>>> From: Anton Mitrofanov <[email protected]> > >>>>>>> > >>>>>>> ptrdiff_t can be 4 bytes, which leads to the next element being 4-byte > >>>>>>> aligned and thus at a different offset than intended. Using a fixed 8-byte > >>>>>>> element for uv_off_px/byte fixes that. > >>>>>>> > >>>>>>> Signed-off-by: Ronald S. Bultje <[email protected]> > >>>>>>> --- > >>>>>>> libswscale/swscale_internal.h | 4 ++-- > >>>>>>> 1 files changed, 2 insertions(+), 2 deletions(-) > >>>>>>> > >>>>>>> diff --git a/libswscale/swscale_internal.h b/libswscale/swscale_internal.h > >>>>>>> index b602541..7166667 100644 > >>>>>>> --- a/libswscale/swscale_internal.h > >>>>>>> +++ b/libswscale/swscale_internal.h > >>>>>>> @@ -345,8 +345,8 @@ typedef struct SwsContext { > >>>>>>> DECLARE_ALIGNED(8, uint64_t, v_temp); > >>>>>>> DECLARE_ALIGNED(8, uint64_t, y_temp); > >>>>>>> int32_t alpMmxFilter[4*MAX_FILTER_SIZE]; > >>>>>>> - DECLARE_ALIGNED(8, ptrdiff_t, uv_off_px); ///< offset (in pixels) between u and v planes > >>>>>>> - DECLARE_ALIGNED(8, ptrdiff_t, uv_off_byte); ///< offset (in bytes) between u and v planes > >>>>>>> + DECLARE_ALIGNED(8, int64_t, uv_off_px); ///< offset (in pixels) between u and v planes > >>>>>>> + DECLARE_ALIGNED(8, int64_t, uv_off_byte); ///< offset (in bytes) between u and v planes > >>>>>>> uint16_t dither16[8]; > >>>>>>> uint32_t dither32[8]; > >>>>>>> > >>>>>>> -- > >>>>>> > >>>>>> What is this supposed to fix, and why are those things declared with > >>>>>> extra alignment at all? It makes no sense. > >>>>> > >>>>> It fixes ptrdiff_t being 4 bytes on x86-32, and then dither16 being at > >>>>> a different address. We hardcode the offset from dither16 somewhere > >>>>> for use in assembly. > >>>> > >>>> Don't do that then. If you must hardcode offsets, put those early in > >>>> the struct, before any variably sized elements. > >>> > >>> That wouldn't fix anything, we use uv_off_px/byte in asm also. > >> > >> So fix the asm. > > > > On my lit of things to do. Not as easy as it sounds. > > Well, using int64_t here penalises all non-asm 32-bit code. That is not > really acceptable.
Let's align8 the dither16/32 variable then. Ronald
_______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
