I've reserved the IDs for int128, uint128, bfloat16, and float128,
because the mask in qvariant.cpp's qIsNumericType() requires primitives
to be less than 64 to operate properly.
Added a QMetaType/QDataStream test to confirm it is indeed built-in.
Change-Id: I3d74c753055744deb8acfffd17247f7f57bada02
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
The C++ equivalent is std::float16_t, defined in P1467[1], and is coming
with GCC 13 both in native mode (for x86, using AVX512FP16) and in
emulated mode. The C and C++ types will be the same type (<stdfloat>
simply typedefs).
qfloat16 will need to remain a wrapper with an integer member to keep
ABI with previous Qt versions. Because it is a trivially-copyable small
type, it gets currently passed in registers; the presence of the integer
member means it gets passed in general-purpose registers, while a single
_Float16 member would be passed in a floating-point register. See:
https://gcc.godbolt.org/z/8fEendjff
[1] https://wg21.link/p1467
Change-Id: I8a5b6425b64a4e319b94fffd161be56397cb48e6
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
CMakeLists.txt and .cmake files of significant size
(more than 2 lines according to our check in tst_license.pl)
now have the copyright and license header.
Existing copyright statements remain intact
Task-number: QTBUG-88621
Change-Id: I3b98cdc55ead806ec81ce09af9271f9b95af97fa
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Replace the current license disclaimer in files by
a SPDX-License-Identifier.
Files that have to be modified by hand are modified.
License files are organized under LICENSES directory.
Task-number: QTBUG-67283
Change-Id: Id880c92784c40f3bbde861c0d93f58151c18b9f1
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
We don't support it any more. I don't think it has ever properly
compiled Qt 6 (and it's no longer working for me against GCC 12's
libstdc++ headers). If you report a bug against it, Intel support's
first question is if you can try instead the new Clang/LLVM-based oneAPI
C++ compiler.
So we support only that one, which identifies itself as Q_CC_CLANG.
Change-Id: I5ff8e16fcdcb4ffd9ab6fffd16eb57a092c8439e
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
- The newest GHS compiler versions set the value of has_signaling_NaN to False.
Add compilation and autotest fix for GHS-compiler 2021/2022 releases.
Task-number: QTBUG-99123
Pick-to: 6.2 6.3
Change-Id: I45e5da6759a15c60c17f896e565002cbba8524ed
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
- GHS compiler is not fully compliant with iec559. Therefore we need
to update is_iec559 checking for GHS case.
Pick-to: 6.2
Change-Id: Ia094509d26bf5f0109f2937547a056267019cffb
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Janne Koskinen <janne.p.koskinen@qt.io>
Analysis of problems with the new test for qFuzzyIsNull() revealed
that, where its version for double uses approximately 4500 * epsilon
and for float used 84 * epsilon as threshold, the qfloat16 version's
value was barely more than epsilon, with the result that the test had
to use a different value than the threshold to pass. (Converting the
threshold from float to qfloat16 and back made it bigger; in effect,
the threshold value was not <= itself.)
Furthermore, comparison with qFuzzyCompare() implied a value of
1/102.5 should be used, roughly 10 * epsilon, for consistency. When
1/102.5 is rounded to three significant digits (the precision we use
in QTest::toString(), for example), to give 0.00976f as threshold, we
get a value that, after conversion to qfloat16 and back to float, does
give a result <= what we started with. So change qFuzzyIsNull() and
its test to use this as qfloat16's threshold value.
[ChangeLog][QtCore][QFloat16] The qfloat16 threshold value for
qFuzzyIsNull() has changed from 1e-3 to 9.76e-3, almost a factor of
ten increase, for consistency with qFuzzyCompare()'s tolerance. Values
between these would previously have had qFuzzyIsNull(f) false despite
qFuzzyCompre(f, 1+f) being true.
Change-Id: I35816dce78da34a3e2339c8bc42d5bd03714a3f6
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Andreas Buhr <andreas.buhr@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
They were missing.
I also wanted to verify that it's true for sub-normal values.
At the same time, relocate qfloat16's implementation of qFuzzyIsNull()
to between those of qFuzzyCompare() and qIsNull(), since its apparent
absence initially confused me.
Change-Id: I9637c0070e754d16744c76fc9f846596257c6a63
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Remove the qmake project files for most of Qt.
Leave the qmake project files for examples, because we still test those
in the CI to ensure qmake does not regress.
Also leave the qmake project files for utils and other minor parts that
lack CMake project files.
Task-number: QTBUG-88742
Change-Id: I6cdf059e6204816f617f9624f3ea9822703f73cc
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Complete search and replace of QtTest and QtTest/QtTest with QTest, as
QtTest includes the whole module. Replace all such instances with
correct header includes. See Jira task for more discussion.
Fixes: QTBUG-88831
Change-Id: I981cfae18a1cabcabcabee376016b086d9d01f44
Pick-to: 6.0
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Modify special case locations to use the new API as well.
Clean up some stale .prev files that are not needed anymore.
Clean up some project files that are not used anymore.
Task-number: QTBUG-86815
Change-Id: I9947da921f98686023c6bb053dfcc101851276b5
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Calibrated to match F16C and ARM-FP16 hardware conversions.
Change-Id: I3bdd4d3db3046fee4aeb24e4ce8b9bc9a06e0397
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Our hardware optimized conversions of float to qfloat16 rounds to even
where our table based conversion truncated to zero.
The rounding is not in this patch exactly round to even like the
hardware implementation but much closer.
Change-Id: I4c5e72c15fef9079d3660680b2727ff7ba4e768a
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Infinite is only when the mantissa is 0, everything else is NaN.
std::isnormal returns false on zero.
Pick-to: 5.15
Change-Id: I897fc0dc3b8a9c557bb1922ea7ca8df501e91859
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Use pro2cmake with '--api-version 2' to force regenerate
projects to use the new prefixed qt_foo APIs.
Change-Id: I055c4837860319e93aaa6b09d646dda4fc2a4069
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
It is finite and normal; it classifies as a zero; and it should not be > qfloat16(0).
Added tests to match.
Change-Id: I7874fb54f622b4cdf28b0894050ad3e75cf5d77c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Its limits() test was rather large and had some overlap with an older
qNan() test, that needed some clean-up (it combined qfloat16 values
with double and float values in ways that caused qfloat16 to be
promoted to another type, so we weren't testing qfloat16).
Renamed the qNan() test to qNaN(), separated out the parts of it that
actually tested infinity. Moved various parts of limits() to these and
rationalised the result. Split out a properties() test from limits()
for the properties of the qfloat16 type that are supplied by its
numeric_limits. Split out a data-driven finite() test to cover some
repeated code that was in limits() and extended it to test more
values. Added more tests of isNormal().
Fixed my earlier UK-ish spelling of "optimise", in the process, and
identify the processor rather than the virtualization as the context
where the compiler errs.
Change-Id: I8133da6fb7995ee20e5802c6357d611c8c0cba73
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It's not clear why this test fails - and only does so sometimes - but
fail it does, so we ned to skip it to let development keep going. As
it happens, the same platform over-optimizes various computations
using qfloat16; which can at least be used to test for this platform,
since it wrongly distinguishes two qfloat16 values that theory and all
other platfomrs agree should coincide.
Fixes: QTBUG-75812
Change-Id: Ie9463d7dc21bca679337b475d13417b9f42bbf9b
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
It should have been qfloat16(1)/qfloat16(infinity) in any case.
Sadly, that behaves no better than qfloat16(1.f/qfloat16(infinity)),
which was promoting the infinity back to float. So retain the check
for over-optimization (but make the comment more accurate).
This is a follow-up to d441f6bba7.
Change-Id: Iec4afe4b04081b0ebfbf98058da606dc3ade07f4
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
In QCOMPARE, handle NaNs and infinities the way tests want them
handled, rather than by strict IEEE rules. In particular, if a test
expects NaN, this lets it treat that just like any other expected
value, despite NaN != NaN as float16 values. Likewise, format
infinities and NaNs specially in toString() so that they're reported
consistently.
Enable the qfloat16 tests that depend on this QCOMPARE() behavior.
Refise the testlib selftest's float test to test qfloat16 the same way
it tests float and double (and format the test the same way).
This is a follow-up to 37f617c405.
Change-Id: I433256a09b1657e6725d68d07c5f80d805bf586a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This extends support for qfloat16 sufficiently for the things testlib
needs in order to treat it as a first-class citizen. Extended tests
for qfloat to check qFpClassify() on it.
Change-Id: I906292afaf51cd9c94ba384ff5aaa855edd56da1
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This shall make it more nearly a first-class numeric type; in
particular, I need some of these for testlib's comparing and
formatting of float16 to handle NaNs and infinities sensibly.
Change-Id: Ic894dd0eb3e05653cd7645ab496463e7a884dff8
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Both ARM and x86 can convert fp16 much faster in bulk than one at a
time. This also enables hardware accelerated conversion on x86, when
F16C isn't unconditionally available at compile time.
This code is implemented in C to ensure that there's no leakage of
inline symbols from the .obj file that was compiled by Visual Studio
with AVX support. Unfortunately, simd.prf uses $(CXX) instead of $(CC)
for all its sources, which means the file gets interpreted as C++ by
g++, clang++ and icpc. Those compilers at least don't leak any symbols.
Done-with: Thiago Macieira <thiago.macieira@intel.com>
Change-Id: I9d26d99e83392861fb09564e0e8e8d76cd8483b3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The operator double() and operator long double() members of qfloat16
are causing cast ambiguities. This removes them, leaving only
operator float() which seems to be adequate.
Also, additional arithmetic operator tests were added which without
this removal fail to compile.
Change-Id: Id52a101b318fd754969b3de13c1e528d0aac2387
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This constitutes a fairly complete submission of an entirely new
floating point type which conforms to IEEE 754 as a 16-bit storage
class. Conversion between qfloat16 and float is currently performed
through a sequence of lookup tables. Global-level functions
qRound(), qRound64(), qFuzzyCompare(), qFuzzyIsNull(), and
qIsNull() each with a qfloat16 parameter have been included
for completeness.
[ChangeLog][QtCore] Added new qfloat16 class.
Change-Id: Ia52eb27846965c14f8140c00faf5ba33c9443976
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
