[FFmpeg-devel] [PATCH] fix 'warning: dereferencing type-punned pointer will break strict-aliasing rules' warning

[Rich Felker]

On Wed, Mar 05, 2008 at 03:37:55PM +0100, Michael Niedermayer wrote:
> > > Yes, old versions of gcc (dont ask which i dunno) ignored align attributes
> > > for stack variables entirely, but they did align uint64_t to 8 bytes even
> > > when it was on the stack (given that the stack was properly aligned).
> > >
> > > [...]
> > >
> > 
> > What would be the correct way to fix this then? or is it unfixable while we
> > still support old gcc versions?
> 
> one of:
> * -fno-strict-aliasing + benchmarks proofing it doesnt slow things down
>   (also dont forget that restrict can be usefull if theres a slowdown)

If there's an actual problem then this is hardly a solution since it's
a gcc-specific feature and the code is known to work on (all existing
versions of) gcc anyway.

> * live with the warnings

As long as we're confident that no sane implementation could generate
wrong code for them, I'm ok with that.

> * find a clean fix with union, iam not sure if this can be done cleanly
>   though.

Hmm, it should be as easy as putting both in a union...

> * find out which gcc versions are affected and start a vote about dropping
>   support for them, though i will vote against droping support for 2.95

Is the alignment essential anyway? gcc 2.95.3 does NOT 8-byte-align
int64_t anyway. It treats 4 as the maximal alignment for all types on
x86.

> * fix gcc and convince gnu to release a 2.95.4 or .5 or what the last official
>   one +1 was (this still would likely need us to drop gcc 3.? support though)

They won't, but we could do that on MPHQ.. Of course it won't be so
easy to add the stack-alignment code and while we're at it, someone
familiar with the parser code should look at adding C++-style
declaration support and support for more than 10 asm args too.. :)

Rich