Commit Graph

7 Commits

Author SHA1 Message Date
Liang Qi
0a1af55a9b Merge "Merge remote-tracking branch 'origin/5.6' into dev" into refs/staging/dev 2016-01-26 11:27:37 +00:00
Thiago Macieira
23bd4651c7 Update the Intel copyright year
Not that we require it, but since The Qt Company did it for all files
they have copyright, even if they haven't touched the file in years
(especially not in 2016), I'm doing the same.

Change-Id: I7a9e11d7b64a4cc78e24ffff142b4c9d53039846
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
2016-01-21 22:44:16 +00:00
Liang Qi
158a3a4159 Merge remote-tracking branch 'origin/5.6' into dev
Conflicts:
	src/corelib/io/qiodevice_p.h
	src/corelib/kernel/qvariant_p.h
	src/corelib/tools/qsimd.cpp
	src/gui/kernel/qguiapplication.cpp
	tests/auto/network/socket/qtcpsocket/tst_qtcpsocket.cpp

Change-Id: I742a093cbb231b282b43e463ec67173e0d29f57a
2016-01-21 08:17:21 +01:00
Jani Heikkinen
1a88b2f768 Updated license headers
From Qt 5.7 -> LGPL v2.1 isn't an option anymore, see
http://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/

Updated license headers to use new LGPL header instead of LGPL21 one
(in those files which will be under LGPL v3)

Change-Id: I046ec3e47b1876cd7b4b0353a576b352e3a946d9
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
2016-01-15 12:25:24 +00:00
Thiago Macieira
f0d0192652 Remove "FOO module" from config.tests/common
Change-Id: I14839ba5678944c2864bffff1417413f16d4ffeb
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
2015-12-04 05:20:29 +00:00
Thiago Macieira
2398e225ab Auto-detect whether 64-bit std::atomic really works
The C++ standard says it must, but some badly-configured toolchains seem
to be lacking support.

In particular, for some 32-bit platforms without native support for
them, GCC implements 64-bit atomics via out-of-line functions in
libatomic. If that library is missing... well, then std::atomic 64-bit
doesn't work and we mustn't try to use it.

This was found when trying to compile Qt 5.6 for MIPS 32-bit:

Linking library libQt5Core.so.5.6.0
.obj/qsimd.o: In function `std::__atomic_base<unsigned long long>::load(std::memory_order) const':
/opt/poky/1.7/sysroots/mips32r2-poky-linux/usr/include/c++/4.9.1/bits/atomic_base.h:500: undefined reference to `__atomic_load_8'
.obj/qsimd.o: In function `std::__atomic_base<unsigned long long>::store(unsigned long long, std::memory_order)':
/opt/poky/1.7/sysroots/mips32r2-poky-linux/usr/include/c++/4.9.1/bits/atomic_base.h:478: undefined reference to `__atomic_store_8'

Yocto bug report: https://bugzilla.yoctoproject.org/show_bug.cgi?id=8274

Change-Id: I42e7ef1a481840699a8dffff140224d6614e5c36
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 3d7586b760)
Reviewed-by: Dmitry Shachnev <mitya57@gmail.com>
2015-12-04 05:20:26 +00:00
Thiago Macieira
3d7586b760 Auto-detect whether 64-bit std::atomic really works
The C++ standard says it must, but some badly-configured toolchains seem
to be lacking support.

In particular, for some 32-bit platforms without native support for
them, GCC implements 64-bit atomics via out-of-line functions in
libatomic. If that library is missing... well, then std::atomic 64-bit
doesn't work and we mustn't try to use it.

This was found when trying to compile Qt 5.6 for MIPS 32-bit:

Linking library libQt5Core.so.5.6.0
.obj/qsimd.o: In function `std::__atomic_base<unsigned long long>::load(std::memory_order) const':
/opt/poky/1.7/sysroots/mips32r2-poky-linux/usr/include/c++/4.9.1/bits/atomic_base.h:500: undefined reference to `__atomic_load_8'
.obj/qsimd.o: In function `std::__atomic_base<unsigned long long>::store(unsigned long long, std::memory_order)':
/opt/poky/1.7/sysroots/mips32r2-poky-linux/usr/include/c++/4.9.1/bits/atomic_base.h:478: undefined reference to `__atomic_store_8'

Yocto bug report: https://bugzilla.yoctoproject.org/show_bug.cgi?id=8274

Change-Id: I42e7ef1a481840699a8dffff140224d6614e5c36
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2015-09-22 22:46:08 +00:00