[Bug fortran/44156] New: dot_product / matmul and signed zeros

[Bug fortran/44156] New: dot_product / matmul and signed zeros

[tkoenig at gcc dot gnu dot org]

Strictly speaking, we should get -0.00000 in all cases.

ig25@linux-fd1f:~/Fort> cat intrinsic_signed_zero.f90
program main
  implicit none
  real, dimension(1) :: a, b
  real, dimension(1,1) :: aa, bb
  a(1) = -1.0
  b(1) = 0.0
  print *,a(1)*b(1)
  print *,dot_product(a,b)
  aa(1,1) = -1.0
  bb(1,1) = 0.0
  print *,matmul(aa,bb)
end program main
ig25@linux-fd1f:~/Fort> gfortran intrinsic_signed_zero.f90
ig25@linux-fd1f:~/Fort> ./a.out
  -0.0000000
   0.0000000
   0.0000000


-- 
           Summary: dot_product / matmul and signed zeros
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Keywords: wrong-code
          Severity: minor
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: tkoenig at gcc dot gnu dot org


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

[Bug fortran/44156] dot_product / matmul and signed zeros

[kargl at gcc dot gnu dot org]

------- Comment #1 from kargl at gcc dot gnu dot org  2010-05-16 16:19 -------
The generated code is fine.  The F2003 standard states on page 38.

   The real type includes a zero value. Processors that distinguish between
   positive and negative zeros shall treat them as equivalent
   (1)   in all relational operations,
   (2)   as actual arguments to intrinsic procedures other than those
         for which it is explicitly specified that negative zero is
         distinguished, and

MATMAL and DOT_PRODUCT are not in the list that (2) applies to.

Remove wrong-code keyword.
Change Severity to enhancement, because might try to argue that this 
is a Quality of Implementation issue.  I'll leave it to Thomas to 
decide whether to close as WONTFIX.

PS:  DOT_PRODUCT is in-lined. -ftree-dump-original shows

      val.2 = 0.0;
      {
        integer(kind=4) S.3;

        S.3 = 1;
        while (1)
          {
            if (S.3 > 1) goto L.1;
            val.2 = a[S.3 + -1] * b[S.3 + -1] + val.2;
            S.3 = S.3 + 1;
          }
        L.1:;
      }
      D.1505 = val.2;

Even if a[S.3 + -1] * b[S.3 + -1] = -0.  The accumulation of the
sum -0 + 0 in the above will result in 0 (without the sign).


-- 

kargl at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|minor                       |enhancement
           Keywords|wrong-code                  |


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

[Bug fortran/44156] dot_product / matmul and signed zeros

[tkoenig at netcologne dot de]

------- Comment #2 from tkoenig at netcologne dot de  2010-05-16 19:03 -------
Subject: Re:  dot_product / matmul and signed zeros

kargl at gcc dot gnu dot org wrote:
> The generated code is fine.  The F2003 standard states on page 38.
> 
>    The real type includes a zero value. Processors that distinguish
> between
>    positive and negative zeros shall treat them as equivalent
>    (1)   in all relational operations,
>    (2)   as actual arguments to intrinsic procedures other than those
>          for which it is explicitly specified that negative zero is
>          distinguished, and
> 
> MATMAL and DOT_PRODUCT are not in the list that (2) applies to. 

In this case, the negative zero is the _result_; it is not passed as an
argument (what's being passed are 0.0 and -1.0, respectively).


So, this looks like a question for c.l.f.

And yes, there are bugs that are more severe than this ;-)


-- 


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

[Bug fortran/44156] dot_product / matmul and signed zeros

[dfranke at gcc dot gnu dot org]

------- Comment #3 from dfranke at gcc dot gnu dot org  2010-05-16 20:17 -------
The simplifiers show the same behaviour:

$> cat pr44156.f90
program main
  implicit none
  real, dimension(1), parameter :: a = -1.0, b = 0.0
  real, dimension(1,1), parameter :: aa = -1.0, bb = 0.0

  real, dimension(1), parameter :: c = dot_product(a,b)
  real, dimension(1,1), parameter :: d = matmul(aa, bb)
  real, parameter :: e = a(1) * b(1)

  print *, c, d, e
end program main

$ gfortran-svn -Wall -W pr44156.f90 && ./a.out 
   0.0000000       0.0000000      -0.0000000

The dump has:
MAIN__ ()
{
  static real(kind=4) c[1] = {};
  static real(kind=4) d[1] = {0.0};
  [writes snipped]
      {
      static real(kind=4) C.1525 = -0.0;

      _gfortran_transfer_real (&dt_parm.0, &C.1525, 4);
    }
}


-- 

dfranke at gcc dot gnu dot org changed:

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


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

[Bug fortran/44156] dot_product / matmul and signed zeros

[jvdelisle at gcc dot gnu dot org]

------- Comment #4 from jvdelisle at gcc dot gnu dot org  2010-05-17 20:51 -------
We have complete control of whether to print the negative sign with
-fno-sign-zero.  I am tempted to say this is a no-never-mind situation.


-- 


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

[Bug fortran/44156] dot_product / matmul and signed zeros

[dfranke at gcc dot gnu dot org]

------- Comment #5 from dfranke at gcc dot gnu dot org  2010-05-17 22:23 -------
(In reply to comment #4)
> We have complete control of whether to print the negative sign with
> -fno-sign-zero.  I am tempted to say this is a no-never-mind situation.

Using the testcase shown in comment #3:

$> gfortran-svn pr44156-c3.f90 -fno-sign-zero && ./a.out
   0.0000000       0.0000000       0.0000000    
$> gfortran-svn pr44156-c3.f90 -fsign-zero && ./a.out
   0.0000000       0.0000000      -0.0000000

The flag does work for the third value, i.e. the line

   real, parameter :: e = a(1) * b(1)

but has no say for the others.


Out of curiosity, what do other compilers do? I, right now, don't have any to
test with.


-- 


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

[Bug fortran/44156] dot_product / matmul and signed zeros

[kargl at gcc dot gnu dot org]

------- Comment #6 from kargl at gcc dot gnu dot org  2010-05-17 23:18 -------
(In reply to comment #5)
> (In reply to comment #4)
> > We have complete control of whether to print the negative sign with
> > -fno-sign-zero.  I am tempted to say this is a no-never-mind situation.
> 
> Using the testcase shown in comment #3:
> 
> $> gfortran-svn pr44156-c3.f90 -fno-sign-zero && ./a.out
>    0.0000000       0.0000000       0.0000000    
> $> gfortran-svn pr44156-c3.f90 -fsign-zero && ./a.out
>    0.0000000       0.0000000      -0.0000000
> 
> The flag does work for the third value, i.e. the line
> 
>    real, parameter :: e = a(1) * b(1)
> 
> but has no say for the others.
> 
> 
> Out of curiosity, what do other compilers do? I, right now, don't have any to
> test with.
> 

I already explained what dot_product is doing in comment #2.
dot_product(a,b) is equivalent to

   s = 0
   do n = 1, m
      s = s + a(n) * b(n)
   end do
   (return s)

For Thomas' code, you end up with 0 + (-0), which is 0 (which
is what IEEE 754 explicitly says in Sec 8.3).  If someone wants
to get -0, then s/he needs to rewrite the in-lining of dot_product
to do

  s = a(1) * b(1)
  do n = 2, m
     s = s + a(n) * b(n)
  end do
  (return n)

Here, the loop won't be executed (and hopefully, the middle-end
reaps the dead code).  In the new looping structure, one might
ask whether it inhibits optimization and/or vectorization.


-- 

kargl at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sgk at troutmask dot apl dot
                   |                            |washington dot edu


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

[Bug fortran/44156] dot_product / matmul and signed zeros

[dfranke at gcc dot gnu dot org]

------- Comment #7 from dfranke at gcc dot gnu dot org  2010-05-17 23:49 -------
(In reply to comment #6)
> I already explained what dot_product is doing in comment #2.
> dot_product(a,b) is equivalent to
> 
>    s = 0
>    do n = 1, m
>       s = s + a(n) * b(n)
>    end do
>    (return s)
> 
> For Thomas' code, you end up with 0 + (-0), which is 0 (which
> is what IEEE 754 explicitly says in Sec 8.3). 

Thanks for the clarification.

Finally also found the c.l.f thread (where, btw, Tobias answers my question on
what other compilers do):
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/a693c3dd5f725e77

After reading it, I'd agree that this is probably a non-issue.


-- 


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

[Bug fortran/44156] dot_product / matmul and signed zeros

[tkoenig at gcc dot gnu dot org]

------- Comment #8 from tkoenig at gcc dot gnu dot org  2010-06-04 07:06 -------
After the discussion, I think we can close this as WONTFIX.


-- 

tkoenig at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |WONTFIX


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