--- 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-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 : Change
--- 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
libstdc++-v3/inclu
--- 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 pr
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
Status|NEW
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2005-03-
--- 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 complex
--- 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
--
http://gcc.gnu.org/bugzilla/show_bug.
--- 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 mainline
--- 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=8350&action=view)
Tweak to the test at the beginning of pow(const complex<_Tp>&, const _Tp&)
--
http://gcc.gnu.org/bugzilla/s
--- 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 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
--- 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
# def
--- Additional Comments From schwab at suse dot de 2005-03-07 02:07 ---
C99 says:
F.9.3.7 The log functions
— log(±0) returns −∞ and raises the
‘‘divide-by-zero’’ floating-point
exception.
Note that HUGE_VAL == INFINITY on IEEE hosts.
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- 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 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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20
--- 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 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
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 returnin
--- 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
--- 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 dave at hiauly1 dot hia dot nrc dot ca
2005-03-07 01:08 ---
Subject: Re: FAIL: 26_numerics/complex/pow.cc execution test
> > Yes, this test doesn't fail on hpux 11. This probably implies a
> > hpux 10 math library issue. I see the following math routines
--- 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 t
--- 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-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, right
--- 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
26 matches
Mail list logo
