#3697 Lots of pdk regression test failures on 64-bit Windows

[Philipp Klaus Krause]

During the investigation of [bugs:#3690] it was found out that we wrongly got 32-bit Windows regression tests results among the 64-bit windows ones. I was now (locally, on my Debian GNU/Linux system) able to do the real 64-bit Windows regression testing.
And it turns out that quite some pdk regression tests actually fail for 64-Bit Windows (I see no failures fore other ports):

Summary for 'pdk15-stack-auto': 2 abnormal stops ( ), 1705 failures, 15294 tests, 5893 test cases, 8771836 bytes, 140037108 ticks
Summary for 'pdk15': 746 failures, 17121 tests, 5902 test cases, 4308563 bytes, 51251984 ticks
Summary for 'pdk14': 616 failures, 11746 tests, 5891 test cases, 2448750 bytes, 23087210 ticks

[Philipp Klaus Krause]

Looking into the generated code for failing tests, I have identified a first underlying issue: a bug in code generation for ^/~ (i.e. bitwise xor).
Wrong code is generated for a corner case of operands allocated to registers (left operand in p a, result in a p). Apparently such allocations happen more often on the 64-Bit Windows build for whatever reason (maybe differences in the STL version used during cross-build?).

I have attached a patch to fix this issue.

I have tested the patch on GNU/Linux testing on amd64 and see no regression failures. I have not yet checked how many of the 64-Bit Windows regression test failures this fixes.

[Philipp Klaus Krause]

On 64-Bit windows, the patch reduces the number of failures, but there are still plenty of them left.

[Philipp Klaus Krause]

Updated patch, should fix more aspects of this, so far only tested on GNU/Linux, where it doesn't break things for me. Will test overnight with 64-Bit Windows build.

[Philipp Klaus Krause]

Next update to tackle more remaining codegen issues.
It seems strange that register allocation on the 64-Bit Windows build is so different; the allocation clearly looks less efficient there; still all the fixed issues are real codegen bugs.

[Philipp Klaus Krause]

I cannot reproduce this issue using the 64-Bit Windows build from the farm. I only see it when building the snapshot locally. So IMO this is not a release-critical issue for 4.4.0.

[Philipp Klaus Krause]

A fix (superset of patches posted above) for most of the code generation issues found is in the next branch in [r14637].
I still don't know why we get that weird data from register allocation (and on my local build only) in the first place, but at least now it results in errors ("FATAL Compiler Internal Error") instead of bad code.

[Philipp Klaus Krause]

I have now reproduced the issue on a second amd64 Debian GNU/Linux testing system.
Apart from the pdk test failures, there is also (on both systems) a crash when trying to compile the uc65c02 regression test infrastructure (Caught signal 11: SIGSEGV when trying to create testfwk.rel)

[Philipp Klaus Krause]

That segfault is now [bugs:#3781].

[Philipp Klaus Krause]

In [r14971], I fixed a code gneration issue that could result in invalid asm being generated for rotations. Now all remaining Windows pdk failures should trigger assertions in the compiler.

[Philipp Klaus Krause]

While I recently fixed a bug that results in older sdcc.exe executables possibly being used, this problem still happens in sdcc from the current nativecrosstools branch.

[Philipp Klaus Krause]

Looks like the underlying problem is another boost flat_map issue, this time affecting boost 1.83.0. I see essentially the entries (18, 7) and (18, 8) being added into previously empty a flat_multimap, then n.operands.find(22) finds something. However, unlike for the similar [bugs:#3697], I was not able to create a small program to reproduce the boost 1.83.0 issue. I was not able to reproduce the bug using boost 1.86.0.

I think the safest approach is to not use boost::container::flat_multimap from boost 1.85.0 or older, and fallback to std::multimap instead. I implemented that approach in [r15079]. But this slows down register allocation.