This is the mail archive of the
mailing list for the GCC project.
[Bug libfortran/24902] COMPLEX_ASSIGN is wrong
- From: "gdr at integrable-solutions dot net" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 16 Nov 2005 20:24:23 -0000
- Subject: [Bug libfortran/24902] COMPLEX_ASSIGN is wrong
- References: <email@example.com/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- 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" <firstname.lastname@example.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
| The issue comes down to what does
| __imag__ a = b; really means.
No, it comes down to what "__imag__ a" means.