[Bug libfortran/24902] New: COMPLEX_ASSIGN is wrong

[Bug libfortran/24902] New: COMPLEX_ASSIGN is wrong

[pinskia at gcc dot gnu dot org]

The defintion of COMPLEX_ASSIGN is wrong, it should be defined as:

#define COMPLEX_ASSIGN(z_, r_, i_) do {z_ = r_ + i_ * 1.0fi} while (0)


This is in reference to PR 23497.


-- 
           Summary: COMPLEX_ASSIGN is wrong
           Product: gcc
           Version: 4.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libfortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: pinskia at gcc dot gnu dot org


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

[Bug libfortran/24902] COMPLEX_ASSIGN is wrong

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2005-11-16 18:58 -------
I mean:
#define COMPLEX_ASSIGN(z_, r_, i_) do {z_ = (r_) + (i_) * 1.0fi} while (0)


-- 


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

[Bug libfortran/24902] COMPLEX_ASSIGN is wrong

[gdr at integrable-solutions dot net]

------- Comment #2 from gdr at integrable-solutions dot net  2005-11-16 19:43 -------
Subject: Re:   New: COMPLEX_ASSIGN is wrong

"pinskia at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:

| The defintion of COMPLEX_ASSIGN is wrong,

that is wrong according to Andrew.

| This is in reference to PR 23497.

In the reference to that thread, please do note that

    <lhs> = <rhs>

yields an lvalue for built-in "="; in partiaular

    __imag__ z = r

yields an lvalue.  do whatever you want in the *middle end*, but be
sure you don't transmute that basic semantics constraint.

-- Gaby


-- 


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

[Bug libfortran/24902] COMPLEX_ASSIGN is wrong

[pinskia at physics dot uc dot edu]

------- Comment #3 from pinskia at gcc dot gnu dot org  2005-11-16 19:50 -------
Subject: Re:  COMPLEX_ASSIGN is wrong

> yields an lvalue.  do whatever you want in the *middle end*, but be
> sure you don't transmute that basic semantics constraint.

Gaby, it also prevents a huge amount of optimizations so what is
the difference from saying it is wrong?

The issue comes down to what does
__imag__ a = b; really means.

And since this is an extension it could mean anything.

Gaby if you want to prevent optimizations from happening, fine with
me.  Just don't prevent the optimization from happening with fixed
up code.

Gaby, remember this is an extension and not a standard thing so take
everything for granted.

-- Pinski


-- 


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

[Bug libfortran/24902] COMPLEX_ASSIGN is wrong

[pinskia at gcc dot gnu dot org]

------- Comment #4 from pinskia at gcc dot gnu dot org  2005-11-16 19:53 -------
I should also note that:
http://gcc.gnu.org/onlinedocs/gcc/Complex.html#Complex

recomends against using the extensions anyways.


-- 


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

[Bug libfortran/24902] COMPLEX_ASSIGN is wrong

[gdr at integrable-solutions dot net]

------- Comment #5 from gdr at integrable-solutions dot net  2005-11-16 20:24 -------
Subject: Re:  COMPLEX_ASSIGN is wrong

"pinskia at physics dot uc dot edu" <gcc-bugzilla@gcc.gnu.org> writes:

| Subject: Re:  COMPLEX_ASSIGN is wrong
| 
| > yields an lvalue.  do whatever you want in the *middle end*, but be
| > sure you don't transmute that basic semantics constraint.
| 
| Gaby, it also prevents a huge amount of optimizations so what is
| the difference from saying it is wrong?

You're putting optimization before semantics; -that- is wrong.  I'm
not interested in the fastest program if it does not meet my needs.
If __imag__ z yields a modifiable lvalue, then it follows, by ordinary
language rules that it can be used on the left hand side of built-in
"=".  In C, the resulting expresion is an rvalue; in C++ it is an
lvalue.  No amount of bizarre extension should break those simple
rules.  

| The issue comes down to what does
| __imag__ a = b; really means.

No, it comes down to what "__imag__ a" means.

-- Gaby


-- 


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

[Bug libfortran/24902] COMPLEX_ASSIGN is wrong

[gdr at integrable-solutions dot net]

------- Comment #6 from gdr at integrable-solutions dot net  2005-11-16 20:27 -------
Subject: Re:  COMPLEX_ASSIGN is wrong

"pinskia at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:

| I should also note that:
| http://gcc.gnu.org/onlinedocs/gcc/Complex.html#Complex
| 
| recomends against using the extensions anyways.

Exactly which sentence says so?

-- Gaby


-- 


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

[Bug libfortran/24902] COMPLEX_ASSIGN is wrong

[pinskia at physics dot uc dot edu]

------- Comment #7 from pinskia at gcc dot gnu dot org  2005-11-16 20:29 -------
Subject: Re:  COMPLEX_ASSIGN is wrong

> 
> 
> 
> ------- Comment #6 from gdr at integrable-solutions dot net  2005-11-16 20:27 -------
> Subject: Re:  COMPLEX_ASSIGN is wrong
> 
> "pinskia at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:
> 
> | I should also note that:
> | http://gcc.gnu.org/onlinedocs/gcc/Complex.html#Complex
> | 
> | recomends against using the extensions anyways.
> 
> Exactly which sentence says so?

"you should use the ISO C99 function" every time it mentions the
extenstions.

-- Pinski


-- 


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

[Bug libfortran/24902] COMPLEX_ASSIGN is wrong

[gdr at integrable-solutions dot net]

------- Comment #8 from gdr at integrable-solutions dot net  2005-11-16 20:39 -------
Subject: Re:  COMPLEX_ASSIGN is wrong

"pinskia at physics dot uc dot edu" <gcc-bugzilla@gcc.gnu.org> writes:

[...]

| > Subject: Re:  COMPLEX_ASSIGN is wrong
| > 
| > "pinskia at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:
| > 
| > | I should also note that:
| > | http://gcc.gnu.org/onlinedocs/gcc/Complex.html#Complex
| > | 
| > | recomends against using the extensions anyways.
| > 
| > Exactly which sentence says so?
| 
| "you should use the ISO C99 function" every time it mentions the
| extenstions.

 (1) that is not the same as recommending against the extension;

 (2) how do you use ISO C99 functions to implement C99 <complex.h>,
     C++98 <complex> that interoperate with C99 _Complex and other
     libraries that predate C99 functions or on plateforms where C99
     functions don't exist but the libraries need to be implemented anyway?

-- Gaby


-- 


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

[Bug libfortran/24902] COMPLEX_ASSIGN is wrong

[kargl at gcc dot gnu dot org]

------- Comment #9 from kargl at gcc dot gnu dot org  2005-11-16 22:45 -------
(In reply to comment #1)
> I mean:
> #define COMPLEX_ASSIGN(z_, r_, i_) do {z_ = (r_) + (i_) * 1.0fi} while (0)
> 

Does this do the right thing in the presence of special cases?
See PR 24581.


-- 


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

[Bug libfortran/24902] COMPLEX_ASSIGN is wrong

[fxcoudert at gcc dot gnu dot org]

------- Comment #10 from fxcoudert at gcc dot gnu dot org  2007-01-05 14:06 -------
This bug has been open for more that one year without any update, without
general agreement on wether we have a bug or a testcase exhibiting incorrect or
suboptimal behaviour.

Closing.


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


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