Unexpected output from intel fmt::fprint

[gsjaardema]

With the following program:

#include <fmt/printf.h>
int main()
{
    fmt::printf("%d:%d %f %s\n", 3, 1234, 12.345, "weekend");
}

I get the expected output on most compiler and lib::fmt version combinations:

3:1234 12.345000 weekend

However, if I use the intel compiler with either 10.0.0 or trunk, I get:

3:1234 12.345001 weekend

Notice the 1 at the end of the floating point output. I'm not sure where this is coming from or how to get the same output on intel with 10.0.X as I get with intel and earlier lib::fmt versions or with all other compilers I have tried.

Here is a compiler explorer link: https://godbolt.org/z/MzG7T9bfr

[gsjaardema]

I added the c-library printf call:

    printf("%d:%d %f %s\n", 3, 1234, 12.345, "weekend");

And that gives me the "expected" output:

3:1234 12.345000 weekend

[gsjaardema]

I also tried with the %g format specifier for the double parameter and get:

3:1234 12.3451 weekend

which is worse accuracy.

If I loop from 0.345 to 99.345:

include <fmt/printf.h>
int main()
{
   for (int i = 0; i < 100; i++) { 
        double di = (double)i;
        fmt::printf("%d:%d %g %s\n", 3, 1234, di+.345, "weekend");
    }
}

The extraneous 1 is added on for these values for %g output:

3:1234 7.345 weekend
3:1234 8.34501 weekend
3:1234 9.34501 weekend
3:1234 10.3451 weekend
3:1234 11.3451 weekend
3:1234 12.3451 weekend
3:1234 13.3451 weekend
3:1234 14.3451 weekend
3:1234 15.3451 weekend
3:1234 16.345 weekend

And these for %f output:

3:1234 7.345000 weekend
3:1234 8.345001 weekend
3:1234 9.345001 weekend
3:1234 10.345001 weekend
3:1234 11.345001 weekend
3:1234 12.345001 weekend
3:1234 13.345001 weekend
3:1234 14.345001 weekend
3:1234 15.345001 weekend
3:1234 16.345000 weekend

[vitaut]

Interestingly, the issue doesn't happen with print: https://godbolt.org/z/1s3ebbv9K.

[gsjaardema]

Interestingly, the issue doesn't happen with print: https://godbolt.org/z/1s3ebbv9K.

Yes, I noticed that. The assembly output is also much cleaner and smaller.

[gsjaardema]

We found another strangeness:

int main()
{
    fmt::printf("%g %g\n", -10., 2.);
}

Returns:

-10.0001 2.00001

[vitaut]

Could be related to #3269.

[gsjaardema]

Could be related to #3269.

That is where a git bisect points for me also.

[gsjaardema]

Interestingly, the issue doesn't happen with print: https://godbolt.org/z/1s3ebbv9K.

Although it does it you define FMT_HEADER_ONLY. https://godbolt.org/z/vazbMba97

[vitaut]

Maybe @jk-jeon has some insights regarding what might be causing this.

[jk-jeon]

This is because the rounding criterion is evaluated incorrectly. The cause is that the static data member fmt::detail::data::fractional_part_rounding_thresholds is initialized with zeros for some reason I am not aware of. Fixing that will fix this issue I believe.

By the way, compiler explorer is really god send. Who can expect I can debug without even having a compiler.

[jk-jeon]

It really sounds like a compiler bug: https://godbolt.org/z/9MKsa8xjq.
Apparently it only happens when the containing struct is a template and the member is an array.

[gsjaardema]

So does basic_data need to be a template struct? I did remove the template <typename T = void> from struct basic_data and verified that it did fix the bug, but I don't know enough about the internals to know why it is a template structure...

[vitaut]

So does basic_data need to be a template struct?

Yes, for the header-only mode. However, we are moving away from it in favor of storing such tables as static constexpr variables in functions which can be applied as a workaround here.

In any case, this is a severe bug in the Intel compiler, please report it.

[vitaut]

Thanks, @jk-jeon, for investigating!

[phprus]

It really sounds like a compiler bug: https://godbolt.org/z/9MKsa8xjq.
Apparently it only happens when the containing struct is a template and the member is an array.

This is EDG frontend and C++ >= 17 bug.
More info: #3043