[Bug libfortran/93727] Fortran 2018: EX edit descriptor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93727
--- Comment #7 from Jerry DeLisle ---
(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
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.56P-2
DOUBLE: 0X1.50P-2
LONG DBL: 0XA.AAB000P-5
123456789012345678901234567890
FLOAT: 0.3334326744079590
DOUBLE: 0.1483
LONG DBL: 0.3334
I will check the libqudmath version as well.
Thanks.
[Bug libfortran/93727] Fortran 2018: EX edit descriptor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93727 --- Comment #6 from Thomas Henlich --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93727 --- Comment #5 from Jerry DeLisle --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93727 Jerry DeLisle 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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93727 Dominique d'Humieres changed: What|Removed |Added CC||markeggleston at gcc dot gnu.org --- Comment #2 from Dominique d'Humieres --- *** Bug 96569 has been marked as a duplicate of this bug. ***
[Bug libfortran/93727] Fortran 2018: EX edit descriptor
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93727 Dominique d'Humieres changed: What|Removed |Added Last reconfirmed||2020-07-12 Status|UNCONFIRMED |NEW Priority|P3 |P4 Ever confirmed|0 |1
