[Bug fortran/44156] dot_product / matmul and signed zeros
--- 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
[Bug fortran/44156] dot_product / matmul and signed zeros
--- 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
--- 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.000 0.000 0.000 $ gfortran-svn pr44156-c3.f90 -fsign-zero ./a.out 0.000 0.000 -0.000 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
--- 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.000 0.000 0.000 $ gfortran-svn pr44156-c3.f90 -fsign-zero ./a.out 0.000 0.000 -0.000 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
--- 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
--- 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
--- 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
--- 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.000 0.000 -0.000
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
