[Ffmpeg-cvslog] r8420 - trunk/libavcodec/dv.c

[Rich Felker]

On Sat, Mar 24, 2007 at 09:17:47PM -0700, Roman Shaposhnik wrote:
> > it's a matter of what the calling
> > code does. Thus all you can ever assume on x86 is 4. In order to be
> > correct, the compiler must generate code to fully align the stack in
> > any function that depends on the stack being aligned. gcc does not do
> > this, so it's broken. Either they should fix this or document the fact
> > that alignment attributes do not work on automatic variables.
>  
>   In Sun Studio compilers we've decided to do a combined approach
> now -- we honor requests for alignment of the automatic variables 
> up to the ABI requirements (although, it seems to be safe to assume
> 8 on Pentium+ these days for obvious reasons) and we issue a warning
> if the requested alignment is higher. I believe it was suggested that
> gcc guys do the same -- but they don't seem to be interested.

I hope you only assume 8 if -march=586 or similar is used. I always
build with vanilla i386 except for really rare cases like mplayer.
Most likely alignment doesn't matter for pre-586 anyway, but I suppose
someone could be using it for evil hacks like storing extra data in
the low bits of pointers... :)

On second thought, assuming 8 is not safe even with -march=586. Why?
Because your code could be called via a function pointer from a
library compiled with the minimum i386 alignment. Or, your code itself
might be a library (like lavc) called from a program that's not
compiled with any special -march flags, or even with a different
compiler version. Also, your system's libc or crt0 startup code might
not initially align beyond the minimum if it's built for plain i386.

I don't think there's any safe way to assume 8-byte alignment on x86.

Rich