https://bugs.kde.org/show_bug.cgi?id=339330
--- Comment #2 from Paul Floyd <pjfl...@wanadoo.fr> ---
That's not enough, at least for Fedora 33, where I get further hazards
==12068== Possible data race during write of size 1 at 0x4DC7E30 by thread #1
==12068== Locks held: none
==12068== at 0x4846952: mempcpy (vg_replace_strmem.c:1562)
==12068== by 0x4C68261: _IO_file_xsputn@@GLIBC_2.2.5 (in
/usr/lib64/libc-2.32.so)
==12068== by 0x4C53018: __vfprintf_internal (in /usr/lib64/libc-2.32.so)
==12068== by 0x4C3F2AE: printf (in /usr/lib64/libc-2.32.so)
==12068== by 0x40125E: main (std_atomic.cpp:12)
==12068== Address 0x4dc7e30 is 0 bytes inside a block of size 1,024 alloc'd
==12068== at 0x483B7A5: malloc (vg_replace_malloc.c:307)
==12068== by 0x4C5B6E3: _IO_file_doallocate (in /usr/lib64/libc-2.32.so)
==12068== by 0x4C6A09F: _IO_doallocbuf (in /usr/lib64/libc-2.32.so)
==12068== by 0x4C69237: _IO_file_overflow@@GLIBC_2.2.5 (in
/usr/lib64/libc-2.32.so)
==12068== by 0x4C682E5: _IO_file_xsputn@@GLIBC_2.2.5 (in
/usr/lib64/libc-2.32.so)
==12068== by 0x4C53018: __vfprintf_internal (in /usr/lib64/libc-2.32.so)
==12068== by 0x4C3F2AE: printf (in /usr/lib64/libc-2.32.so)
==12068== by 0x4011FD: main::{lambda()#1}::operator()() const
(std_atomic.cpp:9)
==12068== by 0x4015D1: void std::__invoke_impl<void,
main::{lambda()#1}>(std::__invoke_other, main::{lambda()#1}&&) (invoke.h:60)
==12068== by 0x401586: std::__invoke_result<main::{lambda()#1}>::type
std::__invoke<main::{lambda()#1}>(std::__invoke_result&&,
(main::{lambda()#1}&&)...) (invoke.h:95)
==12068== by 0x401533: void
std::thread::_Invoker<std::tuple<main::{lambda()#1}>
>::_M_invoke<0ul>(std::_Index_tuple<0ul>) (thread:264)
==12068== by 0x401507: std::thread::_Invoker<std::tuple<main::{lambda()#1}>
>::operator()() (thread:271)
==12068== Block was alloc'd by thread #2
--
You are receiving this mail because:
You are watching all bug changes.
