* [Buildroot] [PATCH 1/1] package/ffmpeg: depends on BR2_TOOLCHAIN_HAS_SYNC_4 @ 2017-04-16 11:41 Bernd Kuhls 2017-04-16 15:05 ` Thomas Petazzoni 0 siblings, 1 reply; 5+ messages in thread From: Bernd Kuhls @ 2017-04-16 11:41 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply related [flat|nested] 5+ messages in thread
* [Buildroot] [PATCH 1/1] package/ffmpeg: depends on BR2_TOOLCHAIN_HAS_SYNC_4 2017-04-16 11:41 [Buildroot] [PATCH 1/1] package/ffmpeg: depends on BR2_TOOLCHAIN_HAS_SYNC_4 Bernd Kuhls @ 2017-04-16 15:05 ` Thomas Petazzoni 2017-04-16 18:10 ` Bernd Kuhls 0 siblings, 1 reply; 5+ messages in thread From: Thomas Petazzoni @ 2017-04-16 15:05 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* [Buildroot] [PATCH 1/1] package/ffmpeg: depends on BR2_TOOLCHAIN_HAS_SYNC_4 2017-04-16 15:05 ` Thomas Petazzoni @ 2017-04-16 18:10 ` Bernd Kuhls 2017-04-17 13:45 ` Thomas Petazzoni 0 siblings, 1 reply; 5+ messages in thread From: Bernd Kuhls @ 2017-04-16 18:10 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* [Buildroot] [PATCH 1/1] package/ffmpeg: depends on BR2_TOOLCHAIN_HAS_SYNC_4 2017-04-16 18:10 ` Bernd Kuhls @ 2017-04-17 13:45 ` Thomas Petazzoni 2017-04-17 14:37 ` Waldemar Brodkorb 0 siblings, 1 reply; 5+ messages in thread From: Thomas Petazzoni @ 2017-04-17 13:45 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* [Buildroot] [PATCH 1/1] package/ffmpeg: depends on BR2_TOOLCHAIN_HAS_SYNC_4 2017-04-17 13:45 ` Thomas Petazzoni @ 2017-04-17 14:37 ` Waldemar Brodkorb 0 siblings, 0 replies; 5+ messages in thread From: Waldemar Brodkorb @ 2017-04-17 14:37 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2017-04-17 14:37 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-04-16 11:41 [Buildroot] [PATCH 1/1] package/ffmpeg: depends on BR2_TOOLCHAIN_HAS_SYNC_4 Bernd Kuhls 2017-04-16 15:05 ` Thomas Petazzoni 2017-04-16 18:10 ` Bernd Kuhls 2017-04-17 13:45 ` Thomas Petazzoni 2017-04-17 14:37 ` Waldemar Brodkorb
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox