[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[Bug c++/11437] ICE in lookup_name_real

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.


------- 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: