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? 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.
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?
Thanks,
- Gary
