Testing of `printf("%a", ...)` is overly restrictive

[alycm]

The printf testsuite tests the output of printf("%.6a", 0.1): https://github.com/KhronosGroup/OpenCL-CTS/blob/dbd3e787fe4cf977c2da7c58f7505918eb293e6c/test_conformance/printf/util_printf.cpp#L188

This test expects the output from device printf to be identical to that of the host printf. However, for %a there are at least four valid representations for finite non-zero values. The OpenCL C specification does not require that host and device output be identical, nor does it require a specific representation.

If using the method of comparing against host printf, this is hard to truly fix as the host can only ever give one output. But pragmatically, this is the only test for %a in the suite, so could explicitly check for any of the four representations of 0.1.

This C program shows the four representations of 0.1 (with the caveat that I'm not sure of the final digit on the second and third examples):

#include <stdio.h>

int main() {
    // Host reference for how 0.1 is printed as a hexfloat.
    printf("%.6a\n", 0.1f);
    // 0x1.99999ap-4

    // But there are four ways to print each finite non-zero floating point
    // number.  See https://stackoverflow.com/a/29172351
    //
    // C99 (and OpenCL C) allows any of these four forms, but 32-bit and
    // 64-bit floats favor particular forms due to the footnote "Binary
    // implementations can choose the hexadecimal digit to the left of the
    // decimal-point character so that subsequent digits align to nibble
    // (4-bit) boundaries."
    float f[4];
    sscanf("0x1.99999ap-4", "%a", &f[0]);  // Aligns for 64-bit floats
    sscanf("0x3.333333p-5", "%a", &f[1]);  // Uncertain of final 3
    sscanf("0x6.666666p-6", "%a", &f[2]);  // Uncertain of final 6
    sscanf("0xc.cccccdp-7", "%a", &f[3]);  // Aligns for 32-bit floats

    printf("%.6a %.6a %.6a %.6a\n", f[0], f[1], f[2], f[3]);
    // 0x1.99999ap-4 0x1.99999ap-4 0x1.99999ap-4 0x1.99999ap-4
}