On 2015-10-28, 6:15 PM, "Development on behalf of Thiago Macieira" <[email protected] on behalf of [email protected]> wrote:
>On Wednesday 28 October 2015 21:41:12 James McDonnell wrote: >> I¹ve created a QNX JIRA for the atomic function pointer compile failure. >> No idea (yet) if 6.6.0 will be patched as a result. > >Thanks James! > >Can you provide the patch, so we can patch our xxatomic files? Um, I don’t have one yet but when it's available, sure. > >> >Plus the tests at tests/auto/corelib/thread/qatomicinteger and the >> >atomic64.cpp config test. We may make the atomic64.cpp functionality >> >mandatory >> >in Qt 5.8. >> >> 8 of the qatomicinteger tests produce ³not supported² (from >>initTestCase) >> when run: >> >> tst_QAtomicInteger_Gcc_char >> tst_QAtomicInteger_Gcc_char16_t >> tst_QAtomicInteger_Gcc_qlonglong >> tst_QAtomicInteger_Gcc_qulonglong >> tst_QAtomicInteger_Gcc_schar >> tst_QAtomicInteger_Gcc_short >> tst_QAtomicInteger_Gcc_uchar >> tst_QAtomicInteger_Gcc_ushort > >That's fine, those are the "Gcc" tests, which test the qatomic_gcc.h >implementation. That's one of the files that my changes remove... > >The important thing is whether the Cxx11 tests pass. Can you confirm they >did? >Or simply apply the 5.7-c++11-atomics topic branch, because then the >std::atomic implementation will be the only one tested (except on MSVC, >of >course). Everything else was fine. All the tests in tst_QAtomicInteger_<type> passed. > >> Everything else is a-okey-dokey. atomic64.cpp compiles fine. > >Great, but... did atomic64.cpp *link*? The problem on that one is usually >linking, not compiling. Yes it linked. It’ll even run after I replace the pointer stuff in main with a "volatile std::atomic<std::int64_t>". > >> >These will make sure other integral types are supported properly, like >> >char16_t. Our tests don't check, but please verify whether >> >pointer-to-members >> >and volatile combinations work too. >> >> Volatile combinations? Atomics of volatile types? Or volatile atomics? > >Volatile atomics, as in volatile std::atomic<int>, not >std::atomic<volatile >int>. The atomicfptr.cpp and atomic64.cpp tests do it the right way. If putting volatile in front of all the QAtomicInteger<T> declarations in tst_qatomicinteger.cpp and doing a build is an adequate test then yes, volatile atomics work. > >> Pointer-to-member works (with one caveat) but only because they fall >>into >> the ³I don¹t know what this is; I¹ll do it by size² category. The >>caveat >> is that pointer-to-member doesn¹t work if the atomic is declared >>volatile. >> The size based atomic has a pointer conversion that fails when the this >> pointer is volatile. I¹ve created a QNX JIRA for this problem. > >However it works, it should be fine. The only difference between pointers >and >integral atomics is fetch_add and the arithmethic operators. Those make >sense >for regular pointers (arrays), but not for function pointers. > >Worst case scenario, someone can compile an addition to an atomic fptr >with >DW, but not with other compilers. Not a problem for us. > >We also don't use volatile atomics anywhere in Qt and our QAtomic classes >don't support them anyway. The check in atomic64.cpp and atomicfptr.cpp >is to >be on the safe side, but we can remove them if the test fails on QNX. > >-- >Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > >_______________________________________________ >Development mailing list >[email protected] >http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
