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.
I mean: #define COMPLEX_ASSIGN(z_, r_, i_) do {z_ = (r_) + (i_) * 1.0fi} while (0)
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
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
I should also note that: http://gcc.gnu.org/onlinedocs/gcc/Complex.html#Complex recomends against using the extensions anyways.
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
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
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
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
(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.
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.