On Mon, 23 Nov 2020, Paul Koning wrote: > > Then there is a fix for the PDP11 backend addressing an issue I found in > > the handling of floating-point comparisons. Unlike all the other changes > > this one has not been regression-tested, not even built as I have no idea > > how to prepare a development environment for a PDP11 target (also none of > > my VAX pieces is old enough to support PDP11 machine code execution). > > I agree this is a correct change, interesting that it was missed before. > You'd expect some ICE issues from that mistake. Perhaps there were and > I didn't realize the cause; the PDP11 test run is not yet fully clean.
Nothing like that, I wouldn't expect an ICE here. Just as none happened with the VAX backend before a test case made me realise a corresponding change was required. It's just a pessimisation: the RTL simply doesn't match and the comparison to remove stays. > I've hacked together a primitive newlib based "bare metal" execution > test setup that uses SIMH, but it's not a particularly clean setup. > And it hasn't been posted, I hope to be able to do that at some point. Hmm, I gather those systems are able to run some kind of BSD Unix: don't they support the r-commands which would allow you to run DejaGNU testing with a realistic environment PDP-11 hardware would be usually used with, possibly on actual hardware even? I always feel a bit uneasy about the accuracy of any simulation (having suffered from bugs in QEMU causing false negatives in software verification). While I would expect old BSD libc to miss some of the C language features considered standard nowadays, I think at least the C GCC frontend runtime (libgcc.a) and the test suite do not overall rely on their presence, and any individual test cases that do can be easily excluded. > Thanks for the fix. I take it as an approval and will apply the change then along with the rest of the series. Thank you for your review. Maciej
