What is -3.I (as opposed to 0-3.I) supposed evaluate to?

What is -3.I (as opposed to 0-3.I) supposed evaluate to?

[Kaveh R. GHAZI]

If I write a complex double constant -3.I (as opposed to 0-3.I), what is
it supposed to evaluate to?  This program:

  #include <stdio.h>

  int main(void)
  {
    const __complex double C1 = (-3.I);
    const __complex double C2 = (0-3.I);

    printf ("%f %f\n", __real__ C1, __imag__ (C1));
    printf ("%f %f\n", __real__ C2, __imag__ (C2));

    return 0;
  }

when compiled with gcc-4.1.2 (and mainline) yields:

	-0.000000 -3.000000
	0.000000 -3.000000

Note the sign difference in the real part.

When I compile it with g++-4.1.2, I get:

	compl.c: In function 'int main()':
	compl.c:5: error: wrong type argument to unary minus

Is this supposed to happen or is it a bug in complex number parsing?
(Sorry if this is a gcc-help question.)

		Thanks,
		--Kaveh

Re: What is -3.I (as opposed to 0-3.I) supposed evaluate to?

[Joseph S. Myers]

On Mon, 8 Jun 2009, Kaveh R. GHAZI wrote:

> If I write a complex double constant -3.I (as opposed to 0-3.I), what is
> it supposed to evaluate to?  This program:

Because GCC does not implement imaginary types, this applies unary minus 
to 0.0+3.0I.  Whereas 0-3.I means 0.0 - (0.0+3.0I), a mixed real/complex 
operation, the real part of whose result is 0.0 except when rounding 
towards negative infinity when it is -0.0.  There are lots of tests in 
gcc.dg/torture/complex-sign*.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: What is -3.I (as opposed to 0-3.I) supposed evaluate to?

[Kaveh R. Ghazi]

From: "Joseph S. Myers" <joseph@codesourcery.com>

> On Mon, 8 Jun 2009, Kaveh R. GHAZI wrote:
>
>> If I write a complex double constant -3.I (as opposed to 0-3.I), what is
>> it supposed to evaluate to?  This program:
>
> Because GCC does not implement imaginary types, this applies unary minus
> to 0.0+3.0I.  Whereas 0-3.I means 0.0 - (0.0+3.0I), a mixed real/complex
> operation, the real part of whose result is 0.0 except when rounding
> towards negative infinity when it is -0.0.  There are lots of tests in
> gcc.dg/torture/complex-sign*.

Okay thanks.

Perhaps the only safe way to create the value, even in the presence of 
rounding mode changes, is to use conj(3.I) ?

        --Kaveh

Re: What is -3.I (as opposed to 0-3.I) supposed evaluate to?

[Joseph S. Myers]

On Mon, 8 Jun 2009, Kaveh R. Ghazi wrote:

> Perhaps the only safe way to create the value, even in the presence of
> rounding mode changes, is to use conj(3.I) ?

Setting the __real__ and __imag__ parts of a temporary variable should 
always be reliable for making a complex number out of arbitrary real and 
imaginary parts.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: What is -3.I (as opposed to 0-3.I) supposed evaluate to?

[Kaveh R. Ghazi]

From: "Joseph S. Myers" <joseph@codesourcery.com>

> On Mon, 8 Jun 2009, Kaveh R. Ghazi wrote:
>
>> Perhaps the only safe way to create the value, even in the presence of
>> rounding mode changes, is to use conj(3.I) ?
>
> Setting the __real__ and __imag__ parts of a temporary variable should
> always be reliable for making a complex number out of arbitrary real and
> imaginary parts.

Well yes, but I meant for compile-time expressions that are exposed to fold 
even at -O0.  (Recall that I'm writing testcases for the MPC stuff.)  I'm 
not 100% confident that the temporary variable will always fold and it's too 
verbose when repeatedly used in a testcase.  With conj, the builtin will 
always fold 3.I and won't do anything unexpected with rounding modes.

I was just wondering why -3.I was evaluating differently than 0-3.I and 
whether it was a bug.  Your explanation was very useful.

        Thanks,
        --Kaveh

Re: What is -3.I (as opposed to 0-3.I) supposed evaluate to?

[Richard Guenther]

On Tue, Jun 9, 2009 at 11:26 AM, Kaveh R. Ghazi<ghazi@caip.rutgers.edu> wrote:
> From: "Joseph S. Myers" <joseph@codesourcery.com>
>
>> On Mon, 8 Jun 2009, Kaveh R. Ghazi wrote:
>>
>>> Perhaps the only safe way to create the value, even in the presence of
>>> rounding mode changes, is to use conj(3.I) ?
>>
>> Setting the __real__ and __imag__ parts of a temporary variable should
>> always be reliable for making a complex number out of arbitrary real and
>> imaginary parts.
>
> Well yes, but I meant for compile-time expressions that are exposed to fold
> even at -O0.  (Recall that I'm writing testcases for the MPC stuff.)  I'm
> not 100% confident that the temporary variable will always fold and it's too
> verbose when repeatedly used in a testcase.  With conj, the builtin will
> always fold 3.I and won't do anything unexpected with rounding modes.

It should always be folded via CCP / value-numbering.  If not that is a bug
that needs to be fixed.

Richard.

> I was just wondering why -3.I was evaluating differently than 0-3.I and
> whether it was a bug.  Your explanation was very useful.



>       Thanks,
>       --Kaveh
>
>