On 20-Jul-16 16:19, Julius Werner wrote:
Well... honestly, isn't it our fault for uprevving
to a buggy
toolchain? If there was a way to write this code such that it will
result in the binary output ARM wants and works on all versions,
submitting a patch to them would be reasonable... but otherwise I can
kinda understand that they don't want to use an inferior solution
because we insist on using an assembler that doesn't know how to
assemble stuff correctly. Isn't the best solution to only uprev archs
that really need new compiler features until the GCC guys manage to
produce a stable version?
Yes, I was wrong. After reading the other threads and talking with
Martin, it indeed seems to be a toolchain issue.
However, the new toolchain had many advantages over the previous one,
and the code was not in (our) ARM TF at the time we uprevved.
The maintenance burden of keeping different versions of toolchains
supported for different architectures as part of the reference toolchain
is imho almost always significantly higher than actually fixing the
issues. (Especially if they are not time critical)
Martin produced a binutils fix for the issue. Whether the binutils
people will find it to be the "right" fix is still to be found out, but
it seems to allow compiling the latest, unmodified ARM TF.