--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-21
12:57 ---
Subject: Bug 20352
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-03-21 12:57:37
Modified files:
libstdc++-v3 :
--- Additional Comments From pcarlini at suse dot de 2005-03-21 12:58
---
Fixed for 4.0.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-15
23:39 ---
Subject: Bug 20352
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-03-15 23:38:54
Modified files:
libstdc++-v3 : ChangeLog
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca
2005-03-08 14:35 ---
Subject: Re: FAIL: 26_numerics/complex/pow.cc execution test
Digging more (in C99 and Posix), it seems that pow(x,y) always behaves the
same
for x == +0 and x == -0: this would imply that
--- Additional Comments From pcarlini at suse dot de 2005-03-07 09:53
---
This is the problem. From the HP-UX 10 manpage
If both x and y are zero, atan2() returns NaN.
The behavior changed in HP-UX 11
If both x and y are zero, atan2() returns zero.
I see. We are assuming the
--- Additional Comments From pcarlini at suse dot de 2005-03-07 10:09
---
Or, better: we can't do much in the right timeframe. When Roger's work will
go in, for float, double and long double complex types will be simply called
pow(0.0, 1.0/3) in this case, instead of the tricky sequence
--- Additional Comments From pcarlini at suse dot de 2005-03-07 13:48
---
Created an attachment (id=8350)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8350action=view)
Tweak to the test at the beginning of pow(const complex_Tp, const _Tp)
--
--- Additional Comments From pcarlini at suse dot de 2005-03-07 13:49
---
Digging more (in C99 and Posix), it seems that pow(x,y) always behaves the same
for x == +0 and x == -0: this would imply that probably it's safe to have in
the generic code something like the attached (vs
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca
2005-03-07 14:52 ---
Subject: Re: FAIL: 26_numerics/complex/pow.cc execution test
Can you test it on the targets you have access to?
I'll try this evening.
Thanks,
Dave
--
--- Additional Comments From pcarlini at suse dot de 2005-03-07 15:04
---
I'll try this evening.
Excellent. Probably, we want this change, irrespective of the improvements
related
to Roger's work. However, probably this means that, for consistency, also the
other overloads of
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
Status|NEW
--- Additional Comments From danglin at gcc dot gnu dot org 2005-03-06
22:52 ---
This fail also occurs on 4.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20352
--- Additional Comments From pcarlini at suse dot de 2005-03-06 23:55
---
The implementation of complex::pow can be definitely improved, and will, as soon
as Roger's work on signbit goes in, still, this issue seems limited to some very
specific, old version of hpux, pre release 11,
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca
2005-03-07 00:06 ---
Subject: Re: FAIL: 26_numerics/complex/pow.cc execution test
The implementation of complex::pow can be definitely improved, and will, as
soon
as Roger's work on signbit goes in, still, this
--- Additional Comments From pcarlini at suse dot de 2005-03-07 00:14
---
Yes, this test doesn't fail on hpux 11. This probably implies a
hpux 10 math library issue. I see the following math routines are
called log, atan2, exp, cos and sin in that order.
Indeed, I was thinking the
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca
2005-03-07 01:31 ---
Subject: Re: FAIL: 26_numerics/complex/pow.cc execution test
We have log(x) == -inf for x == 0+. The exp call is returning 0+
but the argument isn't -inf. It's -5.9923104495410517e+307. -inf
--- Additional Comments From pcarlini at suse dot de 2005-03-07 01:32
---
We have log(x) == -inf for x == 0+. The exp call is returning 0+
but the argument isn't -inf. It's -5.9923104495410517e+307. -inf
is -1.7976931348623157e+308.
Interesting. Therefore, 1/3*(-inf) instead of
On Mar 6, 2005, at 8:31 PM, dave at hiauly1 dot hia dot nrc dot ca
wrote:
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot
ca 2005-03-07 01:31 ---
Subject: Re: FAIL: 26_numerics/complex/pow.cc execution test
We have log(x) == -inf for x == 0+. The exp call is
--- Additional Comments From pinskia at physics dot uc dot edu 2005-03-07
01:39 ---
Subject: Re: FAIL: 26_numerics/complex/pow.cc execution test
On Mar 6, 2005, at 8:31 PM, dave at hiauly1 dot hia dot nrc dot ca
wrote:
--- Additional Comments From dave at hiauly1 dot hia dot
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca
2005-03-07 01:41 ---
Subject: Re: FAIL: 26_numerics/complex/pow.cc execution test
We have log(x) == -inf for x == 0+. The exp call is returning 0+
but the argument isn't -inf. It's -5.9923104495410517e+307.
--- Additional Comments From pcarlini at suse dot de 2005-03-07 01:46
---
In any case, as long as the next exp is 0, the problem must be elsewhere...
Probably the imaginary part of complex::log, as I mentioned in the previous
message.
--
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca
2005-03-07 02:04 ---
Subject: Re: FAIL: 26_numerics/complex/pow.cc execution test
The only other tricky bit of the computation seems atan2(0.0, 0.0)
which should be also zero, of course.
This is the problem. From
--- Additional Comments From schwab at suse dot de 2005-03-07 02:07 ---
C99 says:
F.9.3.7 The log functions
#8212; log(±0) returns #8722;#8734; and raises the
#8216;#8216;divide-by-zero#8217;#8217; #64258;oating-point
exception.
Note that HUGE_VAL == INFINITY on IEEE hosts.
--
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca
2005-03-07 04:03 ---
Subject: Re: FAIL: 26_numerics/complex/pow.cc execution test
Note that HUGE_VAL == INFINITY on IEEE hosts.
I don't believe that's the case for HP-UX 10.20. The define for
HUGE_VALUE is
#
25 matches
Mail list logo
