[Bug libstdc++/48760] [4.6 / 4.7 Regression] std::complex constructor buggy in the face of NaN's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760 --- Comment #26 from paolo at gcc dot gnu.org 2011-04-28 10:52:20 UTC --- Author: paolo Date: Thu Apr 28 10:52:17 2011 New Revision: 173065 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173065 Log: 2011-04-28 Paolo Carlini PR libstdc++/48760 * include/std/complex (complex::complex(float, float), complex::complex(double, double), complex::complex(long double, long double)): Use list-initialization in C++0x mode, initialize in the body in C++03 mode. * testsuite/26_numerics/complex/cons/48760.cc: New. * testsuite/26_numerics/complex/cons/48760_c++0x.cc: Likewise. 2011-04-28 Paolo Carlini * include/std/bitset (_Base_bitset(unsigned long long)): Minor tweak, remove redundant round braces. Added: trunk/libstdc++-v3/testsuite/26_numerics/complex/cons/48760.cc trunk/libstdc++-v3/testsuite/26_numerics/complex/cons/48760_c++0x.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/parallel/losertree.h trunk/libstdc++-v3/include/parallel/multiway_merge.h trunk/libstdc++-v3/include/parallel/multiway_mergesort.h trunk/libstdc++-v3/include/parallel/par_loop.h trunk/libstdc++-v3/include/parallel/partial_sum.h trunk/libstdc++-v3/include/parallel/quicksort.h trunk/libstdc++-v3/include/parallel/random_shuffle.h trunk/libstdc++-v3/include/std/bitset trunk/libstdc++-v3/include/std/complex
[Bug libstdc++/48760] [4.6 / 4.7 Regression] std::complex constructor buggy in the face of NaN's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760
--- Comment #25 from Jason Merrill 2011-04-28
01:53:56 UTC ---
Author: jason
Date: Thu Apr 28 01:53:53 2011
New Revision: 173058
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173058
Log:
PR libstdc++/48760
Implement list-initialization of _Complex.
* decl.c (reshape_init_r): Allow {real,imag} for _Complex.
(check_initializer): Likewise.
* call.c (build_complex_conv): New.
(implicit_conversion): Call it.
(convert_like_real): Handle it.
* typeck2.c (check_narrowing): Handle it.
Added:
trunk/gcc/testsuite/g++.dg/ext/complex8.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/decl.c
trunk/gcc/cp/typeck2.c
trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/48760] [4.6 / 4.7 Regression] std::complex constructor buggy in the face of NaN's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760 Paolo Carlini changed: What|Removed |Added CC|jason at gcc dot gnu.org, | |jason at redhat dot com | AssignedTo|paolo.carlini at oracle dot |jason at redhat dot com |com | --- Comment #24 from Paolo Carlini 2011-04-27 21:38:49 UTC --- Jason is on it.
[Bug libstdc++/48760] [4.6 / 4.7 Regression] std::complex constructor buggy in the face of NaN's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760 --- Comment #23 from Paolo Carlini 2011-04-27 13:27:50 UTC --- Got it ;)
[Bug libstdc++/48760] [4.6 / 4.7 Regression] std::complex constructor buggy in the face of NaN's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760 --- Comment #22 from Jason Merrill 2011-04-27 13:08:48 UTC --- (In reply to comment #21) > PS: C++1x is private jargon, but well, as -std= argument, together with c++0x > we'll need something more realistic, at some point, don't you think? ;) At some point, yes: after the standard is ratified, at which point we won't need an 'x'. :)
[Bug libstdc++/48760] [4.6 / 4.7 Regression] std::complex constructor buggy in the face of NaN's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760 Paolo Carlini changed: What|Removed |Added Summary|[4.6 / 4.7 Regression (?)] |[4.6 / 4.7 Regression] |std::complex constructor|std::complex constructor |buggy in the face of NaN's |buggy in the face of NaN's --- Comment #21 from Paolo Carlini 2011-04-27 09:08:31 UTC --- Ok, thanks, let's see what I can do over the next days, I'll contact you again if I will get stuck. PS: C++1x is private jargon, but well, as -std= argument, together with c++0x we'll need something more realistic, at some point, don't you think? ;)
[Bug libstdc++/48760] [4.6 / 4.7 Regression (?)] std::complex constructor buggy in the face of NaN's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760
--- Comment #20 from Jason Merrill 2011-04-27
03:55:27 UTC ---
(In reply to comment #19)
> : data{ r, i } { }
Yes.
> In my opinion, at this point at least, it would be safer and simpler to
> restrict the syntax to C++1x
What is this C++1x you speak of? But yes, that makes sense.
> Thus, any tip about the right bits of the C++ front-end to touch?
I would start with the BRACE_ENCLOSED_INITIALIZER_P part of
implicit_conversion.
Jason
[Bug libstdc++/48760] [4.6 / 4.7 Regression (?)] std::complex constructor buggy in the face of NaN's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760
--- Comment #19 from Paolo Carlini 2011-04-27
01:26:43 UTC ---
Thus, if I understand correctly Gaby and Jason, we want to be able to
initialize a __complex__ float type *exactly* like an array of two floats?
Thus:
struct C
{
//float data[2];
__complex__ float data;
C(float r, float i)
: data{ r, i } { }
};
??
In my opinion, at this point at least, it would be safer and simpler to
restrict the syntax to C++1x, as part of the extended initializer lists
machinery and deal with the C++03 version of this PR separately (we can wa the
problem in the body, because the constructor isn't constexpr in that case).
Thus, any tip about the right bits of the C++ front-end to touch? Without, it
would take me a while to figure out, I'm afraid...
[Bug libstdc++/48760] [4.6 / 4.7 Regression (?)] std::complex constructor buggy in the face of NaN's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #18 from Jason Merrill 2011-04-26 23:57:02 UTC --- Allowing C++0x list-initialization of complex makes a lot of sense to me.
[Bug libstdc++/48760] [4.6 / 4.7 Regression (?)] std::complex constructor buggy in the face of NaN's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760 --- Comment #17 from joseph at codesourcery dot com 2011-04-26 15:03:49 UTC --- As far as I can see, the main (only?) use of imaginary types is for this issue of constructing complex values. In addition, you need to define for each target the ABI for argument passing and return of imaginary types (and in particular how _Imaginary float is passed in variable arguments - it is *not* promoted to _Imaginary double, whereas float is promoted to double in variable arguments at the C language level before the ABI comes into play, so whereas targets don't need to allow for unpromoted float in variable arguments they do need to allow for unpromoted _Imaginary float). But, given that, it would indeed be nice to support imaginary types.
[Bug libstdc++/48760] [4.6 / 4.7 Regression (?)] std::complex constructor buggy in the face of NaN's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760 --- Comment #16 from Paolo Carlini 2011-04-26 14:54:12 UTC --- Thanks Joseph for the explanation and the references. Now maybe I'm digressing in terms of the C++ issue we are facing, but I'm wondering: at some point, even for C99, shouldn't we support imaginary types?
[Bug libstdc++/48760] [4.6 / 4.7 Regression (?)] std::complex constructor buggy in the face of NaN's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760 --- Comment #15 from joseph at codesourcery dot com 2011-04-26 14:30:50 UTC --- On Mon, 25 Apr 2011, john at johnmaddock dot co.uk wrote: > Sorry to be dumb, but doesn't the result of the C code violate section G.5.2 > in > C99 - which is to say that no matter what the value of the imaginary part of > an > expression, it never changes the real part - even if that is a NaN? I can't make any sense of that sentence - what is the "it" you are saying is changing a real part but shouldn't be? In NaN * 1.0fi, the first operand is real and the second is complex (*not* imaginary, GCC doesn't have imaginary types), so the real part of the result is NaN*0 which is NaN and the imaginary part is NaN*1 which is also NaN. Adding 0 then results in a real part of 0+NaN, which is NaN, and an imaginary part of NaN. This is in accordance with how mixed real/complex arithmetic works in C99 - implemented for C in 4.5 and I think for C++ in 4.6 (with associated removal of bogus optimizations that tried to treat values of complex type as being real or imaginary values if one part was zero). The built-in function semantics would be those of CMPLXF, CMPLX and CMPLXL in 7.3.9.3 in the C1X DIS (N1569).
[Bug libstdc++/48760] [4.6 / 4.7 Regression (?)] std::complex constructor buggy in the face of NaN's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760
--- Comment #14 from Gabriel Dos Reis 2011-04-26
14:12:35 UTC ---
(In reply to comment #12)
> (In reply to comment #9)
> > I guess, in the 4.6.1 time frame we can only workaround the issue in C++03
> > mode
> > by doing the piecewise work in the body. I can maybe help for the compiler
> > work
> > too but I need more guidance: is there an agreement about the C1X inspired
> > builtin suggested by Joseph? In case, can I have a more specific reference?
> >
> > I'm adding in CC Richi too, in case he has additional tips and/or hints
> > about
> > the builtin work..
>
> A __builtin_complex builtin should be almost trivial. It would be purely
> frontend sugar for frontends that lack a way to specify a complex value
> component-wise. The frontend would be resposible for lowering it to
> a COMPLEX_EXPR. I don't think the middle-end wants to deal with
> __builtin_complex as it already has a perfect matching tree code.
Agreed -- except since __builtin_complex is already a perfect match,
the front-end should just accept either
_M_value{r,i}
or
_M_value(r,i)
if it wanted to be C++03 compatible too. Either way, you say, there
is no need to involve the middle end.
>
> Now I understand C++0x might have a proper syntax already, so I'm not sure
> how it relates to this (C++) bug.
>
> What changed in 4.6 is that we put complex values in registers even at -O0.
that is fine (and appreciated!). It is unrelated to the bug though.
> You should be able to reproduce any issue in this bug in older releases
> with optimization turned on (given that the library implementation didn't
> change).
The bug is a source-level bug; the source code is written that way because
we don't have yet a good way to initialize at once GCC builtin COMPLEX_EXPR.
-- Gaby
[Bug libstdc++/48760] [4.6 / 4.7 Regression (?)] std::complex constructor buggy in the face of NaN's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760 --- Comment #13 from Paolo Carlini 2011-04-26 10:03:41 UTC --- Thanks. Thus, since the original issue boils down to a C++ front-end issue only, I guess we have to wait for Jason' opinion whether we can avoid adding a builtin and go the way proposed by Gaby or not. I would really like to see this fixed for 4.6.1 too, I hope we can figure out something suited, minimally invasive and/or restricted to the C++0x codepath...
[Bug libstdc++/48760] [4.6 / 4.7 Regression (?)] std::complex constructor buggy in the face of NaN's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760 --- Comment #12 from Richard Guenther 2011-04-26 08:44:18 UTC --- (In reply to comment #9) > I guess, in the 4.6.1 time frame we can only workaround the issue in C++03 > mode > by doing the piecewise work in the body. I can maybe help for the compiler > work > too but I need more guidance: is there an agreement about the C1X inspired > builtin suggested by Joseph? In case, can I have a more specific reference? > > I'm adding in CC Richi too, in case he has additional tips and/or hints about > the builtin work.. A __builtin_complex builtin should be almost trivial. It would be purely frontend sugar for frontends that lack a way to specify a complex value component-wise. The frontend would be resposible for lowering it to a COMPLEX_EXPR. I don't think the middle-end wants to deal with __builtin_complex as it already has a perfect matching tree code. Now I understand C++0x might have a proper syntax already, so I'm not sure how it relates to this (C++) bug. What changed in 4.6 is that we put complex values in registers even at -O0. You should be able to reproduce any issue in this bug in older releases with optimization turned on (given that the library implementation didn't change).
[Bug libstdc++/48760] [4.6 / 4.7 Regression (?)] std::complex constructor buggy in the face of NaN's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760 --- Comment #11 from Paolo Carlini 2011-04-25 22:04:56 UTC --- Thanks Gaby, your analysis certainly helps. Let's see what Jason, thinks, then.
[Bug libstdc++/48760] [4.6 / 4.7 Regression (?)] std::complex constructor buggy in the face of NaN's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760
Gabriel Dos Reis changed:
What|Removed |Added
CC||jason at redhat dot com
--- Comment #10 from Gabriel Dos Reis 2011-04-25
21:38:59 UTC ---
(In reply to comment #9)
> I guess, in the 4.6.1 time frame we can only workaround the issue in C++03
> mode
> by doing the piecewise work in the body. I can maybe help for the compiler
> work
> too but I need more guidance: is there an agreement about the C1X inspired
> builtin suggested by Joseph? In case, can I have a more specific reference?
>
> I'm adding in CC Richi too, in case he has additional tips and/or hints about
> the builtin work..
I believe in 4.6.1 it should still be possible to have the initialization
from components. All we need is to be able to write
complex(float __r, float __i) : _M_value{__r,__i} { }
or
complex(float __r, float __i) : _M_value({__r, __i}) { }
the work that people are testing really isn't C++03, it is C++0x.
It is fine if the C people don't want it. But in C++0x, we already
have the syntax (so no parser surgery is needed). All that remains is
to have the C++ front-end elaborate that syntax into the proper
initialization (ideal outcome) or a sequence of assignment (less ideal.)
Note that we already have that syntax for iniialization of array members
and a _Complex is supposed to behave like a 2-element array...
It is good that Richi is in the CC (as a RM) but, I suspect Jason should
be too.
-- Gaby
[Bug libstdc++/48760] [4.6 / 4.7 Regression (?)] std::complex constructor buggy in the face of NaN's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760 Paolo Carlini changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #9 from Paolo Carlini 2011-04-25 18:10:34 UTC --- I guess, in the 4.6.1 time frame we can only workaround the issue in C++03 mode by doing the piecewise work in the body. I can maybe help for the compiler work too but I need more guidance: is there an agreement about the C1X inspired builtin suggested by Joseph? In case, can I have a more specific reference? I'm adding in CC Richi too, in case he has additional tips and/or hints about the builtin work..
[Bug libstdc++/48760] [4.6 / 4.7 Regression (?)] std::complex constructor buggy in the face of NaN's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760
Gabriel Dos Reis changed:
What|Removed |Added
CC||gdr at gcc dot gnu.org
--- Comment #8 from Gabriel Dos Reis 2011-04-25
17:57:15 UTC ---
(In reply to comment #1)
> I don't think this is a library proper issue, how can it be? We have just:
>
> constexpr // In C++0x mode
> complex(float __r = 0.0f, float __i = 0.0f)
> : _M_value(__r + __i * 1.0fi) { }
I believe we need a compiler support to construct a complex
value from its independent components -- instead of the low-level
C-style assignments that we are currently forced to do (or use
multiplication.) I think that is the way to go.
-- Gaby
[Bug libstdc++/48760] [4.6 / 4.7 Regression (?)] std::complex constructor buggy in the face of NaN's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760 --- Comment #7 from John Maddock 2011-04-25 17:21:15 UTC --- Sorry to be dumb, but doesn't the result of the C code violate section G.5.2 in C99 - which is to say that no matter what the value of the imaginary part of an expression, it never changes the real part - even if that is a NaN?
[Bug libstdc++/48760] [4.6 / 4.7 Regression (?)] std::complex constructor buggy in the face of NaN's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760 Paolo Carlini changed: What|Removed |Added CC||g...@integrable-solutions.ne ||t --- Comment #6 from Paolo Carlini 2011-04-25 16:46:39 UTC --- Gaby, can you give me an opinion on this? Now the constructor is constexpr, thus we can't have a non-empty body. I can't believe that now we can't fix this without new builtins, and I have yet to understand why the same library code worked fine in 4.5.x and also together with current ICC...
[Bug libstdc++/48760] [4.6 / 4.7 Regression (?)] std::complex constructor buggy in the face of NaN's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.04.25 16:18:13 AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com Target Milestone|--- |4.6.1 Ever Confirmed|0 |1
[Bug libstdc++/48760] [4.6 / 4.7 Regression (?)] std::complex constructor buggy in the face of NaN's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760 Paolo Carlini changed: What|Removed |Added Component|middle-end |libstdc++ --- Comment #5 from Paolo Carlini 2011-04-25 16:12:35 UTC --- Ok, no problem, I can certainly tweak the C++ library in this sense. Strange, anyway, that the behavior of this std::complex constructor changed only in 4.6.0, after so *many* years (and, by the way, if I compile the same library code with current ICC I get again (0,nan))
