BUG: str of DOUBLE_DOUBLE format wrong on ppc64

[ahaldane]

Fixes #11103 for 1.14.4 using a quick hack, which will be superseded by #10444 on master (1.15).

The quick fix is to use the OS printf to print the value. The downside is it does not properly respect the uniqueness, padding, and other arguments for dragon4 printing, but at least it prints the right value now. (This means it fails a few printing unit tests on ppc).

Output on the OSUOSL ppc64be system:

>>> np.arange(3, dtype=np.float128)
array([0., 1., 2.], dtype=float128)
>>> np.array([10000.0, 1.0, 1.234], dtype=np.float128)
array([1.00000000e+04, 1.00000000e+00, 1.23400000e+00], dtype=float128)

>>> np.sqrt(np.array([2.], dtype=np.float128))
array([1.41421356], dtype=float128)
>>> np.set_printoptions(precision=30)
>>> np.sqrt(np.array([2.], dtype=np.float128))
array([1.41421356237309504880168872421], dtype=float128)

[charris]

(This means it fails a few printing unit tests on ppc)

? Before or after this patch?

[charris]

@ahaldane Will it fail current tests on ppc?

[ahaldane]

Yes, it will fail some tests. But those tests were already failing in a much worse way.

Before this PR, it was printing completely nonsensical results. Now it prints the right value, but with the wrong whitespace padding, sometimes.

[charris]

OK. Can you make a doc/release/1.14.4-notes.rst file and add a warning to that affect? Alternatively, maybe could revise/skip the failing tests by platform.

[ahaldane]

I'll make the release note.

I don't want to silence those tests because they need to be fixed in future PRs!

[charris]

Thanks Allan.