[Bug fortran/35877] New: difference between result in optimized and normal executable

[Bug fortran/35877] New: difference between result in optimized and normal executable

[dmarkman at mac dot com]

consider the following program
        program short_test_inf
        complex*16 nan_inf, normal_number, cmplx_test
        real*8 tth, pi, zero
        data tth /6.66666666666666667D-01/
        data pi  /3.1415926535897932385D0/
        data  zero /0.0D0/
        normal_number = dcmplx(tth, zero)   
        nan_inf       = dcmplx(pi/zero, zero/zero)
        cmplx_test = nan_inf * normal_number
        print *,'nan_inf ',nan_inf
        print *,'cmplx_test (inf+iNan)*(2/3+i0) ',cmplx_test
        cmplx_test = nan_inf * tth
        print *,'tth ',tth
        print *,'cmplx_test  (inf+iNan)*(2/3)',cmplx_test
        end program

optimized version (gfortran -O test.F)
returns
 nan_inf  (                +Infinity,                      NaN)
 cmplx_test (inf+iNan)*(2/3+i0)  (                +Infinity,                   
  NaN)
 tth   0.66666666666666663     
 cmplx_test  (inf+iNan)*(2/3) (                +Infinity,                     
NaN)

non optimized version (gfortran test.F)
returns
 nan_inf  (                +Infinity,                      NaN)
 cmplx_test (inf+iNan)*(2/3+i0)  (                      NaN,                   
  NaN)
 tth   0.66666666666666663     
 cmplx_test  (inf+iNan)*(2/3) (                      NaN,                     
NaN)

Note: gfortran4.2.3 returns for both (optimized/non optimized) NaN, NaN
intel 10 fortran has exactly the same behaviour as gfortran 4.3.0:
optimized Inf,NaN
non optimized Inf,Nan
thanks


-- 
           Summary: difference between result in optimized and normal
                    executable
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: dmarkman at mac dot com


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

[Bug fortran/35877] difference between result in optimized and normal executable

[dmarkman at mac dot com]

------- Comment #1 from dmarkman at mac dot com  2008-04-08 21:09 -------
I meant
Note: gfortran4.2.3 returns for both (optimized/non optimized) NaN, NaN
intel 10 fortran has exactly the same behaviour as gfortran 4.3.0:
optimized Inf,NaN
non optimized NaN,Nan


-- 


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

[Bug fortran/35877] difference between result in optimized and normal executable

[jb at gcc dot gnu dot org]

------- Comment #2 from jb at gcc dot gnu dot org  2008-04-14 18:09 -------
Well, your test case is invalid anyway (i0 is referenced before being defined).

Here's a standard conforming portable version that compiles with "-Wall
-pedantic -std=f2003":

        program short_test_inf
        implicit none
        integer, parameter :: dp = selected_real_kind (15)
        complex(dp) nan_inf, normal_number, cmplx_test, i0
        real(dp) tth, pi, zero
        data tth /6.66666666666666667e-01_dp/
        data pi  /3.1415926535897932385_dp/
        data  zero /0.0_dp/
        normal_number = cmplx(tth, zero, dp)   
        nan_inf       = cmplx(pi/zero, zero/zero, dp)
        i0 = cmplx(0, 0, dp)
        cmplx_test = nan_inf * normal_number
C        print *,'nan_inf ',nan_inf
        print *,'cmplx_test (inf+iNan)*(2/3+i0) ',cmplx_test
        cmplx_test = nan_inf * tth
C        print *,'tth ',tth
        print *,'cmplx_test  (inf+iNan)*(2/3)',cmplx_test
        end program

Results with this program comparing 4.1 and 4.4 (trunk):

$ ./gf41-opt 
 cmplx_test (inf+iNan)*(2/3+i0)  (                    NaN,                   
NaN)
 cmplx_test  (inf+iNan)*(2/3) (              +Infinity,                    NaN)
$ ./gf41-nonopt 
 cmplx_test (inf+iNan)*(2/3+i0)  (                    NaN,                   
NaN)
 cmplx_test  (inf+iNan)*(2/3) (                    NaN,                    NaN)
$ ./gf44-opt 
 cmplx_test (inf+iNan)*(2/3+i0)  (                +Infinity,                   
  NaN)
 cmplx_test  (inf+iNan)*(2/3) (                +Infinity,                     
NaN)
$ ./gf44-nonopt 
 cmplx_test (inf+iNan)*(2/3+i0)  (                      NaN,                   
  NaN)
 cmplx_test  (inf+iNan)*(2/3) (                      NaN,                     
NaN)

Basically, I'd like to close this as wontfix. IIRC once you get an FP
exception, all bets are off and the result of further computation can be
anything. Of course it would be nice if results were the same regardless of
optimization level.

For a related issue where being excessively anal about complex arithmetic
resulted in a factor of 5 slowdown, see PR 29549


-- 

jb at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jb at gcc dot gnu dot org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2008-04-14 18:09:38
               date|                            |


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

[Bug fortran/35877] difference between result in optimized and normal executable

[dmarkman at mac dot com]

------- Comment #3 from dmarkman at mac dot com  2008-04-14 21:47 -------
Hi, first of all thanks for your comment
I don't use i0 in the program - it's inside of the quotes
so test is fine
I made all changes you made
and still in 4.3 (opt) I'm getting (+Inf, Nan)
it looks like that 4.4 fixes that Inconsistence
I just don't build 4,4 to check
thanks again

> Well, your test case is invalid anyway (i0 is referenced before being defined).
> 
> Here's a standard conforming portable version that compiles with "-Wall
> -pedantic -std=f2003":
> 
>         program short_test_inf
>         implicit none
>         integer, parameter :: dp = selected_real_kind (15)
>         complex(dp) nan_inf, normal_number, cmplx_test, i0
>         real(dp) tth, pi, zero
>         data tth /6.66666666666666667e-01_dp/
>         data pi  /3.1415926535897932385_dp/
>         data  zero /0.0_dp/
>         normal_number = cmplx(tth, zero, dp)   
>         nan_inf       = cmplx(pi/zero, zero/zero, dp)
>         i0 = cmplx(0, 0, dp)
>         cmplx_test = nan_inf * normal_number
> C        print *,'nan_inf ',nan_inf
>         print *,'cmplx_test (inf+iNan)*(2/3+i0) ',cmplx_test
>         cmplx_test = nan_inf * tth
> C        print *,'tth ',tth
>         print *,'cmplx_test  (inf+iNan)*(2/3)',cmplx_test
>         end program
> 
> Results with this program comparing 4.1 and 4.4 (trunk):
> 
> $ ./gf41-opt 
>  cmplx_test (inf+iNan)*(2/3+i0)  (                    NaN,                   
> NaN)
>  cmplx_test  (inf+iNan)*(2/3) (              +Infinity,                    NaN)
> $ ./gf41-nonopt 
>  cmplx_test (inf+iNan)*(2/3+i0)  (                    NaN,                   
> NaN)
>  cmplx_test  (inf+iNan)*(2/3) (                    NaN,                    NaN)
> $ ./gf44-opt 
>  cmplx_test (inf+iNan)*(2/3+i0)  (                +Infinity,                   
>   NaN)
>  cmplx_test  (inf+iNan)*(2/3) (                +Infinity,                     
> NaN)
> $ ./gf44-nonopt 
>  cmplx_test (inf+iNan)*(2/3+i0)  (                      NaN,                   
>   NaN)
>  cmplx_test  (inf+iNan)*(2/3) (                      NaN,                     
> NaN)
> 
> Basically, I'd like to close this as wontfix. IIRC once you get an FP
> exception, all bets are off and the result of further computation can be
> anything. Of course it would be nice if results were the same regardless of
> optimization level.
> 
> For a related issue where being excessively anal about complex arithmetic
> resulted in a factor of 5 slowdown, see PR 29549
> 


-- 


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

[Bug middle-end/35877] difference between result in optimized and normal executable

[jb at gcc dot gnu dot org]

------- Comment #4 from jb at gcc dot gnu dot org  2008-04-14 23:01 -------
(In reply to comment #3)
> Hi, first of all thanks for your comment
> I don't use i0 in the program - it's inside of the quotes
> so test is fine

Uh oh, yes of course. How embarrassing. Sorry for that.

> I made all changes you made
> and still in 4.3 (opt) I'm getting (+Inf, Nan)
> it looks like that 4.4 fixes that Inconsistence
> I just don't build 4,4 to check
> thanks again

Anyway, I'm reassigning this to middle-end, since regardless of optimization
level the gfortran frontend generates identical trees. Attached is a roughly
equivalent C testcase for the middle-end guys:

#include <stdio.h>
#include <complex.h>

// Compile with -std=c99 -lm

int main(void)
{
    double complex nan_inf, normal_number, cmplx_test;
    double tth = 0.6666666666666667;
    normal_number = tth + I*0;
    nan_inf = 1.0/0.0 + I*(0.0/0.0);
    cmplx_test = nan_inf * normal_number;
    printf ("nan_inf (%f, %f)\n", creal(nan_inf), cimag(nan_inf));
    printf ("nan_inf * (tth,0): (%f, %f)\n", creal(cmplx_test),
cimag(cmplx_test));
    cmplx_test = nan_inf * tth;
    printf ("nan_inf * tth: (%f, %f)\n", creal(cmplx_test), cimag(cmplx_test));
}

Results with 

Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../trunk/configure --enable-languages=c,fortran
--prefix=/home/job/src/gfortran/inst : (reconfigured) ../trunk/configure
--prefix=/home/job/src/gfortran/inst --enable-languages=c,fortran --no-create
--no-recursion : (reconfigured) ../trunk/configure
--prefix=/home/job/src/gfortran/inst --enable-languages=c,fortran --no-create
--no-recursion : (reconfigured) ../trunk/configure
--prefix=/home/job/src/gfortran/inst --enable-languages=c,fortran --no-create
--no-recursion
Thread model: posix
gcc version 4.4.0 20080414 (experimental) (GCC) 

and

Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic
--host=i386-redhat-linux
Thread model: posix
gcc version 4.1.2 20070626 (Red Hat 4.1.2-14)

$ ./gcc41-noopt 
nan_inf (nan, nan)
nan_inf * (tth,0): (nan, nan)
nan_inf * tth: (nan, nan)
$ ./gcc41-opt 
nan_inf (inf, nan)
nan_inf * (tth,0): (inf, nan)
nan_inf * tth: (inf, nan)
$ ./gcc44-noopt 
nan_inf (nan, nan)
nan_inf * (tth,0): (nan, nan)
nan_inf * tth: (nan, nan)
$ ./gcc44-opt 
nan_inf (inf, nan)
nan_inf * (tth,0): (inf, nan)
nan_inf * tth: (inf, nan)


-- 

jb at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|fortran                     |middle-end


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

[Bug middle-end/35877] difference between result in optimized and normal executable

[kargl at gcc dot gnu dot org]

------- Comment #5 from kargl at gcc dot gnu dot org  2008-04-14 23:10 -------
(In reply to comment #4)

> Anyway, I'm reassigning this to middle-end, since regardless of optimization
> level the gfortran frontend generates identical trees. Attached is a roughly
> equivalent C testcase for the middle-end guys:
> 
> #include <stdio.h>
> #include <complex.h>
> 
> // Compile with -std=c99 -lm
> 
> int main(void)
> {
>     double complex nan_inf, normal_number, cmplx_test;
>     double tth = 0.6666666666666667;
>     normal_number = tth + I*0;
>     nan_inf = 1.0/0.0 + I*(0.0/0.0);
>     cmplx_test = nan_inf * normal_number;
>     printf ("nan_inf (%f, %f)\n", creal(nan_inf), cimag(nan_inf));
>     printf ("nan_inf * (tth,0): (%f, %f)\n", creal(cmplx_test),
> cimag(cmplx_test));
>     cmplx_test = nan_inf * tth;
>     printf ("nan_inf * tth: (%f, %f)\n", creal(cmplx_test), cimag(cmplx_test));
> }

This is probably a duplicate of PR 24581.

AFAICT from the audit trail, this will never be fixed.


-- 


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