| Name |
Last commit
|
Last update |
|---|---|---|
| bloat | ||
| crosstest | ||
| pydir | ||
| runtime | ||
| src | ||
| tests_lit | ||
| unittest | ||
| .gitignore | ||
| ALLOCATION.rst | ||
| CMakeLists.txt | ||
| LICENSE.TXT | ||
| LOWERING.rst | ||
| Makefile | ||
| Makefile.standalone | ||
| OWNERS | ||
| README.rst | ||
| codereview.settings |
This fixes a regression likely introduced in d2cb4361 . The problem is that by using the default std::unordered_map comparison predicate std::equal_to, we get incorrect behavior when the key is float or double: 1. 0.0 and -0.0 appear equal, so they share a constant pool entry even though the bit patterns are different. This is a correctness bug. 2. Each instance of NaN gets a separate constant pool entry, because NaN != NaN by C equality rules. This is a performance bug. (This problem doesn't show up with the native bitcode reader, because constants are already unique-ified in the PNaCl bitcode file.) The solution is to use memcmp for floating-point key types. Also, the abi-atomics.ll test is disabled for the MINIMAL build, to fix an oversight from a previous CL. BUG= none R=jfb@chromium.org Review URL: https://codereview.chromium.org/1019233002
| Name |
Last commit
|
Last update |
|---|---|---|
| bloat | Loading commit data... | |
| crosstest | Loading commit data... | |
| pydir | Loading commit data... | |
| runtime | Loading commit data... | |
| src | Loading commit data... | |
| tests_lit | Loading commit data... | |
| unittest | Loading commit data... | |
| .gitignore | Loading commit data... | |
| ALLOCATION.rst | Loading commit data... | |
| CMakeLists.txt | Loading commit data... | |
| LICENSE.TXT | Loading commit data... | |
| LOWERING.rst | Loading commit data... | |
| Makefile | Loading commit data... | |
| Makefile.standalone | Loading commit data... | |
| OWNERS | Loading commit data... | |
| README.rst | Loading commit data... | |
| codereview.settings | Loading commit data... |