If one doesn't set CONFIG+=neon in it's mkspec but the compiler enables
it, Qt fails during linking of libQtGui,
because simd.prf isn't executed as needed (doesn't run into neon{..}).
Although a mkspec which enabled neon (-mfpu=neon) without CONFIG+=neon
could be considered broken,
it's still simpler to just 'fix' Qt to not fail unexpected.
Follow-up to e5066a3a2e
Task-number: QTBUG-37264
Change-Id: I3aa0afbe430547971e76c2c988697c133d69796b
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
ICC 8 and 9 are positively ancient. I doubt anyone is using them for
Qt, let alone Qt 5. ICC 11 through 13 haven't supported OS X.
ICC now masquerades as Clang, so we need to let qmake and
qcompilerdetection.h know about it.
Change-Id: If0d2bd8b6a4a45250c15c9472c062effc76f17de
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
http://msdn.microsoft.com/en-us/library/b0084kay(v=vs.120).aspx says:
__AVX__ Defined when /arch:AVX is specified.
Now we know what flag it is, we don't need to use our _M_AVX flag
anymore. We're also now assuming that Microsoft will follow the same
pattern for AVX2 (i.e., __AVX2__), so this commit also removes the
check for _M_AVX2.
The other defines that were defined alongside AVX2 are removed because
they have no use currently in Qt.
Change-Id: I64a026b2206dbd0d2dffa7c803bee969c9b94a94
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Changed MIPS DSP portion of the mkspecs/features/simd.prf file in order
to fix the corrupted build system for MIPS platforms.
List of the additionally optimized functions
from file src/gui/painting/qdrawhelper.cpp:
- qt_blend_rgb16_on_rgb16
- qt_fetchUntransformed_888
- qt_fetchUntransformed_444
- qt_fetchUntransformed_argb8565
from file src/gui/image/qimage.cpp:
- convert_ARGB_to_ARGB_PM_inplace
from file src/corelib/qstring.cpp:
- ucstrncmp
- toLatin1_helper
- fromLatin1_helper
Change-Id: I5c47a69784917eee29a8dbd2718828a390b27c93
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Various global changes, primarily preprocessor flow, to support the
WinRT platform.
Change-Id: I3fa9cf91d5fb24019362e88fcf205e31b4f810b5
Reviewed-by: Andrew Knight <andrew.knight@digia.com>
This reverts commit 1ef74a763a, as
assembler files in SOURCES break compiling with -pch, as we don't create
a respective PCH.
instead, compile assembler code with QMAKE_CC, not QMAKE_CXX.
the reason why this change is needed in the first place is not clear to
me, but i guess that CXX defines some c++-related macros when
preprocessing the file, which breaks further down the line. this is
counter-intuitive, as the g++ frontend should treat the same sources the
same way as the gcc frontend (differences should be limited the the ld
invocation).
Task-number: QTBUG-29765
Change-Id: Ic0116b3a5fa621f12ac41cadf3062ff00b538e85
Reviewed-by: Rafael Roquetto <rafael.roquetto@kdab.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
For now there's only one architecture per host/target, but
this will change once we start detecting the CPU features
for both device and simulator on iOS.
For convenience we set QT_CPU_FEATURES to the resolved
value of the current architecture, so that simd.prf still
can use QT_CPU_FEATURES directly.
Change-Id: I28e8b339a5c30a630e276165254dba09a3da6940
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
This guarantees that qmake gives them the proper flags (non C++) while
building these asm files.
Change-Id: I41150f543b8fac81bcd0da963b4d0e0a19b9db2f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
So you can get AVX/NEON etc source compiled by assigning to the
corresponding variable (e.g. AVX_SOURCES).
This was previously used in just the gui module, but other
external modules might like it too.
Change-Id: I51aa64760c469c7dc4c71e6f089c2ddef4f509c5
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
