[Bug web/112960] omission in documentation: complex numbers can also have uppercase I and J suffixes

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"

[Bug web/112960] New: omission in documentation: complex numbers can also have uppercase I and J suffixes

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

[Bug tree-optimization/31485] C complex numbers, amd64 SSE, missed optimization opportunity

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

[Bug target/109632] Inefficient codegen when complex numbers are emulated with structs

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.

[Bug target/109632] Inefficient codegen when complex numbers are emulated with structs

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

[Bug target/109632] Inefficient codegen when complex numbers are emulated with structs

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

[Bug target/109632] Inefficient codegen when complex numbers are emulated with structs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109632 --- Comment #9 from Tamar Christina --- Thank you!

[Bug target/109632] Inefficient codegen when complex numbers are emulated with structs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109632 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last

[Bug target/109632] Inefficient codegen when complex numbers are emulated with structs

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

[Bug target/109632] Inefficient codegen when complex numbers are emulated with structs

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?

[Bug target/109632] Inefficient codegen when complex numbers are emulated with structs

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=edit hacky proof-of-concept patch This is a very hacky proof of concept patch. Don't try it on anything

[Bug target/109632] Inefficient codegen when complex numbers are emulated with structs

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

[Bug target/109632] Inefficient codegen when complex numbers are emulated with structs

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 :)

[Bug target/109632] Inefficient codegen when complex numbers are emulated with structs

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

[Bug target/109632] Inefficient codegen when complex numbers are emulated with structs

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.

[Bug target/109632] New: Inefficient codegen when complex numbers are emulated with structs

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

[Bug tree-optimization/64410] gcc 25% slower than clang 3.5 for adding complex numbers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64410 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |5.0

[Bug tree-optimization/105451] miss optimizations due to inconsistency in complex numbers associativity

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105451 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0

[Bug tree-optimization/105451] New: miss optimizations due to inconsistency in complex numbers associativity

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

[Bug tree-optimization/31485] C complex numbers, amd64 SSE, missed optimization opportunity

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31485 Richard Biener changed: What|Removed |Added CC||tnfchris at gcc dot gnu.org ---

[Bug tree-optimization/31485] C complex numbers, amd64 SSE, missed optimization opportunity

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31485 Andrew Pinski changed: What|Removed |Added Component|rtl-optimization|tree-optimization --- Comment #27 from

[Bug rtl-optimization/31485] C complex numbers, amd64 SSE, missed optimization opportunity

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.

[Bug rtl-optimization/31485] C complex numbers, amd64 SSE, missed optimization opportunity

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

[Bug rtl-optimization/31485] C complex numbers, amd64 SSE, missed optimization opportunity

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

[Bug rtl-optimization/31485] C complex numbers, amd64 SSE, missed optimization opportunity

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

[Bug rtl-optimization/31485] C complex numbers, amd64 SSE, missed optimization opportunity

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

[Bug rtl-optimization/31485] C complex numbers, amd64 SSE, missed optimization opportunity

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

[Bug rtl-optimization/31485] C complex numbers, amd64 SSE, missed optimization opportunity

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

[Bug rtl-optimization/31485] C complex numbers, amd64 SSE, missed optimization opportunity

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31485 Jakub Jelinek changed: What|Removed |Added CC||hjl.tools at gmail dot com,

[Bug rtl-optimization/31485] C complex numbers, amd64 SSE, missed optimization opportunity

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.

[Bug rtl-optimization/31485] C complex numbers, amd64 SSE, missed optimization opportunity

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

[Bug rtl-optimization/31485] C complex numbers, amd64 SSE, missed optimization opportunity

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31485 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment

[Bug rtl-optimization/31485] C complex numbers, amd64 SSE, missed optimization opportunity

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

[Bug rtl-optimization/31485] C complex numbers, amd64 SSE, missed optimization opportunity

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

[Bug rtl-optimization/31485] C complex numbers, amd64 SSE, missed optimization opportunity

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,

[Bug rtl-optimization/31485] C complex numbers, amd64 SSE, missed optimization opportunity

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31485 Richard Biener changed: What|Removed |Added Blocks||53947 CC|

[Bug rtl-optimization/31485] C complex numbers, amd64 SSE, missed optimization opportunity

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,

[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct

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,

[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991 --- Comment #27 from Jonathan Wakely --- Not in stage 4.

[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct

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

[Bug fortran/91337] gfortran skips an if statement with some mathematical optimisations with complex numbers.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91337 Chinoune changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug fortran/91337] gfortran skips an if statement with some mathematical optimisations with complex numbers.

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

[Bug fortran/91337] gfortran skips an if statement with some mathematical optimisations with complex numbers.

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

[Bug fortran/91337] gfortran skips an if statement with some mathematical optimisations with complex numbers.

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 ---

[Bug fortran/91337] New: gfortran skips an if statement with some mathematical optimisations with complex numbers.

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

[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct

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

[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct

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

[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct

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=edit fix g++ problem with pow(z,0.5) where imag(z) = -0. This patch has only been tested with the original test

[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct

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

[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct

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=edit fix g++ problem with sqrt(z) where z is complex and imag(z) = -0

[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct

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

[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct

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

[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct

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

[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct

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

[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct

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

[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct

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) =

[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct

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())

[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct

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) =

[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct

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.

[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct

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

[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct

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

[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct

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

[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct

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

[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct

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

[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct

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

[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991 Richard Biener changed: What|Removed |Added Keywords||wrong-code --- Comment #5 from Richard

[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct

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

[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct

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 ---

[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct

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=edit Source file Source file to illustrate this bug.

[Bug libstdc++/89991] New: Complex numbers: Calculation of imaginary part is not correct

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

[Bug fortran/83191] [7/8 Regression] Writing a namelist with repeated complex numbers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83191 Jerry DeLisle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug fortran/83191] [7/8 Regression] Writing a namelist with repeated complex numbers

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=gcc=rev Log: 2017-12-03 Jerry DeLisle Dominique

[Bug fortran/83191] [7/8 Regression] Writing a namelist with repeated complex numbers

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=gcc=rev Log: 2017-12-03 Jerry DeLisle Dominique

[Bug fortran/83191] [7/8 Regression] Writing a namelist with repeated complex numbers

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) >

[Bug fortran/83191] [7/8 Regression] Writing a namelist with repeated complex numbers

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, _len1);

[Bug fortran/83191] [7/8 Regression] Writing a namelist with repeated complex numbers

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

[Bug fortran/83191] [7/8 Regression] Writing a namelist with repeated complex numbers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83191 Jerry DeLisle changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned

[Bug fortran/83191] [7/8 Regression] Writing a namelist with repeated complex numbers

|1 Summary|Writing a namelist with |[7/8 Regression] Writing a |repeated complex numbers|namelist with repeated ||complex numbers Target Milestone|--- |7.3

[Bug fortran/83191] New: Writing a namelist with repeated complex numbers

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

[Bug middle-end/65796] unnecessary stack spills during complex numbers function calls

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65796 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last

[Bug middle-end/65796] New: unnecessary stack spills during complex numbers function calls

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

[Bug tree-optimization/64410] gcc 25% slower than clang 3.5 for adding complex numbers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64410 --- Comment #15 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Tue Jan 20 11:06:13 2015 New Revision: 219885 URL: https://gcc.gnu.org/viewcvs?rev=219885root=gccview=rev Log: 2015-01-20 Richard Biener rguent...@suse.de

[Bug tree-optimization/64410] gcc 25% slower than clang 3.5 for adding complex numbers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64410 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added CC||ro at gcc dot gnu.org

[Bug tree-optimization/64410] gcc 25% slower than clang 3.5 for adding complex numbers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64410 --- Comment #14 from Rainer Orth ro at gcc dot gnu.org --- Created attachment 34496 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34496action=edit sparc-sun-solaris2.11 .vect dump

[Bug tree-optimization/64410] gcc 25% slower than clang 3.5 for adding complex numbers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64410 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED

[Bug tree-optimization/64410] gcc 25% slower than clang 3.5 for adding complex numbers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64410 --- Comment #12 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Fri Jan 9 11:14:55 2015 New Revision: 219380 URL: https://gcc.gnu.org/viewcvs?rev=219380root=gccview=rev Log: 2015-01-09 Richard Biener rguent...@suse.de

[Bug c++/64410] gcc 25% slower than clang 3.5 for adding complex numbers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64410 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||rguenth at

[Bug c++/64410] gcc 25% slower than clang 3.5 for adding complex numbers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64410 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords|

[Bug c++/64410] gcc 25% slower than clang 3.5 for adding complex numbers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64410 --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- Created attachment 34400 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34400action=edit update-address-taken fix

[Bug c++/64410] gcc 25% slower than clang 3.5 for adding complex numbers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64410 --- Comment #8 from Marc Glisse glisse at gcc dot gnu.org --- (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

[Bug c++/64410] gcc 25% slower than clang 3.5 for adding complex numbers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64410 --- Comment #10 from Richard Biener rguenth at gcc dot gnu.org --- Improves runtime from 8.3s to 6.5s (~25%).

[Bug c++/64410] gcc 25% slower than clang 3.5 for adding complex numbers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64410 --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org --- Created attachment 34402 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34402action=edit patch to pattern-detect the load/store This pattern matches real/imagpart uses and

[Bug target/47540] ARM THUMB crash with complex numbers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47540 Joel Sherrill joel at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED

[Bug c++/64410] gcc 25% slower than clang 3.5 for adding complex numbers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64410 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last

[Bug c++/64410] gcc 25% slower than clang 3.5 for adding complex numbers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64410 --- Comment #1 from Marc Glisse glisse at gcc dot gnu.org --- 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

[Bug c++/64410] gcc 25% slower than clang 3.5 for adding complex numbers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64410 --- Comment #2 from Conrad conradsand.arma at gmail dot com --- (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

[Bug c++/64410] gcc 25% slower than clang 3.5 for adding complex numbers

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 add[ps]d seems based

[Bug c++/64410] New: gcc 25% slower than clang 3.5 for adding complex numbers

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

[Bug target/47540] ARM THUMB crash with complex numbers

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47540 Sebastian Huber sebastian.hu...@embedded-brains.de changed: What|Removed |Added CC|

  1   2   >