Bring in WebKit revisions 139553 and 139921.

They are primarily useful for getting rid of some libstdc++-specific
includes which break the build with libc++, and also for simplifying the
code and removing a Darwin-specific code path.

r139553 by ossy@webkit.org:
  Use sync_add_and_fetch instead of gnu_cxx::exchange_and_add
  https://bugs.webkit.org/show_bug.cgi?id=106729

  After r139514 we need atomicIncrement(int64_t volatile*) for all
  platform. Now the GCC implementation of atomicIncrement() is based on
  gnu_cxx::exchange_and_add, which doesn't support int64_t type, but
  sync_add_and_fetch does.

  Reviewed by Benjamin Poulain.

r139921 by benjamin@webkit.org:
  Use GCC's implementation of atomicIncrement/Decrement on Mac
  https://bugs.webkit.org/show_bug.cgi?id=106976

  Reviewed by Filip Pizlo.

  wtf/Atomics.h: GCC and LLVM have builtin for atomic ADD and SUB:
                 sync_add_and_fetch, sync_sub_and_fetch.

  Using them let the compiler just generate the atomic operations inline
  instead of generating a function call to LibC. It also simplify the
  code a bit.

Cherry-picked from qtscript/184fc178f4c753727445694c4830c250f53da588.

Change-Id: Id785e35944682691725947e0f329668d17ff6903
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
clucene: Compile with clang's libc++

When using clang's libc++, the 'using namespace std;' in CLucene's
StdHeader.h causes ambiguity between wcschr() from wchar.h and
std::wcschr() from cwchar (which is automatically included by libc++).

The only symbols used from the std namespace are std::min() and
std::max() so only pull these in, not the whole std namespace.

Cherry-picked from qttools/bc35938d0d49b04bf98feda3e85da186ecc8184d.

Change-Id: Ife6647df795f59a5feebd5c1aa3eebe7446ec720
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Clear the current thread data for the main thread

This avoids crashes accessing deleted memory when creating a QObject
after the last QObject had been deleted, like a qDebug() in global
destructors.

==41000== Invalid read of size 4
==41000==    at 0x5F01ED5: bool QBasicAtomicOps<4>::ref<int>(int&) (qatomic_x86.h:208)
==41000==    by 0x5F01309: QBasicAtomicInteger<int>::ref() (qbasicatomic.h:147)
==41000==    by 0x5F24051: QThreadData::ref() (qthread.cpp:100)
==41000==    by 0x614A984: QObject::QObject(QObject*) (qobject.cpp:681)
==41000==  Address 0x6ee73f0 is 0 bytes inside a block of size 152 free'd
==41000==    at 0x4A0736C: operator delete(void*) (vg_replace_malloc.c:480)
==41000==    by 0x5F240BF: QThreadData::deref() (qthread.cpp:109)
==41000==    by 0x6113F6B: QCoreApplicationData::~QCoreApplicationData() (qcoreapplication.cpp:268)

The comment right above the change in qthread.cpp looks eerily similar
to the problem I'm trying to fix. However, the actual change that
introduced the change is not in the Qt public history, so we can't
know for sure what the problem was then.

Cherry-picked from qtbase/950b35cf97ad398f97883efd2a18ee97994a8a9c.

Change-Id: Ic4072c15529e2ae94ea36fbd0340cf5ee61413d2
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Make sure QThreadData and QAdoptedThread object is destroyed at app exit

Task-number: QTBUG-30134

Restore the lines in qcoreapplication.cpp removed by commit
950b35cf97ad398f97883efd2a18ee97994a8a9c to ensure QThreadData and
QAdoptedThread object of main thread is destroyed at application exit.
We don't set QCoreApplicationPriavte::theMainThread to 0 as before since
it will be set to zero in QThreadData::~QThreadData()

Cherry-picked from qtbase/7dc622290bb8e81af634034f443e25be0d6d48a3.

Change-Id: I6bc62235d0aff7818ca9a9cad45625b2777afc55
Reviewed-by: jian liang <jianliang79@gmail.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Fix crash when re-creating QThreadData after initially destroying it

We destroy the thread data for the main thread when the QCoreApplication
is destructed, and then delete the pthread key for the thread data in
the global static destructor function 'destroy_current_thread_data_key'.

The user may have its own Q_DESTRUCTOR_FUNCTION though, which may or may
not run after we've destroyed the key. If it runs after we've destroyed
the key, we'll end up trying to re-create the tread-data, as expected,
but set_thread_data() will fail to persist it, as pthread_setspecific
is called with an invalid key. The result is an infinite recursion:

...
6  in QThreadData::current () at qthread_unix.cpp:216
7  in QObject::QObject (this=0x48e1b30, dd=@0x48e1b40, parent=0x0) at qobject.cpp:703
8  in QThread::QThread (this=0x48e1b30, dd=@0x48e1b40, parent=0x0) at qthread.cpp:396
9  in QAdoptedThread::QAdoptedThread (this=0x48e1b30, data=0x48e1af0) at qthread.cpp:120
10 in QAdoptedThread::QAdoptedThread (this=0x48e1b30, data=0x48e1af0) at qthread.cpp:130
11 in QThreadData::current () at qthread_unix.cpp:219
12 in QObject::QObject (this=0x48e1a20, dd=@0x48e1a30, parent=0x0) at qobject.cpp:703
...

To solve this, we reset current_thread_data_once when destroying the key,
so that subsequent calls to pthread_once to potentially create the key
will call create_current_thread_data_key once more. This means we'll leak
the key for this particular use-case, since we don't end up calling
pthread_key_delete a second time, but this leak is small and happens
typically only for a short duration during application shutdown.

Cherry-picked from qtbase/46667d604fb2ae11a87c0c075a3d2468d02f7bdb.

Change-Id: Iffc372ca530a486cd3efc2237ab02468bdcb5c81
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>