[Bug libfortran/47945] REAL(8) output conversion error on MinGW32

["burnus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47945

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org

--- Comment #8 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-03-02 07:24:57 UTC ---
It is not completely clear to me what you get for your C test case. My feeling
is that the differences are due to the use of different "printf" routines.

For "double" or "REAL(8)", I think Microsoft's snprintf is used - while for
__float128 or REAL(16) a GLIBC-based snprintf is used in libquadmath.

Not surprisingly, I get on Linux the r16 result - which makes sense as all
snprintf routines are based on GLIBC (program from comment 6)
 0.14285714285714284921269268124888
 0.14285714285714284921269268124888

As both numbers are IEEE identical, one cannot really say that Microsoft libc's
implementation or libquadmath's is wrong.

Note: You could use libquadmath with __float128 also from C, cf.
http://gcc.gnu.org/onlinedocs/libquadmath/quadmath_005fsnprintf.html


(In reply to comment #7)
> > 10.7.2.3.7 I/O rounding mode
> 
> gfortran is not a F2008 compiler and it currently does not support
> I/O rounding modes.

To my knowledge gfortran supports I/O rounding (for output, not for input)
since 4.5.0. However, it neither supports setting the rounding for run-time
arithmetic via F2003's IEEE modules -- nor does it allow to set the rounding
for compile-time simplification (folding).

Besides, I am not really sure whether rounding is/should work if one ask for
more digits than the number actually has...

(I think Steve talked about the compile-time folding when he wrote: gfortran by
default will use round to nearest.)