[Bug libstdc++/48760] New: std::complex constructor buggy in the face of NaN's

[Bug libstdc++/48760] New: std::complex constructor buggy in the face of NaN's

[john at johnmaddock dot co.uk]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760

           Summary: std::complex constructor buggy in the face of NaN's
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: blocker
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: john@johnmaddock.co.uk


If a std::complex<T> is constructed where one argument is finite and one a NaN
then the result is a complex number with both parts NaN, which is in violation
of 26.4.4 in the C++2011 std.

For example:

std::complex<float> c(0, std::numeric::limits<float>::quiet_NaN());

results in both real and imaginary parts of c being a NaN.

This causes failures in the Boost.Math regression tests, see also section
G.6.1.1 in C99 where such values can have well defined results for complex-trig
operations.

[Bug middle-end/48760] [4.6 / 4.7 Regression (?)] std::complex constructor buggy in the face of NaN's

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jsm28 at gcc dot gnu.org
          Component|libstdc++                   |middle-end
            Summary|std::complex constructor    |[4.6 / 4.7 Regression (?)]
                   |buggy in the face of NaN's  |std::complex constructor
                   |                            |buggy in the face of NaN's
           Severity|blocker                     |normal

--- Comment #1 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-04-25 12:07:44 UTC ---
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) { }

where _M_value is a __complex__ float. Joseph, can you have a look? By the way,
what is reported did *not* happen in 4.5.x and nothing changed in the lib in
this area in the meanwhile (besides the C++0x bits, not at issue here).

Note a complete C++ snippet would be:

#include <complex>
#include <limits>
#include <iostream>

int main()
{
  std::complex<float> c(0, std::numeric_limits<float>::quiet_NaN());

  std::cout << c << std::endl;
}

[Bug middle-end/48760] [4.6 / 4.7 Regression (?)] std::complex constructor buggy in the face of NaN's

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760

--- Comment #2 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-04-25 12:41:59 UTC ---
PR24581 can be related, its additional, "unexpected", nans.

A C snippet showing the issue would be:

int main()
{
  float r = 0;
  float i = __builtin_nanf ("");

  __complex__ float c = r + i * 1.0fi; 

  /*
  __complex__ float c;
  __real__ c = r;
  __imag__ c = i;
  */

  __builtin_printf("%f\n", __real__ c);
  __builtin_printf("%f\n", __imag__ c);
}

Indeed, I could tweak the library to construct the complex by pieces, avoiding
the multiplication by the imaginary constant in the constructor, but the
problem would definitely reappear at any following multiplication...

[Bug middle-end/48760] [4.6 / 4.7 Regression (?)] std::complex constructor buggy in the face of NaN's

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760

--- Comment #3 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-04-25 13:21:58 UTC ---
By the way, just in case isn't super-clear to people coming from C, there is
nothing C++1x specific here (26.4.4/1 and /2 are identical to 26.2.4 in the old
standard)

[Bug middle-end/48760] [4.6 / 4.7 Regression (?)] std::complex constructor buggy in the face of NaN's

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760

--- Comment #4 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2011-04-25 16:02:11 UTC ---
On Mon, 25 Apr 2011, paolo.carlini at oracle dot com wrote:

> A C snippet showing the issue would be:
> 
> int main()
> {
>   float r = 0;
>   float i = __builtin_nanf ("");
> 
>   __complex__ float c = r + i * 1.0fi; 
> 
>   /*
>   __complex__ float c;
>   __real__ c = r;
>   __imag__ c = i;
>   */
> 
>   __builtin_printf("%f\n", __real__ c);
>   __builtin_printf("%f\n", __imag__ c);
> }
> 
> Indeed, I could tweak the library to construct the complex by pieces, avoiding
> the multiplication by the imaginary constant in the constructor, but the
> problem would definitely reappear at any following multiplication...

I don't see any C bug here.  Without imaginary types it's correct that 
1.0fi is a complex constant and so you get NaN for both real and imaginary 
parts.  To avoid that, assign to real and imaginary parts as shown in the 
comment, or implement __builtin_cmplx* that correspond to C1X CMPLX* 
macros (which should be pretty easy to do; the built-in functions just 
need to map to COMPLEX_EXPR and handle constants correctly) and use those.

[Bug libstdc++/48760] [4.6 / 4.7 Regression (?)] std::complex constructor buggy in the face of NaN's

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|middle-end                  |libstdc++

--- Comment #5 from Paolo Carlini <paolo.carlini at oracle dot com> 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))

[Bug libstdc++/48760] [4.6 / 4.7 Regression (?)] std::complex constructor buggy in the face of NaN's

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760

Paolo Carlini <paolo.carlini at oracle dot com> 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

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gdr@integrable-solutions.ne
                   |                            |t

--- Comment #6 from Paolo Carlini <paolo.carlini at oracle dot com> 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

[john at johnmaddock dot co.uk]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760

--- Comment #7 from John Maddock <john at johnmaddock dot co.uk> 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

[gdr at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760

Gabriel Dos Reis <gdr at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gdr at gcc dot gnu.org

--- Comment #8 from Gabriel Dos Reis <gdr at gcc dot gnu.org> 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

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu.org

--- Comment #9 from Paolo Carlini <paolo.carlini at oracle dot com> 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

[gdr at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760

Gabriel Dos Reis <gdr at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at redhat dot com

--- Comment #10 from Gabriel Dos Reis <gdr at gcc dot gnu.org> 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

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760

--- Comment #11 from Paolo Carlini <paolo.carlini at oracle dot com> 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

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760

--- Comment #12 from Richard Guenther <rguenth at gcc dot gnu.org> 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

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760

--- Comment #13 from Paolo Carlini <paolo.carlini at oracle dot com> 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

[gdr at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760

--- Comment #14 from Gabriel Dos Reis <gdr at gcc dot gnu.org> 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

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760

--- Comment #15 from joseph at codesourcery dot com <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

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760

--- Comment #16 from Paolo Carlini <paolo.carlini at oracle dot com> 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

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760

--- Comment #17 from joseph at codesourcery dot com <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

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at gcc dot gnu.org

--- Comment #18 from Jason Merrill <jason at gcc dot gnu.org> 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

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760

--- Comment #19 from Paolo Carlini <paolo.carlini at oracle dot com> 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

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760

--- Comment #20 from Jason Merrill <jason at gcc dot gnu.org> 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

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760

Paolo Carlini <paolo.carlini at oracle dot com> 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 <paolo.carlini at oracle dot com> 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

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760

--- Comment #22 from Jason Merrill <jason at gcc dot gnu.org> 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

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760

--- Comment #23 from Paolo Carlini <paolo.carlini at oracle dot com> 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

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760

Paolo Carlini <paolo.carlini at oracle dot com> 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 <paolo.carlini at oracle dot com> 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

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760

--- Comment #25 from Jason Merrill <jason at gcc dot gnu.org> 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

[paolo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760

--- Comment #26 from paolo at gcc dot gnu.org <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  <paolo.carlini@oracle.com>

    PR libstdc++/48760
    * include/std/complex (complex<float>::complex(float, float),
    complex<double>::complex(double, double),
    complex<long double>::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  <paolo.carlini@oracle.com>

    * 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 Regression] std::complex constructor buggy in the face of NaN's

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.6 / 4.7 Regression]      |[4.6 Regression]
                   |std::complex constructor    |std::complex constructor
                   |buggy in the face of NaN's  |buggy in the face of NaN's

--- Comment #27 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-04-28 10:57:30 UTC ---
Fixed in mainline so far.

[Bug libstdc++/48760] [4.6 Regression] std::complex constructor buggy in the face of NaN's

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760

--- Comment #29 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-04-29 23:24:19 UTC ---
This is now fixed in 4_6-branch too in C++03 mode, not in C++0x mode, where we
would need list-initialization of __complex__.  If people believe we can /
should do something else in the release branch, I'm all ears: if for example
people consider a better trade-off for the branch removing the constexpr from
the constructor in order to initialized in the body for C++0x mode too, I'm ok
with that.

[Bug libstdc++/48760] [4.6 Regression] std::complex constructor buggy in the face of NaN's

[paolo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760

--- Comment #28 from paolo at gcc dot gnu.org <paolo at gcc dot gnu.org> 2011-04-29 23:20:04 UTC ---
Author: paolo
Date: Fri Apr 29 23:19:59 2011
New Revision: 173195

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173195
Log:
2011-04-29  Paolo Carlini  <paolo.carlini@oracle.com>

    PR libstdc++/48760
    * include/std/complex (complex<float>::complex(float, float),
    complex<double>::complex(double, double),
    complex<long double>::complex(long double, long double)): Initialize
    in the body in C++03 mode (no fix in C++0x mode).
    * testsuite/26_numerics/complex/cons/48760.cc: New.

Added:
   
branches/gcc-4_6-branch/libstdc++-v3/testsuite/26_numerics/complex/cons/48760.cc
Modified:
    branches/gcc-4_6-branch/libstdc++-v3/ChangeLog
    branches/gcc-4_6-branch/libstdc++-v3/include/std/complex

[Bug libstdc++/48760] [4.6 Regression] std::complex constructor buggy in the face of NaN's

[gdr at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760

--- Comment #30 from Gabriel Dos Reis <gdr at gcc dot gnu.org> 2011-04-29 23:52:32 UTC ---
(In reply to comment #29)
> This is now fixed in 4_6-branch too in C++03 mode, not in C++0x mode, where we
> would need list-initialization of __complex__.  If people believe we can /
> should do something else in the release branch, I'm all ears: if for example
> people consider a better trade-off for the branch removing the constexpr from
> the constructor in order to initialized in the body for C++0x mode too, I'm ok
> with that.

I'm of course biased here, but I value constexpr-ability over complex
numbers with parts that are NaNs.  *If* we cannot have list-initialization
for _Complex, then I suggest we close this PR as WONTFIX.

[Bug libstdc++/48760] [4.6 Regression] std::complex constructor buggy in the face of NaN's

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX
   Target Milestone|4.6.1                       |4.7.0

--- Comment #31 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-04-30 18:15:46 UTC ---
Ok, let's close this as WONTFIX in C++0x mode in 4_6-branch. Fixed in C++03
mode and completely fixed in 4_7-branch.

[Bug libstdc++/48760] [4.6 Regression] std::complex constructor buggy in the face of NaN's

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|WONTFIX                     |FIXED

--- Comment #32 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-05-02 08:46:53 UTC ---
Fixed for 4.7.

[Bug libstdc++/48760] [4.6 Regression] std::complex constructor buggy in the face of NaN's

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kreckel at ginac dot de

--- Comment #33 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-11-02 09:39:20 UTC ---
*** Bug 50957 has been marked as a duplicate of this bug. ***