Hi Derek, On Tue, 15 Dec 2015 17:39:23 +0000, Derek Buitenhuis wrote: > On 12/15/2015 5:23 PM, Jean Delvare wrote: > > Looks like something different from what we were discussing here. > > In which way? > > That patch fixes pointer aliasing in the same way yours breaks it, AFAICT?
I see two completely different things. The change I proposed is specific to one function, only changes const vs non-const, and the object under discussion is being accessed for reading only (thus the const pointer.) It would remove a memcpy but does not introduce a direct copy (with =.) The change you pointed us to is touching very generic functions, handling by nature a very wide variety of pointer types for both reading and writing. So just because the change you pointed us to may be good and desirable, doesn't imply that the change I am proposing is bad and undesirable. Side note #1: if gcc really considers pointer types that only differ by "const" as different when it comes to code optimization, it is seriously broken IMHO. Unfortunately the man page is quite vague on the topic ("unless the types are almost the same", can you be more vague please.) Side note #2: if strict-aliasing optimizations can do so much damage to your code that you end up doing memcpy(arg, &(void *){ NULL }, sizeof(val)); to set a pointer to NULL, maybe you should consider building with -fno-strict-aliasing. Side note #3: I'm surprised this change was needed in the first place as my understanding was that gcc would skip all strict-aliasing optimizations for void pointers, which is what the affected functions are handling. It's sad that the commit message is as vague as gcc's manual page on the topic. -- Jean Delvare SUSE L3 Support _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel