http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51582
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51582
--- Comment #4 from Jason Merrill jason at gcc dot gnu.org 2013-04-06
16:08:28 UTC ---
Created attachment 29816
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29816
patch
Here's a fix. I'm not going to apply it to the 4.6 branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51582
--- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2013-04-05
15:18:10 UTC ---
This was fixed on the trunk by
http://gcc.gnu.org/viewcvs?root=gccview=revrev=177073
I put a simpler variant on the 4.6 branch to fix 49924, but
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53140
Bug #: 53140
Summary: Add support for vector of complex numbers
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53140
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51582
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|4.6.3 |4.6.4
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51582
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Known to work||4.5.3, 4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51582
Bug #: 51582
Summary: ICE when using a class with a matrix of complex
numbers in C++0x mode
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status
Regression] ICE when
|a matrix of complex numbers |using a class with a matrix
|in C++0x mode |of complex numbers in C++0x
||mode
--- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47540
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|4.6.1 |---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47473
--- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-07
18:24:45 UTC ---
Author: jakub
Date: Thu Apr 7 18:24:43 2011
New Revision: 172113
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172113
Log:
Backported from mainline
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47473
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47540
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|4.6.0 |4.6.1
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47473
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47540
Ramana Radhakrishnan ramana at gcc dot gnu.org changed:
What|Removed |Added
CC||ramana at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47473
--- Comment #8 from Diego Novillo dnovillo at gcc dot gnu.org 2011-02-02
17:53:56 UTC ---
Author: dnovillo
Date: Wed Feb 2 17:53:51 2011
New Revision: 169624
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169624
Log:
PR c/47473
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47540
--- Comment #6 from Mikael Pettersson mikpe at it dot uu.se 2011-02-01
10:11:52 UTC ---
The bug started to occur at r140501:
Author: pinskia
Date: Fri Sep 19 22:24:06 2008
New Revision: 140501
URL:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47540
Richard Earnshaw rearnsha at gcc dot gnu.org changed:
What|Removed |Added
CC||rearnsha at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47540
--- Comment #4 from Mikael Pettersson mikpe at it dot uu.se 2011-01-31
10:34:56 UTC ---
I can reproduce the ICE with a 4.5.2 cross to arm-elf. Only occurs for Thumb1.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47540
Ian Lance Taylor ian at airs dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47540
Mikael Pettersson mikpe at it dot uu.se changed:
What|Removed |Added
CC||mikpe at it dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47540
--- Comment #3 from Joel Sherrill joel at gcc dot gnu.org 2011-01-30 16:39:05
UTC ---
Test case also fails on arm-rtems4.11 4.5.2 and arm-rtems4.10 4.4.5. It works
on arm-rtems4.9 which is 4.3.2
= 4.5.2
$ sh -x j
+
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47540
Summary: ARM THUMB crash with complex numbers
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47540
--- Comment #1 from Ian Lance Taylor ian at airs dot com 2011-01-30 07:57:23
UTC ---
Created attachment 23166
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23166
Possible patch
This is a possible patch for this bug. It fixes what appears
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47473
Summary: Incorrect computation with complex numbers when using
-std=c99
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Confirmed|0 |1
Summary|Incorrect computation with |[4.5/4.6 Regression]
|complex numbers when using |Incorrect computation with
|-std=c99|complex numbers when using
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47473
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47473
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47473
--- Comment #4 from H.J. Lu hjl.tools at gmail dot com 2011-01-26 15:14:10
UTC ---
It is caused by revision 147281:
http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00255.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47473
--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-26
15:19:56 UTC ---
Created attachment 23132
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23132
gcc46-pr47473.patch
Untested fix.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47473
--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-26
20:07:02 UTC ---
Author: jakub
Date: Wed Jan 26 20:06:57 2011
New Revision: 169299
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169299
Log:
PR c/47473
* c-lex.c
Summary|[4.5/4.6 Regression]|[4.5 Regression] Incorrect
|Incorrect computation with |computation with complex
|complex numbers when using |numbers when using -std=c99
|-std=c99|
Known to fail|4.6.0
--- Comment #8 from irar at il dot ibm dot com 2010-04-21 11:33 ---
Yes, it's possible to add this to SLP. But I don't understand how
D.3154_3 = COMPLEX_EXPR D.3163_8, D.3164_9;
should be vectorized. D.3154_3 is complex and the rhs will be a vector
{D.3163_8, D.3164_9} (btw, we have to
--- Comment #9 from rguenther at suse dot de 2010-04-21 11:44 ---
Subject: Re: C complex numbers, amd64 SSE, missed
optimization opportunity
On Wed, 21 Apr 2010, irar at il dot ibm dot com wrote:
--- Comment #8 from irar at il dot ibm dot com 2010-04-21 11:33 ---
Yes
--- Comment #10 from irar at il dot ibm dot com 2010-04-21 18:33 ---
Thanks. So, it is not always profitable and requires a cost model.
I am now working on cost model for basic block vectorization, I can look at
this once we have one.
--
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-04-17 11:11 ---
We now have basic-block vectorization but it still works on memory accesses
(visible on the gimple level) only. So it doesn't handle
add1 (ss1 a, ss1 b)
{
float D.3164;
float D.3163;
float b$imag;
float
--- Comment #6 from ddesics at gmail dot com 2010-04-17 00:28 ---
Has any work been done on this enhancement? I'm using gcc 4.3.2, and I noticed
that there is still limited use of SSE instructions for complex arithmetic.
Unless I'm missing something in my understanding, wouldn't the
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-08-02 12:21 ---
Operations in loops should now be vectorized. The original testcase is
probably not worth vectorizing due to calling convention problems (_Complex T
is not passed as a vector).
Complex lowering could generate
--- Comment #4 from ubizjak at gmail dot com 2008-08-02 13:00 ---
(In reply to comment #3)
Operations in loops should now be vectorized. The original testcase is
probably not worth vectorizing due to calling convention problems (_Complex T
is not passed as a vector).
Not really.
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-08-02 13:18 ---
Doh, this is indeed completely broken ;) I'll experiment with lowering
complex operations to vectorized form a bit.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from victork at gcc dot gnu dot org 2008-07-29 22:06 ---
Revision 138198 fixes loop aware SLP vectorization for addition of complex
numbers. So if addition of is done inside a loop, there is a good chance now
that it will be vectorized.
--
http://gcc.gnu.org/bugzilla
--- Comment #3 from rwild at gcc dot gnu dot org 2008-02-22 06:18 ---
Subject: Bug 1
Author: rwild
Date: Fri Feb 22 06:17:46 2008
New Revision: 132540
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132540
Log:
gcc/:
PR c/1
* c-typeck.c (build_binary_op): Warn about
--- Comment #4 from rwild at gcc dot gnu dot org 2008-02-22 06:19 ---
Fixed in 4.4.
--
rwild at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #2 from rwild at gcc dot gnu dot org 2008-02-21 06:29 ---
patch at http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00897.html
--
rwild at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-04-09 18:47 ---
Complex operations are lowered at the tree-level so this would require
vectorizing
of straight line code. Second, calling conventions are different.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31485
) (Debian 4.1.1-21)
--
Summary: C complex numbers, amd64 SSE, missed optimization
opportunity
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: rtl-optimization
The compiler output is:
internal compiler error: tree check: expected ssa_name, have var_decl in
gather_mem_refs_stmt, at tree-ssa-loop-im.c:1275
Please submit a full bug report
--
Summary: ICE tree check using complex numbers and the -fno-
automatic compiler option
-Wfloat-equal warns for comparison of real floating-point numbers,
but not for complex numbers.
double a, b;
_Complex double c, d;
int f(void) { return a == b; }
int g(void) { return c == d; }
warns for the comparison in f, but not for that in g.
--
Summary: -Wfloat-equal does
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-16
06:48 ---
Confirmed, it is easy to see where the problem is when we look at the source:
if (warn_float_equal (code0 == REAL_TYPE || code1 == REAL_TYPE))
warning (comparing floating point with == or !=
Hello
I have looked at the implementation of complex arithmetic in gcc.
I see tree problems with naive formulas for multiplication and
division that are currently in use.
1. Problems with special values. For example (infinity+ i*NaN)^2
should be (infinity + i*0) according to IEC 60559 and
I have looked at the implementation of complex arithmetic in gcc.
We are already aware of this issue, since you have already reported
it ;) The relevant PR is middle-end/18902.
Indeed, our plan involves enabling the (*already available*) algorithm
due to Smith. There are still some open issues,
Paolo Carlini wrote:
We are already aware of this issue, since you have already reported
it ;) The relevant PR is middle-end/18902.
Forgot to add: for other issues, related in particular to multiplication,
not only division, please file appropriate Bugzilla PRs.
Thanks!
Paolo.
Hello
Ok, thanks. The important section of the C99 standard is Annex G (IEC
60559-compatible complex arithmetic): it even provides a reference
implementation of the division in Example2. Perhaps, you could have a
look to a public draft of the final standard, just Google a bit... ;)
But
Hello
Have a look to the implementation: it looks like that even if we switch
to the
better algorithm, still we don't get fully right C99. Of course this
last point
must be better investigate (I'm not a floating point expert) but I
expect someone
replying: let's implement C99 division
Hello
| What was the critice you mentioned above? I can not imagine a sitation in
| which I would need the naive implementation.
Oh, I got repeated complaints from users that the correct method of
computation was slow -- look at the bugzilla archive. I believe there
might alos be
Andreas Klein wrote:
Unfortunally I have own no copy of the C99 standard. So I would be glade
if you could give me an internet ressource which disscuss the C99 division
algorithm or something like that. Then I will try to check what we can do.
Ok, thanks. The important section of the C99
the compiler uses to implement complex
numbers in C99 and Fortran. So, the problem is a compiler problem not
libstdc++ problem.
I have testet my program with a 2.95 and several 3.x versionsions of gcc.
The lastet version I have is 3.3.3.
All versions gave the same result.
What was the critice you
As you mentinon it if have missed the specilization at the end of
std_complex.h. Sorry. I still think that we should have and other
implementation for complexfloating_point, but I cannot change the code
of __complex__ T in the complier.
Interestingly, it looks like the discussed improved algorithm
Hello
Interestingly, it looks like the discussed improved algorithm is
*already* implemented, just not used!
Curious
Have a look to expand_complex_division in gcc/tree-complex.c, then
gcc/toplev.c for flag_complex_divide_method.
Andreas, just for curiosity, are you willing to rebuild your
Andreas Klein wrote:
Have a look to expand_complex_division in gcc/tree-complex.c, then
gcc/toplev.c for flag_complex_divide_method.
Andreas, just for curiosity, are you willing to rebuild your gcc
with flag_complex_divide_method = 1 and report???
Willing is not the problem. But I have only
Paolo Carlini wrote:
I will try to do the same as soon as possible...
I can confirm that setting flag_complex_divide_method = 1 leads to (0, 0).
Paolo.
Hello
However I think if flag_complex_divide_method = 1 fix the problem it would
be a good idea to set it by default.
... but notice that this issue is tricky: there are computational issues
(we are adding
at least a branch for each division) and correctness issues (what about
C99?)
As
Andreas Klein wrote:
... but notice that this issue is tricky: there are computational issues
(we are adding
at least a branch for each division) and correctness issues (what about
C99?)
As I see it the naive formula needs
6 multipications, 2 divisions and 3 additions/subtractions
and the
it specializes
| to __complex__ T which is what the compiler uses to implement complex
| numbers in C99 and Fortran. So, the problem is a compiler problem not
| libstdc++ problem.
|
| I have testet my program with a 2.95 and several 3.x versionsions of gcc.
| The lastet version I have is 3.3.3
Andreas Klein [EMAIL PROTECTED] writes:
| This look like a good deal. However for floting point computations I
| prevere good results over fast results.
You're in the minority (including me :-)).
-- Gaby
Hello
I have found a bug in the implementation of the complex library of
g++ and the complex.h library of the gcc (c99 support).
The simplest program that demonstrates the bug is:
#includeiostream
#includecomplex
using namespace std;
int main() {
of fact, the implementation of complex is criticized,
once in a while, because it does NOT use the grammar school rule you
present above. However, for float, double, long double it specializes
to __complex__ T which is what the compiler uses to implement complex
numbers in C99 and Fortran. So
101 - 167 of 167 matches
Mail list logo