[Bug libfortran/52434] New: Insufficient number of digits in floating point formatting

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

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

             Bug #: 52434
           Summary: Insufficient number of digits in floating point
                    formatting
    Classification: Unclassified
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libfortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: jb@gcc.gnu.org


Currently when formatting floating point numbers (that is, edit descriptors F,
E, EN, ES, G) we first convert the internal value to decimal using snprintf
with a fixed amount of digits, currently 41/24 significant digits depending on
whether quad precision is available. Apart from this being a performance
problem (see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199#c13 ), in some
cases more digits can be useful. E.g. dyadic fractions can be exactly
represented:

! See 
!  
http://www.exploringbinary.com/print-precision-of-dyadic-fractions-varies-by-language/ 
program dyadic
  implicit none
  real(8) :: d
  d = 0.0000000000000000000542101086242752217003726400434970855712890625_8* &
0.0000000000000000000542101086242752217003726400434970855712890625_8*&
0.0000000000000000000542101086242752217003726400434970855712890625_8*&
0.0000000000000000000542101086242752217003726400434970855712890625_8*&
0.0000000000000000000542101086242752217003726400434970855712890625_8*&
0.0000000000000000000542101086242752217003726400434970855712890625_8*&
0.0000000000000000000542101086242752217003726400434970855712890625_8*&
0.0000000000000000000542101086242752217003726400434970855712890625_8*&
0.0000000000000000000542101086242752217003726400434970855712890625_8*&
0.0000000000000000000542101086242752217003726400434970855712890625_8*&
0.0000000000000000000542101086242752217003726400434970855712890625_8*&
0.0000000000000000000542101086242752217003726400434970855712890625_8*&
0.0000000000000000000542101086242752217003726400434970855712890625_8*&
0.0000000000000000000542101086242752217003726400434970855712890625_8*&
0.0000000000000000000542101086242752217003726400434970855712890625_8*&
0.0000000000000000000542101086242752217003726400434970855712890625_8*&
0.00000000000000088817841970012523233890533447265625_8
  print '(F0.1074)', d

  d = 0.99999999999999988897769753748434595763683319091796875_8
  print '(F0.53)', d
end program dyadic

Currently this program outputs

.000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004940656458412465441765687928682213723650600000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
.99999999999999988897769753748434595763683000000000000

The exact output is:

0.000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004940656458412465441765687928682213723650598026143247644255856825006755072702087518652998363616359923797965646954457177309266567103559397963987747960107818781263007131903114045278458171678489821036887186360569987307230500063874091535649843873124733972731696151400317153853980741262385655911710266585566867681870395603106249319452715914924553293054565444011274801297099995419319894090804165633245247571478690147267801593552386115501348035264934720193790268107107491703332226844753335720832431936092382893458368060106011506169809753078342277318329247904982524730776375927247874656084778203734469699533647017972677717585125660551199131504891101451037862738167250955837389733598993664809941164205702637090279242767544565229087538682506419718265533447265625
0.99999999999999988897769753748434595763683319091796875

The solution is to both this problem and the performance issue in PR 38199#c13
is to figure out the correct number of digits needed before calling snprintf.