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: gcc-patches at gcc dot gnu dot org
- Date: Sat, 17 May 2014 09:37:06 +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>
Richard Sandiford <firstname.lastname@example.org> writes:
> 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 wasn't sure if any errors could ever print void_(zero_)node,
> so I tested the pretty-printing routines by adding fake errors
> after convert_to_void, etc.
> Tested on x86_64-linux-gnu. OK to install?
Forgot to say that I also tested boostrap-ubsan and that the wide-int.h
shift-by-64 errors were gone.