ter dereference. The crash
occurs when preparing the first argument for
ff_thread_report_progress(). I believe the process didn't enter the
ff_thread_report_progress() function, even though
ff_thread_report_progress() is in the callback.
Wan-Teh Chang
I was using clang 3.4, which supports the GCC __atomic built-ins but
not C11 atomics.
In any case, I've upgraded to clang 3.8 and abandoned this patch.
Wan-Teh Chang
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
On Thu, Dec 8, 2016 at 2:32 PM, Rémi Denis-Courmont <r...@remlab.net> wrote:
> Le perjantaina 2. joulukuuta 2016, 16.56.16 EET Wan-Teh Chang a écrit :
>> The Solaris and Windows emulations of atomic_compare_exchange_strong()
>> need typecasts to avoid compiler warnings,
ec/pthread_frame.c:475:1
popq%rbx
popq%r12
popq%r14
popq%r15
popq%rbp
.Ltmp159:
retq
.Ltmp160:
.Lfunc_end2:
.size ff_thread_report_progress, .Lfunc_end2-ff_thread_report_progress
--toolchain=clang-tsan
make libavutil/tests/cpu_init
libavutil/tests/cpu_init
There should be no warnings from ThreadSanitizer.
Co-author: Dmitry Vyukov of Google, who suggested the data race fix.
Signed-off-by: Wan-Teh Chang <w...@google.com>
---
libavutil/Makefile | 2 ++
lib
On Fri, Dec 2, 2016 at 2:29 PM, Luca Barbato <lu_z...@gentoo.org> wrote:
> On 02/12/2016 20:27, Wan-Teh Chang wrote:
>
> Should not hurt.
Hi Luca,
Thank you for the review. Could you please commit my patch for me?
Thanks,
Wan-Teh Chang
are different
(|A| and |C|, respectively). |C| is the non-atomic type corresponding
to |A|. In the emulations of atomic_compare_exchange_strong(), |C| is
intptr_t. This implies |A| can only be sig_intptr_t.
Signed-off-by: Wan-Teh Chang <w...@google.com>
---
compat/atomics/suncc/stdatomic
./libavutil/tests/cpu_init
This patch merges the following FFmpeg commits:
d84a21207ea83055dc9b6dc1cd6a379f2ea756e7
048b46b4e294e8bea4ab381e5e5080a4ca31bf35
with additional changes suggested by Diego Biurrun and James Almer.
Signed-off-by: Wan-Teh Chang <w...@google.com>
---
libavutil/Ma
./libavutil/tests/cpu_init
This patch merges the following FFmpeg commits:
d84a21207ea83055dc9b6dc1cd6a379f2ea756e7
048b46b4e294e8bea4ab381e5e5080a4ca31bf35
Signed-off-by: Wan-Teh Chang <w...@google.com>
---
libavutil/Makefile | 1 +
libavutil/tests/.gitignore | 1 +
libavutil
./libavutil/tests/cpu_init
This patch merges the following FFmpeg commits:
d84a21207ea83055dc9b6dc1cd6a379f2ea756e7
048b46b4e294e8bea4ab381e5e5080a4ca31bf35
Signed-off-by: Wan-Teh Chang <w...@google.com>
---
libavutil/Makefile | 1 +
libavutil/tests/.gitignore | 1 +
libavutil
of macro
‘atomic_compare_exchange_strong’
atomic_compare_exchange_strong(object, expected, desired)
^
libavutil/cpu.c:67:9: note: in expansion of macro
‘atomic_compare_exchange_strong_explicit’
atomic_compare_exchange_strong_explicit(_flags, _flags, flags,
^
...
==
Wan-Teh Chang
th in ff_thread_report_progress(), the atomic load
of progress[field] doesn't need the "acquire" memory order because the
calling thread is trying to make the data it just decoded visible to
the other threads, rather than trying to read the data decoded by
other threads.
Please let me know if
/Alternate-Keywords.html
Signed-off-by: Wan-Teh Chang <w...@google.com>
---
compat/atomics/gcc/stdatomic.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/compat/atomics/gcc/stdatomic.h b/compat/atomics/gcc/stdatomic.h
index 67168ab..1b65e80 100644
--- a/compat/atomi
I also noticed that |refcount| is declared as atomic_int in
libavcodec/mmaldec.c but declared as atomic_uint in
libavutil/buffer_internal.h. It would be nice to be consistent.
Wan-Teh Chang
___
libav-devel mailing list
libav-devel@libav.org
https
This is how we initialize refcount in libavutil/buffer.c.
Signed-off-by: Wan-Teh Chang <w...@google.com>
---
libavcodec/mmaldec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/mmaldec.c b/libavcodec/mmaldec.c
index 924bfb2..e64ddba 100644
--- a/liba
15 matches
Mail list logo
