Replace C/C++ void_zero_node with a VOID_CST tree code

Richard Biener richard.guenther@gmail.com
Mon May 19 09:42:00 GMT 2014


On Mon, May 19, 2014 at 11:27 AM, Richard Sandiford
<rdsandiford@googlemail.com> wrote:
> Richard Biener <richard.guenther@gmail.com> writes:
>> On Sat, May 17, 2014 at 10:15 AM, Richard Sandiford
>> <rdsandiford@googlemail.com> wrote:
>>> The main thing keeping zero-precision wide-ints alive was void_zero_node,
>>> a tree used in the C and C++ frontends that has type VOID_TYPE but code
>>> INTEGER_CST.
>>>
>>> Richard B. asked me to replace the INTEGER_CST with a new constant type,
>>> here called VOID_CST.  Most of it is straight-forward.  The one perhaps
>>> controversial bit is that C++ uses void_(zero_)node to represent dummy
>>> objects when e.g. taking the address of a member function without an
>>> associated object.  IIUC the node used in this situation needs to be
>>> distinct from anything that could occur in user code and therefore couldn't
>>> be a simple null pointer.
>>>
>>> This reaches the gimplifier in cases like
>>> g++.old-deja/g++.brendan/operators4.C.  I chose to handle it in the
>>> gimplifier, since void_zero_node was previously handled there too,
>>> although perhaps by accident.  If you object strongly to this then
>>> I'll need pretty detailed instructions about what to do instead,
>>> i.e. exactly which parts of the C++ front end need to be changed
>>> in order for dummy objects never to escape.
>>
>> I suppose it reaches the gimplifier because it's not handled in
>> fold-const.c:fold_convert_loc while the INTEGER_CST void_zero_node
>> was (through fold_convert_const).
>
> But like I said, void_zero_node reached the gimplifier too.  Try adding:
>
>   gcc_assert (TREE_TYPE (TREE_OPERAND (*expr_p, 0)) != void_type_node
>               || TREE_CODE (TREE_OPERAND (*expr_p, 0)) != INTEGER_CST);
>
> to gimplify_conversion and running g++.old-deja/g++.brendan/operators4.C
> to see what I mean.
>
>> That said, only handling (T)void_cst in gimplification looks like
>> a hack.  If necessary we'd want to treat it as construct-T-with-zero-value
>> consistently.
>
> OK, so just remove the gcc_checking_assert?

Which one?  I'd add VOID_CST handling to fold_convert_const.

Richard.

> Thanks,
> Richard



More information about the Gcc-patches mailing list