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
