Janne Grunau <[email protected]> writes: > On 2012-12-07 23:03:07 +0000, Måns Rullgård wrote: >> This changes the LOCAL_ALIGNED definition on systems where >> DECLARE_ALIGNED is used such it matches the manual alignment >> case, ensuring invalid use will not compile on x86 only to >> fail on everything else. >> >> Signed-off-by: Mans Rullgard <[email protected]> >> --- >> libavcodec/dsputil.h | 4 +++- >> 1 file changed, 3 insertions(+), 1 deletion(-) >> >> diff --git a/libavcodec/dsputil.h b/libavcodec/dsputil.h >> index 5640f3a..c1bd401 100644 >> --- a/libavcodec/dsputil.h >> +++ b/libavcodec/dsputil.h >> @@ -610,7 +610,9 @@ void ff_dsputil_init_dwt(DSPContext *c); >> uint8_t la_##v[sizeof(t s o) + (a)]; \ >> t (*v) o = (void *)FFALIGN((uintptr_t)la_##v, a) >> >> -#define LOCAL_ALIGNED_D(a, t, v, s, o, ...) DECLARE_ALIGNED(a, t, v) s o >> +#define LOCAL_ALIGNED_D(a, t, v, s, o, ...) \ >> + DECLARE_ALIGNED(a, t, la_##v) s o; \ >> + t (*v) o = la_##v > > Not really happy about changing arrays to pointers but since we can't > use the array properties (like sizeof array) anyway since that would > break too it's not a great loss.
The point is to make everything behave exactly the same on all systems to avoid more errors like the ones we just saw. > I wouldn't be surprised there some memsets or memcpys arround using > sizeof(array) of a LOCAL_ALIGNED variable. I made sure there were none when we introduced LOCAL_ALIGNED, but I can't be sure nothing has crept in since. If there are any, they're not causing any tests to fail. Comparing the code generated for x86 with and without the patch, there are some minor differences, but nothing that looks alarming. -- Måns Rullgård [email protected] _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
