[Bug c++/11437] ICE in lookup_name_real
PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
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 to: