[Development] QNX and Dinkumware support for constexpr and nullptr

[James McDonnell]

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