This patch fixes the bug https://llvm.org/bugs/show_bug.cgi?id=24152
The float value resides in the first 4 bytes of ValueHandle for both mips and mipsel.
+release manager. The code owner (Richard Smith) doesn't seem to have a phabricator account so I'll add him to to the thread shortly.
I don't know the ubsan implementation so I'm unable to review it. However, I can confirm that this fixes both reported ubsan failures in my patched 3.7.0 release build.
Hans: Is this still a candidate for merging to the release branch? I'm not sure if you count it as a bug fix or finishing a feature.
Assuming it is still a candidate:
Richard: Ping. Is it ok to merge to 3.7.0?
This fix is incorrect, as is the original code. The problem is that the code is assuming that all big-endian targets have a 64-bit uptr type. The right fix would be to revert this change and change the big-endian code to something like:
internal_memcpy(&Value, (const char*)(&Val + 1) - 4, 4);
(That is, on BE systems, the value is in the last four bytes of Val, not the first four, no matter how wide or narrow the uptr type actually is.)
That makes sense to me. I'll sort out a patch but I won't be able to test it until the morning (UK time). My big-endian machine is refusing to respond to anything more than ping and I'm going to have to physically reset it when I get to work tomorrow.
One question though: Given that we only do 32-bit MIPS releases at the moment, is the current patch 'correct enough' for this release?