🚀 go-pugleaf

http://gcc.gnu.org/bugzilla/show_bug.cgi?idG293

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|libquadmath: strtoflt128 -  |libquadmath: strtoflt128 -
                   |C99 hex floating point      |NAN not correctly read and
                   |format missing              |C99 hex floating point
                   |                            |format missing

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-01-14 15:36:52 UTC ---
Additional problem: The NAN string to float128 conversion does not seem to
work.

[The way NaN is printed by the float128->string conversion function is also a
bit odd, but it seems to work (with libgfortran).]

The program below prints:

+N.aN000000000000000000e+02
+7.82797652694030368547e-4942

The a similar Fortran program prints (value printed as hex):
     0        0        0 FFFF8000   -- for NaN (gfortran and ifort)
     0 C0000000     FFFF        0   -- for the "NaN" string (= 0.78280E-4941)

If one debugs gdtoa/strtodg.c, one sees that STRTOG_NaN is properly detected.
Thus, either the bits are wrong in strtodg -- or it is wrongly handled in
strtoflt128.

Example (strtoflt128 was called "quadmath_strtopQ" before renaming.)

#include <quadmath.h>
#include <stdlib.h>  /* For abort.  */
#include <stdio.h>   /* For printf.  */

int main ()
{
  __float128 r;
  char str[200];
  r = nanq(NULL);
  quadmath_dtoaq (str, sizeof (str), 20, r);
  printf("%s\n", str);

  r = 3.0q;
  /* quadmath_strtopQ ("NaN", NULL, &r); */
  r = strtoflt128 ("NaN", NULL);
  quadmath_dtoaq (str, sizeof (str), 20, r);
  printf("%s\n", str);

  if (!isnanq(r)) abort();
  return 0;
}

http://gcc.gnu.org/bugzilla/show_bug.cgi?idG293

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jvdelisle at gcc dot
                   |                            |gnu.org
         AssignedTo|unassigned at gcc dot       |jvdelisle at gcc dot
                   |gnu.org                     |gnu.org

--- Comment #2 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-01-22 14:25:52 UTC ---
Taking this one

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47293

--- Comment #3 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-01-26 05:45:35 UTC ---
I think this fixes it.  Why it was whacked, who knows.

Index: gd_qnan.h
===================================================================
--- gd_qnan.h    (revision 169141)
+++ gd_qnan.h    (working copy)
@@ -2,9 +2,9 @@
 #define d_QNAN0 0x0
 #define d_QNAN1 0xfff80000
 #define ld_QNAN0 0x0
-#define ld_QNAN1 0xc0000000
-#define ld_QNAN2 0xffff
-#define ld_QNAN3 0x0
+#define ld_QNAN1 0x0
+#define ld_QNAN2 0x0
+#define ld_QNAN3 0xffff8000
 #define ldus_QNAN0 0x0
 #define ldus_QNAN1 0x0
 #define ldus_QNAN2 0x0


Test program I used. Try this without the patch and it is very obvious what is
wrong.

character(len=200) :: str
real(16) :: r, x, y, z
integer(16) :: k
x = 0.0
y = 0.0
r = 1.0
str = 'NAN' ; read(str,*) r
print *, r
z = x/y
print *, z
k = transfer(z,k)
print "(b128)", k
print *
k = transfer(r,k)
print "(b128)", k
end