[Bug libfortran/93727] Fortran 2018: EX edit descriptor

[Bug libfortran/93727] Fortran 2018: EX edit descriptor

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93727

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2020-07-12
             Status|UNCONFIRMED                 |NEW
           Priority|P3                          |P4
     Ever confirmed|0                           |1

[Bug libfortran/93727] Fortran 2018: EX edit descriptor

[jvdelisle at charter dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93727

jvdelisle at charter dot net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jvdelisle at charter dot net

--- Comment #1 from jvdelisle at charter dot net ---
I will take this one.

[Bug libfortran/93727] Fortran 2018: EX edit descriptor

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93727

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |markeggleston at gcc dot gnu.org

--- Comment #2 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
*** Bug 96569 has been marked as a duplicate of this bug. ***

[Bug libfortran/93727] Fortran 2018: EX edit descriptor

[jvdelisle at charter dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93727

--- Comment #3 from jvdelisle at charter dot net ---
Interesting language if not sort of weird:

"exp is a binary exponent expressed as a decimal integer"

I am in early stages of choosing how to do this.

[Bug libfortran/93727] Fortran 2018: EX edit descriptor

[jvdelisle at charter dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93727

--- Comment #4 from jvdelisle at charter dot net ---
An Update. I have the front end and runtime parsing for OUTPUT done and am now
looking at the actual implementation.  We have the printf series of functions
available and can use the %A format specifier to create the hexidecimal float
string.

I want to note here that on input, apparently the F editing requires one to be
able to READ a hexadecimal float with the F descriptor as well as the EX
descriptor. See 
13.7.2.3.2 part 7.

Another aspect I am studying has to do with rounding.  On output I assume we
must support RU, RD, RN vs truncating. Considering that the purpose of this
type of representation of a float is mostly for "looking under the hood" I
initially was thinking simple truncation should suffice and if a user does not
know they have not specified enough precision for all hexadecimals, tough
beans.  After all, in hexadecimal, it is always an exact fit. I am curious what
others think about this.

Regardless, we will need a new rounding function to round the hexadecimals
before output.

On input, obviously we need to do a new read function and for the F descriptor
we will have to look ahead to identify that it is a hexadecimal before
processing it, otherwise it just looks like a bad float.

[Bug libfortran/93727] Fortran 2018: EX edit descriptor

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93727

Jerry DeLisle <jvdelisle at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |jvdelisle at gcc dot gnu.org
           Severity|enhancement                 |normal
                 CC|                            |jvdelisle at gcc dot gnu.org

[Bug libfortran/93727] Fortran 2018: EX edit descriptor

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93727

--- Comment #5 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
I have been studying this a bit by looking at the 2023 std and functionality of
printf().
Specifically printf() provides the 'A' descriptor which can be used for float
(kind=4) and double (kind=8).  It will accept a long double (80 bit aka
kind=10). I am noticing that the results of double and long double are
identical, no extra precision visible. It is very possible I am not doing that
correctly.

I do not see anything related to quad precision floats.  I am posting this as i
think we will have to do some of our own translating byte portions of floats
ourselves. Portability may be an issue. For example IBM 360 128bit precision or
some other processor may not follow the same internal representations.

Regardless I have preliminary code for the frontend that results in calling
anew fucntion write_ex in transfer.c

I think that kind=4 and kind=8 will be fine. Any thoughts on kind=10 or kind=16
I would appreciate as I further explore this.

[Bug libfortran/93727] Fortran 2018: EX edit descriptor

[thenlich at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93727

--- Comment #6 from Thomas Henlich <thenlich at gcc dot gnu.org> ---
(In reply to Jerry DeLisle from comment #5)
> I have been studying this a bit by looking at the 2023 std and functionality
> of printf().
> Specifically printf() provides the 'A' descriptor which can be used for
> float (kind=4) and double (kind=8).  It will accept a long double (80 bit
> aka kind=10). I am noticing that the results of double and long double are
> identical, no extra precision visible. It is very possible I am not doing
> that correctly.
> 
> I do not see anything related to quad precision floats.  I am posting this
> as i think we will have to do some of our own translating byte portions of
> floats ourselves. Portability may be an issue. For example IBM 360 128bit
> precision or some other processor may not follow the same internal
> representations.
> 
> Regardless I have preliminary code for the frontend that results in calling
> anew fucntion write_ex in transfer.c
> 
> I think that kind=4 and kind=8 will be fine. Any thoughts on kind=10 or
> kind=16 I would appreciate as I further explore this.

Just some thoughts:

Have you tried "%LA" for long double?

Have you tried quadmath_snprintf
(https://gcc.gnu.org/onlinedocs/libquadmath/quadmath_005fsnprintf.html) with
"%QA" for quad precision?

[Bug libfortran/93727] Fortran 2018: EX edit descriptor

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93727

--- Comment #7 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
(In reply to Thomas Henlich from comment #6)
--- snip ---
> Just some thoughts:
> 
> Have you tried "%LA" for long double?
> 
> Have you tried quadmath_snprintf
> (https://gcc.gnu.org/onlinedocs/libquadmath/quadmath_005fsnprintf.html) with
> "%QA" for quad precision?

That was the hint I needed.

#include <stdio.h>
int main()
  {
     float x =       1.0f / 3.0f;
     double y =      1.0l / 3.0l;
     long double z = 1.0L / 3.0L;
     printf("   FLOAT: %.18A\n", x);
     printf("  DOUBLE: %.18lA\n", y);
     printf("LONG DBL: %.18LA\n", z);
     printf("          123456789012345678901234567890\n");
     printf("   FLOAT: %.20f\n", x);
     printf("  DOUBLE: %.20lf\n", y);
     printf("LONG DBL: %.20Lf\n", z);
  }

$ gcc hexfloat.c 
$ ./a.out 
   FLOAT: 0X1.555556000000000000P-2
  DOUBLE: 0X1.555555555555500000P-2
LONG DBL: 0XA.AAAAAAAAAAAAAAB000P-5
          123456789012345678901234567890
   FLOAT: 0.33333334326744079590
  DOUBLE: 0.33333333333333331483
LONG DBL: 0.33333333333333333334

I will check the libqudmath version as well.

Thanks.