[patch] PR93727 Fortran 2018: EX edit descriptor

[Jerry D]

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
> 
>>
>> - 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


>> 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; '

> 
> 
> 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.
> 
>>
>> Best,
>> Harald
>> --- snip ---
> 
> Thanks for the review.  I will fix these and resubmit.
> 
> Jerry
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pr93727-submitv2.diff
Type: text/x-patch
Size: 25884 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/fortran/attachments/20260201/811c166a/attachment-0001.bin>