This is the mail archive of the
mailing list for the GCC project.
Re: Replace C/C++ void_zero_node with a VOID_CST tree code
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 19 May 2014 11:03:22 +0100
- Subject: Re: Replace C/C++ void_zero_node with a VOID_CST tree code
- Authentication-results: sourceware.org; auth=none
- References: <87mwegzuqz dot fsf at talisman dot default> <CAFiYyc0u71qJwezDgBKtAME9ZjJW18GcCcgz4mpU1KMdQDTotw at mail dot gmail dot com> <87ppjaglt5 dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <CAFiYyc1iEX4kEvQ=bBfBuYXcqrAzmE=gUn7KCNk29DAHgUsmUA at mail dot gmail dot com>
Richard Biener <email@example.com> writes:
> On Mon, May 19, 2014 at 11:27 AM, Richard Sandiford
> <firstname.lastname@example.org> wrote:
>> Richard Biener <email@example.com> writes:
>>> On Sat, May 17, 2014 at 10:15 AM, Richard Sandiford
>>> <firstname.lastname@example.org> 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
>>>> 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
>> OK, so just remove the gcc_checking_assert?
> Which one?
The one I'd added to the gimplifier:
--- gcc/gimplify.c 2014-05-15 13:49:24.483656013 +0100
+++ gcc/gimplify.c 2014-05-16 17:55:17.087700837 +0100
@@ -1681,7 +1681,15 @@ gimplify_conversion (tree *expr_p)
/* Then strip away all but the outermost conversion. */
STRIP_SIGN_NOPS (TREE_OPERAND (*expr_p, 0));
- /* And remove the outermost conversion if it's useless. */
+ /* Support C++-style dummy objects, in which void_zero is
+ cast to a pointer type. We treat these as null pointers. */
+ if (TREE_OPERAND (*expr_p, 0) == void_node)
+ gcc_checking_assert (POINTER_TYPE_P (TREE_TYPE (*expr_p)));
+ *expr_p = build_int_cst (TREE_TYPE (*expr_p), 0);
+ /* Remove the outermost conversion if it's useless. */
if (tree_ssa_useless_type_conversion (*expr_p))
*expr_p = TREE_OPERAND (*expr_p, 0);
> I'd add VOID_CST handling to fold_convert_const.
But like you say, if that was enough, void_zero_node would never
have reached the gimplifier, whereas as above it does. I tried adding:
gcc_assert (TREE_CODE (arg1) != VOID_CST);
to fold_convert_const and it doesn't trigger for operators4.C.
It also doesn't trigger for g++-mike/p10769b.C, which was the
other main motivating case.