https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384
--- Comment #31 from Patrick Palka <ppalka at gcc dot gnu.org> --- (In reply to Iain Sandoe from comment #28) > (In reply to Iain Sandoe from comment #27) > > for Darwin x86 > > > > * the test at line 83 fails, and with some more debugging stuff inserted and > > the abort removed, there are 66 cases where the strings do not agree, so a > > bug in libc (probably) .. I'm doing seem more tests on a newer system > > version. > > repeated on macOS11 (Darwin20) - the fails are for precisions 1, 5, 9 and 13 > (if there's any significance to that) with a pattern that looks like this: > > begin 9.2p-11003, printf_buffer 0x9.1p-11003 > FAILED: prec has value 1 > -- > begin 9.1a2b4p-11003, printf_buffer 0x9.1a2b3p-11003 > FAILED: prec has value 5 > -- > begin 9.1a2b3c4d6p-11003, printf_buffer 0x9.1a2b3c4d5p-11003 > FAILED: prec has value 9 > -- > begin 9.1a2b3c4d5e6f8p-11003, printf_buffer 0x9.1a2b3c4d5e6f7p-11003 > FAILED: prec has value 13 > -- > begin 9.1a2b3c4d5e6f8p-11003, printf_buffer 0x9.1a2b3c4d5e6f7p-11003 > FAILED: prec has value 13 > -- > begin 9.1a2b3c4d5e6f8p-11003, printf_buffer 0x9.1a2b3c4d5e6f7p-11003 > FAILED: prec has value 13 > > (and similarly for the other values that fail, not read the code enough yet > to figure out why we get the three cases for 13...). Thanks for digging into this! So it looks like the disagreement here is the rounding of the least significant hexit. Assuming the FP rounding mode is set to FE_TONEAREST, seems like a bug in printf indeed.. I can't think of any reason why this happens only with precisions 1,5,9 and 13 and not also with 3,7,11.
