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.
Tristan.
