On Mar 13, 2012, at 9:57 PM, Gary Funck wrote:

> On 03/06/12 14:09:23, Tristan Gingold wrote:
>> The patch is simple: the C front-end will now calls
>> c_build_pointer_type (instead of build_pointer_type), which in
>> turn calls build_pointer_type_for_mode using the right mode.
> [...]
> Joining this discussion a bit late ... I have a few questions.
> This change impacts the GUPC branch, mainly because UPC introduces
> pointers that are generally larger than conventional "C" pointers,
> and thus some changes were needed in the "build pointer" area,
> and that logic needed to be adjusted to work with this patch.
> Here is the new c_build_pointer_type.  It a static function
> constrained to be called from within the c-decl.c file wehre
> it resides.
> static tree
> c_build_pointer_type (tree to_type)
> {
>  addr_space_t as = to_type == error_mark_node? ADDR_SPACE_GENERIC
>                                              : TYPE_ADDR_SPACE (to_type);
>  enum machine_mode pointer_mode;
>  if (as != ADDR_SPACE_GENERIC || c_default_pointer_mode == VOIDmode)
>    pointer_mode = targetm.addr_space.pointer_mode (as);
>  else
>    pointer_mode = c_default_pointer_mode;
>  return build_pointer_type_for_mode (to_type, pointer_mode, false);
> }
> Here is the old build_pointer_type() in tree.c.  It is external/public
> and is called from various places.
> tree
> build_pointer_type (tree to_type)
> {
>  addr_space_t as = to_type == error_mark_node? ADDR_SPACE_GENERIC
>                                              : TYPE_ADDR_SPACE (to_type);
>  enum machine_mode pointer_mode = targetm.addr_space.pointer_mode (as);
>  return build_pointer_type_for_mode (to_type, pointer_mode, false);
> }
> c_build_pointer_type () introduces c_default_pointer_mode
> and uses it as long as:
>   as == ADDR_SPACE_GENERIC && c_default_pointer_mode != VOIDmode
> but build_pointer_type will not use c_default_pointer_mode.
> My first question is: are there still contexts where build_pointer_type()
> is called to compile "C" statements/expressions for cases not
> covered by the calls within c-decl.c?

Yes.  In the discussion, Joseph Myers has pointed them.
Some of them are bugs (but should be replaced by build_pointer_type_for_mode),
others aren't incorrect (e.g. for built-in functions).

Currently c_build_pointer_type is called for user declared pointer types.

>  I ask, because we tried
> moving our checks for UPC pointer-to-shared types from
> build_pointer_type() into only c_build_pointer_type() and
> ran into calls to build_pointer_type() that still passed
> in UPC pointer-to-shared typed objects.  What this may
> indicate is that there are situations where the new
> c_default_pointer_mode may need to be applied when
> build_pointer_type() is called.  I don't recall off-hand
> when these situations came up, but it might be easy enough
> to put some assertions in build_pointer_type() and then
> run the "C" test suite and see what turns up.

I think we should discuss these cases.  From my current understanding, these
direct calls that affect you are currently bugs.

Once I completed the VMS patch submission, I would add some tests to check
the handling of pointer modes.

> Thus, I wonder if it might not be best to generalize
> build_pointer_type() instead of introducing c_build_pointer_type()
> and dealing with any "C" specific checks (somehow) there?

I am almost sure that this is not correct.  build_pointer_type is part of the
middle end, where the 'pragma pointer_size' doesn't apply and the ptr_mode
should be used.


Reply via email to