------- 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
