[FFmpeg-devel] [RFC] remove lrintf fallback implementation

[Víctor Paesa]

Hi,

>> > And what it's not ARCH_X86?
>>
>> I cannot remember any other architecture reporting here the lack of
>> llrint(), should they exist, they can also add some asm().
>
> No architecture ever reported a lack of llrint().  And how would they,
> it's not a processor feature.  The platform/OS that is known to lack
> llrint() is Cygwin.

Very true, the correct word is platform/OS, though in this case the i387
provides one OP code so convenient that is almost a processor feature.

> AFAIK Cygwin runs on on both i386 and AMD64.

Cygwin is 32 bits, the AMD64 is probably running in 32 bit mode.

> If your patch works fine on both then there will be no immediate
> breakage.

> However, I think this is the wrong approach.  If you are going to
> implement llrint(), do it in Cygwin, not in FFmpeg.  It is the right
> place to fix the issue instead of working around it and will give you
> better karma by helping many other projects, not just FFmpeg.
>
> See this thread I started on the Cygwin mailing list (and ignore the
> flamage):
>
> http://thread.gmane.org/gmane.os.cygwin/92561
>
> All you have to do is add llrint() to newlib, Cygwin will pick it up
> from there.  Alternatively you can wait for the next gcc upgrade in
> Cygwin, which will reportedly carry along llrint().
>
> All in all I am against this patch.  We should be removing
> platform-specific workarounds, not adding more of them.  If you cannot
> wait for this to get fixed by the gcc upgrade, address the problem in
> the right place, i.e. patch Cygwin, not FFmpeg.

I have downloaded newlib source and they favour .S files to inline
assembly so waiting for the next gcc looks a viable alternative (it will
take more or less the same time than me learning how to prepare a patch).

To make things a bit more difficult: my patch is based on LGPL'ed code,
and Cygwin only uses newlib code having PD or BSD licenses.
See http://cygwin.com/ml/cygwin-developers/2007-10/msg00037.html

The route I'm pondering by now is to create my own (minimalistic) libm99:
if gcc delivers a C99 function missing in newlib I can do the same too,
and it be would just a matter of using --extra-libs instead of
patching ffmpeg.

Regards,
V?ctor