[Bug libstdc++/18882] New: wrong results of pow( complex<long double>(2, 1), odd integer )

[Bug libstdc++/18882] New: wrong results of pow( complex<long double>(2, 1), odd integer )

[mikulik at physics dot muni dot cz]

 

-- 
           Summary: wrong results of pow( complex<long double>(2, 1), odd
                    integer )
           Product: gcc
           Version: 3.3.1
            Status: UNCONFIRMED
          Severity: critical
          Priority: P1
         Component: libstdc++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: mikulik at physics dot muni dot cz
                CC: gcc-bugs at gcc dot gnu dot org


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

[Bug libstdc++/18882] wrong results of pow( complex<long double>(2, 1), odd integer )

[mikulik at physics dot muni dot cz]

------- Additional Comments From mikulik at physics dot muni dot cz  2004-12-08 08:53 -------
Created an attachment (id=7704)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7704&action=view)
for given x and n=1,2,3,4,5,... , print pow(x, n)


-- 


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

[Bug libstdc++/18882] wrong results of pow( complex<long double>(2, 1), odd integer )

[mikulik at physics dot muni dot cz]

------- Additional Comments From mikulik at physics dot muni dot cz  2004-12-08 09:01 -------
Results of pow(complex<long double>, int) calculated by GNU C++ 3.x are wrong.

Further, multiplications of complex<long double> and int or double are
unimplemented:

complex<long double> x, y;
y = 2 * x;
y = 2.0 * x;

And also
complex<double> x, y;
y = 2 * x;
y = x / 2;

Please fix it all. Thanks.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|                            |3.3.1 3.4.2
      Known to work|                            |2.95


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

[Bug libstdc++/18882] wrong results of pow( complex<long double>(2, 1), odd integer )

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2004-12-08 10:18 -------
So, let's begin from the end: there is nothing *unimplemented* as far as
operator* is concerned: have a look to section 26.2.1 of the Standard, there
are *no* overloads taking two different template parameters.

The first issue, serious, does *not* occur on mainline, and seems a very nasty
compiler bug: in fact, the library code for pow(complex, int) is *identical* in
mainline and 3.4. Also, there are no specializations for long double vs double
and in presence of different behaviors, this is alone a very good reason to
suspect the compiler.

Gaby, what shall we do? I'm afraid that the compiler people will not be able
to work with the full std::complex testcase :-(( but a recategorization seems
rather obvious to me.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gdr at integrable-solutions
                   |                            |dot net


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

[Bug libstdc++/18882] wrong results of pow( complex<long double>(2, 1), odd integer )

[chris at bubblescope dot net]

------- Additional Comments From chris at bubblescope dot net  2004-12-08 14:15 -------
Heres a much smaller testcase which shows this bug:

#include<stdio.h>
 
class complex
  {
  public:
    complex(long double r=0, long double i=0)
   {
    __real__ _M_value = r;
    __imag__ _M_value = i;
   }
    long double real() const
    { return __real__ _M_value; }
    long double imag() const
    { return __imag__ _M_value; }
    __complex__ long double _M_value;
  };

int main(void)
{
complex x(2,2),y,z;
int n = 1;
y = (n==1) ? x : complex(3,3);
n=2;
z = (n==1) ? x : complex(3,3);
printf("(%Lf,%Lf),(%Lf,%Lf),(%Lf,%Lf)\n",x.real(),x.imag(),y.real(),y.imag(),z.real(),z.imag());
} 


This should print (2.0,2.0),(2.0,2.0),(3.0,3.0). Instead it prints
(2.0,2.0),(2.0,0.0),(3.0,3.0).

This bug is fairly obscure: As far as I can see it only appears if:
a) Using long double complex
b) Using n ? y : z operator
c) y is a previously declared variable, z is a temporary created here.

It turns up in bits/cmath.tcc, __cmath_power. A quick hacky fix is to change the
first line of this function from:
_Tp __y = __n % 2 ? __x : 1;
to
_Tp __temp=1;
_Tp __y = __n % 2 ? __x : __temp;

If you want to get your code to work.

I confirm this bug occurs in g++ 3.3.3 (on cygwin), and despite some fiddling I
can't get a similar thing to happen with current CVS.

-- 


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

[Bug middle-end/18882] [3.3/3.4/4.0? Regression] wrong results of pow( complex<long double>(2, 1), odd integer )

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-08 14:45 -------
It works for me on the mainline and 3.3.2 on ppc-darwin, must be a code generation bug then.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|critical                    |normal
          Component|libstdc++                   |middle-end
 GCC target triplet|                            |i686-pc-linux-gnu
           Keywords|                            |wrong-code
            Summary|wrong results of pow(       |[3.3/3.4/4.0? Regression]
                   |complex<long double>(2, 1), |wrong results of pow(
                   |odd integer )               |complex<long double>(2, 1),
                   |                            |odd integer )
   Target Milestone|---                         |3.4.4


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

[Bug middle-end/18882] [3.3/3.4/4.0? Regression] wrong results of pow( complex<long double>(2, 1), odd integer )

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2004-12-08 14:59 -------
Mainline seems ok on i686/x86_64/ia64-linux. I can confirm that 3.3.3 and 3.4.3 
are *not* ok on i686-linux.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
      Known to fail|3.3.1 3.4.2                 |3.3.1 3.3.3 3.4.2 3.4.3
   Last reconfirmed|0000-00-00 00:00:00         |2004-12-08 14:59:01
               date|                            |


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

[Bug middle-end/18882] [3.3/3.4 Regression] wrong results of pow( complex<long double>(2, 1), odd integer )

[mikulik at physics dot muni dot cz]

------- Additional Comments From mikulik at physics dot muni dot cz  2004-12-08 16:28 -------
>> Further, multiplications of complex<long double> and int or double 
>> are unimplemented 
 
> So, let's begin from the end: there is nothing *unimplemented* as far 
> as operator* is concerned: have a look to section 26.2.1 of the Standard, 
> there are *no* overloads taking two different template parameters. 
 
Aha, that means that designers of the "new" Complex class had forgotten that a 
complex number can be multiplied by an integer -- and thus broke compatibility 
towards the "traditional" Complex class :-(( 
 

-- 


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

[Bug middle-end/18882] [3.3/3.4 Regression] wrong results with complex long double

[bangerth at dealii dot org]

------- Additional Comments From bangerth at dealii dot org  2004-12-08 16:29 -------
Here's my shortest version: 
------------------- 
extern "C" void abort (); 
  
struct C { 
    __complex__ long double c; 
}; 
 
int main() { 
  C x = {2+2i}; 
   
  int n = 1; 
  C y = (n==1) ? x : (C){3+3i}; 
  if (__imag__ y.c != 2) 
    abort (); 
}  
---------------------- 
This fails on 3.3 and 3.4 branches: 
 
g/x> /home/bangerth/bin/gcc-3.2*/bin/c++ x.cc ; ./a.out  
 
g/x> /home/bangerth/bin/gcc-3.3*/bin/c++ x.cc ; ./a.out  
Aborted 
 
g/x> /home/bangerth/bin/gcc-3.4*/bin/c++ x.cc ; ./a.out  
Aborted 
 
g/x> /home/bangerth/bin/gcc-4*/bin/c++ x.cc ; ./a.out  
 
W. 

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[3.3/3.4 Regression] wrong  |[3.3/3.4 Regression] wrong
                   |results of pow( complex<long|results with complex long
                   |double>(2, 1), odd integer )|double


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

[Bug middle-end/18882] [3.3/3.4 Regression] wrong results with complex long double

[ebotcazou at gcc dot gnu dot org]

------- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-12-14 09:34 -------
Investigating.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |ebotcazou at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED


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

[Bug middle-end/18882] [3.3/3.4 Regression] wrong results with complex long double

[ebotcazou at gcc dot gnu dot org]

------- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-12-14 09:35 -------
This is the same problem as PR middle-end/14988.  I'll backport the fix.


-- 


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

[Bug middle-end/18882] [3.3/3.4 Regression] wrong results with complex long double

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-12-16 10:23 -------
Subject: Bug 18882

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-3_4-branch
Changes by:	ebotcazou@gcc.gnu.org	2004-12-16 10:23:32

Modified files:
	gcc            : ChangeLog function.c 
	gcc/testsuite  : ChangeLog 
Added files:
	gcc/testsuite/g++.dg/other: complex1.C 

Log message:
	PR middle-end/18882
	* function.c (assign_stack_local_1): Use BITS_PER_UNIT alignment
	when passed -2 as 'align'.
	(put_var_into_stack): Use 'bool' as the type for the three local
	predicates.  Adjust calls to put_reg_into_stack.
	When passed a CONCAT, instruct put_reg_into_stack to use
	a consecutive stack slot for the second part.
	(put_reg_into_stack): Remove 'promoted_mode' parameter, add
	'consecutive_p' parameter.  Turn the three predicates into 'bool'
	parameters.  Retrieve the register mode from 'reg'.
	When consecutive_p is true, instruct assign_stack_local_1 to use
	BITS_PER_UNIT alignment.
	(put_addressof_into_stack): Use 'bool' as the type for the two
	local predicates. Adjust call to put_reg_into_stack.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=2.2326.2.743&r2=2.2326.2.744
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/function.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.483.4.22&r2=1.483.4.23
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3389.2.327&r2=1.3389.2.328
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/other/complex1.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.2.1



-- 


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

[Bug middle-end/18882] [3.3/3.4 Regression] wrong results with complex long double

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-12-16 14:07 -------
Subject: Bug 18882

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-3_3-branch
Changes by:	ebotcazou@gcc.gnu.org	2004-12-16 14:04:54

Modified files:
	gcc            : ChangeLog function.c 
	gcc/testsuite  : ChangeLog 
Added files:
	gcc/testsuite/g++.dg/other: complex1.C 

Log message:
	PR middle-end/18882
	* function.c (assign_stack_local_1): Use BITS_PER_UNIT alignment
	when passed -2 as 'align'.
	(put_var_into_stack): Adjust calls to put_reg_into_stack.
	When passed a CONCAT, instruct put_reg_into_stack to use
	a consecutive stack slot for the second part.
	(put_reg_into_stack): Remove 'promoted_mode' parameter, add
	'consecutive_p' parameter.  Retrieve the register mode from 'reg'.
	When consecutive_p is true, instruct assign_stack_local_1 to use
	BITS_PER_UNIT alignment.
	(put_addressof_into_stack): Adjust call to put_reg_into_stack.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.16114.2.1041&r2=1.16114.2.1042
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/function.c.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.389.2.17&r2=1.389.2.18
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.2261.2.389&r2=1.2261.2.390
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/other/complex1.C.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=NONE&r2=1.1.4.1



-- 


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

[Bug middle-end/18882] [3.3/3.4 Regression] wrong results with complex long double

[ebotcazou at gcc dot gnu dot org]

------- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-12-16 14:09 -------
See http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01119.html


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|3.4.4                       |3.3.6


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