[FFmpeg-devel] PATCH: av_strtod

[Ramiro Polla]

Hi,

On Mon, Jun 1, 2009 at 2:27 AM, Pavel Pavlov <pavel at summit-tech.ca> wrote:
> In my spare time I ported ffpeg to another compiler (icl) and had to
> resolve some bugs related to failed regression tests.
[...]
> I belive that the root of the problem is incomplete implemetation of
> strtod of the ms library.

This is a known issue with msvcrt. Search the ffmpeg-devel archives
for some past discussions. MinGW32 uses a POSIX compliant strtod
implementation and it suits us well.

[...]

> Then my lib doesn't pass seek_test.exe.

This is also known issue. Look for a thread on this list about huge
negative numbers, MinGW32, and printf or something. MinGW32 has a
printf implementation that recently fixed this issue, and it also
suits us well.

[...]

> Other than that, my build passes validation (if I build seek_test with
> gcc). I didn't test any performance between gcc/icl builds; the reaon I
> decided to port to intel compiler is that I had crashes somewhere inside
> avcodec if I had a video call running overnight and I just couldn't find
> out where and why (I use ms vs). Since intel compiler can generate debug
> info compatible with ms tools I decided to do it. Not only I'm able to
> easily step-trough the code with VS, but also with icl build my original
> problem is gone :)

Great. I'm sure some people will appreciate that:
http://ffmpeg.arrozcru.org/forum/viewtopic.php?f=10&t=1005

> Port to intel compiler requires too intrusive changes to the code, so I
> don't even try to send a diff.

Even though, yes, it is most likely that your patches will get
rejected here, it would be nice if you could share them.

> Biggest problem is the black voodoo code related to inline assembly and
> MANGLE(...)

> plus the worst ever code is in recently added
> mlp_filter_channel_x86, which mangles lables. WTF, why not a standalone
> .asm file instead?!?

A patch based in configure disabling that code on supported compilers
where it fails is welcome.

> Moreover, there is a big problem that very often compiler doesn't have
> enough registers to assemble inline asm, which I also had to solve.
> Surprisingly, in non optimized build icl and gcc get that not enough
> general regs error in exactly the same code, which makes me think that
> intel compiler borrowed some code from gcc ;)
> Icc (linux intel compiler) uses gas as the assembler for the inline
> att-style asm, in win32 build they have built in asm (that is quite
> limited). The only feature that I didn't properly do is the .align
> derective for the inline assembly. In icl the only way to do it is to
> use ms-style inline assembly and to use ALIGN derective which is
> supported.

It's not quite clear how you got around some issues. Specially the
ones listed here:
http://wiki.multimedia.cx/index.php?title=Icc#Windows_version

Did you rewrite inline assembly in ms style, or is there a way to
switch inline assembly modes inside the asm block so that you can
insert your ALIGN directive? Did you disable the code that needs
MANGLE?

Ramiro Polla