This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
BPs & build_pointer_type ()
- To: gcc at gcc dot gnu dot org
- Subject: BPs & build_pointer_type ()
- From: Greg McGary <gkm at eng dot ascend dot com>
- Date: Thu, 28 Oct 1999 12:05:29 -1000
For the sake of bounded pointers, the interface build_pointer_type (t)
needs to change. Depending on boundedness, a "pointer" type will be
either a POINTER_TYPE node, or a RECORD_NODE having three POINTER_TYPE
members.
I had originally hoped that I could keep the old build_pointer_type ()
interface, and have it return whatever was the default (RECORD_NODE
when flag_bounded_pointers, and POINTER_TYPE when !flag_bounded_pointers),
but this now seems like a bad idea, because it allows unwelcome
surprises, and allows old gcc code to continue to exist unexamined.
Generally, when build_pointer_type called at the front-end, we want
RECORD_NODE when flag_bounded_pointers. When build_pointer_type is
called at lower-levels, we most often want POINTER_TYPE, but sometimes
want RECORD_NODE. In call cases, I now think it best that calls to
build_pointer_type make the desired node-type explicit. We therefore
need two kind of calls:
1) always return a RECORD_NODE when flag_bounded_pointers,
and return POINTER_TYPE when !flag_bounded_pointers.
2) always return a POINTER_NODE regardless of flag_bounded_pointers.
I think this is best done by adding another argument to
build_pointer_type. This argument could be either:
a) a number (0 for POINTER_NODE & 1 for RECORD_NODE)
The benefit is brevity at the expense of self-documentation.
b) enum tree_code (either POINTER_NODE or RECORD_NODE)
The benefit of (b) is that it's self-documenting,
and we need not create a new enum
c) a new enum with two members to represent POINTER & RECORD
The benefit of (c) is that it's self-documenting,
and you can't pass an inappropriate tree_code
Unless someone has strong opinions otherwise, I'll go with (b).
Greg