Richard Biener <richard.guent...@gmail.com> writes:
> On Sat, May 17, 2014 at 10:15 AM, Richard Sandiford
> <rdsandif...@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?
Thanks,
Richard
