[Bug testsuite/32841] New: FAIL: gfortran.dg/edit_real_1.f90 on Darwin8

[Bug testsuite/32841] New: FAIL: gfortran.dg/edit_real_1.f90 on Darwin8

[dominiq at lps dot ens dot fr]

Copy of http://gcc.gnu.org/ml/fortran/2007-07/msg00388.html

I have finally decided to give a shot to OSX 10.4 on my G5 and I do
see the edit_real_1.f90 failure. The culprit is:

  write (s, '(1PE10.3,A)') huge(0d0), "z"

The follwoing reduced code:

! { dg-do run }
! Check real value edit descriptors
! Also checks that rounding is performed correctly
program edit_real_1
  character(len=20) s
  character(len=20) x
  parameter (x = "xxxxxxxxxxxxxxxxxxxx")

  print *, huge(0d0), nearest(huge(0d0), -1.0d0)
  print '(2(1PG30.18))', huge(0d0), nearest(huge(0d0), -1.0d0)
  s = x
  write (s, '(1PG10.3,A)') huge(0d0), "z"
  print *, s
  ! E format, very large number.
  ! Used to overflow with positive scale factor
  s = x
  write (s, '(1PE10.3,A)') huge(0d0), "z"
  print *, s
  ! The actual value is target specific, so just do a basic check
  if ((s(1:1) .eq. "*") .or. (s(7:7) .ne. "+") .or. &
      (s(11:11) .ne. "z")) call abort
end

gives under OSX 10.3:

  1.797693134862316E+308  1.797693134862316E+308
      1.797693134862315708+308      1.797693134862315509+308
  1.798+308z         
  1.798+308z         

while it gives under 10.4:

               +Infinity  1.797693134862316E+308
                     +Infinity      1.797693134862315509+308
  +Infinityz         
  +Infinityz         
Abort

One can argue that huge(0d0) rounded to three digits is +Infinity,
but I think it is a bug to get +Infinity with the 18 digit precision.

Any idea on how to trace the problem?

Dominique

BTW when I said under OSX 10.3, it was not accurate, I meant
gfortran 4.3 compiled under 10.3, but run under 10.4

Following mails:

http://gcc.gnu.org/ml/fortran/2007-07/msg00393.html
http://gcc.gnu.org/ml/fortran/2007-07/msg00399.html
http://gcc.gnu.org/ml/fortran/2007-07/msg00400.html


-- 
           Summary: FAIL: gfortran.dg/edit_real_1.f90 on Darwin8
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: testsuite
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: dominiq at lps dot ens dot fr
GCC target triplet: powerpc-apple-darwin8


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

[Bug testsuite/32841] FAIL: gfortran.dg/edit_real_1.f90 on Darwin8

[jvdelisle at gcc dot gnu dot org]

------- Comment #1 from jvdelisle at gcc dot gnu dot org  2007-07-20 20:54 -------
The WTITEing of "Infinity" is dependent on the following C code in io/write.c

      res = isfinite (n); 
      if (res == 0)

So if the isfinite function is broken on this system, that would explain this
problem.

Can you test with a C program to see if indeed this is the problem?


-- 


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

[Bug testsuite/32841] FAIL: gfortran.dg/edit_real_1.f90 on Darwin8

[dominiq at lps dot ens dot fr]

------- Comment #2 from dominiq at lps dot ens dot fr  2007-07-20 21:00 -------
Subject: Re:  FAIL: gfortran.dg/edit_real_1.f90 on
 Darwin8

> Can you test with a C program to see if indeed this is the problem?

My knowledge of C it very limited, you know!-(

Could you send me some canvas to start with?


-- 


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

[Bug testsuite/32841] FAIL: gfortran.dg/edit_real_1.f90 on Darwin8

[jvdelisle at gcc dot gnu dot org]

------- Comment #3 from jvdelisle at gcc dot gnu dot org  2007-07-20 21:01 -------
Additional note: isfinite may be getting redefined in libgfortran.h

/* The isfinite macro is only available with C99, but some non-C99
   systems still provide fpclassify, and there is a `finite' function
   in BSD.

   Also, isfinite is broken on Cygwin.

   When isfinite is not available, try to use one of the
   alternatives, or bail out.  */

#if defined(HAVE_BROKEN_ISFINITE) || defined(__CYGWIN__)
#undef isfinite
#endif

#if defined(HAVE_BROKEN_ISNAN)
#undef isnan
#endif

#if defined(HAVE_BROKEN_FPCLASSIFY)
#undef fpclassify
#endif

#if !defined(isfinite)
#if !defined(fpclassify)
#define isfinite(x) ((x) - (x) == 0)
#else
#define isfinite(x) (fpclassify(x) != FP_NAN && fpclassify(x) != FP_INFINITE)
#endif /* !defined(fpclassify) */
#endif /* !defined(isfinite)  */

#if !defined(isnan)
#if !defined(fpclassify)
#define isnan(x) ((x) != (x))
#else
#define isnan(x) (fpclassify(x) == FP_NAN)
#endif /* !defined(fpclassify) */
#endif /* !defined(isfinite)  */


-- 


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

[Bug testsuite/32841] FAIL: gfortran.dg/edit_real_1.f90 on Darwin8

[dominiq at lps dot ens dot fr]

------- Comment #4 from dominiq at lps dot ens dot fr  2007-07-20 21:20 -------
Subject: Re:  FAIL: gfortran.dg/edit_real_1.f90 on
 Darwin8

I don't know if the following code is correct, but it returns 1:

#include <math.h>
#include <stdio.h>

int main()
{
 double x;

 x = 1.79769313486231570814527423731704356798070567526e+308;

 printf("%1d \n", isfinite(x));
}


-- 


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

[Bug testsuite/32841] FAIL: gfortran.dg/edit_real_1.f90 on Darwin8

[jvdelisle at gcc dot gnu dot org]

------- Comment #5 from jvdelisle at gcc dot gnu dot org  2007-07-20 21:41 -------
Try this:

#include <stdio.h>
#include <stdlib.h>
#include <math.h>

int
main ()
{
  double x, y;

  x = 1.79769313486231570814527423731704356798070567526e+308;

  printf("%52.47e\n", x);
  printf("isfinite = %d\n", isfinite(x));
  printf("isfinite = %d\n", isfinite(1.1 * x));

  return 0;
}

compiled with: gcc -std=c99 -lm test.c

I get:

$ gcc -std=c99 -lm test.c 
$ ./a.out
1.79769313486231570814527423731704356798070567526e+308
isfinite = 1
isfinite = 0


-- 


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

[Bug testsuite/32841] FAIL: gfortran.dg/edit_real_1.f90 on Darwin8

[dominiq at lps dot ens dot fr]

------- Comment #6 from dominiq at lps dot ens dot fr  2007-07-20 22:08 -------
Subject: Re:  FAIL: gfortran.dg/edit_real_1.f90 on
 Darwin8

> Try this: ...

I get

1.79769313486231570814527423731704356798070567526e+308
isfinite = 1
isfinite = 0

There is something I don't understand:
in libgfortran/configure I read:

# Check for a isfinite macro that works on long doubles.

so it seems that HAVE_BROKEN_ISFINITE is set if
isfinite is broken for long doubles (which seems
likely, see the Jack's comment), but it is then used
in libgfortran/libgfortran.h to redefine isfinite
(corresponding to double?). Am I missing something?


-- 


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

[Bug testsuite/32841] FAIL: gfortran.dg/edit_real_1.f90 on Darwin8

[jvdelisle at gcc dot gnu dot org]

------- Comment #7 from jvdelisle at gcc dot gnu dot org  2007-07-20 22:21 -------
Can you post the config.h file from your build directory?

blddir/archdir/libgfortran/config.h


-- 


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

[Bug testsuite/32841] FAIL: gfortran.dg/edit_real_1.f90 on Darwin8

[dominiq at lps dot ens dot fr]

------- Comment #8 from dominiq at lps dot ens dot fr  2007-07-20 22:28 -------
Subject: Re:  FAIL: gfortran.dg/edit_real_1.f90 on
 Darwin8

> Can you post the config.h file from your build directory?

Unfortunately, it is gone (fink install) and I'll be away for two days.
So not before Monday evening French time.


-- 


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

[Bug testsuite/32841] FAIL: gfortran.dg/edit_real_1.f90 on Darwin8

[dominiq at lps dot ens dot fr]

------- Comment #9 from dominiq at lps dot ens dot fr  2007-07-23 14:53 -------
Created an attachment (id=13954)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13954&action=view)
darwin_objdir/powerpc-apple-darwin8/libgfortran/config.h

> Can you post the config.h file from your build directory?

I attached the file


-- 


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

[Bug testsuite/32841] FAIL: gfortran.dg/edit_real_1.f90 on Darwin8

[dominiq at lps dot ens dot fr]

------- Comment #10 from dominiq at lps dot ens dot fr  2007-07-23 15:03 -------
This a regression from 4.2. The following code

real(8) x, y
real(8) down, up
x = huge(x)
y = down(x)
print *, y, up(y)-x, up(up(y))-x, up(up(x))-x
y = up(y)
print *, x, y
end
real(8) function up(x)
real(8) x
up = nearest(x, 1.0d0)
end
real(8) function down(x)
real(8) x
down = nearest(x, -1.0d0)
end

gives with GNU F95 version 4.2.0 (powerpc-apple-darwin8):

  1.797693134862316E+308   0.00000000000000                    +Infinity       
       +Infinity
  1.797693134862316E+308  1.797693134862316E+308

and with GNU F95 version 4.3.0 20070713 (experimental) (powerpc-apple-darwin8)

  1.797693134862316E+308   0.00000000000000                    +Infinity       
       +Infinity
               +Infinity               +Infinity


So the problem seems related to the output and not to a constant folding.


-- 


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

[Bug libfortran/32841] [4.3 regression libfortran] HUGE(1.0d0) is written a +Infinity on Darwin8

[dominiq at lps dot ens dot fr]

------- Comment #11 from dominiq at lps dot ens dot fr  2007-07-24 09:31 -------
The regression occured between revisions 123612 and 123624, see:

http://gcc.gnu.org/ml/gcc-testresults/2007-04/msg00300.html
http://gcc.gnu.org/ml/gcc-testresults/2007-04/msg00311.html

The most likely candidate is revision 123623, though I did not see anything
obviously wrong. Note that writing HUGE(1.0) gives the expected result:

print *,  huge(1.0), huge(1.0d0)
end

  3.4028235E+38               +Infinity


-- 

dominiq at lps dot ens dot fr changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|testsuite                   |libfortran
            Summary|FAIL:                       |[4.3 regression libfortran]
                   |gfortran.dg/edit_real_1.f90 |HUGE(1.0d0) is written a
                   |on Darwin8                  |+Infinity on Darwin8


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

[Bug libfortran/32841] [4.3 regression] HUGE(1.0d0) is written a +Infinity on Darwin8

[jvdelisle at gcc dot gnu dot org]

------- Comment #12 from jvdelisle at gcc dot gnu dot org  2007-07-25 04:45 -------
There were two modifications between these revs:

123620 format.c

123623 write.c

I will take this on.


-- 

jvdelisle at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |jvdelisle at gcc dot gnu dot
                   |dot org                     |org
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2007-07-25 04:45:04
               date|                            |


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

[Bug libfortran/32841] [4.3 regression] HUGE(1.0d0) is written a +Infinity on Darwin8

[jvdelisle at gcc dot gnu dot org]

------- Comment #13 from jvdelisle at gcc dot gnu dot org  2007-07-25 05:28 -------
This is interesting.  Using valgrind induces a problem with huge(1.0_10) on
x86-64

[jerry@quasar test]$ ./a.out 
  3.4028235E+38  1.797693134862316E+308  1.1897314953572317650E+4932
[jerry@quasar test]$ valgrind ./a.out 
==19036== Memcheck, a memory error detector.
==19036== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==19036== Using LibVEX rev 1658, a library for dynamic binary translation.
==19036== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==19036== Using valgrind-3.2.1, a dynamic binary instrumentation framework.
==19036== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==19036== For more details, rerun with: -v
==19036== 
  3.4028235E+38  1.797693134862316E+308                    +Infinity
==19036== 
==19036== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 5 from 1)
==19036== malloc/free: in use at exit: 0 bytes in 0 blocks.
==19036== malloc/free: 12 allocs, 12 frees, 25,910 bytes allocated.
==19036== For counts of detected errors, rerun with: -v
==19036== All heap blocks were freed -- no leaks are possible.



-- 


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

[Bug libfortran/32841] [4.3 regression] HUGE(1.0d0) is written a +Infinity on Darwin8

[dominiq at lps dot ens dot fr]

------- Comment #14 from dominiq at lps dot ens dot fr  2007-07-25 06:38 -------
Subject: Re:  [4.3 regression] HUGE(1.0d0) is written a
 +Infinity on Darwin8

> There were two modifications between these revs:
> 123620 format.c
> 123623 write.c

Yes, but the first one is very short and not connected
to isfinite while the second one has a lot of change
in config* among others.


-- 


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

[Bug libfortran/32841] [4.3 regression] HUGE(1.0d0) is written a +Infinity on Darwin8

[dominiq at lps dot ens dot fr]

------- Comment #15 from dominiq at lps dot ens dot fr  2007-07-25 06:41 -------
Subject: Re:  [4.3 regression] HUGE(1.0d0) is written a
 +Infinity on Darwin8

Forgot to say in my previous mail that libgfortran/config.h for
gcc4.2.1 contains:

...
/* Define if fpclassify is broken. */
/* #undef HAVE_BROKEN_FPCLASSIFY */

/* Define if isfinite is broken. */
#define HAVE_BROKEN_ISFINITE 1

/* Define if isnan is broken. */
/* #undef HAVE_BROKEN_ISNAN */
...


-- 


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

[Bug libfortran/32841] [4.3 regression] HUGE(1.0d0) is written a +Infinity on Darwin8

[jvdelisle at gcc dot gnu dot org]

------- Comment #16 from jvdelisle at gcc dot gnu dot org  2007-07-25 22:38 -------
Dominique,

Maybe you could try to delete the conditional defines that redefine isfinite so
that the native calls are used and see if the problem goes away.


-- 


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

[Bug libfortran/32841] [4.3 regression] HUGE(1.0d0) is written a +Infinity on Darwin8

[dominiq at lps dot ens dot fr]

------- Comment #17 from dominiq at lps dot ens dot fr  2007-07-27 05:56 -------
Subject: Re:  [4.3 regression] HUGE(1.0d0) is written a
 +Infinity on Darwin8

> Maybe you could try to delete the conditional defines that redefine isfinite so
> that the native calls are used and see if the problem goes away.

I have done something slightly different, but with the same result,
I have moved line 167:

#undef isfinite

outside the 

#if defined(HAVE_BROKEN_ISFINITE) || defined(__CYGWIN__)

block. This change fixes the bug, edit_real_1.f90 pass.

Now the questions are 
(1) why HAVE_BROKEN_ISFINITE is not set by gcc 4.3 while it
is by gcc 4.2?
(2) if the isfinite used by C is working, why isfinite is
not working for libfortran?


-- 


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

[Bug libfortran/32841] [4.3 regression] HUGE(1.0d0) output as +Infinity on ppc-darwin8

[fxcoudert at gcc dot gnu dot org]

------- Comment #18 from fxcoudert at gcc dot gnu dot org  2007-07-27 06:50 -------
Hum, I don't see anything in rev. 123623
(http://gcc.gnu.org/viewcvs?view=rev&revision=123623) that looks too
suspicious. What would need to be done now, in my opinion, is to:
  1. check that rev. 123622 passes,
  2. check that rev.123623 fails,
  3a. check if reverting the libgfortran/io/write.c change makes it pass again
  3b. check whether reverting the change to libgfortran/configure.ac makes it
pass again (after autoreconf && automake in that directory)

This really has the cost of only (sic) one bootstrap, since only libgfortran
needs rebuilding each time. I don't have a ppc-darwin computer anymore, so I
unfortunately can't test.


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fxcoudert at gcc dot gnu dot
                   |                            |org
            Summary|[4.3 regression] HUGE(1.0d0)|[4.3 regression] HUGE(1.0d0)
                   |is written a +Infinity on   |output as +Infinity on ppc-
                   |Darwin8                     |darwin8


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

[Bug libfortran/32841] [4.3 regression] HUGE(1.0d0) output as +Infinity on ppc-darwin8

[dominiq at lps dot ens dot fr]

------- Comment #19 from dominiq at lps dot ens dot fr  2007-07-27 19:34 -------
Subject: Re:  [4.3 regression] HUGE(1.0d0) output as
 +Infinity on ppc-darwin8

> Hum, I don't see anything in rev. 123623
> (http://gcc.gnu.org/viewcvs?view=rev&revision=123623) that looks too
> suspicious. What would need to be done now, in my opinion, is to:
>  1. check that rev. 123622 passes,
>  ...

I cannot say that I am fond of this brute force approach!-(it has to go too far
in the past to look practical). Before that I'ld like to understand what's
going wrong. In the meantime a quick and blind fix is to replace in
libgfortran/libgfortran.h the line

#if defined(HAVE_BROKEN_ISFINITE) || defined(__CYGWIN__)

by

#if defined(HAVE_BROKEN_ISFINITE) || defined(__CYGWIN__) ||
defined(whatever_for_PPC_Darwin)

This fix the failure:

FAIL: gfortran.dg/large_real_kind_2.F90  -O0  execution test
FAIL: gfortran.dg/large_real_kind_2.F90  -O1  execution test
FAIL: gfortran.dg/large_real_kind_2.F90  -O2  execution test
FAIL: gfortran.dg/large_real_kind_2.F90  -O3 -fomit-frame-pointer  execution
test
FAIL: gfortran.dg/large_real_kind_2.F90  -O3 -fomit-frame-pointer
-funroll-loops  execution test
FAIL: gfortran.dg/large_real_kind_2.F90  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  execution test
FAIL: gfortran.dg/large_real_kind_2.F90  -O3 -g  execution test
FAIL: gfortran.dg/large_real_kind_2.F90  -Os  execution test
FAIL: gfortran.dg/large_real_kind_form_io_2.f90  -O0  execution test
FAIL: gfortran.dg/large_real_kind_form_io_2.f90  -O1  execution test
FAIL: gfortran.dg/large_real_kind_form_io_2.f90  -O2  execution test
FAIL: gfortran.dg/large_real_kind_form_io_2.f90  -O3 -fomit-frame-pointer 
execution test
FAIL: gfortran.dg/large_real_kind_form_io_2.f90  -O3 -fomit-frame-pointer
-funroll-loops  execution test
FAIL: gfortran.dg/large_real_kind_form_io_2.f90  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  execution test
FAIL: gfortran.dg/large_real_kind_form_io_2.f90  -O3 -g  execution test
FAIL: gfortran.dg/large_real_kind_form_io_2.f90  -Os  execution test
FAIL: gfortran.fortran-torture/compile/pr32417.f90,  "-O"   (internal compiler
error)

                === gfortran Summary for unix/-m32 ===

# of expected passes            19398
# of unexpected failures        17
# of expected failures          9
# of unsupported tests          58

/opt/gcc/darwin_build/gcc/testsuite/gfortran/../../gfortran  version 4.3.0
20070720 (experimental)

Now among the many things I don't understand is the following facts.

(1) the following program:

#include <stdio.h>
#include <stdlib.h>
#ifdef HAVE_MATH_H
#include <math.h>
#endif
#include <float.h>
int main ()
{
#ifdef isfinite
#ifdef LDBL_MAX
  printf("LDBL_MAX is defined\n");
  if (!isfinite(LDBL_MAX)) printf("bad long double\n");
#endif
#ifdef DBL_MAX
   printf("DBL_MAX is defined\n");
  if (!isfinite(DBL_MAX)) printf("bad double\n");
#endif
  printf("isfinite defined\n");
#endif
printf("end of test\n");
}

gives:

LDBL_MAX is defined
bad long double
DBL_MAX is defined
isfinite defined
end of test

when compiled with gcc version 4.3.0 20070720 and 

LDBL_MAX is defined
DBL_MAX is defined
isfinite defined
end of test

when compiled with gcc version 4.0.1 (Apple Computer, Inc. build 5367)
using gcc?? -DHAVE_MATH_H isfinite_p.c (gcc?? stands for the different
flavors).

By any chance is it possible that libgfortran/configure uses
the system gcc and not xgcc?  In that case that would explain
why the broken isfinite is not detected.

(2) From this it seems that isfinite(DBL_MAX) is working.
Why is it not working when writing HUGE(1.0d0)?
Does the writing use long doubles?


-- 


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

[Bug libfortran/32841] [4.3 regression] HUGE(1.0d0) output as +Infinity on ppc-darwin8

[jvdelisle at gcc dot gnu dot org]

------- Comment #20 from jvdelisle at gcc dot gnu dot org  2007-07-27 20:40 -------
Dominique,

I have the same problem as FX.  I do not have access to this platform.  If I
could  secure shell (ssh) into one of these, I would work on this.

Your idea on the order of #defines is probably on the right track.  Jannes
patch did tweak the includes somewhat.


-- 


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

[Bug libfortran/32841] [4.3 regression] HUGE(1.0d0) output as +Infinity on ppc-darwin8

[dominiq at lps dot ens dot fr]

------- Comment #21 from dominiq at lps dot ens dot fr  2007-07-27 21:43 -------
Subject: Re:  [4.3 regression] HUGE(1.0d0) output as
 +Infinity on ppc-darwin8

> Your idea on the order of #defines is probably on the right track.

As I said, this is the quickest way to hide the problem.
I have tested that it works and it's only the matter
to know the equivalent of __CYGWIN__ for powerpc-darwin to
implement it.

Indeed it won't help to understand the origin of the problem
which may resurface in an other context. It would help
to have answers to the following questions:

(1) why isfinite(DBL_MAX) is working, but not isfinite(HUGE(1.0d0))?
Does libfortran convert HUGE(1.0d0) to long double?
If not, what's happening?

(2) Does configure use the system gcc or xgcc from the latest stage?
In the first case, this explain why HAVE_BROKEN_ISFINITE is not
defined, but raise the question of the relevance of building
gcc through 3 stages while keeping the config at stage 1.
I the second case, why HAVE_BROKEN_ISFINITE is not defined?


-- 


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

[Bug libfortran/32841] [4.3 regression] HUGE(1.0d0) output as +Infinity on ppc-darwin8

[fxcoudert at gcc dot gnu dot org]

------- Comment #23 from fxcoudert at gcc dot gnu dot org  2007-07-27 23:46 -------
(In reply to comment #22)
> So we could fix this by doing the extract_real differently.  Let em give this 
> further thought.

I plan to change that in the future, because always converting to the longest
floating-point type is probably not efficient. In my opinion, we need
specialized versions of this code for each floating-point type, but it requires
a bit of clear thinking to minimize code duplication and to ease maintainance.


-- 


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

[Bug libfortran/32841] [4.3 regression] HUGE(1.0d0) output as +Infinity on ppc-darwin8

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.3.0


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

[Bug libfortran/32841] [4.3 regression] HUGE(1.0d0) output as +Infinity on ppc-darwin8

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P5


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

[Bug libfortran/32841] [4.3 regression] HUGE(1.0_16) output as +Infinity on ppc-darwin8

[fxcoudert at gcc dot gnu dot org]

------- Comment #24 from fxcoudert at gcc dot gnu dot org  2007-09-29 23:15 -------
First, I should note that this doesn't affect real kinds 4 and 8, due to
Jerry's per-kind I/O change; this bug now only shows up for real(kind=16).
Second, this is a problem with huge(0._16) not being equal to LDBL_MAX, see
http://gcc.gnu.org/ml/fortran/2007-09/msg00461.html for details.


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|jvdelisle at gcc dot gnu dot|fxcoudert at gcc dot gnu dot
                   |org                         |org
            Summary|[4.3 regression] HUGE(1.0d0)|[4.3 regression]
                   |output as +Infinity on ppc- |HUGE(1.0_16) output as
                   |darwin8                     |+Infinity on ppc-darwin8


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

[Bug libfortran/32841] [4.3 regression] HUGE(1.0_16) output as +Infinity on ppc-darwin8

[fxcoudert at gcc dot gnu dot org]

------- Comment #25 from fxcoudert at gcc dot gnu dot org  2007-09-29 23:20 -------
I should have posted my reduced testcase, so that I don't lose it:

real(16) :: y
y=huge(y)
write(*,"(G60.50E4)") y
write(*,"(G60.50E4)") nearest(y,1.)
end


-- 


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

[Bug libfortran/32841] [4.3 regression] HUGE(1.0_16) output as +Infinity on ppc-darwin8 (gfortran.dg/large_real_kind_2.F90)

[burnus at gcc dot gnu dot org]

------- Comment #26 from burnus at gcc dot gnu dot org  2008-01-17 10:52 -------
gfortran.dg/large_real_kind_2.F90 also fails on sparc-linux-gnu with "-m64",
see:
http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg00724.html


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.3 regression]            |[4.3 regression]
                   |HUGE(1.0_16) output as      |HUGE(1.0_16) output as
                   |+Infinity on ppc-darwin8    |+Infinity on ppc-darwin8
                   |                            |(gfortran.dg/large_real_kind
                   |                            |_2.F90)


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

[Bug libfortran/32841] [4.3 regression] HUGE(1.0_16) output as +Infinity on ppc-darwin8 (gfortran.dg/large_real_kind_2.F90)

[dominiq at lps dot ens dot fr]

------- Comment #27 from dominiq at lps dot ens dot fr  2008-01-25 15:39 -------
See also pr24685.


-- 


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

[Bug libfortran/32841] [4.3/4.4 regression] HUGE(1.0_16) output as +Infinity on ppc-darwin8 (gfortran.dg/large_real_kind_2.F90)

[fxcoudert at gcc dot gnu dot org]

------- Comment #28 from fxcoudert at gcc dot gnu dot org  2008-02-21 13:50 -------
That 27-headed (and counting!) monster PR is really hard to deal with. Here is
some more information:

  -- On powerpc-apple-darwin-9.2.0 (MacOS 10.5.2), the testcases in comments #0
(original report) and #10 gives correct results.

  -- On powerpc-apple-darwin-9.2.0, however, the following C testcase:

#include <stdio.h>
#include <math.h>
#include <float.h>

int main ()
{
  if (!isfinite(LDBL_MAX))
    puts("LDBL_MAX should be finite!");
}

gives wrong results (printing out "LDBL_MAX should be finite!") with gcc-4.4
and the system gcc 4.0.1 (Apple Inc. build 5465). It works with the system gcc
3.3 20030304 (Apple Computer, Inc. build 1823). I've submitted it to Apple as
#5757007.

  -- On powerpc-apple-darwin-9.2.0, HAVE_BROKEN_ISFINITE is not set, while
clearly it should! Digging out, it is because the testcase is run without
including math.h, and that makes it work (ie, if in the C testcase above, you
remove the line including <math.h>, the testcase passes!). Why HAVE_MATH_H is
not defined is beyond my understanding, but since it's the only place in
libgfortran where we actually worry about it, I suggest we simply remove it.

  -- Working around the isfinite() bug above is possible by using
__builtin_isfinite(), which works fine. I think, however, we can't do that
unconditionally as, IIRC, not all targets are able to expand
__builtin_isfinite().


-- 


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

[Bug libfortran/32841] [4.3/4.4 regression] HUGE(1.0_16) output as +Infinity on ppc-darwin8 (gfortran.dg/large_real_kind_2.F90)

[fxcoudert at gcc dot gnu dot org]

------- Comment #29 from fxcoudert at gcc dot gnu dot org  2008-02-24 11:59 -------
Subject: Bug 32841

Author: fxcoudert
Date: Sun Feb 24 11:59:09 2008
New Revision: 132587

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132587
Log:
        PR libfortran/32841
        * acinclude.m4: Don't use HAVE_MATH_H.
        * configure: Regenerate.

Modified:
    trunk/libgfortran/ChangeLog
    trunk/libgfortran/acinclude.m4
    trunk/libgfortran/configure


-- 


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

[Bug libfortran/32841] [4.3/4.4 regression] HUGE(1.0_16) output as +Infinity on ppc-darwin8 (gfortran.dg/large_real_kind_2.F90)

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|fxcoudert at gcc dot gnu dot|unassigned at gcc dot gnu
                   |org                         |dot org
             Status|ASSIGNED                    |NEW


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

[Bug libfortran/32841] [4.3/4.4 regression] HUGE(1.0_16) output as +Infinity on ppc-darwin8 (gfortran.dg/large_real_kind_2.F90)

[fxcoudert at gcc dot gnu dot org]

------- Comment #30 from fxcoudert at gcc dot gnu dot org  2008-02-24 12:09 -------
So, this was demonstrated to not be a problem on powerpc-apple-darwin9.2.0 any
more. We thus need to establish whether this was fixed in libgfortran or
whether this was fixed in the darwin8 -> darwin9 transition. To do that, the 
testcases in comments #0 (original report) and #10 should be tested on a
powerpc-apple-darwin8 machine; both the cases of a compiler configured on
powerpc-apple-darwin8 and a compiler configured on powerpc-apple-darwin9 but
run on powerpc-apple-darwin8 might prove interesting.

Other than that, I don't think there's much we can do. Related PR24685 was
closed as INVALID after showing it is due to a system libc bug (reported to
Apple). Even if we tracked this one down, the conclusion would probably be the
same :(  For now, I'm marking it as WAITING. If noone can provide information
in the near future, I'll support closing it altogether.

(The sparc-linux failure with -m64 is, as far as we know, unrelated; if more
information if available, a new PR should be open.)


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING


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

[Bug libfortran/32841] [4.3/4.4 regression] HUGE(1.0_16) output as +Infinity on ppc-darwin8 (gfortran.dg/large_real_kind_2.F90)

[dominiq at lps dot ens dot fr]

------- Comment #31 from dominiq at lps dot ens dot fr  2008-02-25 13:46 -------
Subject: Re:  [4.3/4.4 regression] HUGE(1.0_16) output
 as +Infinity on ppc-darwin8 (gfortran.dg/large_real_kind_2.F90)

Answer to comment #30:

> a compiler configured on powerpc-apple-darwin9 but
> run on powerpc-apple-darwin8 might prove interesting.

I am not sure this will be possible. For other reasons I tried it on Intel
and got the following error:

[ibook-dhum] gcc/i686-darwin% /Volumes/OSX_10.5/opt/gcc/gcc4.4w/bin/gfortran -v
dyld: Library not loaded: /usr/lib/libiconv.2.dylib
  Referenced from: /Volumes/OSX_10.5/opt/gcc/gcc4.4w/bin/gfortran
  Reason: Incompatible library version: gfortran requires version 7.0.0 or
later, but libiconv.2.dylib provides version 5.0.0
Trace/BPT trap


-- 


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

[Bug libfortran/32841] [4.3/4.4 regression] HUGE(1.0_16) output as +Infinity on ppc-darwin8 (gfortran.dg/large_real_kind_2.F90)

[fxcoudert at gcc dot gnu dot org]

------- Comment #32 from fxcoudert at gcc dot gnu dot org  2008-03-12 10:36 -------
(In reply to comment #31)
>> a compiler configured on powerpc-apple-darwin9 but
>> run on powerpc-apple-darwin8 might prove interesting.
> 
> I am not sure this will be possible. For other reasons I tried it on Intel
> and got the following error:

OK, then we only have: "the testcases in comments #0 (original report) and #10
should be tested on a powerpc-apple-darwin8 machine". Given the high
probability that, if it still fails on ppc-apple-darwin8, it is a bug in MacOS
libraries, I'm closing this PR. If someone can test or has more information,
please reopen it (or open another report).


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |INVALID


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