> This patch causes an ICE when building libobjc, which is part of
> normal bootstrap.
>
> PR 58179
>
> /nasfarm/edelsohn/src/src/libobjc/accessors.m: In function 'objc_getProperty':
> /nasfarm/edelsohn/src/src/libobjc/accessors.m:127:11: internal
> compiler error: in obj_type_ref_class, at tree.c:11876
> result = RETAIN (*(pointer_to_ivar));
Oops, sorry, I was really convinced OBJ_TYPE_REF is a C++ thing so I did not
test obj-C. The obj-C use is produced by:
/* Possibly rewrite a function CALL into an OBJ_TYPE_REF expression. This
needs to be done if we are calling a function through a cast. */
tree
objc_rewrite_function_call (tree function, tree first_param)
{
if (TREE_CODE (function) == NOP_EXPR
&& TREE_CODE (TREE_OPERAND (function, 0)) == ADDR_EXPR
&& TREE_CODE (TREE_OPERAND (TREE_OPERAND (function, 0), 0))
== FUNCTION_DECL)
{
function = build3 (OBJ_TYPE_REF, TREE_TYPE (function),
TREE_OPERAND (function, 0),
first_param, size_zero_node);
}
return function;
}
so obviously it is again type of the first parameter that correspond to the
type of a pointer to the class.
I am testing
Index: tree.c
===================================================================
--- tree.c (revision 201814)
+++ tree.c (working copy)
@@ -11873,7 +11873,11 @@ obj_type_ref_class (tree ref)
ref = TREE_TYPE (ref);
gcc_checking_assert (TREE_CODE (ref) == POINTER_TYPE);
ref = TREE_TYPE (ref);
- gcc_checking_assert (TREE_CODE (ref) == METHOD_TYPE);
+ /* Wee look for type THIS points to. ObjC also builds
+ OBJ_TYPE_REF with non-method calls, their first parameter
+ ID however also corresponds to class type. */
+ gcc_checking_assert (TREE_CODE (ref) == METHOD_TYPE
+ || TREE_CODE (ref) == FUNCTION_TYPE);
ref = TREE_VALUE (TYPE_ARG_TYPES (ref));
gcc_checking_assert (TREE_CODE (ref) == POINTER_TYPE);
return TREE_TYPE (ref);
This obviously should get me to the same value as TREE_TYPE (TREE_TYPE
(FIRST_PARAM)) the old code will get from OBJ_REF_OBJECT generated above. I
will go with this patch if it passes testing to unbreak bootstrap.
The question however is if we should not drop OBJ_TYPE_REF generation in objc
or if we want to somehow add the necesary bits to actually make it useful?
At least in the testcase above however there is no TYPE_BINFO attached, so
there is no way backend can actually take use of it. OBJ_TYPE_REF will just sit
there and consume memory + drag alive the parameter.
By grep, objc prouces some BINFOs but they never have VTABLE attached. So even
if sometimes binfo was there, the devirtualization machinery will be unable to
do anything useful about it.
Moreover objc apparently never produce any virtual functions/methods.
Can someone explain me in greater detail how the objc use works?
Honza
