--- Comment #23 from paolo dot carlini at oracle dot com 2010-02-18 00:45
---
Now I understand the issue this way: the slow down is unavoidable if we want a
correct treatment of signed zero, and the slow down itself is due to the way
the middle-end handles mixed arithmetic. However, the
--- Comment #22 from paolo dot carlini at oracle dot com 2010-02-18 00:16
---
Now I'm confused: I can understand that the C++ front-end is still sometimes
incorrect about signed zeros in mixed arithmetic (these are very old issues),
but why 4.5 is slower than 4.4?!? I something differen
--- Comment #21 from rguenth at gcc dot gnu dot org 2010-02-18 00:02
---
It was fixed by
2009-05-08 Joseph Myers
PR c/24581
* c-typeck.c (build_binary_op): Handle arithmetic between one real
and one complex operand specially.
* tree-complex.c (some_n
--- Comment #20 from paolo dot carlini at oracle dot com 2010-02-17 23:52
---
Richard, I'm pretty sure I read something about signed zeros and slowness, but
now I can't find anything in the 4.5 web page. Should we add
something to it, in particular about -fno-signed-zeros to restore pe
--- Comment #19 from rguenth at gcc dot gnu dot org 2010-02-17 23:43
---
(In reply to comment #18)
> Then file a compiler PR, because between 4.4 and 4.5 *nothing* changed in the
> library.
4.5 has fixed tree-complex to honor signed zeros properly. 4.4 is broken
in this regard.
--
--- Comment #18 from paolo dot carlini at oracle dot com 2010-02-17 23:33
---
Then file a compiler PR, because between 4.4 and 4.5 *nothing* changed in the
library.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43108
--- Comment #17 from jan at epgmod dot phys dot tue dot nl 2010-02-17
23:28 ---
(In reply to comment #16)
> Which regression?!? Nothing changed in this code for *years*.
I use std::complex. With gcc-4.5.0 the performance of c*f is three
times worse than with gcc.4.4.x.
That regression
--- Comment #16 from paolo dot carlini at oracle dot com 2010-02-17 23:18
---
Which regression?!? Nothing changed in this code for *years*.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43108
--- Comment #15 from jan at epgmod dot phys dot tue dot nl 2010-02-17
23:16 ---
(In reply to comment #8)
> The patch will make results incorrect regarding the sign of zeros. Does
> the C++ standard library allow this? Thus, does it specify multiplication
> with a scalar float as compo
--- Comment #14 from paolo dot carlini at oracle dot com 2010-02-17 22:57
---
If the compiler does something wrong, then we should fix the compiler, not add
hacks to the library, without fixing the plethora of uses of __complex__
outside the library. Thus, if you are sure, please double
--- Comment #13 from jan at epgmod dot phys dot tue dot nl 2010-02-17
22:54 ---
(In reply to comment #10)
> Regarding the specific semantics, Richard, there is little to say: we want the
> C99 semantics, by and large. Maybe there are some missing details, but we
> decided already that,
--- Comment #12 from paolo dot carlini at oracle dot com 2010-02-17 22:40
---
Excellent.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43108
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-02-17 22:38
---
Then there is nothing to fix. Use -fno-signed-zeros if you do not care
about the difference of +0.0 and -0.0. Then you get the desired optimization
which tree-complex indeed can figure out.
--
rguenth at gcc
--- Comment #10 from paolo dot carlini at oracle dot com 2010-02-17 22:34
---
Regarding the specific semantics, Richard, there is little to say: we want the
C99 semantics, by and large. Maybe there are some missing details, but we
decided already that, when we switched the complex multi
--- Comment #9 from paolo dot carlini at oracle dot com 2010-02-17 22:27
---
To be clear, once more: the proposed change has been suggested *already* and
rejected, being something which the compiler should be perfectly able to figure
out, when legal according to the optimization options
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-02-17 22:17 ---
The patch will make results incorrect regarding the sign of zeros. Does
the C++ standard library allow this? Thus, does it specify multiplication
with a scalar float as component-wise multiplication?
--
http:/
--- Comment #7 from jan at epgmod dot phys dot tue dot nl 2010-02-17 22:16
---
Created an attachment (id=19902)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19902&action=view)
changelog entry
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43108
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-02-17 22:15 ---
(In reply to comment #4)
> (In reply to comment #3)
> > Well, but float * complex isn't the same as complex *
> > complex. But the library (and also C promotion if you write
> > that in literal C) presents us with c
--- Comment #5 from jan at epgmod dot phys dot tue dot nl 2010-02-17 22:15
---
Created an attachment (id=19901)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19901&action=view)
patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43108
--- Comment #4 from paolo dot carlini at oracle dot com 2010-02-17 21:43
---
(In reply to comment #3)
> Well, but float * complex isn't the same as complex *
> complex. But the library (and also C promotion if you write
> that in literal C) presents us with complex * complex.
Where, e
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-02-17 21:30 ---
(In reply to comment #2)
> I don't see why you want to deal with special cases in the library instead of
> the optimizers: indeed, your *very* analysis shows that the missed
> optimization
> is happening in tree-com
--- Comment #2 from paolo dot carlini at oracle dot com 2010-02-17 21:24
---
I don't see why you want to deal with special cases in the library instead of
the optimizers: indeed, your *very* analysis shows that the missed optimization
is happening in tree-complex.c and improving it woul
--- Comment #1 from jan at epgmod dot phys dot tue dot nl 2010-02-17 21:05
---
Created an attachment (id=19898)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19898&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43108
23 matches
Mail list logo
