[FFmpeg-devel] [PATCH] AAC: type puns for 16 bit floating point rounding

Alex Converse alex.converse
Thu Dec 4 19:28:17 CET 2008

On Thu, Dec 4, 2008 at 12:11 PM, M?ns Rullg?rd <mans at mansr.com> wrote:
> Uoti Urpala wrote:
>> On Thu, 2008-12-04 at 14:22 +0000, M?ns Rullg?rd wrote:
>>> Uoti Urpala wrote:
>>> > On Thu, 2008-12-04 at 09:35 +0000, M?ns Rullg?rd wrote:
>>> >> Uoti Urpala <uoti.urpala at pp1.inet.fi> writes:
>>> >>
>>> >> > On Thu, 2008-12-04 at 03:13 +0000, M?ns Rullg?rd wrote:
>>> >> >> Are this things safe under strict aliasing rules?
>>> >> >
>>> >> > Yes GCC does guarantee that it will work (all the accesses use
>>> >> > unionvalue.field syntax with the same union).
>>> >>
>>> >> What gcc does is irrelevant.  Is it guaranteed by the C standard?
>>> >
>>> > The GCC behavior is more relevant than the standard in this case. The
>>> That is only true in the reverse situation, i.e. when the standard allows
>>> something but gcc misbehaves.  Then we have no choice but avoiding the
>>> offending construct.  If gcc happens to generate intuitively correct
>>> code for something that is undefined by the standard, we should still not
>>> be using that something.
>> It's not that GCC "happens to" generate the correct result, but that it
>> explicitly defines it will work.
> Same thing.  GCC happens to define this one way.  Another compiler may do
> it differently.  GCC is not the only compiler.  BTW, where is such
> behaviour of gcc documented?

"The practice of reading from a different union member than the one
most recently written to (called "type-punning") is common. Even with
-fstrict-aliasing, type-punning is allowed, provided the memory is
accessed through the union type."


>>> > and it seems unlikely that some compiler would use more strict ones in
>>> > the future
>>> Upon what do you base this assertion?
>> Disallowing that would break even more code than the GCC introduction of
>> strict aliasing did, it's desirable to have some supported mechanism for
>> type punning, and disallowing it is unlikely to allow any significant
>> optimizations.
> Try for a moment to not see gcc as the centre of the universe.  Until
> you've tested *every* compiler, you simply cannot say what works and
> what doesn't.

Suppose we only do this for compilers that claim __GNUC__?



More information about the ffmpeg-devel mailing list