[Ada] fix issue with non private system.address handling

[Arnaud Charlet <charlet at adacore dot com>]

Manually tested on alpha-openvms
Tested on i686-linux, committed on trunk

On VMS_64 address types are visibly integer types, but arithmetic operations on
them are abstract, to prevent spurious ambiguities when integer literals appear
in an address context. For operators, we remove abstract interpretations during
the first pass of overload resolution. The current patch rejects literals that
appear as actuals in call to user-defined subprograms that have a formal that
is a descendent of address. This removes further spurious ambiguities in more
obscure cases.

See gnat.dg/addr3.adb

Also:
Tag checks on assignments to class-wide objects generate explicit references to
the tag component of the object. This component must be treated as visible even
though the only visible source components of a private extension are its
discriminants.

2007-08-31  Ed Schonberg  <schonberg@adacore.com>

	* sem_ch3.adb: The predicate Is_Descendent_Of_Address is now an entity
	flag, for effiency. It is called when analyzing arithmetic operators
	and also for actuals in calls that are universal_integers. The flag is
	set for the predefined type address, and for any type or subtype
	derived from it.

	* sem_ch4.adb (Analyze_One_Call): Reject an actual that is a
	Universal_Integer, when the formal is a descendent of address and the
	call appears in user code.
	(Analyze_Selected_Component): if the prefix is a private extension, the
	tag component is visible.

	* sem_util.ads, sem_util.adb: Remove Is_Descendent_Of_Address, now an
	entity flag.

Attachment: difs
Description: Text document