Sorry for the late report but I’ve only just found these issues. Llvm.org isn’t working for me at the moment but I’ll file tickets once it is.
The issues are:
Almabench has some significant numerical differences and fails the reference check for some configs. I’m investigating this one at the moment but early indications are that it’s a similar (but different) problem to the one we had in LLVM 3.6.2.
Read-only exception tables have broken compatibility with the ~2 year old gcc toolchains I was using for release testing cross compilation. This isn’t a problem for most test-suite runs since we can just update the assembler but is causing trouble for microMIPS. More recent toolchains lack the microMIPS multilib I was using and migrating to the new one is causing link failures. These failures are related to ELF header bits specifying the SNaN/QNaN encodings to be IEEE754-1985 or IEEE754-2008 compliant. I suspect the –mnan=2008 isn’t reaching the assembler.
Clang is incompatible with changes to the mips-mti-linux-gnu sysroot from Imagination’s mips-mti-linux-gnu toolchain. Libaries are still multilib’d (albeit with a reduced set) but some of the include paths aren’t anymore. It’s also no longer correct to include sysroot/include (this path is added by common code) since this skips some function definitions. Instead, we must only include sysroot/usr/include like GCC does. There may be more details but so far the fix doesn’t look simple. As far as I can tell, clang’s multilib expects includes and libraries to have the same layout (osSuffix() seems to control both). The good news is that it’s not a regression since we can use toolchains from before this layout change.
Leading Software Design Engineer, MIPS Processor IP
Imagination Technologies Limited