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]

Re: BPs & build_pointer_type ()


  In message <199910282205.MAA18204@tucson-net-82.eng.ascend.com>you write:
  > 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).
The problem I see is that you're going to hose any language that is not
currently integrated into the sources (eg Pascal & Ada).  We need to try
and avoid these kinds of changes to the interfaces that languages and
backends use if at all possible.

One possibility would be to keep the old build_pointer_type, but have it
abort if flag_bounded_pointers is ever nonzero.

Then create a new function which returns either the record or pointer based
on an argument and flag_unbounded_pointers.

Then convert every existing call to use the new function.

That way non-integrated front-ends continue to work for the most common
case (ie, !flag_bounded_pointers).
jeff


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