[Ada] translate System.Address as void pointer for convention C

[Eric Botcazou]

The natural idiom is to import/export objects whose type is void pointer in C 
with the System.Address type in Ada, for example the malloc & memcpy routines.
However System.Address is (almost) always a scalar type in Ada so there is a 
discrepancy between the C side (pointer) and the Ada side (integer) which is 
problematic at least in 2 cases:
  1. Calling conventions that treat pointer and integer types differently, for 
example the SVR4 ABI on m68k or the x32 ABI on x86-64,
  2. LTO mode, which attempts to unify the representation across languages.

Geert (and probably others) suggested some time ago that System.Address be 
translated as void pointer for convention C in order to address this issue.

Tested on x86_64-suse-linux, applied on the mainline.


2016-06-29  Eric Botcazou  <ebotcazou@adacore.com>

	PR ada/48835
	PR ada/61954
	* gcc-interface/gigi.h (enum standard_datatypes): Add ADT_realloc_decl
	(realloc_decl): New macro.
	* gcc-interface/decl.c (gnat_to_gnu_entity) <E_Variable>: Use local
	variable for the entity type and translate it as void pointer if the
	entity has convention C.
	(gnat_to_gnu_entity) <E_Function>: If this is not a definition and the
	external name matches that of malloc_decl or realloc_decl, return the
	correspoding node directly.
	(gnat_to_gnu_subprog_type): Likewise for parameter and return types.
	* gcc-interface/trans.c (gigi): Initialize void_list_node here, not...
	Initialize realloc_decl.
	* gcc-interface/utils.c (install_builtin_elementary_types): ...here.
	(build_void_list_node): Delete.
	* gcc-interface/utils2.c (known_alignment) <CALL_EXPR>: Return the
	alignment of the system allocator for malloc_decl and realloc_decl.
	Do not take alignment from void pointer types either.

-- 
Eric Botcazou
-------------- next part --------------
A non-text attachment was scrubbed...
Name: p.diff
Type: text/x-patch
Size: 13509 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20160629/36d5cc9c/attachment.bin>