Sorry, let me be more specific: 1) there's a problem with the configure-time code that detects whether the compiler supports Neon intrinsics. Somehow, MeeGo managed to get a false positive here and configure decides that the compiler doesn't support Neon. This is not fixed.
2) there was a problem with the configure-time code that turned on the Neon intrinsics support. It did not support run-time detection: instead, if it figured that the compiler supported Neon intrinsics, it turned Neon everywhere by adding the "-mfpu=neon" option. At the same time, the code with Neon intrinsics was statically enabled, bypassing the runtime detection. This has been fixed. 3) qstring.cpp contains the only code in Qt that uses Neon intrinsics but does not check at runtime. It is enabled at compile-time if the compiler was launched with -mfpu=neon. There are two reasons for this: a) the complexity involved in supporting run-time detection for code such as qstring.cpp, as it requires creating a separate .cpp file, compiling it with different compiler options, etc. b) there's an associated runtime overhead with the checking of the variable and making the function call to the Neon-enabled code (which cannot be inlined, as it is in a separate .cpp) So we concluded that if you want to build Qt without Neon, you may as well live without the Neon optimisations for strings. -- You received this bug notification because you are a member of Kubuntu Bugs, which is subscribed to qt4-x11 in ubuntu. https://bugs.launchpad.net/bugs/664431 Title: QT on armel is built with NEON by default -- kubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/kubuntu-bugs
