bogus FAILs from mmix ld testsuite

[Jan Beulich]

Hello,

very reliably with an unchanged configuration, but also very dependent upon
the configuration I'm observing

FAIL: ld-mmix/bpo-15
FAIL: ld-mmix/bpo-15m
FAIL: ld-mmix/bpo-21
FAIL: ld-mmix/bpo-21m

The sole thing I changed for a particular purpose was to pass --enable-shared
to top-level configure. Yet it can't be just that, since in other isolated
tests using the same option (in varying combinations with others) doesn't
yield the same bogus(?) effect.

Re-running "make check" (without any re-building of binaries) makes the
failures go away.

In particular, taking the first failure as example, ld.log has

./ld-new   -L.../ld/testsuite/ld-mmix  -m elf64mmix -o tmpdir/dump tmpdir/start.o tmpdir/bpo-7.o 
Executing on host: sh -c {./ld-new   -L.../ld/testsuite/ld-mmix  -m elf64mmix -o tmpdir/dump tmpdir/start.o tmpdir/bpo-7.o  2>&1}  /dev/null dump.tmp (timeout = 300)
spawn [open ...]
.../ld/.libs/ld-new: tmpdir/bpo-7.o:(.text+0x2): undefined reference to `areg'
failed with: <.../ld/.libs/ld-new: tmpdir/bpo-7.o:(.text+0x2): undefined reference to `areg'>, expected: <^[^c][^h][^i][^l][^d].* undefined reference to `areg'$>
FAIL: ld-mmix/bpo-15

(paths shortened for readability). I can't help the impression that the actual
output matches the expectation expression, so I'm at a loss to explain why FAIL
is reported in the first place. Am I overlooking something very obvious? Has
anyone else ever observed anything similar?

Thanks, Jan