[Buildroot] [PATCH 1/1] package/ffmpeg: depends on BR2_TOOLCHAIN_HAS_SYNC_4

[Buildroot] [PATCH 1/1] package/ffmpeg: depends on BR2_TOOLCHAIN_HAS_SYNC_4

[Bernd Kuhls]

Fixes
http://autobuild.buildroot.net/results/5a2/5a2a7f24c8727f7f3aee2ca72b4472f261610c27/

Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
---
 package/ffmpeg/Config.in | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/package/ffmpeg/Config.in b/package/ffmpeg/Config.in
index b5850db72..42a357446 100644
--- a/package/ffmpeg/Config.in
+++ b/package/ffmpeg/Config.in
@@ -3,7 +3,8 @@ config BR2_PACKAGE_FFMPEG_ARCH_SUPPORTS
 	# fenv.h lacks FE_INVALID, FE_OVERFLOW & FE_UNDERFLOW on nios2
 	# No support for ARMv7-M in the ARM assembly logic
 	# Microblaze build affected by gcc PR71124 (infinite loop)
-	default y if !BR2_nios2 && !BR2_ARM_CPU_ARMV7M && !BR2_microblaze
+	default y if !BR2_nios2 && !BR2_ARM_CPU_ARMV7M && \
+		!BR2_microblaze && BR2_TOOLCHAIN_HAS_SYNC_4
 
 menuconfig BR2_PACKAGE_FFMPEG
 	bool "ffmpeg"
-- 
2.11.0

[Buildroot] [PATCH 1/1] package/ffmpeg: depends on BR2_TOOLCHAIN_HAS_SYNC_4

[Thomas Petazzoni]

Hello,

On Sun, 16 Apr 2017 13:41:35 +0200, Bernd Kuhls wrote:
> Fixes
> http://autobuild.buildroot.net/results/5a2/5a2a7f24c8727f7f3aee2ca72b4472f261610c27/

In a patch sent yesterday, you made ffmpeg link against libatomic. It's
a bit weird that it also uses the __sync built-ins. Does it use
both __atomic and __sync built-ins? In all configurations? On all
architectures?

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH 1/1] package/ffmpeg: depends on BR2_TOOLCHAIN_HAS_SYNC_4

[Bernd Kuhls]

Thomas Petazzoni <thomas.petazzoni-
wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote in 
news:20170416170537.5eee03e2 at free-electrons.com:

> Hello,
> 
> On Sun, 16 Apr 2017 13:41:35 +0200, Bernd Kuhls wrote:
>> Fixes
>> 
http://autobuild.buildroot.net/results/5a2/5a2a7f24c8727f7f3aee2ca72b4472f2
61610c27/
> 
> In a patch sent yesterday, you made ffmpeg link against libatomic. It's
> a bit weird that it also uses the __sync built-ins. Does it use
> both __atomic and __sync built-ins? In all configurations? On all
> architectures?

Hi Thomas,

afaics both __atomic and __sync functions are used at the same time, for 
example:
http://git.videolan.org/?
p=ffmpeg.git;a=blob;f=libavcodec/mediacodecdec_common.c;h=2ec25c581d34f8f50
09b84161a79589dbaf21683;hb=refs/heads/release/3.3#l145

calls

atomic_fetch_add(&s->refcount, 1);

which translates to __sync_fetch_and_add:
http://git.videolan.org/?
p=ffmpeg.git;a=blob;f=compat/atomics/gcc/stdatomic.h;h=e13ed0e068b8fb50c7a6
9ca19a2600dae31a5a21;hb=refs/heads/release/3.3#l132

And http://git.videolan.org/?
p=ffmpeg.git;a=blob;f=libavutil/buffer.c;h=8d1aa5fa841eb934b9b1846672d9c43d
be23bca3;hb=refs/heads/release/3.3#l102

calls

atomic_fetch_add_explicit(&buf->buffer->refcount, 1, memory_order_relaxed);

which translates to atomic_fetch_add:
http://git.videolan.org/?
p=ffmpeg.git;a=blob;f=compat/atomics/gcc/stdatomic.h;h=e13ed0e068b8fb50c7a6
9ca19a2600dae31a5a21;hb=refs/heads/release/3.3#l135

Regards, Bernd

[Buildroot] [PATCH 1/1] package/ffmpeg: depends on BR2_TOOLCHAIN_HAS_SYNC_4

[Thomas Petazzoni]

Hello,

Adding Waldemar, as there are some m68k toolchain questions/issues
below.

On Sun, 16 Apr 2017 20:10:36 +0200, Bernd Kuhls wrote:

> afaics both __atomic and __sync functions are used at the same time, for 
> example:
> http://git.videolan.org/?
> p=ffmpeg.git;a=blob;f=libavcodec/mediacodecdec_common.c;h=2ec25c581d34f8f50
> 09b84161a79589dbaf21683;hb=refs/heads/release/3.3#l145
> 
> calls
> 
> atomic_fetch_add(&s->refcount, 1);
> 
> which translates to __sync_fetch_and_add:
> http://git.videolan.org/?
> p=ffmpeg.git;a=blob;f=compat/atomics/gcc/stdatomic.h;h=e13ed0e068b8fb50c7a6
> 9ca19a2600dae31a5a21;hb=refs/heads/release/3.3#l132
> 
> And http://git.videolan.org/?
> p=ffmpeg.git;a=blob;f=libavutil/buffer.c;h=8d1aa5fa841eb934b9b1846672d9c43d
> be23bca3;hb=refs/heads/release/3.3#l102
> 
> calls
> 
> atomic_fetch_add_explicit(&buf->buffer->refcount, 1, memory_order_relaxed);
> 
> which translates to atomic_fetch_add:
> http://git.videolan.org/?
> p=ffmpeg.git;a=blob;f=compat/atomics/gcc/stdatomic.h;h=e13ed0e068b8fb50c7a6
> 9ca19a2600dae31a5a21;hb=refs/heads/release/3.3#l135

I really would like to see a better investigation here, rather than
one-off fixes. Looking at the ffmpeg configure script:

if disabled stdatomic_h; then
    if enabled atomics_gcc; then
        add_cppflags '-I\$(SRC_PATH)/compat/atomics/gcc'
    elif enabled atomics_win32; then
        add_cppflags '-I\$(SRC_PATH)/compat/atomics/win32'
    elif enabled atomics_suncc; then
        add_cppflags '-I\$(SRC_PATH)/compat/atomics/suncc'
    elif enabled pthreads; then
        add_compat atomics/pthread/stdatomic.o
        add_cppflags '-I\$(SRC_PATH)/compat/atomics/pthread'
    else
        enabled threads && die "Threading is enabled, but no atomics are available"
        add_cppflags '-I\$(SRC_PATH)/compat/atomics/dummy'
    fi
fi

So, in our Linux case:

 - It tries to use <stdatomic.h> if available
 - Otherwise, it uses the atomics/gcc built-ins, i.e __sync built-ins
 - Otherwise, it uses pthread based locks

So, for the m68k case, why isn't the fallback to pthread locks not
working? Also, if you look at the config.log for the m68k toolchain,
you see:

check_builtin stdatomic_h stdatomic.h atomic_int foo, bar = ATOMIC_VAR_INIT(-1); atomic_store(&foo, 0)
check_code ld stdatomic.h atomic_int foo, bar = ATOMIC_VAR_INIT(-1); atomic_store(&foo, 0) cc
check_ld cc
check_cc
BEGIN /tmp/ffconf.oqKy0y9w.c
    1   #include <stdatomic.h>
    2   int main(void) { atomic_int foo, bar = ATOMIC_VAR_INIT(-1); atomic_store(&foo, 0); return 0; }
END /tmp/ffconf.oqKy0y9w.c
/home/thomas/projets/buildroot/output/host/usr/bin/m68k-linux-gcc -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 --sysroot=/home/thomas/projets/buildroot/output/host/usr/m68k-buildroot-uclinux-uclibc/sysroot -isysroot /home/thomas/projets/buildroot/output/host/usr/m68k-buildroot-uclinux-uclibc/sysroot -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -Wl,-elf2flt -static -std=c11 -fomit-frame-pointer -c -o /tmp/ffconf.5kFw4oXu.o /tmp/ffconf.oqKy0y9w.c

So no error at all on <stdatomic.h>, so why does it fall back to __sync
built-ins?

Also Waldemar, you marked __sync 4 bytes built-in as not available for
m68k_cf (commit df00b174f6c965be52d58a7911cec74de1426f8d), but it seems
to also fail on __atomic builtins with a gcc ICE. Has this issue been
reported to upstream gcc? Buildroot currently assumes that the m68k
toolchain provides __atomic built-ins. You can try to test the
toolchain with the following C program:

#include <stdint.h>

int main(void)
{
        uint8_t a;
        uint16_t b;
        uint32_t c;
        uint64_t d;

        __sync_fetch_and_add(&a, 3);
        __sync_fetch_and_add(&b, 3);
        __sync_fetch_and_add(&c, 3);
        __sync_fetch_and_add(&d, 3);

        __sync_val_compare_and_swap(&a, 1, 2);
        __sync_val_compare_and_swap(&b, 1, 2);
        __sync_val_compare_and_swap(&c, 1, 2);
        __sync_val_compare_and_swap(&d, 1, 2);

        __atomic_add_fetch(&a, 3, __ATOMIC_RELAXED);
        __atomic_add_fetch(&b, 3, __ATOMIC_RELAXED);
        __atomic_add_fetch(&c, 3, __ATOMIC_RELAXED);
        __atomic_add_fetch(&d, 3, __ATOMIC_RELAXED);

        __atomic_compare_exchange_n(&a, &a, 2, 1,  __ATOMIC_RELAXED,  __ATOMIC_RELAXED);
        __atomic_compare_exchange_n(&b, &b, 2, 1,  __ATOMIC_RELAXED,  __ATOMIC_RELAXED);
        __atomic_compare_exchange_n(&c, &c, 2, 1,  __ATOMIC_RELAXED,  __ATOMIC_RELAXED);
        __atomic_compare_exchange_n(&d, &d, 2, 1,  __ATOMIC_RELAXED,  __ATOMIC_RELAXED);

        return 0;
}

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH 1/1] package/ffmpeg: depends on BR2_TOOLCHAIN_HAS_SYNC_4

[Waldemar Brodkorb]

Hi Thomas,
Thomas Petazzoni wrote,

> Hello,
> 
> Adding Waldemar, as there are some m68k toolchain questions/issues
> below.
> 
> On Sun, 16 Apr 2017 20:10:36 +0200, Bernd Kuhls wrote:
> 
> > afaics both __atomic and __sync functions are used at the same time, for 
> > example:
> > http://git.videolan.org/?
> > p=ffmpeg.git;a=blob;f=libavcodec/mediacodecdec_common.c;h=2ec25c581d34f8f50
> > 09b84161a79589dbaf21683;hb=refs/heads/release/3.3#l145
> > 
> > calls
> > 
> > atomic_fetch_add(&s->refcount, 1);
> > 
> > which translates to __sync_fetch_and_add:
> > http://git.videolan.org/?
> > p=ffmpeg.git;a=blob;f=compat/atomics/gcc/stdatomic.h;h=e13ed0e068b8fb50c7a6
> > 9ca19a2600dae31a5a21;hb=refs/heads/release/3.3#l132
> > 
> > And http://git.videolan.org/?
> > p=ffmpeg.git;a=blob;f=libavutil/buffer.c;h=8d1aa5fa841eb934b9b1846672d9c43d
> > be23bca3;hb=refs/heads/release/3.3#l102
> > 
> > calls
> > 
> > atomic_fetch_add_explicit(&buf->buffer->refcount, 1, memory_order_relaxed);
> > 
> > which translates to atomic_fetch_add:
> > http://git.videolan.org/?
> > p=ffmpeg.git;a=blob;f=compat/atomics/gcc/stdatomic.h;h=e13ed0e068b8fb50c7a6
> > 9ca19a2600dae31a5a21;hb=refs/heads/release/3.3#l135
> 
> I really would like to see a better investigation here, rather than
> one-off fixes. Looking at the ffmpeg configure script:
> 
> if disabled stdatomic_h; then
>     if enabled atomics_gcc; then
>         add_cppflags '-I\$(SRC_PATH)/compat/atomics/gcc'
>     elif enabled atomics_win32; then
>         add_cppflags '-I\$(SRC_PATH)/compat/atomics/win32'
>     elif enabled atomics_suncc; then
>         add_cppflags '-I\$(SRC_PATH)/compat/atomics/suncc'
>     elif enabled pthreads; then
>         add_compat atomics/pthread/stdatomic.o
>         add_cppflags '-I\$(SRC_PATH)/compat/atomics/pthread'
>     else
>         enabled threads && die "Threading is enabled, but no atomics are available"
>         add_cppflags '-I\$(SRC_PATH)/compat/atomics/dummy'
>     fi
> fi
> 
> So, in our Linux case:
> 
>  - It tries to use <stdatomic.h> if available
>  - Otherwise, it uses the atomics/gcc built-ins, i.e __sync built-ins
>  - Otherwise, it uses pthread based locks
> 
> So, for the m68k case, why isn't the fallback to pthread locks not
> working? Also, if you look at the config.log for the m68k toolchain,
> you see:
> 
> check_builtin stdatomic_h stdatomic.h atomic_int foo, bar = ATOMIC_VAR_INIT(-1); atomic_store(&foo, 0)
> check_code ld stdatomic.h atomic_int foo, bar = ATOMIC_VAR_INIT(-1); atomic_store(&foo, 0) cc
> check_ld cc
> check_cc
> BEGIN /tmp/ffconf.oqKy0y9w.c
>     1   #include <stdatomic.h>
>     2   int main(void) { atomic_int foo, bar = ATOMIC_VAR_INIT(-1); atomic_store(&foo, 0); return 0; }
> END /tmp/ffconf.oqKy0y9w.c
> /home/thomas/projets/buildroot/output/host/usr/bin/m68k-linux-gcc -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 --sysroot=/home/thomas/projets/buildroot/output/host/usr/m68k-buildroot-uclinux-uclibc/sysroot -isysroot /home/thomas/projets/buildroot/output/host/usr/m68k-buildroot-uclinux-uclibc/sysroot -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -Wl,-elf2flt -static -std=c11 -fomit-frame-pointer -c -o /tmp/ffconf.5kFw4oXu.o /tmp/ffconf.oqKy0y9w.c
> 
> So no error at all on <stdatomic.h>, so why does it fall back to __sync
> built-ins?
> 
> Also Waldemar, you marked __sync 4 bytes built-in as not available for
> m68k_cf (commit df00b174f6c965be52d58a7911cec74de1426f8d), but it seems
> to also fail on __atomic builtins with a gcc ICE. Has this issue been
> reported to upstream gcc? Buildroot currently assumes that the m68k
> toolchain provides __atomic built-ins. You can try to test the
> toolchain with the following C program:

I get an ICE.

The bug exist since a while:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68467

There was some progress last year, but no solution.

Coldfire neither provide support for atomic nor __sync* at the moment
AFAIK.

best regards
 Waldemar