This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

BPs & build_pointer_type ()


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]