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

[Måns Rullgård]

Uoti Urpala wrote:
> On Fri, 2008-12-05 at 02:23 +0000, M?ns Rullg?rd wrote:
>> Uoti Urpala <uoti.urpala at pp1.inet.fi> writes:
>> > First you claimed that GCC just "happened to" generate a particular
>> > result. That was false; GCC explicitly defines the behavior.
>>
>> From a standards point of view there is no difference.  Things are
>> either in the standard or not.  Behaviour under aliasing is
>
> You're basically saying that it doesn't matter if you make false claims
> because you think you're right in the end anyway.

Try one more time to understand: if a feature is not part of the standard,
it is not relevant for a portable programme whether or not some compiler
implements said feature.  As long as a possibility exists for a standards-
compliant compiler not to implement the feature, portable code cannot use
it.

>> > Then you changed the claim to "GCC defines it this way, but another
>> > compiler may just as well do it another way". That was false too;
>>
>> There may not be a compiler in existence right now that does it
>> differently.  That does not preclude a compiler with different
>> behaviour being written tomorrow.  Would you like me to write one for
>> you?
>
> The behavior in a seriously written compiler won't be random. A compiler
> written with the intention to make it annoy people obviously doesn't
> count.

The result of aliasing through pointers works *is* pretty much random.
It depends entirely on whether the compiler performed a reordering
optimisation or not.

>> > it's not an arbitrary thing that each compiler would be likely to
>> > pick randomly.
>>
>> Yes, it is.  That is the meaning of UNDEFINED in the standard.
>
> Undefined means the standard makes _no_ requirements. It does not mean
> the standard would prohibit compiler writers from using their brain and
> instead require them to throw dice to make _every_ undefined behavior
> completely unpredictable.

If the standard makes *no* requirements, as you seem to agree is the case,
it also does not require compiler authors to agree on how to handle these
situations, and it certainly does not require them to agree with you.

>> >> >> > (like right shifting negative numbers, or casting unsigned to
>> >> >> > signed to get a negative result).
>
>> > Then why do you believe *that* compiler-defined behavior can never
>> > change, and why is code relying on it not subject to your requirements
>> > that you stated without any exceptions for practical cases?
>>
>> Representation of numbers is implementation-defined.  This implies
>> that a compiler must make a choice and document it.  Furthermore,
>> using different representations would result in incompatible machine
>> code.  Changing the representation of numbers would require a change
>> of the ABI for the machine/OS, and this does not happen unnoticed.
>
> Neither shifting nor casting results are determined by representation.

They are not entirely unrelated either; the standard defines shifting
as, well, shifting, and the result of shifting a 1 into the sign bit
depends on the bit representation of negative numbers.  Completely
independently of representation, right-shifting of negative numbers is
implementation-defined, not undefined.

>> Things left UNDEFINED by the standard, on the other hand, are free to
>> change arbitrarily between different compilers, versions of the same
>> compiler, or depending on compiler flags.  A change will not matter to
>> conforming code.  This is not just hypothetical.  Compilers do vary,
>> and gcc frequently changes the details of undefined aspects, often due
>> to changes in the optimiser.
>
> Again a strawman argument. Of course there are lots of undefined things
> which are likely to change and have changed. But I have obviously never
> claimed that _no_ undefined thing is unpredictable.

So undefined behaviour should be treated as unpredictable, except when
the current behaviour with one compiler happens to be convenient?

>> Again, I ask you to name the other compilers you have verified the
>> behaviour of.  Did you check even one?
>
> What does it matter if I give a compiler name? That alone would prove
> nothing anyway.

It would prove that you are not just making things up as you go.

>> > As illustrated by the examples above there's lots of code in FFmpeg that
>> > is not defined by a standard. Do you want to have all of it removed?
>>
>> Ideally I would want all such code to be either rewritten properly or
>> protected so as not to be compiled with unknown compilers.
>
> Good luck with that...

You are certainly not making the task easier by adding *more* such code.

>> > I replied, and then in response you wrote only nonsense about
>> > "seeing gcc as the centre of the universe" even though my reply was
>> > in no way specific to GCC.
>>
>> Your reply merely regurgitated your old arguments about gcc doing it
>> this way or that and how it would be rude of someone to write a
>> compiler behaving differently.
>
> A blatant lie. Here's what I wrote:
> ----
> 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.
> ----

Different words, same meaning.

> I think your arguments are getting stupid enough that continuing the
> thread further is a waste of time.

I think you finally ran out of everything resembling an argument and thus
had to take to insults.

All your so-called arguments can be summarised as one of "gcc does it like
that", "I like it that way", "all other compilers, none of which I bothered
to check, do the same".  Please get some verifiable facts, or go away.

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