Re: [patch] PR93727 Fortran 2018: EX edit descriptor

Hi Jerry!

On 2/2/26 06:09, Jerry D wrote:
> Attached patch fixes everything so far.
> 
> See my annotations below.
> 
> -- Jerry
> 
> On 2/1/26 3:00 PM, Jerry D wrote:
>> On 2/1/26 12:44 PM, Harald Anlauf wrote:
>>> Hi Jerry,
>>>
>>> thanks for your draft patch!
>>>
>>> I don't mind implementing it step by step, but it does not
>>> work here as I think it should (based on two other compilers).
>>>
>>> Let's look at the testcases first:
>>>
>>> - real(10) should be restricted to platforms where this is
>>>    available; it will be rejected on several others
>>
>> I found one compiler that did not support real(10) even though the 
>> hardware has it and it did support real(16). Some don't do either. I 
>> am certain we need to set target in the test cases

I meant: do all platforms which *we* support implement real(10)?
You could

% grep -r __GFC_REAL_10__ gcc/testsuite/gfortran.dg/

for similar solutions.

>>>
>>> - EXformat_1.f90
>>>
>>>    r4 = -huge(1.0_4/3.0_4)
>>>
>>> this is identical to
>>>
>>>    r4 = -huge(1.0_4)
> 
> Fixed
> 
>>
>> Yes, I will tweak that.
>>>
>>> and should print as:
>>>
>>> -0XF.FFFFFP+124
>>>
> 
> Fixed (note system dependent on the first hex digit):
> 
>    write(s1,"(EX0.0,'<')") r4
>    if (s1.ne."-0X1.FFFFFEP+127<") stop 1
>    write(s1,"(EX0.0,'<')") r8
>    if (s1.ne."-0X1.FFFFFFFFFFFFFP+1023<") stop 2
>    write(s1,"(EX0.0,'<')") r10
>    if (s1.ne."-0XF.FFFFFFFFFFFFFFFP+16380<") stop 3

Let's see:

13.7.2.3.6 EX editing

The EXw.d and EXw.dEe edit descriptors indicate that the external field
occupies w positions, except when w is zero in which case the processor
selects the field width. The fractional part of the field contains d
hexadecimal digits, except when d is zero in which case the processor
selects the number of hexadecimal digits to be the minimum required so
that the output field is equal to the internal value; ...

But -0XF.FFFFFP+124 is shorter than -0X1.FFFFFEP+127, so I think
you should recheck.  Sorry for the extra work ;-)

> 
>>> and not
>>>
>>> -0X1.P+127
>>>
>>
>> hmm, I Added an = sign in a conditional looking at something else and 
>> forgot
>> to take it back out.
>>
>>    /* Handle the 'd' parameter - adjust mantissa precision if 
>> specified */
>>    if (d > 0)      <---------- I had >=, my bad.
>>      {
>>
>>
>> This gives:
>>
>> 123456789012345678901234567890
>> -0X1.FFFFFEP+127<
>> -0X1.FFFFFFFFFFFFFP+1023<
>> -0XF.FFFFFFFFFFFFFFFP+16380<
>>
>> Notice how this implementation normalizes differently then others.
>>
>>> etc.
>>>
>>> Similarly for EXformat_2.f90, the first write should be
>>>
>>>   >          -0X9.D14707B63DFBP+3<
>>>
> 
> Fixed and now:
> 
>    write(str1, '(">",EX30.0,"<")') num
>    if (str1.ne.">         -0X1.3A28E0F6C7BF6P+6<") stop 1
> 
> Also system dependent, compiler dependent.
> 
>>> and not
>>>
>>>   >                      -0X1.P+6<
>>
>> Likwise, thanks for seeing these.
>>
>>>
>>> I would also recommend to extend the string length s1 so that
>>> other brands do not complain about it being to short:
>>>
>>>    character(kind=1, len=16) :: s1
>>>
>>
>> Easy to do.
>>
> 
> Fixed to len=45
> 
>>> I also get a warning at compilation of io.cc:
>>>
>>> ../../gcc-trunk/gcc/fortran/io.cc: In function 'format_token 
>>> format_lex()':
>>> ../../gcc-trunk/gcc/fortran/io.cc:449:11: warning: this statement may 
>>> fall through [-Wimplicit-fallthrough=]
>>>    449 |           switch (c)
>>>        |           ^~~~~~
>>> ../../gcc-trunk/gcc/fortran/io.cc:464:9: note: here
>>>    464 |         case 'Z':
>>>        |         ^~~~
>>>
>>> Can you check the logic?
> 
> Found it and fixed, missed a ' break; '

If we didn't find it, one of the testers would complain later..

>>
>>
>> Yes, I did not see it fly by, but will check.
>>
>>>
>>> I stopped the review here.
> 
> Feel free to continue.
> 
>>>
>>> Finally a few general comments: please try to stick to the
>>> 80 columns/line recommendation for commit messages as well
>>> as for code.
>>
> 
> I went through and fixed line lengths.
> 
> 
>> Agree, I can adjust.

Thanks for that.

We're getting closer...  Eagerly waiting for version 3 ;-)

Best,
Harald

>>
>>>
>>> Best,
>>> Harald
>>> --- snip ---
>>
>> Thanks for the review.  I will fix these and resubmit.
>>
>> Jerry
>>
>>