This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
The problem pertains to passing components of records as by-reference parameters to procedures, the types of the components being by-copy types; the trick here is pragma Import_Valued_Procedure and its siblings, which let the user specify the passing mechanism on a per-procedure basis. That is basically the same problem for Gigi as the Reference trick, because it may wind up trying to take the address of something that was not meant to be addressed in the first place. So Gigi has an ad-hoc mechanism to deal with non-addressable Out or In Out parameters passed by-ref: it first creates a temporary, passes its address to the procedure and then generates an explicit backwards copy operation in order to update the actual parameter. Clearly this mechanism is on the fringe of legality: 6.2 (2) reads "When a parameter is passed by reference, the formal parameter denotes (a view of) the object denoted by the actual parameter; reads and updates of the formal parameter directly reference the actual parameter object." Moreover we have discovered that Starlet very likely makes questionable assumptions about pragma Import_Valued_Procedure, which in particular are not fulfilled if the above mechanism is triggered. So it must be used very sparingly and the compiler now issues a warning when it is triggered in presence of pragma Import_Valued_Procedure or its siblings. The predicate for the mechanism essentially is addressable_p from trans.c. As of today, addressable_p is equivalent to !DECL_NONADDRESSABLE_P for fields that are not bitfields; as a consequence, we now create temporaries for any non-aliased components of records whose type is by-copy and for which the ABI does not mandate by-reference, in particular non-aliased scalar components. The fix is to differentiate "semantics addressability" as conveyed by DECL_NONADDRESSABLE_P from "technical addressability" as predicated by addressable_p. The former would of course imply the latter, but the latter could be true even in the absence of the former. Test case, only relevant to VMS should output: Status from ASCTOID: 1 pragma Extend_System (Aux_DEC); with SYSTEM; use SYSTEM; procedure p is subtype RIGHTS_ID_TYPE is SYSTEM.UNSIGNED_LONGWORD; subtype COND_VALUE_TYPE is SYSTEM.UNSIGNED_LONGWORD; procedure ASCTOID ( STATUS : out COND_VALUE_TYPE; ID : out RIGHTS_ID_TYPE ); pragma INTERFACE (EXTERNAL, ASCTOID); pragma IMPORT_VALUED_PROCEDURE (ASCTOID, "SYS$ASCTOID", (COND_VALUE_TYPE, RIGHTS_ID_TYPE), (VALUE, REFERENCE)); type ace_type is record size : unsigned_byte; key : rights_id_type; end record; status : cond_value_type; client_ace : ace_type := (size => 12, key => 0); begin ASCTOID (status => status, id => client_ace.key); end p; 2005-08-29 Arnaud Charlet <charlet@adacore.com> Eric Botcazou <ebotcazou@adacore.com> * trans.c: Protect < in error msg with quote Replace GCC_ZCX by Back_End_Exceptions. (addressable_p) <COMPONENT_REF>: Also return 1 if the field has been sufficiently aligned in the record.
Attachment:
difs.3
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |