Commit Graph

18 Commits

Author SHA1 Message Date
Ulf Hermann
8c2ca33073 Replace qdtoa and qstrtod implementation by a 3rdparty library
This also fixes the underlying cause of QTBUG-44039 and QTBUG-43885.

You can choose between system, qt, and no libdouble-conversion
support. If you choose "no", snprintf_l and sscanf_l will be
used.

By default, system double conversion is used if the system provides a
double-conversion library. Otherwise the bundled libdouble-conversion
is built. sscanf_l and snprintf_l are not used by default as the
planned "shortest" conversion mode to produce the shortest possible
string will give less precise results when implemented with snprintf_l.

Change-Id: I8ca08a0fca5c54cf7009e48e771385614f6aa031
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
2015-11-02 17:00:50 +00:00
Thiago Macieira
a587ad1e50 configure: Add support for detecting AVX512 instructions
Tested on Linux with Clang 3.7, GCC 4.9, 5.1 and 6.0, ICC 16 beta; on OS
X with Clang-XCode 6.4, ICC 16 beta; on Windows with MSVC 2013 and ICC
15. MinGW is not tested.

GCC 4.9:     AVX512F AVX512ER AVX512CD AVX512PF
GCC 5 & 6:   AVX512F AVX512ER AVX512CD AVX512PF AVX512DQ AVX512BW AVX512VL AVX512IFMA AVX512VBMI
Clang 3.7:   AVX512F AVX512ER AVX512CD
Clang-XCode: <none>
ICC 15 & 16: AVX512F AVX512ER AVX512CD AVX512PF AVX512DQ AVX512BW AVX512VL
MSVC 2013:   <none>

Change-Id: Ib306f8f647014b399b87ffff13f1da1b161c31d7
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2015-09-25 20:29:22 +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
Thiago Macieira
4684c1afe5 Add detection of C++14 and C++1z compiler features
[ChangeLog][General Improvements] Qt's buildsystem now detects whether
the compiler supports C++14 and experimental support for C++1z. If the
compiler supports it, then Qt is automatically compiled using that
support.
\
This does not apply to user applications built using qmake: those are
still built with C++11 support only. To enable support for C++14 in your
application, add to your .pro file: CONFIG += c++14 (similarly for
C++1z).

Change-Id: Ib056b47dde3341ef9a52ffff13ef1f5d01c42596
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
2015-09-05 23:05:40 +00:00
Thiago Macieira
3accdb8086 Detect which C++ standard edition the compiler defaults to
Change-Id: I2991557a5cc74cd18e88ffff13f670bf25d5423e
Reviewed-by: Kai Koehne <kai.koehne@theqtcompany.com>
2015-08-25 06:25:11 +00:00
Thiago Macieira
752362b0fa Require more of the C++11 Standard Library
Since libstdc++ builds on OS X and QNX 6.5 are no longer supported,
simply require <initializer_list> and std::move in order to claim C++11
support works.

The minimum OS X versions need to be fixed elsewhere.

Change-Id: Ib056b47dde3341ef9a52ffff13ef1d2ac3923f5c
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Jake Petroules <jake.petroules@petroules.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
Reviewed-by: Rafael Roquetto <rafael.roquetto@kdab.com>
2015-08-06 07:13:46 +00:00
Nico Vertriest
a7f2af0911 Replace MAC OS X with OS X
Task-number: QTBUG-46374
Change-Id: I7bc633ab551740bd328a24b0ccae1d534af47138
Reviewed-by: Martin Smith <martin.smith@digia.com>
2015-06-30 07:33:31 +00:00
Jani Heikkinen
83a5694dc2 Update copyright headers
Qt copyrights are now in The Qt Company, so we could update the source
code headers accordingly. In the same go we should also fix the links to
point to qt.io.

Outdated header.LGPL removed (use header.LGPL21 instead)

Old header.LGPL3 renamed to header.LGPL3-COMM to match actual licensing
combination. New header.LGPL-COMM taken in the use file which were
using old header.LGPL3 (src/plugins/platforms/android/extract.cpp)

Added new header.LGPL3 containing Commercial + LGPLv3 + GPLv2 license
combination

Change-Id: I6f49b819a8a20cc4f88b794a8f6726d975e8ffbe
Reviewed-by: Matti Paaso <matti.paaso@theqtcompany.com>
2015-02-11 06:49:51 +00:00
Daniel Molkentin
3430e7ce77 Add libproxy backend for QNetworkProxyFactory
It will be used on Unix systems if the required dev package is
present. (Detected by a configure compile test.)
You can configure with -no-libproxy to avoid the dependency.
It will not be used on OS X or Windows, as we already implement
the native API for getting proxies there.

Currently we use whatever PAC runner is provided by the distro
for running PAC scripts - if we want to run PAC scripts using
Qt, then we would have to implement a pacrunner plugin to libproxy.
Note that their webkit pacrunner is using javascriptcore already.

Tested using the libproxy 0.4.7 that is included in Ubuntu 12.04.
Re-tested using Ubuntu 14.04 which ships libproxy 0.4.11.

It works except when both socks and http proxies are configured in
the manual settings - in that case libproxy returns only the socks
proxy. This seems to be covered by libproxy issue 119.

[ChangeLog][QtNetwork] Introduce libproxy backend for Unix platforms,
enabled automatically if the required dev package is present

Task-number: QTBUG-26295
Change-Id: I521c0a198fcf482386ea8a189114a0077778265c
Reviewed-by: Richard J. Moore <rich@kde.org>
2015-02-05 14:29:03 +00:00
Matti Paaso
974c210835 Update license headers and add new license files
- Renamed LICENSE.LGPL to LICENSE.LGPLv21
- Added LICENSE.LGPLv3
- Removed LICENSE.GPL

Change-Id: Iec3406e3eb3f133be549092015cefe33d259a3f2
Reviewed-by: Iikka Eklund <iikka.eklund@digia.com>
2014-09-24 12:26:19 +02:00
Thiago Macieira
032f0f543e Fix building of the C++11 config.test on Windows with ICL
The Intel compiler does support C++11 options on the command-line.
configure.exe will correctly try to run it, but the test would fail for
incorrect reasons.

First, we need to pass the option -Qstd=c++11 to enable it.

Second, on Windows, the GCC experimental define isn't defined, nor is
__cplusplus updated yet. So we have to rely on the Intel-specific macro.

Third, we need CONFIG += console so that the application succeeds in
linking against a main() function, as opposed to a WinMain one.

Change-Id: I8f3252189df4f8854a9d9aa2cd919c288d2df420
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2014-06-27 08:28:01 +02:00
Thiago Macieira
ff6754fb8c Allow Clang to compile without libc++
Clang is perfectly able to deal with the libstdc++ headers. The
problem on Mac is that those headers are mightily old (from GCC 4.2),
so they are insufficient for C++11 support.

So make a more accurate test. This allows Clang to enable C++11 in the
presence of newer libstdc++ header (e.g., Clang on Linux or Clang on
FreeBSD).

Change-Id: I4f457ca82bf13feca0af78c9363cb6365bb3f68e
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
2013-09-09 23:04:48 +02:00
Tor Arne Vestbø
ba1aba61cc Disable app_bundle and lib_bundle when running configure tests
Just like configure.prf.

Change-Id: I760e0ca5bec41b3befb738a8a7a468e8f1a15946
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
2013-07-16 13:44:18 +02:00
Sergio Ahumada
48e0c4df23 Update copyright year in Digia's license headers
Change-Id: Ic804938fc352291d011800d21e549c10acac66fb
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
2013-01-18 09:07:35 +01:00
Iikka Eklund
be15856f61 Change copyrights from Nokia to Digia
Change copyrights and license headers from Nokia to Digia

Change-Id: If1cc974286d29fd01ec6c19dd4719a67f4c3f00e
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Reviewed-by: Sergio Ahumada <sergio.ahumada@digia.com>
2012-09-22 19:20:11 +02:00
Kai Koehne
f0e2c6fe1c Add c++11 option to configure.exe
Also check for c++11 support in configure.exe (which is also used by MinGW builds).
The c++11 check is therefore moved from 'unix' to 'common' directory.

Change-Id: I082848f032c2770e52e34f331b83820f395c06b6
Reviewed-by: Qt Doc Bot <qt_docbot@qt-project.org>
Reviewed-by: Yuchen Deng <loaden@gmail.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2012-09-13 16:47:27 +02:00
Thiago Macieira
b4525b3407 Add configure-time checking for the SSE and AVX features on Windows
Modify configure.exe to run some configure-time tests and check if
the SSE and AVX compiler features are supported.

The tests themselves required a bit of changes to compile with
MSVC. The include in sse4_2.cpp was wrong. And for whatever reason, it
didn't like the volatile variables, which GCC, Clang and ICC have been
happy with. This should produce no effect in compilation, though: even
dead code must be syntactically correct. We're not running the output.

Change-Id: Ibe5d0904a378a7efed853c7215f88a2ddcefb1b3
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
2012-06-12 17:34:52 +02:00
Thiago Macieira
f5a7d88378 Move the AVX and SSE tests to config.tests/common
This is the first step in supporting these checks on Windows.

Change-Id: I77cfd46bd733161ad2e52c2f76a6354b95ff737d
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
2012-06-12 04:29:44 +02:00