[libgfortran] Fix numerous formatting bugs

On 04/27/2011 12:57 PM, Janne Blomqvist wrote:
> On Wed, Apr 27, 2011 at 08:53, Janne Blomqvist
> <blomqvist.janne@gmail.com>  wrote:
>> On Wed, Apr 27, 2011 at 07:09, Jerry DeLisle<jvdelisle@frontier.com>  wrote:
>>> On 04/25/2011 07:36 AM, Janne Blomqvist wrote:
>>>>
>>>> On Mon, Apr 25, 2011 at 14:44, Jerry DeLisle<jvdelisle@frontier.com>
>>>>   wrote:
>>>>>
>>>>> On 04/25/2011 03:48 AM, Janne Blomqvist wrote:
>>>>>>
>>>>>> Now, for one of the testcase changes:
>>>>>>
>>>>>> --- gcc/testsuite/gfortran.dg/char4_iunit_1.f03 (revision 172909)
>>>>>> +++ gcc/testsuite/gfortran.dg/char4_iunit_1.f03 (working copy)
>>>>>> @@ -24,11 +24,11 @@ program char4_iunit_1
>>>>>>     write(string, *) .true., .false. , .true.
>>>>>>     if (string .ne. 4_" T F T                                    ") call
>>>>>> abort
>>>>>>     write(string, *) 1.2345e-06, 4.2846e+10_8
>>>>>> -  if (string .ne. 4_"  1.23450002E-06   42846000000.000000     ") call
>>>>>> abort
>>>>>> +  if (string .ne. 4_"  1.234500019E-06   42846000000.000000    ") call
>>>>>> abort
>>>>>>
>>>>>> This looks wrong. For correctly rounded REAL(4) output, we need 9
>>>>>> significant digits, but here we print 10.
>>>>>>
>>>>>
>>>>> Well, I bumped it up for defaults based on pr48488 comment #2 shown
>>>>> below.
>>>>
>>>> Yes, that comment in the PR is correct; to guarantee that a
>>>> binary->ascii->binary roundtrip preserves the original binary value
>>>> (with the default "round to nearest, break on even" rounding mode),
>>>> one must output at least {9, 17, 21, 36} significant digits for real
>>>> kinds 4, 8, 10, and 16, respectively (yes, I double-checked IEEE
>>>> 754-2008 that this is indeed correct).
>>>>
>>>> Since for the G edit descriptor d is equivalent to the number of
>>>> significant digits, AFAICS the write.c patch below is correct and the
>>>> bug must be elsewhere, no?
>>>>
>>>
>>> No.
>>>
>>> Look at this example:
>>>
>>> program t4
>>>   implicit none
>>>   character(len=44) :: string
>>>   write(*,*) 1.2345e-06, 4.2846e+10_8
>>>   write(*,'(1x,1pG16.9e2,1x,1pG25.17e3)') 1.2345e-06, 4.2846e+10_8
>>>   write(*,'(1x,1pG15.8e2,1x,1pG25.17e3)') 1.2345e-06, 4.2846e+10_8
>>> end program t4
>>>
>>> This gives with the patch:
>>>
>>>   1.234500019E-06   42846000000.000000
>>>   1.234500019E-06   42846000000.000000
>>>   1.23450002E-06   42846000000.000000
>>>
>>> And without the patch:
>>>
>>>   1.23450002E-06   42846000000.000000
>>>   1.234500019E-06   42846000000.000000
>>>   1.23450002E-06   42846000000.000000
>>>
>>> d is the number of digits after the decimal point, not the number of
>>> significant digits.
>>
>> I stand corrected. Or well, I still stand by my previous statement
>> that with the G edit descriptor d corresponds to the number of
>> significant digits. However, only when not using the scale factor.
>>
>> Since we use a scale factor of 1, when the magnitude of the number is
>> such that the E edit descriptor is used, according to F2008 10.7.2.3.3
>> paragraph 6 for 0<  k<  d+2 we must print k significant digits to the
>> left of the decimal point and d-k+1 to the right. That is, with k=1 we
>> print one digit to the left of the decimal point and d-1+1=d to the
>> right which has the effect of increasing the number of significant
>> digits by one!
>>
>> However, when the magnitude of the value is such that F editing is
>> used, the scale factor has no effect and we thus print d significant
>> digits.
>>
>> So in order to guarantee an exact binary<->ascii roundtrip we must
>> accept an extra digit in some cases. Or then do something which would
>> make list formatted (and perhaps G0 as well?) write differ from 1PGw.d
>> (effectively, reduce d by one when the magnitude is such that E
>> editing is used)?
>
> That is, what about something like the attached patch on top of your
> patch. With the patch, the test program
>
> program t4
>   implicit none
>   character(len=44) :: string
>   write(*,*) 1.2345e-06, 4.2846e+10_8, 1.1
>   write(*,'(1x,1pG16.9e2,1x,1pG25.17e3)') 1.2345e-06, 4.2846e+10_8
>   write(*,'(1x,1pG15.8e2,1x,1pG25.17e3)') 1.2345e-06, 4.2846e+10_8
>   write(*,'(1x,1pG0,1x,1pG0)') 1.2345e-06, 1.1
>   write(*,'(1x,1pG0.9,1x,1pG0.9)') 1.2345e-06, 1.1
> end program t4
>
> outputs
>
>     1.23450002E-06   42846000000.000000        1.10000002
>    1.234500019E-06   42846000000.000000
>    1.23450002E-06   42846000000.000000
>   1.23450002E-06 1.10000002
>   1.234500019E-06 1.10000002
>
> So the change is that now it prints the same number of significant
> digits in E and F mode, both for list formatted output and kPG0 when
> k>=0. For list formatted we can do pretty much what we want, and for
> G0 the standard only says the processor can choose appropriate values
> for w, d, and e. So far we have chosen d and e only based on the kind,
> but AFAICS nothing prevents taking into account the magnitude as well.
>
> I haven't modified any of the testcases so I expect some number of
> regressions due to that, but I'm asking for opinions on the approach
> itself before doing that.
>

Actually only saw one test case failure which I have adjusted.  The attached 
patch applies Janne's patch to my patch and the fix for pr48787.  Regression 
tested on x86-64.

OK for trunk?  I sure would like to get this in so I can move on to other things.

Jerry

[libgfortran] Fix numerous formatting bugs

Commit Message

Comments

Patch