--- Additional Comments From fredrik dot huss at home dot se 2005-03-16
17:25 ---
I see similar problems with real by complex multiplications in C++.
The following test program,
#include
std::complex a, b;
double c;
void f()
{
a = b * c;
}
when compiled with "g++ -O3 -
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-01
21:26 ---
(In reply to comment #18)
> > :;
> > D.2390 = 0.0 / SR.22;
> > D.2392 = SR.22 + D.2390 * 0.0;
> > c$real = (D.2371 + D.2372 * D.2390) / D.2392;
> > c$imag = (D.2372 - D.2371 * D.2390) / D.2392;
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-01
21:14 ---
(In reply to comment #17)
> Andrew,
>
> I'm sorry if I'm not making myself clear here.
>
> The problem that I see is that, on ia64-unknown-linux-gnu and on
> i386-pc-linux-gnu, with clean trees, I see code
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-01
21:07 ---
Andrew,
I'm sorry if I'm not making myself clear here.
The problem that I see is that, on ia64-unknown-linux-gnu and on
i386-pc-linux-gnu, with clean trees, I see code like
:;
D.2390 = 0.0 / SR.22;
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-01
17:13 ---
(In reply to comment #15)
> I can only assume that this has regressed, that this is a
> little-endian problem (why it should be so is beyond me, though),
> that your specific vibes make this go away or that
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-01
15:43 ---
(In reply to comment #14)
> (In reply to comment #13)
> > (In reply to comment #11)
> I get the same as I got above with the following version on x86:
> GNU C version 4.0.0 20050225 (experimental) (i686-
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-28
23:02 ---
(In reply to comment #13)
> (In reply to comment #11)
I get the same as I got above with the following version on x86:
GNU C version 4.0.0 20050225 (experimental) (i686-pc-linux-gnu)
compiled by GNU
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-28
21:58 ---
(In reply to comment #11)
> For me I get:
> D.1542 = COMPLEX_EXPR / SR.4, IMAGPART_EXPR / SR.4>;
> D.1541 = D.1542;
> D.1500 = D.1541;
> return (double) REALPART_EXPR + (double) IMAGPART_EXPR
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-28
21:38 ---
So after my investigation says this is fixed so closing as such.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-28
21:36 ---
For me I get:
D.1542 = COMPLEX_EXPR / SR.4, IMAGPART_EXPR / SR.4>;
D.1541 = D.1542;
D.1500 = D.1541;
return (double) REALPART_EXPR + (double) IMAGPART_EXPR <
0.0;
The only problem with this is
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-28
20:55 ---
What I meant was comment#8 *sigh*
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19953
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-28
20:55 ---
Comment #7 shows that there is still something to be done
for (br+I*bi)/a (with real br, bi, a). This could be
simplified to br/a + I*bi/a, which isn't happening.
Thomas
--
What|Remove
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-27
12:52 ---
Is this really fixed?
Look at this:
$ cat c-div.c
#include
#include
int main()
{
float a;
complex float b,c;
foo(&a,&b);
c = b/a;
return creal(c) + cimag(c) < 0;
}
$ gcc -ffast-ma
--- Additional Comments From rth at gcc dot gnu dot org 2005-02-24 20:04
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-24
20:00 ---
Subject: Bug 19953
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-02-24 20:00:09
Modified files:
gcc: ChangeLog builtins.c fold-const.c tre
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org |
Status|NEW
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-15
10:29 ---
> And in fact this only can happen with -funsafe-math-optimizations (or maybe
with -fno-trapping-
> math because a+0.0 can trap.
Hmm...
if b is complex and has the value (0., signalling NaN) and a is
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-15
06:15 ---
(In reply to comment #3)
> For addition, this is a regression against 3.3.5:
Actually it is not and here is why:
fadds .LC0
.LC0 is actually zero.
And in fact this only can happen with -funsafe-m
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-14
20:06 ---
Same thing for complex division, where the performance
penalty is probably also pretty severe:
$ cat c-div.c
#include
#include
int main()
{
float a;
complex float b,c;
foo(&a,&b);
c
19 matches
Mail list logo
