[Bug fortran/33271] New: nint_2.f90 abort compiled with -O0

[Bug fortran/33271] New: nint_2.f90 abort compiled with -O0

[michelin60 at gmail dot com]

This is at the specific request of Mr. Coudert.

Testsuite output:

Executing on host: /var/tmp/43/build-159/gcc/testsuite/gfortran/../../gfortran
-B/var/tmp/43/build-159/gcc/testsuite/gfortran/../../
/var/tmp/43/gcc-4.3.0/gcc/testsuite/gfortran.dg/nint_2.f90   -O0  
-pedantic-errors 
-L/var/tmp/43/build-159/powerpc-unknown-linux-gnu/./libgfortran/.libs
-L/var/tmp/43/build-159/powerpc-unknown-linux-gnu/./libgfortran/.libs
-L/var/tmp/43/build-159/powerpc-unknown-linux-gnu/./libiberty  -lm   -o
./nint_2.exe    (timeout = 300)
PASS: gfortran.dg/nint_2.f90  -O0  (test for excess errors)
Setting LD_LIBRARY_PATH to
.:/var/tmp/43/build-159/powerpc-unknown-linux-gnu/./libgfortran/.libs:/var/tmp/43/build-159/powerpc-unknown-linux-gnu/./libgfortran/.libs:/var/tmp/43/build-159/gcc:.:/var/tmp/43/build-159/powerpc-unknown-linux-gnu/./libgfortran/.libs:/var/tmp/43/build-159/powerpc-unknown-linux-gnu/./libgfortran/.libs:/var/tmp/43/build-159/gcc:/var/tmp/43/build-159/powerpc-unknown-linux-gnu/libstdc++-v3/.libs:/var/tmp/43/build-159/powerpc-unknown-linux-gnu/libgomp/.libs:/var/tmp/43/build-159/./gcc:/var/tmp/43/build-159/./prev-gcc
FAIL: gfortran.dg/nint_2.f90  -O0  execution test

This is the compile command for the standard standard x.i file

/var/tmp/43/build-159/gcc/testsuite/gfortran/../../gfortran -v -save-temps
-B/var/tmp/43/build-159/gcc/testsuite/gfortran/../../
/var/tmp/43/gcc-4.3.0/gcc/testsuite/gfortran.dg/nint_2.f90   -O0  
-pedantic-errors 
-L/var/tmp/43/build-159/powerpc-unknown-linux-gnu/./libgfortran/.libs
-L/var/tmp/43/build-159/powerpc-unknown-linux-gnu/./libgfortran/.libs
-L/var/tmp/43/build-159/powerpc-unknown-linux-gnu/./libiberty  -lm   -o
./nint_2.exe  

The resulting compiler message:

Driving: /var/tmp/43/build-159/gcc/testsuite/gfortran/../../gfortran -v
-save-temps -B/var/tmp/43/build-159/gcc/testsuite/gfortran/../../
/var/tmp/43/gcc-4.3.0/gcc/testsuite/gfortran.dg/nint_2.f90 -O0 -pedantic-errors
-L/var/tmp/43/build-159/powerpc-unknown-linux-gnu/./libgfortran/.libs
-L/var/tmp/43/build-159/powerpc-unknown-linux-gnu/./libgfortran/.libs
-L/var/tmp/43/build-159/powerpc-unknown-linux-gnu/./libiberty -lgfortranbegin
-lgfortran -lm -o ./nint_2.exe -lgfortran -lm -shared-libgcc
Reading specs from /var/tmp/43/build-159/gcc/testsuite/gfortran/../../specs
Target: powerpc-unknown-linux-gnu
Configured with: ../gcc-4.3.0/configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --host=powerpc-unknown-linux-gnu
--build=powerpc-unknown-linux-gnu --enable-__cxa_atexit --enable-threads=posix
--enable-shared --enable-clocale=gnu --enable-bootstrap
--enable-languages=c,fortran,c++ --enable-altivec --disable-libssp
--disable-decimal-float --disable-libmudflap --disable-nls --disable-werror
--disable-multilib --with-ibmlongdouble --with-cpu=G4 --enable-clocale=gnu
--with-system-zlib
Thread model: posix
gcc version 4.3.0 20070831 (experimental) (GCC) 
 /var/tmp/43/build-159/gcc/testsuite/gfortran/../../f951
/var/tmp/43/gcc-4.3.0/gcc/testsuite/gfortran.dg/nint_2.f90 -quiet -dumpbase
nint_2.f90 -mcpu=G4 -auxbase nint_2 -O0 -pedantic-errors -version
-fintrinsic-modules-path /usr/lib/gcc/powerpc-unknown-linux-gnu/4.3.0/finclude
-o nint_2.s
GNU F95 (GCC) version 4.3.0 20070831 (experimental) (powerpc-unknown-linux-gnu)
        compiled by GNU C version 4.3.0 20070831 (experimental), GMP version
4.2.1, MPFR version 2.2.1-p5.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
 /var/tmp/43/build-159/gcc/testsuite/gfortran/../../as -mppc -maltivec -many -V
-Qy -o nint_2.o nint_2.s
GNU assembler version 2.18 (powerpc-unknown-linux-gnu) using BFD version (GNU
Binutils) 2.18
 /var/tmp/43/build-159/gcc/testsuite/gfortran/../../collect2 --eh-frame-hdr -V
-Qy -m elf32ppclinux -dynamic-linker /lib/ld.so.1 -o ./nint_2.exe
/usr/lib/crt1.o /usr/lib/crti.o
/var/tmp/43/build-159/gcc/testsuite/gfortran/../../crtbegin.o
-L/var/tmp/43/build-159/powerpc-unknown-linux-gnu/./libgfortran/.libs
-L/var/tmp/43/build-159/powerpc-unknown-linux-gnu/./libgfortran/.libs
-L/var/tmp/43/build-159/powerpc-unknown-linux-gnu/./libiberty
-L/var/tmp/43/build-159/gcc/testsuite/gfortran/../..
-L/usr/lib/gcc/powerpc-unknown-linux-gnu/4.3.0 nint_2.o -lgfortranbegin
-lgfortran -lm -lgfortran -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
/var/tmp/43/build-159/gcc/testsuite/gfortran/../../crtsavres.o
/var/tmp/43/build-159/gcc/testsuite/gfortran/../../crtend.o /usr/lib/crtn.o
GNU ld (GNU Binutils) 2.18
  Supported emulations:
   elf32ppclinux
   elf32ppc
   elf32ppcsim
   elf64ppc


This is the resulting nint_2.s:


        .file   "nint_2.f90"
        .gnu_attribute 4, 1
        .gnu_attribute 8, 1
        .section        .rodata
        .align 2
        .type   options.0.1387, @object
        .size   options.0.1387, 28
options.0.1387:
        .long   102
        .long   127
        .long   1
        .long   0
        .long   0
        .long   1
        .long   0
        .section        ".text"
        .align 2
        .globl MAIN__
        .type   MAIN__, @function
MAIN__:
        stwu 1,-80(1)
        mflr 0
        stw 0,84(1)
        stw 31,76(1)
        mr 31,1
        li 3,7
        lis 9,options.0.1387@ha
        la 4,options.0.1387@l(9)
        bl _gfortran_set_options
        lis 9,.LC0@ha
        lfd 0,.LC0@l(9)
        stfd 0,40(31)
        li 9,0
        li 10,0
        stw 9,24(31)
        stw 10,28(31)
        lfd 1,40(31)
        bl lround
        mr 0,3
        stw 0,20(31)
        srawi 0,0,31
        stw 0,16(31)
        lwz 0,16(31)
        lwz 9,20(31)
        or 0,0,9
        cmpwi 7,0,0
        bne 7,.L2
        lwz 0,24(31)
        lwz 9,28(31)
        or 0,0,9
        cmpwi 7,0,0
        beq 7,.L3
.L2:
        bl _gfortran_abort
.L3:
        lis 9,.LC1@ha
        lfd 0,.LC1@l(9)
        stfd 0,40(31)
        li 9,0
        li 10,1
        stw 9,24(31)
        stw 10,28(31)
        lfd 1,40(31)
        bl lround
        mr 0,3
        stw 0,20(31)
        srawi 0,0,31
        stw 0,16(31)
        lwz 0,16(31)
        cmpwi 7,0,0
        bne 7,.L4
        lwz 0,20(31)
        cmpwi 7,0,1
        bne 7,.L4
        lwz 0,24(31)
        cmpwi 7,0,0
        bne 7,.L4
        lwz 0,28(31)
        cmpwi 7,0,1
        beq 7,.L23
.L4:
        bl _gfortran_abort
.L23:
        lis 9,.LC2@ha
        lfd 0,.LC2@l(9)
        stfd 0,40(31)
        li 9,0
        li 10,1
        stw 9,24(31)
        stw 10,28(31)
        lfd 1,40(31)
        bl lround
        mr 0,3
        stw 0,20(31)
        srawi 0,0,31
        stw 0,16(31)
        lwz 0,16(31)
        cmpwi 7,0,0
        bne 7,.L7
        lwz 0,20(31)
        cmpwi 7,0,1
        bne 7,.L7
        lwz 0,24(31)
        cmpwi 7,0,0
        bne 7,.L7
        lwz 0,28(31)
        cmpwi 7,0,1
        beq 7,.L24
.L7:
        bl _gfortran_abort
.L24:
        lis 9,.LC3@ha
        lfs 0,.LC3@l(9)
        stfs 0,12(31)
        li 0,0
        stw 0,32(31)
        lfs 1,12(31)
        bl lroundf
        mr 0,3
        stw 0,8(31)
        lwz 0,8(31)
        cmpwi 7,0,0
        bne 7,.L10
        lwz 0,32(31)
        cmpwi 7,0,0
        beq 7,.L11
.L10:
        bl _gfortran_abort
.L11:
        lis 9,.LC4@ha
        lfs 0,.LC4@l(9)
        stfs 0,12(31)
        li 0,1
        stw 0,32(31)
        lfs 1,12(31)
        bl lroundf
        mr 0,3
        stw 0,8(31)
        lwz 0,8(31)
        cmpwi 7,0,1
        bne 7,.L12
        lwz 0,32(31)
        cmpwi 7,0,1
        beq 7,.L13
.L12:
        bl _gfortran_abort
.L13:
        lis 9,.LC5@ha
        lfs 0,.LC5@l(9)
        stfs 0,12(31)
        li 0,1
        stw 0,32(31)
        lfs 1,12(31)
        bl lroundf
        mr 0,3
        stw 0,8(31)
        lwz 0,8(31)
        cmpwi 7,0,1
        bne 7,.L14
        lwz 0,32(31)
        cmpwi 7,0,1
        beq 7,.L15
.L14:
        bl _gfortran_abort
.L15:
        lis 9,.LC6@ha
        lfd 0,.LC6@l(9)
        stfd 0,40(31)
        lfd 1,40(31)
        bl llround
        mr 10,4
        mr 9,3
        stw 9,16(31)
        stw 10,20(31)
        lis 9,0x10
        li 10,1
        stw 9,24(31)
        stw 10,28(31)
        lwz 9,16(31)
        lwz 0,24(31)
        cmpw 7,9,0
        bne 7,.L16
        lwz 0,20(31)
        lwz 9,28(31)
        cmpw 7,0,9
        bne 7,.L16
        lwz 0,16(31)
        lis 9,0x10
        cmpw 7,0,9
        bne 7,.L16
        lwz 0,20(31)
        cmpwi 7,0,1
        beq 7,.L25
.L16:
        bl _gfortran_abort
.L25:
        lis 9,.LC7@ha
        lfd 0,.LC7@l(9)
        stfd 0,40(31)
        lfd 1,40(31)
        bl llround
        mr 10,4
        mr 9,3
        stw 9,16(31)
        stw 10,20(31)
        lis 9,0xffef
        ori 9,9,65535
        li 10,-1
        stw 9,24(31)
        stw 10,28(31)
        lwz 9,16(31)
        lwz 0,24(31)
        cmpw 7,9,0
        bne 7,.L19
        lwz 0,20(31)
        lwz 9,28(31)
        cmpw 7,0,9
        bne 7,.L19
        lwz 9,16(31)
        lis 0,0xffef
        ori 0,0,65535
        cmpw 7,9,0
        bne 7,.L19
        lwz 0,20(31)
        li 9,-1
        cmpw 7,0,9
        beq 7,.L26
.L19:
        bl _gfortran_abort
.L26:
        lwz 11,0(1)
        lwz 0,4(11)
        mtlr 0
        lwz 31,-4(11)
        mr 1,11
        blr
        .size   MAIN__, .-MAIN__
        .section        .rodata
        .align 3
.LC0:
        .long   1071644671
        .long   -1
        .align 3
.LC1:
        .long   1071644672
        .long   0
        .align 3
.LC2:
        .long   1071644672
        .long   1
        .align 2
.LC3:
        .long   1056964607
        .align 2
.LC4:
        .long   1056964608
        .align 2
.LC5:
        .long   1056964609
        .align 3
.LC6:
        .long   1127219200
        .long   1
        .align 3
.LC7:
        .long   -1020264448
        .long   1
        .ident  "GCC: (GNU) 4.3.0 20070831 (experimental)"
        .section        .note.GNU-stack,"",@progbits


The resulting executable came up with Abort.

I recompile with -O1 and execution was OK:

At your disposal for any further requests.


-- 
           Summary: nint_2.f90 abort compiled with -O0
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: michelin60 at gmail dot com
 GCC build triplet: powerpc
  GCC host triplet: powerpc
GCC target triplet: powerpc


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

[Bug fortran/33271] nint_2.f90 abort compiled with -O0

[michelin60 at gmail dot com]

------- Comment #1 from michelin60 at gmail dot com  2007-08-31 15:36 -------
While I am properly logged in I did not even try using the attachment ptocess
given the difficulties Torsten and myself had with PR33126 and PR33252


-- 

michelin60 at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fxcoudert at gcc dot gnu dot
                   |                            |org


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

[Bug fortran/33271] nint_2.f90 abort compiled with -O0

[fxcoudert at gcc dot gnu dot org]

------- Comment #2 from fxcoudert at gcc dot gnu dot org  2007-08-31 16:36 -------
Could you compile with "-O0 -fdump-tree-original" and attach the
nint_3.f90.003t.original file (or similarly named)? Could you also run with
"-O1 -fdump-tree-optimized" and attach nint_3.f90.115t.optimized (or similarly
named)?

Thanks!


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  GCC build triplet|powerpc                     |powerpc-unknown-linux-gnu
   GCC host triplet|powerpc                     |powerpc-unknown-linux-gnu
 GCC target triplet|powerpc                     |powerpc-unknown-linux-gnu


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

[Bug fortran/33271] nint_2.f90 abort compiled with -O0

[michelin60 at gmail dot com]

------- Comment #3 from michelin60 at gmail dot com  2007-08-31 17:24 -------
> Could you compile with "-O0 -fdump-tree-original" and attach the
> nint_3.f90.003t.original file (or similarly named)? Could you also run with
> "-O1 -fdump-tree-optimized" and attach nint_3.f90.115t.optimized (or similarly
> named)?

No problem but some questions:

A) I see that you and others put a number of patches and regenerations. Do you
want me to rebootstrap and then do it? If an earlier version is acceptable do
you want using the test command as amended per above can  I do outside of the
gcc tree?

If outside the tree I can do it right now. I also hope that the attachment
process works again. personally I had no problems until PR33252. I presume you
are in Europe with a 6 hour time difference. 

I will do it on nint_2.f90 right now to try the attachment nint_3.f90 migh have
been a slip on your part. They are small thus not attached.


Original:

MAIN__ ()
{
  real8 a;
  int4 j2;
  int8 i2;
  int8 i1;
  real4 b;
  int4 j1;
  static int4 options.0[7] = {68, 127, 0, 0, 0, 1, 0};

  _gfortran_set_options (7, (void *) &options.0);
  a = 4.99999999999999944488848768742172978818416595459e-1;
  i2 = 0;
  i1 = (int8) __builtin_lround (a);
  if (i1 != 0 || i2 != 0)
    {
      _gfortran_abort ();
    }
  a = 5.0e-1;
  i2 = 1;
  i1 = (int8) __builtin_lround (a);
  if (i1 != 1 || i2 != 1)
    {
      _gfortran_abort ();
    }
  a = 5.00000000000000111022302462515654042363166809082e-1;
  i2 = 1;
  i1 = (int8) __builtin_lround (a);
  if (i1 != 1 || i2 != 1)
    {
      _gfortran_abort ();
    }
  b = 4.999999701976776123046875e-1;
  j2 = 0;
  j1 = (int4) __builtin_lroundf (b);
  if (j1 != 0 || j2 != 0)
    {
      _gfortran_abort ();
    }
  b = 5.0e-1;
  j2 = 1;
  j1 = (int4) __builtin_lroundf (b);
  if (j1 != 1 || j2 != 1)
    {
      _gfortran_abort ();
    }
  b = 5.00000059604644775390625e-1;
  j2 = 1;
  j1 = (int4) __builtin_lroundf (b);
  if (j1 != 1 || j2 != 1)
    {
      _gfortran_abort ();
    }
  a = 4.503599627370497e+15;
  i1 = __builtin_llround (a);
  i2 = 4503599627370497;
  if (i1 != i2 || i1 != 4503599627370497)
    {
      _gfortran_abort ();
    }
  a = -4.503599627370497e+15;
  i1 = __builtin_llround (a);
  i2 = -4503599627370497;
  if (i1 != i2 || i1 != -4503599627370497)
    {
      _gfortran_abort ();
    }
}


Optimized:  ?????

;; Function MAIN__ (MAIN__)

Analyzing Edge Insertions.
MAIN__ ()
{
  static int4 options.0[7] = {68, 127, 0, 0, 0, 1, 0};

<bb 2>:
  _gfortran_set_options (7, &options.0);
  return;

}
Invalid sum of incoming frequencies 10000, should be 9053


-- 


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

[Bug fortran/33271] nint_2.f90 abort compiled with -O0

[fxcoudert at gcc dot gnu dot org]

------- Comment #4 from fxcoudert at gcc dot gnu dot org  2007-09-03 10:04 -------
(In reply to comment #3)
> A) I see that you and others put a number of patches and regenerations. Do you
> want me to rebootstrap and then do it?

I don't think we've touched anything who should affect this since you filed the
PR, so no real need to update.

It starts to sound like a library problem... could you compile and run the
following C source:

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

int main (void)
{
  double a;
  float b;
  int j1, j2;
  long long int i1, i2;

  printf ("%lu %lu %lu\n", sizeof(int), sizeof(long int), sizeof(long long
int));

  a = 4.99999999999999944488848768742172978818416595459e-1L;
  i2 = 0;
  i1 = (long long int) __builtin_lround (a);
  if (i1 != 0 || i2 != 0)
    puts ("Abort 1");
  a = 5.0e-1L;
  i2 = 1;
  i1 = (long long int) __builtin_lround (a);
  if (i1 != 1 || i2 != 1)
    puts ("Abort 2");
  a = 5.00000000000000111022302462515654042363166809082e-1L;
  i2 = 1;
  i1 = (long long int) __builtin_lround (a);
  if (i1 != 1 || i2 != 1)
    puts ("Abort 3");
  b = 4.999999701976776123046875e-1;
  j2 = 0;
  j1 = (int) __builtin_lroundf (b);
  if (j1 != 0 || j2 != 0)
    puts ("Abort 4");
  b = 5.0e-1;
  j2 = 1;
  j1 = (int) __builtin_lroundf (b);
  if (j1 != 1 || j2 != 1)
    puts ("Abort 5");
  b = 5.00000059604644775390625e-1;
  j2 = 1;
  j1 = (int) __builtin_lroundf (b);
  if (j1 != 1 || j2 != 1)
    puts ("Abort 6");
  a = 4.503599627370497e+15L;
  i1 = __builtin_llround (a);
  i2 = 4503599627370497;
  if (i1 != i2 || i1 != 4503599627370497)
    puts ("Abort 7");
  a = -4.503599627370497e+15L;
  i1 = __builtin_llround (a);
  i2 = -4503599627370497;
  if (i1 != i2 || i1 != -4503599627370497)
    puts ("Abort 8");

  return 0;
}

(gcc a.c -lm -W -Wall; try with -O0 and -O1, I expect it will fail only at
-O0).

One last question: in your build tree, you should have a file named
${builddir}/${target_triplet}/libgfortran/config.h. How does it define the
macros HAVE_LLROUND, HAVE_LLROUNDF, HAVE_LLROUNDL, HAVE_LROUND, HAVE_LROUNDF
and HAVE_LROUNDL?


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
           Keywords|                            |wrong-code
   Last reconfirmed|0000-00-00 00:00:00         |2007-09-03 10:04:32
               date|                            |


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

[Bug fortran/33271] nint_2.f90 abort compiled with -O0

[michelin60 at gmail dot com]

------- Comment #5 from michelin60 at gmail dot com  2007-09-03 13:49 -------

> (gcc a.c -lm -W -Wall; try with -O0 and -O1, I expect it will fail only at
> -O0).
> 
> One last question: in your build tree, you should have a file named
> ${builddir}/${target_triplet}/libgfortran/config.h. How does it define the
> macros HAVE_LLROUND, HAVE_LLROUNDF, HAVE_LLROUNDL, HAVE_LROUND, HAVE_LROUNDF
> and HAVE_LROUNDL?
> 
Let me start off by saying that today is a holiday and that tomoorow I am back
at work and traveling, I am not allowed to use __any__ business assets for GCC
connected activity.

That last question seems beyond my ken. I am running glibc-2.6.1
(the latest official). The GCC tree is just the fairly current svn without any
changes by myself. I am a chemical engineer and computers, compilers are just
tools as far as I am concerned. I certainly do not use the latest for
production work (I have about a dozen compilers that I can make active at any
given time. This is my home machine and completely disconnected from my
company.

We just had an extensive power outage and we just recovering. I will try and
run that program today? the question is with which C compiler ( the latest
Trunk, gcc-4.3.0? 4.1.current? 3.3.6 ? or 3.4.6? and even the junky 4.2.1) I am
not prepared to give you a choice of glibc as going back to earlier versions is
generally discouraged and rather risky.

Regarding the last question just look in your own current svn tree.

You might also look at PR33271 or PR33277 for my latest fiasco with Pinski. He
appears to owe his job to Dr. Edelsohn and was just hanging around a school
where a relative is a department head for several years. (this is documentable)

Do not try to recruit me as a maintainer because I would __never__ consider
working in an organization as politiized and poorly run as GCC. Mark Mitchel is
just not allowed to act as a real release manager.

The exception is the fortran group (minus Kargl). Where Paul Thomas has been
doing herculean work. I would love to see at least part of that work in 4.1.x
as 4.2.x and 4.3.x are completely messed up with things like decimal float
(major marketing tool of IBM). By the way the latest gcc on AIX is 3.3.1. Thus,
the IBM marketing types are pratically stating that they want to see gcc-4
hobbled.

Now if you do not want to work with me any more, just let me know. I am am
pretty hard boiled from the US corporate world and can spot the gcc
manipulations from a mile away.


-- 


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

[Bug fortran/33271] nint_2.f90 abort compiled with -O0

[fxcoudert at gcc dot gnu dot org]

------- Comment #6 from fxcoudert at gcc dot gnu dot org  2007-09-03 14:09 -------
(In reply to comment #5)
> Let me start off by saying that today is a holiday and that tomoorow I am back
> at work and traveling, I am not allowed to use __any__ business assets for GCC
> connected activity.

That's fine, I'm certainly not in a hurry. We'll have this fixed before
release, and of course the sooner the better, a few days on a corner case is
not a big deal (this testcase is really a corner case).

> We just had an extensive power outage and we just recovering. I will try and
> run that program today? the question is with which C compiler ( the latest
> Trunk, gcc-4.3.0? 4.1.current? 3.3.6 ? or 3.4.6? and even the junky 4.2.1)

Try with the same compiler that gave you the Fortran failure. Otherwise, take
any other one, what the code I posted is really testing is your glibc.

>> One last question: in your build tree, you should have a file named
>> ${builddir}/${target_triplet}/libgfortran/config.h. How does it define the
>> macros HAVE_LLROUND, HAVE_LLROUNDF, HAVE_LLROUNDL, HAVE_LROUND, HAVE_LROUNDF
>> and HAVE_LROUNDL?
> 
> Regarding the last question just look in your own current svn tree.

No, I'm not referring to the source tree but the build tree (the one where your
object build files are stored in). That's the directory where you run the
"configure && make" in.  Could you look into that directory, for a file named
powerpc-unknown-linux-gnu/libgfortran/config.h, and paste the lines of that
file which contain the text "HAVE_LROUND" and the other ones I was quoting?


PS: Please refrain from comments on individuals. There are numerous media to
express your opinion on how open source projects in general (and GCC in
particular) are run, but this Bugzilla isn't one of them. I'm giving you
technical help, and acknowledge the help you're giving the project by having
access to this specific target. Let's keep it constructive.


-- 


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

[Bug fortran/33271] nint_2.f90 abort compiled with -O0

[fxcoudert at gcc dot gnu dot org]

------- Comment #7 from fxcoudert at gcc dot gnu dot org  2007-09-03 14:11 -------
And please stop CCing people! I'm taking care of this bug, and there really is
no need to bother other people by sending them copies of all
comments/investigation we exchange on the issue.


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|dje at watson dot ibm dot   |
                   |com, pinskia at gcc dot gnu |
                   |dot org                     |
         AssignedTo|unassigned at gcc dot gnu   |fxcoudert at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2007-09-03 10:04:32         |2007-09-03 14:11:58
               date|                            |


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

[Bug fortran/33271] nint_2.f90 abort compiled with -O0

[burnus at gcc dot gnu dot org]

------- Comment #8 from burnus at gcc dot gnu dot org  2007-09-03 14:25 -------
> > One last question: in your build tree, you should have a file named
> > ${builddir}/${target_triplet}/libgfortran/config.h. How does it define the
> > macros HAVE_LLROUND, HAVE_LLROUNDF, HAVE_LLROUNDL, HAVE_LROUND, HAVE_LROUNDF
> > and HAVE_LROUNDL?
>
> That last question seems beyond my ken. I am running glibc-2.6.1
> (the latest official).

That file should be in your case in
/var/tmp/43/build-159/powerpc-unknown-linux-gnu/libgfortran/config.h
         ^^^^^^^^^^^^ <- this might be different,
         depending where you build gcc/gfortran; this was the
         directory used in your bug description (comment #0)

The file is generated at configure time and thus specific to the system where
gcc/gfortran is build.

On my system (x86_64-unknown-linux-gnu, but also glibc-2.6), I have in the
equivalent file:

#define HAVE_LLROUND 1
#define HAVE_LLROUNDF 1
#define HAVE_LLROUNDL 1
#define HAVE_LLROUND 1
#define HAVE_LLROUNDF 1
#define HAVE_LLROUNDL 1

I would expect that your config.h has the same entries (as we both use a recent
glibc), but it would be great if you could confirm this.

> The question is with which C compiler ( the latest Trunk, gcc-4.3.0?
> 4.1.current? 3.3.6 ? or 3.4.6? and even the junky 4.2.1)

As FX wants to check whether the C Library (glibc) works correctly, it should
not matter; but if you have the choice I would use gcc 4.3.0.


-- 


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

[Bug fortran/33271] nint_2.f90 abort compiled with -O0

[dje at gcc dot gnu dot org]

------- Comment #9 from dje at gcc dot gnu dot org  2007-09-04 19:11 -------
By the way, nint_2.f90 also fails at -O0 on AIX.


-- 


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

[Bug fortran/33271] nint_2.f90 abort compiled with -O0

[fxcoudert at gcc dot gnu dot org]

------- Comment #10 from fxcoudert at gcc dot gnu dot org  2007-09-05 09:47 -------
(In reply to comment #9)
> By the way, nint_2.f90 also fails at -O0 on AIX.

And it works on powerpc-apple-darwin. David, could you test my C program in
comment #4, and look into ${builddir}/${target_triplet}/libgfortran/config.h to
see what value have the HAVE_LROUND{F,,L} and HAVE_LLROUND{F,,L} macros?


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  GCC build triplet|powerpc-unknown-linux-gnu   |powerpc-unknown-linux-gnu,
                   |                            |powerpc-ibm-aix5.3.0.0
   GCC host triplet|powerpc-unknown-linux-gnu   |powerpc-unknown-linux-gnu,
                   |                            |powerpc-ibm-aix5.3.0.0
 GCC target triplet|powerpc-unknown-linux-gnu   |powerpc-unknown-linux-gnu,
                   |                            |powerpc-ibm-aix5.3.0.0
            Version|4.3.0                       |unknown


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

[Bug fortran/33271] nint_2.f90 abort compiled with -O0

[dje at watson dot ibm dot com]

------- Comment #11 from dje at watson dot ibm dot com  2007-09-05 17:13 -------
Subject: Re:  nint_2.f90 abort compiled with -O0 

>>>>> fxcoudert at gcc dot gnu dot org writes:

FX> look into ${builddir}/${target_triplet}/libgfortran/config.h to
FX> see what value have the HAVE_LROUND{F,,L} and HAVE_LLROUND{F,,L} macros?

/* libm includes llround */
#define HAVE_LLROUND 1

/* libm includes llroundf */
#define HAVE_LLROUNDF 1

/* libm includes llroundl */
#define HAVE_LLROUNDL 1

/* libm includes lround */
#define HAVE_LROUND 1

/* libm includes lroundf */
#define HAVE_LROUNDF 1

/* libm includes lroundl */
#define HAVE_LROUNDL 1


-- 


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

[Bug fortran/33271] nint_2.f90 abort compiled with -O0

[dje at watson dot ibm dot com]

------- Comment #12 from dje at watson dot ibm dot com  2007-09-05 17:19 -------
Subject: Re:  nint_2.f90 abort compiled with -O0 

>>>>> fxcoudert at gcc dot gnu dot org writes:

FX> David, could you test my C program in comment #4

$ ./xgcc -B./ -W -Wall -O1 fx.c
fx.c: In function 'main':
fx.c:46: warning: integer constant is too large for 'long' type
fx.c:47: warning: integer constant is too large for 'long' type
fx.c:51: warning: integer constant is too large for 'long' type
fx.c:52: warning: integer constant is too large for 'long' type
$ ./a.out
4 4 8
$ ./xgcc -B./ -W -Wall -O0 fx.c
fx.c: In function 'main':
fx.c:46: warning: integer constant is too large for 'long' type
fx.c:47: warning: integer constant is too large for 'long' type
fx.c:51: warning: integer constant is too large for 'long' type
fx.c:52: warning: integer constant is too large for 'long' type
ld: 0711-317 ERROR: Undefined symbol: .lround
ld: 0711-317 ERROR: Undefined symbol: .lroundf
ld: 0711-317 ERROR: Undefined symbol: .llround
$ ./xgcc -B./ -W -Wall -O0 fx.c -lm
fx.c: In function 'main':
fx.c:46: warning: integer constant is too large for 'long' type
fx.c:47: warning: integer constant is too large for 'long' type
fx.c:51: warning: integer constant is too large for 'long' type
fx.c:52: warning: integer constant is too large for 'long' type
$ ./a.out
4 4 8
Abort 1
$ ./xgcc -B./ -maix64 -W -Wall -O1 fx.c 
$ ./a.out
4 8 8
$ ./xgcc -B./ -maix64 -W -Wall -O0 fx.c -lm
$ ./a.out
4 8 8
Abort 1


-- 


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

[Bug fortran/33271] nint_2.f90 abort compiled with -O0

[fxcoudert at gcc dot gnu dot org]

------- Comment #13 from fxcoudert at gcc dot gnu dot org  2007-09-06 17:47 -------
The following code:

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

int main (void)
{
  printf ("%ld %ld %ld\n", lround (nextafter(0.5,-9.0)), lround (0.5), lround
(nextafter(0.5,9.0)));
}

should print "0 1 1". On both ppc-aix and ppc-linux (thanks David for testing!)
it says "1 1 1", which is wrong. The powerpc-linux issue is a glibc bug, I
filed it as #4997 (http://www.cygwin.com/bugzilla/show_bug.cgi?id=4997). The
powerpc-aix issue is a AIX libm bug.


-- 


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

[Bug fortran/33271] nint_2.f90 abort compiled with -O0

[fxcoudert at gcc dot gnu dot org]

------- Comment #14 from fxcoudert at gcc dot gnu dot org  2007-09-06 17:48 -------
Subject: Bug 33271

Author: fxcoudert
Date: Thu Sep  6 17:48:32 2007
New Revision: 128196

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128196
Log:
        PR fortran/33271
        * gfortran.dg/nint_2.f90: xfail on powerpc-ibm-aix* and
        powerpc*-linux-gnu.

Modified:
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/nint_2.f90


-- 


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

[Bug fortran/33271] nint_2.f90 abort compiled with -O0

[fxcoudert at gcc dot gnu dot org]

------- Comment #15 from fxcoudert at gcc dot gnu dot org  2007-09-06 17:50 -------
Testcase XFAILed on both platforms, should appear as a failure any more. Please
reopen the PR if I made a mistake and it still appears.


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


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

[Bug fortran/33271] nint_2.f90 abort compiled with -O0

[dominiq at lps dot ens dot fr]

------- Comment #16 from dominiq at lps dot ens dot fr  2007-09-07 11:42 -------
This way to fix the problem shakes the (little) confidence I have in the test
suite!

Would not it be better to let the tests fail for the mentionned platforms until
a (real) fix is found (as it is done for large_real_kind_2.F90 and
large_real_kind_form_io_2.f90 on Darwin)?


-- 


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

[Bug fortran/33271] nint_2.f90 abort compiled with -O0

[fxcoudert at gcc dot gnu dot org]

------- Comment #17 from fxcoudert at gcc dot gnu dot org  2007-09-07 12:06 -------
(In reply to comment #16)
> This way to fix the problem shakes the (little) confidence I have in the test
> suite!

You're, as always, welcome to improve it! (both by submitting code and general
ideas to make it better)

> Would not it be better to let the tests fail for the mentionned platforms until
> a (real) fix is found (as it is done for large_real_kind_2.F90 and
> large_real_kind_form_io_2.f90 on Darwin)?

I'm not sure I understand what you suggest. nint_2.f90 fails on ppc-aix and
ppc-linux because those targets have a system math library that contains a bug.
The code that gfortran create is OK, and the testcase would not fail if the AIX
and powerpc-glibc didn't have a buggy lround(). In fact, it is passing on all
other targets.

So, in that case, and contrarily to large_real_kind_2.F90, the bug here is not
in GCC, all we can do is really to wait for AIX and glibc to fix their
libraries. This is not going to happen soon (especially for AIX), and we
certainly have no control over it. This leaves two options: keep the testcase
failing on these two platforms, which means that people will probably report
the failure again, or at least investigate it. The nice thing in a testsuite is
that every single failure should be indicating a bug that we can act on: it's
not the case here. The other option is to XFAIL it on these two targets, which
means (a) we don't see the failure, (b) there is a record that this should, in
a perfect world, pass, but due to circumstances out of our control it is
expected to fail, and (c) when it starts passing (because glibc/AIX will have
been fixed), it will show up in test results as XPASS, and we can act (remove
the xfail).

If I understood you, you'd like option 1 above, am I right? Why do you think it
is better for the project?


PS: I should note that the bug in question is a relatively minor one: lround(),
on ppc-glibc and AIX, returns a wrong answer for the floating-point number
immediately lower than 0.5, Prec(0.5). All values are fine, except Prec(0.5),
-Prec(0.5), 4503599627370497 and -4503599627370497.


-- 


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

[Bug fortran/33271] nint_2.f90 abort compiled with -O0

[dominiq at lps dot ens dot fr]

------- Comment #18 from dominiq at lps dot ens dot fr  2007-09-07 13:49 -------
FX, 

Please don't take my comment on the test suite personally.  

I think the PR should be resolved as WONTFIX for the reasons you explain and
the test case should fail on the platform on which it fails.

For the moment, I cannot think of the better way to warn the user that there is
something wrong with NINT() even if it is for corner cases.

I have to leave right now for 3 days without internet connection.  I'll give
more specific comments when returning.


-- 


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

[Bug fortran/33271] nint_2.f90 abort compiled with -O0

[dominiq at lps dot ens dot fr]

------- Comment #19 from dominiq at lps dot ens dot fr  2007-09-11 10:44 -------
In order to avoid a too long post, I am splitting my answer in pieces.

> PS: I should note that the bug in question is a relatively minor one:
> lround(), on ppc-glibc and AIX, returns a wrong answer for the
> floating-point number immediately lower than 0.5, Prec(0.5).  All values
> are fine, except Prec(0.5), -Prec(0.5), 4503599627370497 and
> -4503599627370497.

The marketing guys at Intel tried this kind of justification during the
divide fiasco and got the following joke:

Q&A:  THE PENTIUM FDIV BUG

Q:  How many Pentium designers does it take to screw in a light bulb?
A:  1.99904274017, but that's close enough for non-technical people.

More seriously, the test fails for the above values, but this does not mean
that it does not fail for other values.  The most common mistake when computing
nint(x) is to use int(x+0.5) without setting the rounding mode towards 0.
If int(x+0.5) is used with the default round to nearest, all the values
nearest(real(2**i)-0.5,-1.0) (at least) and all the odd integers between
2**51 and 2**52-1 are not rounded correctly (towards real(2**i) and even
integers respectively).  So before concluding that only four values give a
wrong results, more tests should be performed with these known candidates
for failures.

This is one of my prejudice against, not the test suite itself, but its use:
incorrect conclusions are drawn from incomplete test cases.


-- 


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

[Bug fortran/33271] nint_2.f90 abort compiled with -O0

[fxcoudert at gcc dot gnu dot org]

------- Comment #20 from fxcoudert at gcc dot gnu dot org  2007-09-11 11:06 -------
(In reply to comment #19)
> More seriously, the test fails for the above values, but this does not mean
> that it does not fail for other values.

Sorry, I was posting in a haste and was to affirmative. What I meant is: the
AIX and powerpc-glibc routines are only failing for a finite number of values.
That's dead annoying, but it will still be working most of the time. If I were
using one of these platforms for production work, I'd be dead annoyed and
complain heavily to the vendor (especially for AIX, which is not free), but as
I'm not, there's only so much I can do.

> So before concluding that only four values give a
> wrong results, more tests should be performed with these known candidates
> for failures.

Well, tests certainly need to be conducted and the source code reviewed. But
this needs to be done the packages who have incorrect behaviour: GNU libc and
AIX libm.

> This is one of my prejudice against, not the test suite itself, but its use:
> incorrect conclusions are drawn from incomplete test cases.

Well, you're welcome to contribute to the testsuite to extend its coverage. I'm
glad it's there, because it keeps us from regressing too much (we *still*
regress, and any regression is one too many, and the testsuite could be
extended, but we're better off than if it weren't there).

Also, to answer your affirmation that XFAILed tests are of no use to users,
it's wrong. The testsuite is primarily designed for GCC developers to check on
the status of their code, which is why the default reports only contain FAILing
and XPASSing testcases. But it can also be used by users to check on what their
compiler limitations are, in which case you need to check for XFAILing tests
also. These are kept in the test summary, they're just not output in default
reports. XFAIL is used to signal a functionality that's not working, due not to
defect in GCC but in other software (such as the libc).


-- 


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

[Bug fortran/33271] nint_2.f90 abort compiled with -O0

[dje at gcc dot gnu dot org]

------- Comment #21 from dje at gcc dot gnu dot org  2007-09-11 11:29 -------
AIX defect number 628397 opened against the math library.


-- 


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