https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112960
--- Comment #1 from Stephan Stiller ---
name of document (forgotten in original bug report text): "GNU C Language
Introduction and Reference Manual"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112960
Bug ID: 112960
Summary: omission in documentation: complex numbers can also
have uppercase I and J suffixes
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31485
--- Comment #29 from Andrew Pinski ---
https://gcc.gnu.org/pipermail/gcc-patches/2023-September/630011.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109632
--- Comment #12 from rsandifo at gcc dot gnu.org
---
The patch in comment 11 is just a related spot improvement.
The PR itself is still unfixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109632
--- Comment #11 from CVS Commits ---
The trunk branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:b096a6ebe9d9f9fed4c105f6555f724eb32af95c
commit r14-1131-gb096a6ebe9d9f9fed4c105f6555f724eb32af95c
Author: Richard Sandiford
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109632
--- Comment #10 from rsandifo at gcc dot gnu.org
---
After prototyping this further, I no longer think that lowering
at the gimple level is the best answer. (I should have listened
to Richi.) Although it works, its major drawback is that
it's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109632
--- Comment #9 from Tamar Christina ---
Thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109632
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109632
--- Comment #7 from rsandifo at gcc dot gnu.org
---
Thinking more about it, it would probably be better to defer the
split until around lower_complex time, after IPA (especially inlining),
NRV and tail-recursion. Doing it there should also mak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109632
--- Comment #6 from Tamar Christina ---
That's an interesting approach, I think it would also fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109391 would it not? Since the
int16x8x3_t return would be "scalarized" avoiding the bad expansion?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109632
--- Comment #5 from rsandifo at gcc dot gnu.org
---
Created attachment 54941
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54941&action=edit
hacky proof-of-concept patch
This is a very hacky proof of concept patch. Don't try it on
anyt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109632
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109632
--- Comment #3 from Tamar Christina ---
note that even if we can't stop SLP, we should be able to generate as efficient
code by being creative about the instruction selection, that's why I marked it
as a target bug :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109632
--- Comment #2 from Tamar Christina ---
(In reply to Richard Biener from comment #1)
> Well, the usual unknown ABI boundary at function entry/exit.
Yes but LLVM gets it right, so should be a solve able computer science problem.
:)
Note that th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109632
--- Comment #1 from Richard Biener ---
Well, the usual unknown ABI boundary at function entry/exit.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109632
Bug ID: 109632
Summary: Inefficient codegen when complex numbers are emulated
with structs
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64410
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105451
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105451
Bug ID: 105451
Summary: miss optimizations due to inconsistency in complex
numbers associativity
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31485
Richard Biener changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31485
Andrew Pinski changed:
What|Removed |Added
Component|rtl-optimization|tree-optimization
--- Comment #27 from A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31485
--- Comment #26 from Andrew Pinski ---
Note there might be a dup of this bug somewhere too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31485
--- Comment #25 from Joel Yliluoma ---
(In reply to Jakub Jelinek from comment #24)
> on x86 read e.g. about MXCSR register and in the description of each
> instruction on which Exceptions it can raise.
So the quick answer to #15 is that addps i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31485
--- Comment #24 from Jakub Jelinek ---
Bugzilla is not the right place to educate users. Of course the C FE_*
exceptions map to real hardware exceptions, on x86 read e.g. about MXCSR
register and in the description of each instruction on which E
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31485
--- Comment #23 from Joel Yliluoma ---
(In reply to Jakub Jelinek from comment #21)
> (In reply to Joel Yliluoma from comment #20)
> > Which exceptions would be generated by data in an unused portion of a
> > register?
>
> addps adds 4 float ele
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31485
--- Comment #22 from rguenther at suse dot de ---
On Tue, 21 Apr 2020, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31485
>
> Jakub Jelinek changed:
>
>What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31485
--- Comment #21 from Jakub Jelinek ---
(In reply to Joel Yliluoma from comment #20)
> Which exceptions would be generated by data in an unused portion of a
> register?
addps adds 4 float elements, there is no "unused" portion.
If some of the ele
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31485
--- Comment #20 from Joel Yliluoma ---
(In reply to Jakub Jelinek from comment #16)
> (In reply to Joel Yliluoma from comment #15)
> > (In reply to Richard Biener from comment #14)
> > > I also think llvms code generation is bogus since it appear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31485
Jakub Jelinek changed:
What|Removed |Added
CC||hjl.tools at gmail dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31485
--- Comment #18 from Jakub Jelinek ---
Note, we could do movq %xmm0, %xmm0; movq %xmm1, %xmm1; addpd %xmm1, %xmm0 for
the #c4 first function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31485
--- Comment #17 from rguenther at suse dot de ---
On Tue, 21 Apr 2020, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31485
>
> Jakub Jelinek changed:
>
>What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31485
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31485
--- Comment #15 from Joel Yliluoma ---
(In reply to Richard Biener from comment #14)
> I also think llvms code generation is bogus since it appears the ABI
> does not guarantee zeroed upper elements of the xmm0 argument
> which means they could c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31485
--- Comment #14 from Richard Biener ---
(In reply to Joel Yliluoma from comment #13)
> GCC 4.1.2 is indicated in the bug report headers.
> Luckily, Compiler Explorer has a copy of that exact version, and it indeed
> vectorizes the second function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31485
--- Comment #13 from Joel Yliluoma ---
GCC 4.1.2 is indicated in the bug report headers.
Luckily, Compiler Explorer has a copy of that exact version, and it indeed
vectorizes the second function: https://godbolt.org/z/DC_SSb
On my own system, th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31485
Richard Biener changed:
What|Removed |Added
Blocks||53947
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31485
--- Comment #11 from Joel Yliluoma ---
Looks like this issue has taken a step or two *backwards* in the past years.
Where as the second function used to be vectorized properly, today it seems
neither of them are.
Contrast this with Clang, which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991
--- Comment #28 from Jonathan Wakely ---
(In reply to kargl from comment #21)
> Created attachment 46102 [details]
> fix g++ problem with sqrt(z) where z is complex and imag(z) = -0
This one assumes copysign is valid for arguments of type _Tp, w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991
--- Comment #27 from Jonathan Wakely ---
Not in stage 4.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91337
Chinoune changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91337
--- Comment #2 from Steve Kargl ---
On Sat, Aug 03, 2019 at 03:14:57PM +, kargl at gcc dot gnu.org wrote:
> --- Comment #1 from kargl at gcc dot gnu.org ---
> (In reply to Chinoune from comment #0)
> > I have encountered some underflows/overf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91337
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91337
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91337
Bug ID: 91337
Summary: gfortran skips an if statement with some mathematical
optimisations with complex numbers.
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991
--- Comment #25 from Steve Kargl ---
On Tue, Apr 09, 2019 at 08:24:29PM +, redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991
>
> --- Comment #24 from Jonathan Wakely ---
> Thanks for the patch, I'll test it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991
--- Comment #24 from Jonathan Wakely ---
Thanks for the patch, I'll test it fully tomorrow.
I'll open a separate bug for the FreeBSD issue. We could use more fine-grained
configure checks so that most C99 math functions are enabled, even if some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991
--- Comment #23 from kargl at gcc dot gnu.org ---
Created attachment 46105
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46105&action=edit
fix g++ problem with pow(z,0.5) where imag(z) = -0.
This patch has only been tested with the origina
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991
--- Comment #22 from Steve Kargl ---
On Mon, Apr 08, 2019 at 10:17:00PM +, redi at gcc dot gnu.org wrote:
> (In reply to kargl from comment #19)
> > I get the expected. So, if you're on a system that has
> > _GLIBCXX_USE_C99_COMPLEX, you won
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991
--- Comment #21 from kargl at gcc dot gnu.org ---
Created attachment 46102
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46102&action=edit
fix g++ problem with sqrt(z) where z is complex and imag(z) = -0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991
--- Comment #20 from Jonathan Wakely ---
(In reply to Steve Kargl from comment #16)
> If Andrew is correct and a builtin is called,
Wasn't that me, not Andrew?
> you might find
> my results if you use -fno-builtins (check spelling).
No, same r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991
--- Comment #19 from kargl at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #18)
> On Mon, Apr 08, 2019 at 08:03:36PM +, pinskia at gcc dot gnu.org wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991
> >
> > --- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991
--- Comment #18 from Steve Kargl ---
On Mon, Apr 08, 2019 at 08:03:36PM +, pinskia at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991
>
> --- Comment #17 from Andrew Pinski ---
> >Doesn't this gets the wrong answ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991
--- Comment #17 from Andrew Pinski ---
>Doesn't this gets the wrong answer for __y = -0 (as -0 < 0 is false)?
No, you missed this part:
// The branch cut is on the negative axis.
So maybe the bug is inside FreeBSD and Window
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991
--- Comment #16 from Steve Kargl ---
On Mon, Apr 08, 2019 at 07:20:22PM +, redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991
>
> --- Comment #13 from Jonathan Wakely ---
> (In reply to Steve Kargl from comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991
--- Comment #15 from Andrew Pinski ---
(In reply to Jonathan Wakely from comment #13)
> (In reply to Steve Kargl from comment #10)
> > % g++8 -o z a.cpp -lm && ./z
> > z = (-1.84250315177824e-07,-0)
> >pow(z,0.5) = (2.6283607659
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991
--- Comment #14 from Jonathan Wakely ---
Which is unsurprising because std::sqrt(z) just calls
__builtin_csqrt(z.__rep())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991
--- Comment #13 from Jonathan Wakely ---
(In reply to Steve Kargl from comment #10)
> % g++8 -o z a.cpp -lm && ./z
> z = (-1.84250315177824e-07,-0)
>pow(z,0.5) = (2.62836076598358e-20,-0.000429243887758258)
> sqrt(z) = (0,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991
--- Comment #12 from Jonathan Wakely ---
(In reply to Steve Kargl from comment #11)
> unless [Note: ...] is non-normative text.
That's exactly what it is.
But we can still aim to meet the intended behaviour.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991
--- Comment #11 from Steve Kargl ---
On Mon, Apr 08, 2019 at 02:32:38PM +, sgk at troutmask dot
apl.washington.edu wrote:
>
> I don't have a copy of the C++ standard, so take this specualtion.
> pow(z,0.5) is equivalent to sqrt(z). From the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991
--- Comment #10 from Steve Kargl ---
On Mon, Apr 08, 2019 at 09:59:22AM +, redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991
>
> --- Comment #7 from Jonathan Wakely ---
> I think it's allowed. The standards
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991
--- Comment #9 from Jonathan Wakely ---
(In reply to Richard Biener from comment #5)
> The issue is
>
> std::pow (__x=..., __y=@0x7fffdcb8: 0.5)
> at /home/space/rguenther/install/gcc-9.0/include/c++/9.0.1/complex:1027
> (gdb) l
> 1022
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991
--- Comment #8 from Andrew Pinski ---
Also isn't it true that this is just a different quadrant of the solution?
That is the answer is correct but which quadrant being selected is different?
That is (a^0.5) actually has two answers where the im
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991
--- Comment #7 from Jonathan Wakely ---
I think it's allowed. The standards have very little to say about accuracy of
any mathematical functions, and complex(0, 0.0) == complex(0,
-0.0) is true according to the standard, because +0.0 == -0.0 is t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991
--- Comment #6 from Andrew Pinski ---
(In reply to Richard Biener from comment #5)
> The issue is
>
> std::pow (__x=..., __y=@0x7fffdcb8: 0.5)
> at /home/space/rguenther/install/gcc-9.0/include/c++/9.0.1/complex:1027
> (gdb) l
> 1022
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
--- Comment #5 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991
--- Comment #3 from t.sprodowski at web dot de ---
Octave 4.2.2: ans = 2.6284e-20 + 4.2924e-04i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991
--- Comment #1 from t.sprodowski at web dot de ---
Created attachment 46095
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46095&action=edit
Source file
Source file to illustrate this bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991
Bug ID: 89991
Summary: Complex numbers: Calculation of imaginary part is not
correct
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83191
Jerry DeLisle changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83191
--- Comment #7 from Jerry DeLisle ---
Author: jvdelisle
Date: Sun Dec 3 20:43:59 2017
New Revision: 255368
URL: https://gcc.gnu.org/viewcvs?rev=255368&root=gcc&view=rev
Log:
2017-12-03 Jerry DeLisle
Dominique d'Humieres
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83191
--- Comment #6 from Jerry DeLisle ---
Author: jvdelisle
Date: Sun Dec 3 16:47:12 2017
New Revision: 255365
URL: https://gcc.gnu.org/viewcvs?rev=255365&root=gcc&view=rev
Log:
2017-12-03 Jerry DeLisle
Dominique d'Humieres
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83191
--- Comment #5 from Jerry DeLisle ---
(In reply to Jerry DeLisle from comment #4)
> Alternatively one could do this:
>
> @@ -1809,9 +1809,11 @@ write_complex (st_parameter_dt *dtp, const char
> *source, int kind, size_t size)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83191
--- Comment #4 from Jerry DeLisle ---
Alternatively one could do this:
@@ -1809,9 +1809,11 @@ write_complex (st_parameter_dt *dtp, const char *source,
int kind, size_t size)
precision, buf_size, result1, &res_len1);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83191
--- Comment #3 from Dominique d'Humieres ---
The following patch does the trick:
--- ../_clean/libgfortran/io/write.c2017-11-22 20:37:44.0 +0100
+++ libgfortran/io/write.c 2017-11-28 23:45:55.0 +0100
@@ -1552,7 +1552,7 @
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83191
Jerry DeLisle changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
med|0 |1
Summary|Writing a namelist with |[7/8 Regression] Writing a
|repeated complex numbers|namelist with repeated
||complex numbers
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83191
Bug ID: 83191
Summary: Writing a namelist with repeated complex numbers
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65796
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65796
Bug ID: 65796
Summary: unnecessary stack spills during complex numbers
function calls
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64410
--- Comment #15 from Richard Biener ---
Author: rguenth
Date: Tue Jan 20 11:06:13 2015
New Revision: 219885
URL: https://gcc.gnu.org/viewcvs?rev=219885&root=gcc&view=rev
Log:
2015-01-20 Richard Biener
PR tree-optimization/64410
* g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64410
--- Comment #14 from Rainer Orth ---
Created attachment 34496
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34496&action=edit
sparc-sun-solaris2.11 .vect dump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64410
Rainer Orth changed:
What|Removed |Added
CC||ro at gcc dot gnu.org
--- Comment #13 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64410
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64410
--- Comment #12 from Richard Biener ---
Author: rguenth
Date: Fri Jan 9 11:14:55 2015
New Revision: 219380
URL: https://gcc.gnu.org/viewcvs?rev=219380&root=gcc&view=rev
Log:
2015-01-09 Richard Biener
PR tree-optimization/64410
* tre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64410
--- Comment #10 from Richard Biener ---
Improves runtime from 8.3s to 6.5s (~25%).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64410
--- Comment #9 from Richard Biener ---
Created attachment 34402
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34402&action=edit
patch to pattern-detect the load/store
This pattern matches real/imagpart uses and single-use complex stores a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64410
--- Comment #8 from Marc Glisse ---
(In reply to Richard Biener from comment #5)
> (In reply to Marc Glisse from comment #1)
> > There are a number of things that make it complicated.
> > 1) gcc doesn't like to vectorize when the number of iterat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64410
--- Comment #7 from Richard Biener ---
Created attachment 34400
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34400&action=edit
update-address-taken fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64410
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Status|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64410
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47540
Joel Sherrill changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64410
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
eas the default expansion for
vector addition is addpd. Using addpd by default for complex would make some
code better (this example would hopefully be optimal without need for any
optimization) and some worse, I don't know if there are good benchmarks for
complex numbers.
Clang's use of a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64410
--- Comment #2 from Conrad ---
(In reply to Marc Glisse from comment #1)
> 3) the ABI for complex uses 2 separate double instead of a vector of 2
> double.
Technically yes, but in practice aren't the 2 separate doubles guaranteed to be
consecuti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64410
--- Comment #1 from Marc Glisse ---
There are a number of things that make it complicated.
1) gcc doesn't like to vectorize when the number of iterations is not known at
compile time.
2) gcc doesn't vectorize anything already involving complex or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64410
Bug ID: 64410
Summary: gcc 25% slower than clang 3.5 for adding complex
numbers
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47540
Sebastian Huber changed:
What|Removed |Added
CC||sebastian.huber@embedded-br
1 - 100 of 167 matches
Mail list logo
