[FFmpeg-devel] lurking bugs in the mmx-related assembler code (?)

[u-9iep at aetey.se]

On Mon, Oct 03, 2016 at 09:48:47PM +0200, Nicolas George wrote:
> > As bright as the people here are, they land in a foreign area, which
> > accidentally leads to statements like the above.
> 
> I am sorry, but an appeal to authority will not cut it in front of real
> arguments.

[Everyone, sorry for offtopic]

It was not an appeal to authority but a warning, trying to reduce the
number of nice and intelligent people making fools of themselves.

> The real argument here is: musl makes several assumptions about the
> architecture and compiler (for example: that floats and ints have the same

You should have noticed that it is actually generated per architecture
and has requirements on compilers.

> endianness) that are not mandated by any standard. And although these

Hmm isn't there such a thing called the CPU specification?

> assumptions are very reasonable and widely respected, there will eventually
> be an architecture or, more probably, a compiler, that will break them.

You mean if you _choose_ to build it for a wrong architecture or by a
wrong compiler? Then yes. :) But not otherwise.

When built properly it will fully cooperate with applications which
conform to standards. Any of them.

Unfortunately, this apparently can not be said about ffmpeg.
Replacing one standard-conforming library with another one can
apparently lead to a crash.

> FFmpeg does exactly the same.

Alas, not really.

> In this instance, we know the reason for FFmpeg: resetting the FPU state is
> expensive, and this is speed-critical code. Please tell us what are musl's
> reasons for using this ugly hack. If the answer is speed, I would very much

Be careful before calling any code "ugly". May be you just do not
understand it.

And concerning why it looks this way - this is _irrelevant_ here.
Don't try to blame the error of the old vp3 code on musl.

> like to see a benchmark comparing this implementation to a portable but
> optimized log2, especially for x86_32, where  int <-> float conversions are
> very expensive.

You are welcome to learn why the things are done in a certain way.
A good place to start might be the musl mailing list.

Yours,
Rune