[Development] QNX and Dinkumware support for constexpr and nullptr
James McDonnell
jmcdonnell at qnx.com
Fri Oct 30 16:29:33 CET 2015
On 2015-10-28, 6:15 PM, "Development on behalf of Thiago Macieira"
<development-bounces at qt-project.org on behalf of
thiago.macieira at intel.com> 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
>Development at qt-project.org
>http://lists.qt-project.org/mailman/listinfo/development
More information about the Development
mailing list