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.
--
(timeout = 300)
Reading specs from /home/hp/combined/mmixware-sim/gcc/specs^M
Target: mmix-knuth-mmixware^M
Configured with: /home/hp/combined/combined/configure
--target=mmix-knuth-mmixware^M
Thread model: single^M
gcc version 4.1.0 20050306 (experimental)^M
/home/hp/combined/mmixware-sim/gcc/cc1
--
What|Removed |Added
Component|regression |other
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20354
--
What|Removed |Added
Component|other |testsuite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20354
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-07
03:15 ---
No feedback in 3 months.
--
What|Removed |Added
Status|WAITING
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-07
03:26 ---
Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable
types
On Mar 6, 2005, Mark Mitchell [EMAIL PROTECTED] wrote:
Alexandre Oliva wrote:
+case TARGET_EXPR:
+ {
+
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-07
03:28 ---
Subject: Re: [PR c++/19199] don't turn cond_expr lvalue into min_expr rvalue
(continued from PR c++/20280)
On Mar 5, 2005, Mark Mitchell [EMAIL PROTECTED] wrote:
Roger has objected to this change in the
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-07
03:41 ---
This should be done in the front-ends.
--
What|Removed |Added
Component|middle-end
--- 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
#
--- Additional Comments From mark at codesourcery dot com 2005-03-07 04:19
---
Subject: Re: [PR c++/19199] don't turn cond_expr lvalue into min_expr rvalue
(continued from PR c++/20280)
Alexandre Oliva wrote:
On Mar 5, 2005, Mark Mitchell [EMAIL PROTECTED] wrote:
Roger has
--- Additional Comments From mark at codesourcery dot com 2005-03-07 04:44
---
Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable
types
Alexandre Oliva wrote:
This doesn't look quite right. First, we're trying to get rid of
tsubst_copy; we should not add new
--- Additional Comments From casevh at comcast dot net 2005-03-07 06:15
---
I downloaded and tried the Sun Studio 10 compiler. It does require math_c99.h as
distributed by Sun. So I'd say gcc will need to work around this header file.
--
It appears that some critical expression attributes are lost when memory
reference expressions
are converted to rtl BLKmode operands typically used in (set BLK BLK)
operations for example.
This bug prevents volatile and read-only BLKmode memory reference operands from
being
treatedf properly
--
What|Removed |Added
Component|c |middle-end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20355
--- Additional Comments From pluto at pld-linux dot org 2005-03-07 07:21
---
(In reply to comment #1)
Can you try again? I think this was caused by the patch for PR 20155 which
had to be reverted.
it didn't helped.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20349
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-07
07:24 ---
I think this caused by the patch which fixed PR 19733.
--
What|Removed |Added
101 - 121 of 121 matches
Mail list logo
