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

[Måns Rullgård]

"Alex Converse" <alex.converse at gmail.com> writes:

> 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."
> http://gcc.gnu.org/onlinedocs/gcc-4.3.2/gcc/Optimize-Options.html#index-fstrict_002daliasing-721
>
> [...]
>
>>>> > 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__?

Do other compilers that set __GNUC__ work the same way in this regard?
I can't think of a way to test it reliably.

-- 
M?ns Rullg?rd
mans at mansr.com