--- Comment #20 from jan at etpmod dot phys dot tue dot nl 2006-09-27
07:51 ---
First of all, the problem is that bad that even 1*z != z when *no* optimisation
is requested. Consider:
#include iostream
#include limits
#include complex
int main()
{
std::complexdouble
--- Comment #21 from pcarlini at suse dot de 2006-09-27 08:07 ---
(In reply to comment #20)
First of all, the problem is that bad that even 1*z != z when *no*
optimisation is requested.
Yes :(
Secondly, could somebody clarify how patch
--- Comment #19 from pcarlini at suse dot de 2006-09-07 09:11 ---
A side note, maybe not completely obvious to everyone and clarifying the
relationship to 24581. I understand that:
(+0) + (-0) = +0
therefore, when in the expansion of the complex product one of the two terms of
the
--- Comment #2 from pcarlini at suse dot de 2006-09-06 17:11 ---
I think this difference is ultimately due to the existenxce of a separate *_O0
version of tree_lower_complex, in tree-complex.c. Rth added it (as part of
fixing 20610), I believe the generic version is right (-0), and I'm
--- Comment #3 from pcarlini at suse dot de 2006-09-06 17:11 ---
I think we can confirm it.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #4 from pcarlini at suse dot de 2006-09-06 18:43 ---
But this issue should be recategorized, is about lowering and optimization of
complex numbers, maybe Andrew can help about that?
--
pcarlini at suse dot de changed:
What|Removed
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-09-06 18:50 ---
There are most likely a couple of different issues here. A front-end one with
(1.0+0.0i)*(-1) being expanded incorrectly, there is a bug about a case like
that too, see PR 24581. There might even be a libstdc++
--- Comment #6 from pluto at agmk dot net 2006-09-06 19:18 ---
(In reply to comment #2)
I think this difference is ultimately due to the existenxce of a separate *_O0
version of tree_lower_complex, in tree-complex.c. Rth added it (as part of
fixing 20610), I believe the generic
--- Comment #7 from pcarlini at suse dot de 2006-09-06 20:23 ---
Both the front-ends deal with 0 * -1 in the same way, the result is -0 (just
try). Anyway, the issue is crazy, a reduced pure C testcase (in principle
identical to what the complexdouble class does) behaves exactly the
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-09-06 20:27 ---
(In reply to comment #7)
Both the front-ends deal with 0 * -1 in the same way, the result is -0 (just
try). Anyway, the issue is crazy, a reduced pure C testcase (in principle
identical to what the complexdouble
--- Comment #9 from pcarlini at suse dot de 2006-09-06 20:59 ---
(In reply to comment #8)
This is PR 24581 after all then.
I don't know, I'm afraid there is even more to it :(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28408
--- Comment #10 from pcarlini at suse dot de 2006-09-07 00:44 ---
I'm re-reading the various floating-point standards and Annexes and I think
this issue may turn out to be a not-a-bug. Whether those standards make sense
it's another matter ;) So, what I'm reading: C99, F.8.2 says that 0
--- Comment #11 from joseph at codesourcery dot com 2006-09-07 01:23
---
Subject: Re: What should be value of complexdouble(1.0,0.0)
*= -1?
On Thu, 7 Sep 2006, pcarlini at suse dot de wrote:
I'm re-reading the various floating-point standards and Annexes and I think
this issue
--- Comment #12 from pcarlini at suse dot de 2006-09-07 01:33 ---
(In reply to comment #11)
F.8 is *illustrative* of transformations that are *not* permitted. It
doesn't permit anything.
Where do you read that in F.8.2 ?!? I read:
0 * x - 0.0The expressions 0 * x and 0.0
--- Comment #13 from pcarlini at suse dot de 2006-09-07 01:51 ---
And, by the way, it's also generally untrue that F8 is only illustrative of not
permitted transformations. For example, a few lines above:
1 * x and x / 1 - x The expressions 1 * x, x / 1 and x are equivalent
--- Comment #14 from joseph at codesourcery dot com 2006-09-07 01:52
---
Subject: Re: What should be value of complexdouble(1.0,0.0)
*= -1?
On Thu, 7 Sep 2006, pcarlini at suse dot de wrote:
F.8 is *illustrative* of transformations that are *not* permitted. It
doesn't permit
--- Comment #15 from joseph at codesourcery dot com 2006-09-07 01:57
---
Subject: Re: What should be value of complexdouble(1.0,0.0)
*= -1?
On Thu, 7 Sep 2006, pcarlini at suse dot de wrote:
And, by the way, it's also generally untrue that F8 is only illustrative of
not
--- Comment #16 from pcarlini at suse dot de 2006-09-07 02:04 ---
(In reply to comment #15)
Such statements also are informative, not normative. The normative
requirements come from F.3 (the operations shall be the IEC 60559
operations) and IEC 60559.
If you have IEC 60559 at
--- Comment #17 from bangerth at math dot tamu dot edu 2006-09-07 02:29
---
Subject: Re: What should be value of complexdouble(1.0,0.0)
*= -1?
If you have IEC 60559 at hand, and it explicitely says, as normative, that 0 *
-finite = -0 then, I agree that this is a bug. However, I
--- Comment #18 from pcarlini at suse dot de 2006-09-07 02:47 ---
(In reply to comment #17)
It is true that Appendix F has normative in the section title, but
F.8 starts out with
... in any case, the IEC 60559 entry in C99status reads Broken ;) ;)
--
--- Comment #1 from bangerth at dealii dot org 2006-07-18 13:34 ---
Is this related to libstdc++ PR 20758? Or is this unrelated since it
apparently isn't in the implementation of libstdc++ but in the
optimizers?
W.
--
bangerth at dealii dot org changed:
What|Removed
21 matches
Mail list logo
