Since the x86_simd/main.cpp file already has all the source for each and
every test anyway, just reuse it.
Change-Id: I938b024e38bf4aac9154fffd14f779f450827fb9
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
only few tests remain, and many of these were mis-classified anyway.
Change-Id: Ic3bc96928a0c79fe77b9ec10e6508d4822f18df2
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
We're adding a lot of unnecessary files that end up later as cargo-cult,
for at most a handful of lines. So instead move the testcases directly
into the .json file.
The following sources were not inlined, because multiple tests share
them, and the inlining infra does not support that (yet):
- avx512
- openssl
- gnu-libiconv/sun-libiconv (there is also a command line option to
select the exact variant, which makes it hard/impossible to properly
coalesce the library sources)
The following sources were not inlined because of "complications":
- verifyspec contains a lengthy function in the project file
- stl contains lots of code in the source file
- xlocalescanprint includes a private header from the source tree via a
relative path, which we can't do, as the test's physical location is
variable.
- corewlan uses objective c++, which the inline system doesn't support
reduce_relocs and reduce_exports now create libraries with main(), which
is weird enough, but doesn't hurt.
Done-with: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Change-Id: Ic3a088f9f08a4fd7ae91fffd14ce8a262021cca0
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
these would be caught by the central verifyspec test, if we even got
that far.
Change-Id: I3eda80c4614b94f869d907f0a40166f4914ea692
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
amends b4525b3407, which gives no indication for why this was done.
judging by other tests, it wasn't cargo-culted. i presume it was just
about disabling debug-and-release, and the debug choice was arbitrary.
the central system nowadays does the same, just that it uses release.
amends 1533bfc5fc, which certainly _was_ cargo-culted from the former.
as a side effect, this removes some other CONFIG manipulations which are
handled centrally or are wholly ineffective nowadays.
Change-Id: Ib9af2837925a2f19af05506e798a26d363635735
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The instruction is "RDRAND", but the feature name, according to GCC, is
RDRND, so I had to change some macros in qsimd_p.h.
Change-Id: Icd0e0d4b27cb4e5eb892fffd14b5166779137e63
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
With this setup clang cannot use c++1z yet.
Fixed with clang 5.0.
In file included from /data/sources/qt/qt5/qtbase/src/corelib/codecs/qtextcodec.cpp:53:
In file included from ../../../include/QtCore/5.9.1/QtCore/private/qcoreglobaldata_p.h:1:
In file included from ../../../include/QtCore/5.9.1/QtCore/private/../../../../../../../../../sources/qt/qt5/qtbase/src/corelib/kernel/qcoreglobaldata_p.h:55:
In file included from ../../../include/QtCore/qmap.h:1:
In file included from ../../../include/QtCore/../../../../../../sources/qt/qt5/qtbase/src/corelib/tools/qmap.h:52:
In file included from /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../include/c++/7.1.1/map:60:
In file included from /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../include/c++/7.1.1/bits/stl_tree.h:72:
In file included from /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../include/c++/7.1.1/bits/node_handle.h:39:
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../include/c++/7.1.1/optional:1032:27: error: use of class template 'optional' requires template arguments
Change-Id: Ib4cd8a9f5791a6e6cae4e6d61dfec3ad50dd63ab
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
We can't depend on QT_HAS_INCLUDE for such an important functionality in
QtQml, so detect at configure time.
alloca() is not a POSIX function (it apparently first appeared in
Version 32V AT&T UNIX), so the actual header that defines it varies from
system to system. Clearly, if alloca.h exists, that's the one, so we try
it first. On most other systems that don't define it, it's in stdlib.h.
The only exception is Windows, where it's actually defined in malloc.h.
Task-number: QTBUG-59700
Started-by: Thiago Macieira <thiago.macieira@intel.com>
Change-Id: Icd0e0d4b27cb4e5eb892fffd14b4b2b389a4684e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
MSVC, Apple's Clang and Clang prior to 3.9 do not recognize _cvtss_sh
and _cvtsh_ss. So expand the operation to use directly the packed
intrinsics.
Change-Id: I27b55fdf514247549455fffd14b2046fd638593d
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Test failed on QNX 7, even though alloca is available. On QNX7,
it's a macro that expands to a line with NULL, but without define
for it.
alloca.cpp:44:5: error: 'NULL' was not declared in this scope
Task-number: QTBUG-59700
Change-Id: I3631d139990020a3adbab8b72e49929b6e721e80
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
The configure-time detection (cxx11default) isn't enough if the compiler
can be changed. This is especially necessary if Qt is compiled with a
compiler that defaults to >= C++11 (e.g., GCC 6) and then the user
selects a compiler another compiler (e.g., Clang) via -spec option. In
that case, we'd miss adding the -std=c++11 or -std=gnu++11 option to the
command-line, causing the compilation to fail.
As a nice side-effect, even moc without moc_predefs.h will now get the
__cplusplus setting.
Task-number: QTBUG-58321
Change-Id: I74966ed02f674a7295f8fffd14a8be35da9640e1
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
The AES instructions were first introduced with the Westmere shrink
(22nm) of the Nehalem architecture. The SHA instructions are still
pending on Intel architecture, but is available on AMD family 17h (gcc
argument -march=znver1).
Both features operate on SSE registers, so that's why the MSVC command-
line argument is the SSE2 one and the configure-time tests depend on
features.sse2.
The qmake feature names end in "ni" because "aes" and "sha" are too
simple and could clash with other uses. The QT_COMPILER_SUPPORTS_ macro
doesn't have the "NI" suffix because it has to match the GCC/Clang
predefined macro.
Change-Id: I445bb15619f6401494e8fffd149dbd1f862ff51c
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Use F16C or ARM FP16 if available at compile time.
Configure check added because older clang compilers have F16C defines
and flags but not all the intrinsics.
Change-Id: I71f358b8fd003e70ab8fcf35097414591e485112
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Alloca() is not supported on all platforms, like
INTEGRITY on ARM, so adding a configure check for it.
This can be used when building QtQml and 3rd party
code, in particular PCRE2 and SQLite.
Change-Id: I9785e16c21f67d1a68fef567e18c3356170f027e
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
instead of letting the specs validate themselves on each call, let them
only define a callback for use by the verifyspec configure test. this
is somewhat faster, and allows them to be loaded before qdevice.pri is
populated.
Change-Id: I2b60d006b33bbf42c28949f10ad429520ed32f46
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
this is much more intuitive, and actually produces a sensible result
with configure -recheck after a compiler upgrade.
Change-Id: Icfa0b85377d9fc014e66490c8ebf6c9236df978e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
cleaner, and covers windows as well.
Change-Id: I0e884909a3f49610fab750ba1ef6112f43e5d5d1
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
so far, each library was distributed over a test and (optionally) a
'library' output of a feature. this was conceptually messy and limiting.
so instead, turn libraries into a category of their own.
libraries now support multiple properly separated sources, which makes
overriding them a lot saner. sources can be conditional to accommodate
platform differences.
as an immediate consequence, move (almost) all library references from
the config test projects to the json file.
a few tests were excluded, because they are doing somewhat magic things
that should not be handled in this bulk change:
- freetype: .pri file shared with actual source code
- clock-gettime: -lrt is conditional, and there is a .pri file which is
shared with actual source code
- ipc_posix: -lrt & -lpthread conditional
- iconv: -liconv conditional
the multi-source mechanism is used to make a variety of tests work on
windows, where the library name differs from unix (and sometimes between
build configurations). some tests still needed minor adjustments to
actually work.
on the way, fix up disagreements between manually specified libraries
and pkg-config lines (affecting several xcb-related tests).
Change-Id: Ic8c58556fa0cf8f981d386b13ea34b4431b127c5
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
it's bound to the bourne shell, which is not readily available on
windows hosts.
on the way, the pch, fvisibility, and bsymbolic_functions tests were
rewritten as regular compile tests. they now just verify that qmake's
built-in support for the tested features actually works.
Change-Id: Ibac246f21b5ececa40da3f576dc789982eaf9fdf
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Conflicts:
configure
5.7 now supports clang on android; but dev re-worked configure
src/gui/kernel/qevent.h
One side renamed a parameter of a constructor; the other added an
alternate constructor on the next line. Applied the rename to both
for consistency.
tests/auto/tools/moc/tst_moc.cpp
Each side added a new test at the end.
.qmake.conf
Ignored 5.7's change to MODULE_VERSION.
configure.json
No conflict noticed by git; but changes in 5.7 were needed for the
re-worked configure to accommodate 5.7's stricter handling of C++11.
Change-Id: I9cda53836a32d7bf83828212c7ea00b1de3e09d2
it positively makes no sense to have a configure test which will be
never reached due to the configure/qmake bootstrap failing with a
slew of totally unhelpful error messages.
pre-standardization partial c++11 implementations are now rejected,
except for VS2013, which is still sufficient despite not announcing full
compatibility.
Change-Id: I58af10e03960af06b80cedac105cf8433f7a1745
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Change d1b09dba45 removed the
support to detect the C++ version the compiler used by
default. In essence, it forced the compiler in C++11 mode,
if the default was still C++98.
This change reimplements the functionality in the new
configuration system.
Change-Id: Ib4bf7ade85288776f9ae2a870f19764df727e0a5
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
And ask the user to apply one of the patches we're carrying to their
Standard Libraries.
Change-Id: I7e6338336dd6468ead24ffff141139c79056922e
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
This test was the old way of checking whether to enable
c++11 functionality. That is now anyway required, so there
is no need for this test anymore.
Change-Id: I083e85a4698cac6bd9b573525c7b977f63e14113
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
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>
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>
That implies we need to differentiate between a variable set but empty
and an empty variable. GCC, Clang and the Intel compiler accept -msse2
on 64-bit builds without warning (they also accept -mno-sse2), but the
Microsoft compiler does not have that option.
Change-Id: I54233388ba10994996ae3e749fd829085e8fd7b7
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
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>
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>
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>
[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>
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>
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>
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>
