PLEASE REPLY TO [EMAIL PROTECTED] ONLY, *NOT* [EMAIL PROTECTED]

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



------- Additional Comments From neroden at gcc dot gnu dot org  2003-07-09 
05:51 -------
OK.  I now understand things better, and see that __imag is supposed to be an 
operator, which is kinda gross.

The bug can be reproduced with a of any class or struct type, but not with a of 
any numeric type (I guess they're implicitly converted or something).

My pointer to the ICE is still correct.  More info. :-)  build_x_unary_op 
decides that it should look for a function, so it calls build_new_op.
build_new_op is called with code==REALPART_EXPR or IMAGPART_EXPR.  Then we get 
to the line:
    fnname = ansi_opname (code);
which assigns to fnname the value 0x0, which is what gets passed to the 
function name lookup (looking for a user-defined operator).

Now, ansi_opname is a macro, expanding to:
(operator_name_info[(int) (CODE)].identifier)
__real__ and __imag__ aren't listed in operators.def, so their table entries 
are never initialized.
Isn't that lovely.

I think that points to an obvious fix.





------- You are receiving this mail because: -------
You reported the bug, or are watching the reporter.


Reply via email to