[Development] QNX and Dinkumware support for constexpr and nullptr

[Thiago Macieira]

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?

> >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 is a-okey-dokey.  atomic64.cpp compiles fine.

Great, but... did atomic64.cpp *link*? The problem on that one is usually 
linking, not compiling.

> >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.

> 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