The Intel whitepaer[1] recommends using the RDSEED over RDRAND whenever
present. libstdc++ from GCC 10 will also use it in std::random_device.
[ChangeLog][QtCore][QRandomGenerator] The system() random generator will
now use the RDSEED instruction on x86 processors whenever available as
the first source of random data. It will fall back to RDRAND and then to
the system functions, in that order.
[1] https://software.intel.com/en-us/articles/intel-digital-random-number-generator-drng-software-implementation-guide
Change-Id: I907a43cd9a714da288a2fffd15bab176e54e1975
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Multi arch build in one go is need to support the new .aab packaging format.
By default the users apps are built for all Android ABIs: arm64-v8a armeabi-v7a x86_64 x86
The user can pass ANDROID_ABIS to qmake to filter the ABIs during development,
e.g. qmake ANDROID_ABIS="arm64-v8a armeabi-v7a" will build only for arm ABIs.
[ChangeLog][Android] Android multi arch build in one go,
needed to support the new .aab packaging format.
Change-Id: I3a64caf9621c2a195863976a62a57cdf47e6e3b5
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
If the host architecture is different from -platform (canadian cross
build with -external-hostbindir) then we cannot use QMAKE_HOST.os to
deduce the executable extension for that platform, because this value
comes from the qmake binary that was pointed to by
-external-hostbindir.
Move the target name deduction mechanism to the actual configure test
.pro files to make sure the right scopes are available, and write the
deduced target name to a text file. That text file is read by
qtConfTest_architecture to get the right binary to analyze.
Fixes: QTBUG-77286
Change-Id: I68b844dd51dbfda6432a4b0dca6331899c82255f
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Android is also unix, so can pick up the host 'arch' binary when
rerunning configure. This patch splits the names so we don't end up
confusing target and host binaries.
Task-number: QTBUG-76445
Change-Id: Ib65251a514e45ad8873f523d71c17e13e56ea58a
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
GCC for 64-bit Windows has a bug that it fails to properly re-align the
stack pointer for use with 256-bit memory addresses (AVX). Therefore,
there's about a 50/50 chance that any function using AVX will have an
improperly-aligned stack. In release mode, stack accesses should be
rare, but in debug mode they happen frequently. Either way, this is a
ticking time bomb, so we disable.
Clang is not affected.
32-bit MinGW is not affected.
64-bit in other OSes with GCC are not affected.
Fixes: QTBUG-73539
Change-Id: Id061f35c088044b69a15fffd1580967808f31671
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
use library objects for all variants, and inline the tests.
Change-Id: I029f9a6655a783dab4a22abf601aadbb484c03af
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
... and use that to inline the xlocalescanprint test.
Change-Id: I0973133d7f9ecc9a38b70dc4b83df174a35b2b1f
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
these were new on dev while the original migration happened on 5.9, or
came from new changes which hadn't adapted yet.
Change-Id: I5e48437061a97e6df6e93881c98471455e177631
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Some Linux distributions patch OpenSSL's soname, making builds
on such distributions not deployable elsewhere. The problem is that
the code loading OpenSSL symbols would attempt to use the soname
of the build machine, and therefore not finding the OpenSSL
libraries on the deploy system.
The binary builds of Qt for Linux are affected by this problem,
as they build under RHEL7.4 which changes to soname of OpenSSL to
a non-standard string. This makes the binary builds not pick up
OpenSSL 1.0 from the machine where the build gets installed on.
Given that in the pre-1.1 versions only the 1.0 series is supported,
bump the minimum requirement of Qt to that. The 1.0.x releases
(up to 1.0.2, at the time of this writing) have kept binary
compatibility, and advertise a soname of "1.0.0", which is used
by most distributions.
So, if loading of OpenSSL with the build-time soname fails,
try to load them with the "1.0.0" hardcoded soname.
[ChangeLog][QtNetwork][SSL] OpenSSL >= 1.0 is now required to build
Qt with OpenSSL support.
Task-number: QTBUG-68156
Change-Id: Ieff1561a3c1d278b511f09fef06580f034f188c6
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
_mm512_mask_cvtepi32_storeu_epi8 is VPMOVDB (convert from 32-bit to 8-bit
with truncation) where the destination is a memory address, with an
OpMask register used to indicate which of the lanes in the vector to
store. Similarly, _mm512_mask_cvtepi16_storeu_epi8 is VPMOVWB (convert
from 16-bit o 8-bit), which is useful for UTF-16 to Latin1 conversion.
Change-Id: I8f261579aad648fdb4f0fffd15542ea306841ce6
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
"AVX512MIC" (Many Integrated Cores) is the set of AVX-512 features found
on the Intel Xeon Phi coprocessors (codename "Knights Landing"), which
is an unlikely architecture for Qt to run on.
The two profiles with VL came from study of early GCC code and are no
longer applicable. GCC source code now shows both VBMI and IFMA as part
of the -march=cannonlake feature set.
Change-Id: Iff4151c519c144d580c4fffd153a0f268919fe2c
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
This adds detection for: VAES, GFNI, AVX512VBMI2, AVX512VNNI,
AVX512BITALG, AVX512VPOPCNTDQ, AVX512_4NNIW, AVX512_4FMAPS. These
features were found in the "Intel® Architecture Instruction Set
Extensions and Future Features" manual, revision 30. This commit also
adds support for RDPID (already in the main manual) and the Control-flow
Enforcement Technology, which appears in a separate Intel paper.
This new support was done by adding a new generator script so we don't
have to maintain two tables in sync, one in qsimd.cpp with the feature
names, and the other in qsimd_p.h.
Since we now need a lot more bits, it's no longer worth keeping the two
halves of the qt_cpu_features variable mostly similar to the main two
CPUID results. This commit goes back to keeping things in order, like we
used to prior to commit 6a8251a89b (Qt 5.6)
At the time of this commit, GCC 8 has macros for AVX512VPOPCNTDQ,
AVX512_4NNIW, AVX512_4FMAPS, AVX512VBMI2 and GFNI.
Change-Id: I938b024e38bf4aac9154fffd14f7afae50faaa96
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
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>
This has two main benefits:
1) introduces a qmake CONFIG we can use in .pro/.pri/.prf files
2) removes the need to keep an up-to-date list of which compilers
support the feature
The test is implemented as trying to compile every single SIMD test we
currently have, but without passing the -mXXX option. The reason for
trying all of them is that some people may have modified their mkspecs
to add -mXXX options or -march=XXX, which could enable the particular
feature we tried, resulting in a false positive outcome.
Change-Id: I938b024e38bf4aac9154fffd14f7784dc8d1f020
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
It seems the compiler supports /arch:AVX512 and /arch:AVX512F but none
of the other switches (and neither are documented). And when you pass
those, you also get Conflict Detection (CD), Double & Quad (DQ), Byte &
Word (BW) and Vector Length (VL), which matches the ICC switch
"-xCORE-AVX512". Unlike ICC, there doesn't seem to be an option to
enable only the common part of AVX-512.
Support for Intel Xeon Phi's current features (Exponential &
Reciprocation and Prefetch) and future ones (IFMA, VBMI, 4FMAPS, 4VNNI
and VPOPCNTDQ) seems to be missing altogether.
See https://blogs.msdn.microsoft.com/vcblog/2017/07/11/microsoft-visual-studio-2017-supports-intel-avx-512/
Change-Id: I98105cd9616b8097957db680d73eb1f86e487e6d
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Convert QSysInfo/QOperatingSystemVersion to __builtin_available where
required or possible, or to QOperatingSystemVersion where
__builtin_available cannot be used and is not needed (such as negated
conditions, which are not supported by that construct).
Change-Id: I83c0e7e777605b99ff4d24598bfcccf22126fdda
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The use as in the code:
futimesat(fd, NULL, &tv)
is not documented to work. The file descriptor should be a directory's
one, not an open file (though the Linux source code seems to handle that
case). This call was done as a fallback to futimes, so it's very
unlikely a system would have futimesat and not futimes.
Both the Linux and the FreeBSD man pages say it's deprecated anyway.
Change-Id: I8d96dea9955d4c749b99fffd14cd94068dc7668a
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Availability of D3D11_QUERY_DATA_TIMESTAMP_DISJOINT depends on the used
MinGW version so that the check for MINGW is not sufficient. The newly
added configure test can be used for every toolset.
Task-number: QTBUG-57916
Change-Id: Ia9cb48f3e673841101a93cbc8ea23aff9547f639
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@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>
testing the non-xkb xcb parts is unnecessary, as we already did that
separately.
Change-Id: I452cc746315117a0169f0e0c764fe7e0229437e9
Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
just use 'which' and be done with it. the script was rather arcane, and
worked around deficiencies of cygwin (no longer relevant) and solaris
(assumed to be somewhat sane meanwhile).
Change-Id: I2e11ea3c87ac06a85604ac8d58d8fee95eae2e15
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
remove useless define and ifdef/error, and check for a more appropriate
function.
Change-Id: I1a1622cc157c49ebb6787068ade7b33e45e228ca
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
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>
- #error hack for MIPSpro compiler from unix/clock-*
- irix exclusions from unix/*iconv
- hpux defines from unix/{getifaddrs,ipv6ifname} (the obsolete
hpuxi-g++-64 spec would add them automatically anyway)
Change-Id: Ib227e5626c0e8c8f6faebf76c312d77955f80b92
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>
in the gles tests, use #ifdef __APPLE__ directly instead of defining
BUILD_ON_MAC. this is consistent with the desktop gl test, less magic,
and corresponds with the later usage (which does #ifdef Q_OS_MAC).
amends f3d82a89.
in the desktop gl test, clean out the dead Q_OS_MAC define from the
project file (added in 45dc5852 concurrently to the more direct fix in
864815ef).
Change-Id: Ieebad3c7e87218b887f61485c331b93eadfcf406
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
It's a Linux-specific call that was added to the kernel in pre
historical times (before Git). Sqlite3 uses mremap(2) but it has its own
checking. Nothing else in Qt uses this.
Looks like the last user was the QPF font engine, removed in commit
d7e424ee66 almost four years ago. And
that's considering that the QPF font engine wasn't in use since Qt 5.0
because QWS was no more...
Change-Id: Idaa189413f404cffb1eafffd14ceee7488514c1d
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
This patch-set implements a new QSslSocket backend based on OpenSSL 1.1.
1. General.
The code in this patch was organized to achieve these (somewhat contradicting)
objectives:
- keep the new code free of #if-ery, as far as possible;
- make it easy to clean away dead code when we're eventually able to retire
out-dated OpenSSL versions;
- reduce the amount of code duplication.
If changes in some file/component were insignificant (~5 one-liners per file),
we still use pp-checks like: #if QT_CONFIG(opensslv11) ... #else ... #endif -
the logic is simple and it's still easy to clean the code if we remove the legacy
back-end. Where it saved #if-ery, we also introduced 'forward-compatible'
macros implementing equivalents of 1.1 functions using older OpenSSL.
In case some class contains a lot of version-specific ifdefs (particularly where
nested #if-ery was complex) we choose to split code into: "pre11" h/cpp files,
"shared" h/cpp files (they preserve their original names, e.g qsslsocket_openssl.cpp)
and "11" h/cpp files. If in future we remove the legacy back-end, "pre11" should be
removed; "shared" and "11" parts - merged.
2. Configuration.
We introduced a new feature 'opensslv11' which complements the pre-existing
'openssl' and 'openssl-linked' features. The 'opensslv11' feature is enabled
by a simple test which either compiles successfully or ends in a compilation
error, depending on a value of the OPENSSL_VERSION_NUMBER constant. If the
feature was enabled, we also append an additional compilation flag
-DOPENSSL_API_COMPAT=0x10100000L to make sure our new code does not contain
deprecated structures, function calls, macro-invocations from OpenSSL < 1.1.
Change-Id: I2064efbe9685def5d2bb2233a66f7581954fb74a
Reviewed-by: André Klitzing <aklitzing@gmail.com>
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
The getentropy function, first found in OpenBSD, is present in glibc
since version 2.25 and Bionic since Android 6.0 and NDK r11. It uses the
Linux 3.17 getrandom system call. Unlike glibc's getrandom() wrapper,
the glibc implementation of getentropy() function is not a POSIX thread
cancellation point, so we prefer to use that even though we have to
break the reading into 256-byte blocks.
The big advantage is that these functions work even in the absence of a
/dev/urandom device node, in addition to a few cycles shaved off by not
having to open a file descriptor and close it at exit. What's more, the
glibc implementation blocks until entropy is available on early boot, so
we don't have to worry about a failure mode. The Bionic implementation
will fall back by itself to /dev/urandom and, failing that, gathering
entropy from elsewhere in the system in a way it cannot fail either.
uClibc has a wrapper to getrandom(2) but no getentropy(3). MUSL has
neither.
Change-Id: Ia53158e207a94bf49489fffd14c8cee1b968a619
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Follow the usual pattern:
Add a config test and automatic include of GLES3/gl32.h if there
is a GLES 3.2 capable header+lib at build time.
Then, regardless of this being enabled, expose all new 3.2 API
functions in QOpenGLExtraFunctions and resolve them dynamically
at run time.
This way 3.2 functions will be available when deployed to a 3.2
capable system (or OpenGL 3/4.x with the functions in question
available) regardless of what was present in the sysroot at build
time.
Change-Id: Ia52551f3178591e1e56ceac8e45d89c6b13f4927
Reviewed-by: Sean Harmer <sean.harmer@kdab.com>
GCC didn't support it until version 5 or 6, so add configure tests for
both <random> and <sys/auxv.h>. Normally I'd say "upgrade", but this is
too low-level and important a feature.
There's a good chance that all our supported compilers have <random>
anyway. As for <sys/auxv.h>, it's present on Glibc, Bionic and MUSL, but
I don't see it in uClibc (AT_RANDOM is a Linux-specific feature).
Change-Id: Ia3e896da908f42939148fffd14c5b2af491f7a77
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
This was originally enabled in the mkspecs for 64-bit QNX 7.0.0
but that broke when the qtConfig change was made. It looks like
qtConfig shouldn't be used in the platform mkspecs. I suspect
the stack-protector changes were left out of the 32-bit mkspecs
so that 6.6.0 builds wouldn't be affected.
Ignore the stack-protector/stack-protector-all possibility since
it isn't possible to access it without a command line option.
Specifying both options doesn't even make sense since
stack-protector-all encompasses stack-protector.
For now, leave out command line control of this feature.
Task-number: QTBUG-59644
Change-Id: I99323216be5b592dd2c3bef6d22da195764a6e65
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
