Remove useless code setting but not using variables

Clang 3.3 found a variable assigned to itself, probably to cause
GCC to shut up about a variable set-but-unused. So simply stop
assigning the value at all to this variable.

qxcbxsettings.cpp:155:16: error: explicitly assigning a variable of type 'uint' (aka 'unsigned int') to itself [-Werror,-Wself-assign]

Change-Id: I74ae8f724e87c1b3f6b9d358e13d6a440ff4a3e1
Reviewed-by: Uli Schlachter <psychon@znc.in>
Reviewed-by: Jan Arve Sæther <jan-arve.saether@digia.com>
Fix the C++11 and GCC-atomic intrinsics when not using GCC

Both Clang and ICC complain about the use of those atomics when used
with a forward-declared pointee. GCC doesn't, which makes me think
it's a GCC bug.

When using QBasicAtomicPointer<Foo> with these atomics, the _q_value
member causes the instantiation of QAtomicOps<Foo>, which causes the
instantiation of the regular member function
QAtomicOps<Foo>::fetchAndAddRelaxed. The problem is that function
takes a QAtomicAdditiveType<Foo>::AdditiveT as parameter, which
requires sizeof(Foo). Clang 3.3 and ICC 14 correctly expand and
complain. GCC 4.7-4.9 apparently don't.

The fix is to apply the same trick we used for the other atomics:
change all ops functions (including fetchAndAddRelaxed) to be member
templates. That way, they can't be expanded until the actual use.

Clang errors:
qgenericatomic.h:73:33: error: invalid application of 'sizeof' to an incomplete type 'QMutexData'
qatomic_gcc.h:136:48: note: in instantiation of template class 'QAtomicAdditiveType<QMutexData *>' requested here
qbasicatomic.h:272:22: note: in instantiation of template class 'QAtomicOps<QMutexData *>' requested here

ICC errors:
qgenericatomic.h(73): error: incomplete type is not allowed
    detected during:
      instantiation of class "QAtomicAdditiveType<T *> [with T=QMutexData]" at line 111 of "qatomic_cxx11.h"
      instantiation of class "QAtomicOps<T> [with T=QMutexData *]" at line 272 of "qbasicatomic.h"

Found-by: Tor Arne
Change-Id: I9b10648cd47109a943b34a4c9926d77cd0c4fe12
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>