On Tue, 2011-04-26 at 10:42 +0100, Måns Rullgård wrote:
> Uoti Urpala writes:
> > On Sun, 2011-04-24 at 07:05 -0400, Ronald S. Bultje wrote:
> >> On Sun, Apr 24, 2011 at 2:06 AM, Uoti Urpala
> >> wrote:
> >> > The current generic C implementation, which is always used when the
> >> > public head
Uoti Urpala writes:
> On Sun, 2011-04-24 at 07:05 -0400, Ronald S. Bultje wrote:
>> On Sun, Apr 24, 2011 at 2:06 AM, Uoti Urpala wrote:
>> > The current generic C implementation, which is always used when the
>> > public header is included from other programs (either directly or
>> > through int
On Sun, Apr 24, 2011 at 9:18 AM, Clément Bœsch wrote:
> On Sun, Apr 24, 2011 at 09:06:16AM +0300, Uoti Urpala wrote:
>> The current generic C implementation, which is always used when the
>> public header is included from other programs (either directly or
>> through intreadwrite.h) compiles to a
On Sun, 2011-04-24 at 07:05 -0400, Ronald S. Bultje wrote:
> On Sun, Apr 24, 2011 at 2:06 AM, Uoti Urpala wrote:
> > The current generic C implementation, which is always used when the
> > public header is included from other programs (either directly or
> > through intreadwrite.h) compiles to a m
On Sun, Apr 24, 2011 at 09:06:16AM +0300, Uoti Urpala wrote:
> The current generic C implementation, which is always used when the
> public header is included from other programs (either directly or
> through intreadwrite.h) compiles to a mess like this (gcc-4.6 on AMD64):
> movq%rdi, %
Hi,
On Sun, Apr 24, 2011 at 2:06 AM, Uoti Urpala wrote:
> The current generic C implementation, which is always used when the
> public header is included from other programs (either directly or
> through intreadwrite.h) compiles to a mess like this (gcc-4.6 on AMD64):
> movq %rdi, %rdx
On 4/24/11 8:06 AM, Uoti Urpala wrote:
+#elif 0
Maybe if 0 code could be removed or investigated.
Beside that the patch seems ok.
lu
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
The current generic C implementation, which is always used when the
public header is included from other programs (either directly or
through intreadwrite.h) compiles to a mess like this (gcc-4.6 on AMD64):
movq%rdi, %rdx
shrq$32, %rdx
movl%edx, %eax
sall
