------- Comment #15 from pinskia at gcc dot gnu dot org 2005-11-15 21:42 ------- (In reply to comment #14) > There is nothing wrong with the code in Comment #1; __imag__ is an > lvalue-yielding operator. If, for some reason, we wanted to make __imag__ > yield an rvalue, then this code would be rejected with an error; under no > circumstances should it yield a warning about the complex value being > uninitialized upon initialization of its imaginary component. It would be > reasonable to warn about a subsequent use of the complex value, as the real > part remains uninitialized. I think we should make this based on one part being uninitialized as we are currently because that is just crazy otherwise. Again this is just like:
a=(a&0xFFFF0000)|(b&0x000FFFF) which is what the gimplifier does currently where b is the real part of a is the full part. There is no difference between that and doing __imag___ a = b; I don't see why the warning here is bogus as it is loading by parts the a and is uninitialized when comming in. Scaler types are defined this way so you can do optimizations like this. __imag__ a = b is really defined as a = COMPLEX<REAL_PART<a>, b> which is the same as doing what I did for an integer type. I don't understand why there is a reluntant to fixing libstdc++ so that you get better optimizable code. I would not doubt this could cause wrong code due to how libstdc++ does the initialization of complex. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23497
