From 6a84a367b109389757fc57a4645fde3e881691f1 Mon Sep 17 00:00:00 2001 From: charlet Date: Fri, 17 Feb 2012 14:07:11 +0000 Subject: [PATCH] 2012-02-17 Thomas Quinot * sem_aggr.adb: Minor reformatting. 2012-02-17 Robert Dewar * gnat_ugn.texi: Update doc for -gnatw.m to include 2*x case. 2012-02-17 Vincent Pucci * sem_dim.adb (Is_Dim_IO_Package_Entity): New routine. (Is_Dim_IO_Package_Instantiation): Is_Dim_IO_Package_Entity call added. (Is_Procedure_Put_Call): Is_Dim_IO_Package_Entity call added. * s-dim.ads: Make package Pure. 2012-02-17 Gary Dismukes * prj-nmsc.adb: Minor reformatting. 2012-02-17 Yannick Moy * gnat_rm.texi: Update GNAT RM with a separate chapter on restrictions. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@184338 138bc75d-0d04-0410-961f-82ee72b054a4 --- gcc/ada/ChangeLog | 25 + gcc/ada/gnat_rm.texi | 4379 ++++++++++++++++++++++++++++--------------------- gcc/ada/gnat_ugn.texi | 4 +- gcc/ada/prj-nmsc.adb | 2 +- gcc/ada/s-dim.ads | 2 + gcc/ada/sem_aggr.adb | 7 +- gcc/ada/sem_dim.adb | 52 +- 7 files changed, 2536 insertions(+), 1935 deletions(-) diff --git a/gcc/ada/ChangeLog b/gcc/ada/ChangeLog index 5f1aae8..7394320 100644 --- a/gcc/ada/ChangeLog +++ b/gcc/ada/ChangeLog @@ -1,3 +1,28 @@ +2012-02-17 Thomas Quinot + + * sem_aggr.adb: Minor reformatting. + +2012-02-17 Robert Dewar + + * gnat_ugn.texi: Update doc for -gnatw.m to include 2*x case. + +2012-02-17 Vincent Pucci + + * sem_dim.adb (Is_Dim_IO_Package_Entity): New routine. + (Is_Dim_IO_Package_Instantiation): Is_Dim_IO_Package_Entity + call added. + (Is_Procedure_Put_Call): Is_Dim_IO_Package_Entity + call added. + * s-dim.ads: Make package Pure. + +2012-02-17 Gary Dismukes + + * prj-nmsc.adb: Minor reformatting. + +2012-02-17 Yannick Moy + + * gnat_rm.texi: Update GNAT RM with a separate chapter on restrictions. + 2012-02-17 Yannick Moy * gnat_ugn.texi: Fix typos. diff --git a/gcc/ada/gnat_rm.texi b/gcc/ada/gnat_rm.texi index 6155a8c..86e0620 100644 --- a/gcc/ada/gnat_rm.texi +++ b/gcc/ada/gnat_rm.texi @@ -71,6 +71,7 @@ AdaCore * About This Guide:: * Implementation Defined Pragmas:: * Implementation Defined Attributes:: +* Implementation Defined Restrictions:: * Implementation Advice:: * Implementation Defined Characteristics:: * Intrinsic Subprograms:: @@ -191,6 +192,7 @@ Implementation Defined Pragmas * Pragma Shared:: * Pragma Short_Circuit_And_Or:: * Pragma Short_Descriptors:: +* Pragma Simple_Storage_Pool_Type:: * Pragma Source_File_Name:: * Pragma Source_File_Name_Project:: * Pragma Source_Reference:: @@ -269,6 +271,7 @@ Implementation Defined Attributes * Result:: * Safe_Emax:: * Safe_Large:: +* Simple_Storage_Pool:: * Small:: * Storage_Unit:: * Stub_Type:: @@ -286,6 +289,95 @@ Implementation Defined Attributes * Wchar_T_Size:: * Word_Size:: +Implementation Defined Restrictions + +* Partition-Wide Restrictions:: +* Unit-Level Restrictions:: + +Partition-Wide Restrictions + +* Immediate_Reclamation:: +* Max_Asynchronous_Select_Nesting:: +* Max_Entry_Queue_Length:: +* Max_Protected_Entries:: +* Max_Select_Alternatives:: +* Max_Storage_At_Blocking:: +* Max_Task_Entries:: +* Max_Tasks:: +* No_Abort_Statements:: +* No_Access_Parameter_Allocators:: +* No_Access_Subprograms:: +* No_Allocators:: +* No_Anonymous_Allocators:: +* No_Calendar:: +* No_Coextensions:: +* No_Default_Initialization:: +* No_Delay:: +* No_Dependence:: +* No_Direct_Boolean_Operators:: +* No_Dispatch:: +* No_Dispatching_Calls:: +* No_Dynamic_Attachment:: +* No_Dynamic_Priorities:: +* No_Entry_Calls_In_Elaboration_Code:: +* No_Enumeration_Maps:: +* No_Exception_Handlers:: +* No_Exception_Propagation:: +* No_Exception_Registration:: +* No_Exceptions:: +* No_Finalization:: +* No_Fixed_Point:: +* No_Floating_Point:: +* No_Implicit_Conditionals:: +* No_Implicit_Dynamic_Code:: +* No_Implicit_Heap_Allocations:: +* No_Implicit_Loops:: +* No_Initialize_Scalars:: +* No_IO:: +* No_Local_Allocators:: +* No_Local_Protected_Objects:: +* No_Local_Timing_Events:: +* No_Nested_Finalization:: +* No_Protected_Type_Allocators:: +* No_Protected_Types:: +* No_Relative_Delay:: +* No_Requeue_Statements:: +* No_Secondary_Stack:: +* No_Select_Statements:: +* No_Specific_Termination_Handlers:: +* No_Specification_of_Aspect:: +* No_Standard_Allocators_After_Elaboration:: +* No_Standard_Storage_Pools:: +* No_Stream_Optimizations:: +* No_Streams:: +* No_Task_Allocators:: +* No_Task_Attributes_Package:: +* No_Task_Hierarchy:: +* No_Tasking:: +* No_Terminate_Alternatives:: +* No_Unchecked_Access:: +* Simple_Barriers:: +* Static_Priorities:: +* Static_Storage_Size:: + +Unit-Level Restrictions + +* No_Elaboration_Code:: +* No_Entry_Queue:: +* No_Implementation_Aspect_Specifications:: +* No_Implementation_Attributes:: +* No_Implementation_Identifiers:: +* No_Implementation_Pragmas:: +* No_Implementation_Restrictions:: +* No_Implementation_Units:: +* No_Implicit_Aliasing:: +* No_Obsolescent_Features:: +* No_Recursion:: +* No_Reentrancy:: +* No_Wide_Characters:: +* SPARK:: +* No_Task_Termination:: + The Implementation of Standard I/O * Standard I/O Packages:: @@ -554,7 +646,12 @@ compiler. @item @ref{Implementation Defined Attributes}, lists GNAT -implementation-dependent attributes which can be used to extend and +implementation-dependent attributes, which can be used to extend and +enhance the functionality of the compiler. + +@item +@ref{Implementation Defined Restrictions}, lists GNAT +implementation-dependent restrictions, which can be used to extend and enhance the functionality of the compiler. @item @@ -830,6 +927,7 @@ consideration, the use of these pragmas should be minimized. * Pragma Shared:: * Pragma Short_Circuit_And_Or:: * Pragma Short_Descriptors:: +* Pragma Simple_Storage_Pool_Type:: * Pragma Source_File_Name:: * Pragma Source_File_Name_Project:: * Pragma Source_Reference:: @@ -4241,83 +4339,25 @@ plus the following set of restrictions: @table @code @item Max_Entry_Queue_Length => 1 -Defines the maximum number of calls that are queued on a (protected) entry. -Note that this restrictions is checked at run time. Violation of this -restriction results in the raising of Program_Error exception at the point of -the call. For the Profile (Ravenscar) the value of Max_Entry_Queue_Length is -always 1 and hence no task can be queued on a protected entry. - +No task can be queued on a protected entry. @item Max_Protected_Entries => 1 -[RM D.7] Specifies the maximum number of entries per protected type. The -bounds of every entry family of a protected unit shall be static, or shall be -defined by a discriminant of a subtype whose corresponding bound is static. -For the Profile (Ravenscar) the value of Max_Protected_Entries is always 1. - @item Max_Task_Entries => 0 -[RM D.7] Specifies the maximum number of entries -per task. The bounds of every entry family -of a task unit shall be static, or shall be -defined by a discriminant of a subtype whose -corresponding bound is static. A value of zero -indicates that no rendezvous are possible. For -the Profile (Ravenscar), the value of Max_Task_Entries is always -0 (zero). - +No rendezvous are possible. @item No_Abort_Statements -[RM D.7] There are no abort_statements, and there are -no calls to Task_Identification.Abort_Task. - @item No_Dynamic_Attachment -There is no call to any of the operations defined in package Ada.Interrupts -(Is_Reserved, Is_Attached, Current_Handler, Attach_Handler, Exchange_Handler, -Detach_Handler, and Reference). - @item No_Dynamic_Priorities -[RM D.7] There are no semantic dependencies on the package Dynamic_Priorities. - @item No_Implicit_Heap_Allocations -[RM D.7] No constructs are allowed to cause implicit heap allocation. - @item No_Local_Protected_Objects -Protected objects and access types that designate -such objects shall be declared only at library level. - @item No_Local_Timing_Events -[RM D.7] All objects of type Ada.Timing_Events.Timing_Event are -declared at the library level. - @item No_Protected_Type_Allocators -There are no allocators for protected types or -types containing protected subcomponents. - @item No_Relative_Delay -There are no delay_relative statements. - @item No_Requeue_Statements -Requeue statements are not allowed. - @item No_Select_Statements -There are no select_statements. - @item No_Specific_Termination_Handlers -[RM D.7] There are no calls to Ada.Task_Termination.Set_Specific_Handler -or to Ada.Task_Termination.Specific_Handler. - @item No_Task_Allocators -[RM D.7] There are no allocators for task types -or types containing task subcomponents. - @item No_Task_Hierarchy -[RM D.7] All (non-environment) tasks depend -directly on the environment task of the partition. - @item No_Task_Termination -Tasks which terminate are erroneous. - @item Simple_Barriers -Entry barrier condition expressions shall be either static -boolean expressions or boolean objects which are declared in -the protected type which contains the entry. @end table @noindent @@ -4564,6 +4604,73 @@ Short_Descriptor[_xxx]. This is helpful in porting legacy applications from a 32-bit environment to a 64-bit environment. This pragma is ignored for non-VMS versions. +@node Pragma Simple_Storage_Pool_Type +@unnumberedsec Pragma Simple_Storage_Pool_Type +@findex Simple_Storage_Pool_Type +@cindex Storage pool, simple +@cindex Simple storage pool +@noindent +Syntax: + +@smallexample @c ada +pragma Simple_Storage_Pool_Type (type_LOCAL_NAME); +@end smallexample + +@noindent +A type can be established as a ``simple storage pool type'' by applying +the representation pragma @code{Simple_Storage_Pool_Type} to the type. +A type named in the pragma must be a library-level immutably limited record +type or limited tagged type declared immediately within a package declaration. +The type can also be a limited private type whose full type is allowed as +a simple storage pool type. + +For a simple storage pool type @var{SSP}, nonabstract primitive subprograms +@code{Allocate}, @code{Deallocate}, and @code{Storage_Size} can be declared that +are subtype conformant with the following subprogram declarations: + +@smallexample @c ada +procedure Allocate + (Pool : in out SSP; + Storage_Address : out System.Address; + Size_In_Storage_Elements : System.Storage_Elements.Storage_Count; + Alignment : System.Storage_Elements.Storage_Count); + +procedure Deallocate + (Pool : in out SSP; + Storage_Address : System.Address; + Size_In_Storage_Elements : System.Storage_Elements.Storage_Count; + Alignment : System.Storage_Elements.Storage_Count); + +function Storage_Size (Pool : SSP) + return System.Storage_Elements.Storage_Count; +@end smallexample + +@noindent +Procedure @code{Allocate} must be declared, whereas @code{Deallocate} and +@code{Storage_Size} are optional. If @code{Deallocate} is not declared, then +applying an unchecked deallocation has no effect other than to set its actual +parameter to null. If @code{Storage_Size} is not declared, then the +@code{Storage_Size} attribute applied to an access type associated with +a pool object of type SSP returns zero. Additional operations can be declared +for a simple storage pool type (such as for supporting a mark/release +storage-management discipline). + +An object of a simple storage pool type can be associated with an access +type by specifying the attribute @code{Simple_Storage_Pool}. For example: + +@smallexample @c ada + +My_Pool : My_Simple_Storage_Pool_Type; + +type Acc is access My_Data_Type; + +for Acc'Simple_Storage_Pool use My_Pool; + +@end smallexample + +@noindent +See attribute @code{Simple_Storage_Pool} for further details. + @node Pragma Source_File_Name @unnumberedsec Pragma Source_File_Name @findex Source_File_Name @@ -5791,6 +5898,7 @@ consideration, you should minimize the use of these attributes. * Result:: * Safe_Emax:: * Safe_Large:: +* Simple_Storage_Pool:: * Small:: * Storage_Unit:: * Stub_Type:: @@ -6516,6 +6624,66 @@ The @code{Safe_Large} attribute is provided for compatibility with Ada 83. See the Ada 83 reference manual for an exact description of the semantics of this attribute. +@node Simple_Storage_Pool +@unnumberedsec Simple_Storage_Pool +@cindex Storage pool, simple +@cindex Simple storage pool +@findex Simple_Storage_Pool +@noindent +For every nonformal, nonderived access-to-object type @var{Acc}, the +representation attribute @code{Simple_Storage_Pool} may be specified +via an attribute_definition_clause (or by specifying the equivalent aspect): + +@smallexample @c ada + +My_Pool : My_Simple_Storage_Pool_Type; + +type Acc is access My_Data_Type; + +for Acc'Simple_Storage_Pool use My_Pool; + +@end smallexample + +@noindent +The name given in an attribute_definition_clause for the +@code{Simple_Storage_Pool} attribute shall denote a variable of +a ``simple storage pool type'' (see pragma @code{Simple_Storage_Pool_Type}). + +The use of this attribute is only allowed for a prefix denoting a type +for which it has been specified. The type of the attribute is the type +of the variable specified as the simple storage pool of the access type, +and the attribute denotes that variable. + +It is illegal to specify both @code{Storage_Pool} and @code{Simple_Storage_Pool} +for the same access type. + +If the @code{Simple_Storage_Pool} attribute has been specified for an access +type, then applying the @code{Storage_Pool} attribute to the type is flagged +with a warning and its evaluation raises the exception @code{Program_Error}. + +If the Simple_Storage_Pool attribute has been specified for an access +type @var{S}, then the evaluation of the attribute @code{@var{S}'Storage_Size} +returns the result of calling @code{Storage_Size (@var{S}'Simple_Storage_Pool)}, +which is intended to indicate the number of storage elements reserved for +the simple storage pool. If the Storage_Size function has not been defined +for the simple storage pool type, then this attribute returns zero. + +If an access type @var{S} has a specified simple storage pool of type +@var{SSP}, then the evaluation of an allocator for that access type calls +the primitive @code{Allocate} procedure for type @var{SSP}, passing +@code{@var{S}'Simple_Storage_Pool} as the pool parameter. The detailed +semantics of such allocators is the same as those defined for allocators +in section 13.11 of the Ada Reference Manual, with the term +``simple storage pool'' substituted for ``storage pool''. + +If an access type @var{S} has a specified simple storage pool of type +@var{SSP}, then a call to an instance of the @code{Ada.Unchecked_Deallocation} +for that access type invokes the primitive @code{Deallocate} procedure +for type @var{SSP}, passing @code{@var{S}'Simple_Storage_Pool} as the pool +parameter. The detailed semantics of such unchecked deallocations is the same +as defined in section 13.11.2 of the Ada Reference Manual, except that the +term ``simple storage pool'' is substituted for ``storage pool''. + @node Small @unnumberedsec Small @cindex Ada 83 attributes @@ -6736,2628 +6904,3023 @@ package @code{Interfaces.C}. @code{Standard'Word_Size} (@code{Standard} is the only permissible prefix) provides the value @code{System.Word_Size}. -@c ------------------------ -@node Implementation Advice -@chapter Implementation Advice +@node Implementation Defined Restrictions +@chapter Implementation Defined Restrictions + @noindent -The main text of the Ada Reference Manual describes the required -behavior of all Ada compilers, and the GNAT compiler conforms to -these requirements. +All RM defined Restriction identifiers are implemented: -In addition, there are sections throughout the Ada Reference Manual headed -by the phrase ``Implementation advice''. These sections are not normative, -i.e., they do not specify requirements that all compilers must -follow. Rather they provide advice on generally desirable behavior. You -may wonder why they are not requirements. The most typical answer is -that they describe behavior that seems generally desirable, but cannot -be provided on all systems, or which may be undesirable on some systems. +@itemize @bullet +@item language-defined restrictions (see 13.12.1) +@item tasking restrictions (see D.7) +@item high integrity restrictions (see H.4) +@end itemize -As far as practical, GNAT follows the implementation advice sections in -the Ada Reference Manual. This chapter contains a table giving the -reference manual section number, paragraph number and several keywords -for each advice. Each entry consists of the text of the advice followed -by the GNAT interpretation of this advice. Most often, this simply says -``followed'', which means that GNAT follows the advice. However, in a -number of cases, GNAT deliberately deviates from this advice, in which -case the text describes what GNAT does and why. +@noindent +GNAT implements additional restriction identifiers. All restrictions, whether +language defined or GNAT-specific, are listed in the following. -@cindex Error detection -@unnumberedsec 1.1.3(20): Error Detection -@sp 1 -@cartouche -If an implementation detects the use of an unsupported Specialized Needs -Annex feature at run time, it should raise @code{Program_Error} if -feasible. -@end cartouche -Not relevant. All specialized needs annex features are either supported, -or diagnosed at compile time. +@menu +* Partition-Wide Restrictions:: +* Unit-Level Restrictions:: +@end menu -@cindex Child Units -@unnumberedsec 1.1.3(31): Child Units -@sp 1 -@cartouche -If an implementation wishes to provide implementation-defined -extensions to the functionality of a language-defined library unit, it -should normally do so by adding children to the library unit. -@end cartouche -Followed. +@node Partition-Wide Restrictions +@section Partition-Wide Restrictions -@cindex Bounded errors -@unnumberedsec 1.1.5(12): Bounded Errors -@sp 1 -@cartouche -If an implementation detects a bounded error or erroneous -execution, it should raise @code{Program_Error}. -@end cartouche -Followed in all cases in which the implementation detects a bounded -error or erroneous execution. Not all such situations are detected at -runtime. +There are two separate lists of restriction identifiers. The first +set requires consistency throughout a partition (in other words, if the +restriction identifier is used for any compilation unit in the partition, +then all compilation units in the partition must obey the restriction). -@cindex Pragmas -@unnumberedsec 2.8(16): Pragmas -@sp 1 -@cartouche -Normally, implementation-defined pragmas should have no semantic effect -for error-free programs; that is, if the implementation-defined pragmas -are removed from a working program, the program should still be legal, -and should still have the same semantics. -@end cartouche -The following implementation defined pragmas are exceptions to this -rule: +@menu +* Immediate_Reclamation:: +* Max_Asynchronous_Select_Nesting:: +* Max_Entry_Queue_Length:: +* Max_Protected_Entries:: +* Max_Select_Alternatives:: +* Max_Storage_At_Blocking:: +* Max_Task_Entries:: +* Max_Tasks:: +* No_Abort_Statements:: +* No_Access_Parameter_Allocators:: +* No_Access_Subprograms:: +* No_Allocators:: +* No_Anonymous_Allocators:: +* No_Calendar:: +* No_Coextensions:: +* No_Default_Initialization:: +* No_Delay:: +* No_Dependence:: +* No_Direct_Boolean_Operators:: +* No_Dispatch:: +* No_Dispatching_Calls:: +* No_Dynamic_Attachment:: +* No_Dynamic_Priorities:: +* No_Entry_Calls_In_Elaboration_Code:: +* No_Enumeration_Maps:: +* No_Exception_Handlers:: +* No_Exception_Propagation:: +* No_Exception_Registration:: +* No_Exceptions:: +* No_Finalization:: +* No_Fixed_Point:: +* No_Floating_Point:: +* No_Implicit_Conditionals:: +* No_Implicit_Dynamic_Code:: +* No_Implicit_Heap_Allocations:: +* No_Implicit_Loops:: +* No_Initialize_Scalars:: +* No_IO:: +* No_Local_Allocators:: +* No_Local_Protected_Objects:: +* No_Local_Timing_Events:: +* No_Nested_Finalization:: +* No_Protected_Type_Allocators:: +* No_Protected_Types:: +* No_Relative_Delay:: +* No_Requeue_Statements:: +* No_Secondary_Stack:: +* No_Select_Statements:: +* No_Specific_Termination_Handlers:: +* No_Specification_of_Aspect:: +* No_Standard_Allocators_After_Elaboration:: +* No_Standard_Storage_Pools:: +* No_Stream_Optimizations:: +* No_Streams:: +* No_Task_Allocators:: +* No_Task_Attributes_Package:: +* No_Task_Hierarchy:: +* No_Tasking:: +* No_Terminate_Alternatives:: +* No_Unchecked_Access:: +* Simple_Barriers:: +* Static_Priorities:: +* Static_Storage_Size:: +@end menu -@table @code -@item Abort_Defer -Affects semantics -@item Ada_83 -Affects legality -@item Assert -Affects semantics -@item CPP_Class -Affects semantics -@item CPP_Constructor -Affects semantics -@item Debug -Affects semantics -@item Interface_Name -Affects semantics -@item Machine_Attribute -Affects semantics -@item Unimplemented_Unit -Affects legality -@item Unchecked_Union -Affects semantics -@end table +@node Immediate_Reclamation +@unnumberedsubsec Immediate_Reclamation +@findex Immediate_Reclamation +[RM H.4] This restriction ensures that, except for storage occupied by +objects created by allocators and not deallocated via unchecked +deallocation, any storage reserved at run time for an object is +immediately reclaimed when the object no longer exists. + +@node Max_Asynchronous_Select_Nesting +@unnumberedsubsec Max_Asynchronous_Select_Nesting +@findex Max_Asynchronous_Select_Nesting +[RM D.7] Specifies the maximum dynamic nesting level of asynchronous +selects. Violations of this restriction with a value of zero are +detected at compile time. Violations of this restriction with values +other than zero cause Storage_Error to be raised. + +@node Max_Entry_Queue_Length +@unnumberedsubsec Max_Entry_Queue_Length +@findex Max_Entry_Queue_Length +[RM D.7] This restriction is a declaration that any protected entry compiled in +the scope of the restriction has at most the specified number of +tasks waiting on the entry at any one time, and so no queue is required. +Note that this restriction is checked at run time. Violation of this +restriction results in the raising of Program_Error exception at the point of +the call. -@noindent -In each of the above cases, it is essential to the purpose of the pragma -that this advice not be followed. For details see the separate section -on implementation defined pragmas. +@node Max_Protected_Entries +@unnumberedsubsec Max_Protected_Entries +@findex Max_Protected_Entries +[RM D.7] Specifies the maximum number of entries per protected type. The +bounds of every entry family of a protected unit shall be static, or shall be +defined by a discriminant of a subtype whose corresponding bound is static. -@unnumberedsec 2.8(17-19): Pragmas -@sp 1 -@cartouche -Normally, an implementation should not define pragmas that can -make an illegal program legal, except as follows: -@end cartouche -@sp 1 -@cartouche -A pragma used to complete a declaration, such as a pragma @code{Import}; -@end cartouche -@sp 1 -@cartouche -A pragma used to configure the environment by adding, removing, or -replacing @code{library_items}. -@end cartouche -See response to paragraph 16 of this same section. +@node Max_Select_Alternatives +@unnumberedsubsec Max_Select_Alternatives +@findex Max_Select_Alternatives +[RM D.7] Specifies the maximum number of alternatives in a selective accept. + +@node Max_Storage_At_Blocking +@unnumberedsubsec Max_Storage_At_Blocking +@findex Max_Storage_At_Blocking +[RM D.7] Specifies the maximum portion (in storage elements) of a task's +Storage_Size that can be retained by a blocked task. A violation of this +restriction causes Storage_Error to be raised. + +@node Max_Task_Entries +@unnumberedsubsec Max_Task_Entries +@findex Max_Task_Entries +[RM D.7] Specifies the maximum number of entries +per task. The bounds of every entry family +of a task unit shall be static, or shall be +defined by a discriminant of a subtype whose +corresponding bound is static. + +@node Max_Tasks +@unnumberedsubsec Max_Tasks +@findex Max_Tasks +[RM D.7] Specifies the maximum number of task that may be created, not +counting the creation of the environment task. Violations of this +restriction with a value of zero are detected at compile +time. Violations of this restriction with values other than zero cause +Storage_Error to be raised. + +@node No_Abort_Statements +@unnumberedsubsec No_Abort_Statements +@findex No_Abort_Statements +[RM D.7] There are no abort_statements, and there are +no calls to Task_Identification.Abort_Task. -@cindex Character Sets -@cindex Alternative Character Sets -@unnumberedsec 3.5.2(5): Alternative Character Sets -@sp 1 -@cartouche -If an implementation supports a mode with alternative interpretations -for @code{Character} and @code{Wide_Character}, the set of graphic -characters of @code{Character} should nevertheless remain a proper -subset of the set of graphic characters of @code{Wide_Character}. Any -character set ``localizations'' should be reflected in the results of -the subprograms defined in the language-defined package -@code{Characters.Handling} (see A.3) available in such a mode. In a mode with -an alternative interpretation of @code{Character}, the implementation should -also support a corresponding change in what is a legal -@code{identifier_letter}. -@end cartouche -Not all wide character modes follow this advice, in particular the JIS -and IEC modes reflect standard usage in Japan, and in these encoding, -the upper half of the Latin-1 set is not part of the wide-character -subset, since the most significant bit is used for wide character -encoding. However, this only applies to the external forms. Internally -there is no such restriction. +@node No_Access_Parameter_Allocators +@unnumberedsubsec No_Access_Parameter_Allocators +@findex No_Access_Parameter_Allocators +[RM H.4] This restriction ensures at compile time that there are no +occurrences of an allocator as the actual parameter to an access +parameter. + +@node No_Access_Subprograms +@unnumberedsubsec No_Access_Subprograms +@findex No_Access_Subprograms +[RM H.4] This restriction ensures at compile time that there are no +declarations of access-to-subprogram types. + +@node No_Allocators +@unnumberedsubsec No_Allocators +@findex No_Allocators +[RM H.4] This restriction ensures at compile time that there are no +occurrences of an allocator. + +@node No_Anonymous_Allocators +@unnumberedsubsec No_Anonymous_Allocators +@findex No_Anonymous_Allocators +[RM H.4] This restriction ensures at compile time that there are no +occurrences of an allocator of anonymous access type. + +@node No_Calendar +@unnumberedsubsec No_Calendar +@findex No_Calendar +[GNAT] This restriction ensures at compile time that there is no implicit or +explicit dependence on the package @code{Ada.Calendar}. -@cindex Integer types -@unnumberedsec 3.5.4(28): Integer Types +@node No_Coextensions +@unnumberedsubsec No_Coextensions +@findex No_Coextensions +[RM H.4] This restriction ensures at compile time that there are no +coextensions. See 3.10.2. -@sp 1 -@cartouche -An implementation should support @code{Long_Integer} in addition to -@code{Integer} if the target machine supports 32-bit (or longer) -arithmetic. No other named integer subtypes are recommended for package -@code{Standard}. Instead, appropriate named integer subtypes should be -provided in the library package @code{Interfaces} (see B.2). -@end cartouche -@code{Long_Integer} is supported. Other standard integer types are supported -so this advice is not fully followed. These types -are supported for convenient interface to C, and so that all hardware -types of the machine are easily available. -@unnumberedsec 3.5.4(29): Integer Types +@node No_Default_Initialization +@unnumberedsubsec No_Default_Initialization +@findex No_Default_Initialization -@sp 1 -@cartouche -An implementation for a two's complement machine should support -modular types with a binary modulus up to @code{System.Max_Int*2+2}. An -implementation should support a non-binary modules up to @code{Integer'Last}. -@end cartouche -Followed. +[GNAT] This restriction prohibits any instance of default initialization +of variables. The binder implements a consistency rule which prevents +any unit compiled without the restriction from with'ing a unit with the +restriction (this allows the generation of initialization procedures to +be skipped, since you can be sure that no call is ever generated to an +initialization procedure in a unit with the restriction active). If used +in conjunction with Initialize_Scalars or Normalize_Scalars, the effect +is to prohibit all cases of variables declared without a specific +initializer (including the case of OUT scalar parameters). + +@node No_Delay +@unnumberedsubsec No_Delay +@findex No_Delay +[RM H.4] This restriction ensures at compile time that there are no +delay statements and no dependences on package Calendar. + +@node No_Dependence +@unnumberedsubsec No_Dependence +@findex No_Dependence +[RM 13.12.1] This restriction checks at compile time that there are no +dependence on a library unit. + +@node No_Direct_Boolean_Operators +@unnumberedsubsec No_Direct_Boolean_Operators +@findex No_Direct_Boolean_Operators +[GNAT] This restriction ensures that no logical (and/or/xor) are used on +operands of type Boolean (or any type derived +from Boolean). This is intended for use in safety critical programs +where the certification protocol requires the use of short-circuit +(and then, or else) forms for all composite boolean operations. -@cindex Enumeration values -@unnumberedsec 3.5.5(8): Enumeration Values -@sp 1 -@cartouche -For the evaluation of a call on @code{@var{S}'Pos} for an enumeration -subtype, if the value of the operand does not correspond to the internal -code for any enumeration literal of its type (perhaps due to an -un-initialized variable), then the implementation should raise -@code{Program_Error}. This is particularly important for enumeration -types with noncontiguous internal codes specified by an -enumeration_representation_clause. -@end cartouche -Followed. +@node No_Dispatch +@unnumberedsubsec No_Dispatch +@findex No_Dispatch +[RM H.4] This restriction ensures at compile time that there are no +occurrences of @code{T'Class}, for any (tagged) subtype @code{T}. -@cindex Float types -@unnumberedsec 3.5.7(17): Float Types -@sp 1 -@cartouche -An implementation should support @code{Long_Float} in addition to -@code{Float} if the target machine supports 11 or more digits of -precision. No other named floating point subtypes are recommended for -package @code{Standard}. Instead, appropriate named floating point subtypes -should be provided in the library package @code{Interfaces} (see B.2). -@end cartouche -@code{Short_Float} and @code{Long_Long_Float} are also provided. The -former provides improved compatibility with other implementations -supporting this type. The latter corresponds to the highest precision -floating-point type supported by the hardware. On most machines, this -will be the same as @code{Long_Float}, but on some machines, it will -correspond to the IEEE extended form. The notable case is all ia32 -(x86) implementations, where @code{Long_Long_Float} corresponds to -the 80-bit extended precision format supported in hardware on this -processor. Note that the 128-bit format on SPARC is not supported, -since this is a software rather than a hardware format. +@node No_Dispatching_Calls +@unnumberedsubsec No_Dispatching_Calls +@findex No_Dispatching_Calls +[GNAT] This restriction ensures at compile time that the code generated by the +compiler involves no dispatching calls. The use of this restriction allows the +safe use of record extensions, classwide membership tests and other classwide +features not involving implicit dispatching. This restriction ensures that +the code contains no indirect calls through a dispatching mechanism. Note that +this includes internally-generated calls created by the compiler, for example +in the implementation of class-wide objects assignments. The +membership test is allowed in the presence of this restriction, because its +implementation requires no dispatching. +This restriction is comparable to the official Ada restriction +@code{No_Dispatch} except that it is a bit less restrictive in that it allows +all classwide constructs that do not imply dispatching. +The following example indicates constructs that violate this restriction. -@cindex Multidimensional arrays -@cindex Arrays, multidimensional -@unnumberedsec 3.6.2(11): Multidimensional Arrays -@sp 1 -@cartouche -An implementation should normally represent multidimensional arrays in -row-major order, consistent with the notation used for multidimensional -array aggregates (see 4.3.3). However, if a pragma @code{Convention} -(@code{Fortran}, @dots{}) applies to a multidimensional array type, then -column-major order should be used instead (see B.5, ``Interfacing with -Fortran''). -@end cartouche -Followed. +@smallexample +package Pkg is + type T is tagged record + Data : Natural; + end record; + procedure P (X : T); -@findex Duration'Small -@unnumberedsec 9.6(30-31): Duration'Small -@sp 1 -@cartouche -Whenever possible in an implementation, the value of @code{Duration'Small} -should be no greater than 100 microseconds. -@end cartouche -Followed. (@code{Duration'Small} = 10**(@minus{}9)). + type DT is new T with record + More_Data : Natural; + end record; + procedure Q (X : DT); +end Pkg; -@sp 1 -@cartouche -The time base for @code{delay_relative_statements} should be monotonic; -it need not be the same time base as used for @code{Calendar.Clock}. -@end cartouche -Followed. +with Pkg; use Pkg; +procedure Example is + procedure Test (O : T'Class) is + N : Natural := O'Size;-- Error: Dispatching call + C : T'Class := O; -- Error: implicit Dispatching Call + begin + if O in DT'Class then -- OK : Membership test + Q (DT (O)); -- OK : Type conversion plus direct call + else + P (O); -- Error: Dispatching call + end if; + end Test; -@unnumberedsec 10.2.1(12): Consistent Representation -@sp 1 -@cartouche -In an implementation, a type declared in a pre-elaborated package should -have the same representation in every elaboration of a given version of -the package, whether the elaborations occur in distinct executions of -the same program, or in executions of distinct programs or partitions -that include the given version. -@end cartouche -Followed, except in the case of tagged types. Tagged types involve -implicit pointers to a local copy of a dispatch table, and these pointers -have representations which thus depend on a particular elaboration of the -package. It is not easy to see how it would be possible to follow this -advice without severely impacting efficiency of execution. + Obj : DT; +begin + P (Obj); -- OK : Direct call + P (T (Obj)); -- OK : Type conversion plus direct call + P (T'Class (Obj)); -- Error: Dispatching call -@cindex Exception information -@unnumberedsec 11.4.1(19): Exception Information -@sp 1 -@cartouche -@code{Exception_Message} by default and @code{Exception_Information} -should produce information useful for -debugging. @code{Exception_Message} should be short, about one -line. @code{Exception_Information} can be long. @code{Exception_Message} -should not include the -@code{Exception_Name}. @code{Exception_Information} should include both -the @code{Exception_Name} and the @code{Exception_Message}. -@end cartouche -Followed. For each exception that doesn't have a specified -@code{Exception_Message}, the compiler generates one containing the location -of the raise statement. This location has the form ``file:line'', where -file is the short file name (without path information) and line is the line -number in the file. Note that in the case of the Zero Cost Exception -mechanism, these messages become redundant with the Exception_Information that -contains a full backtrace of the calling sequence, so they are disabled. -To disable explicitly the generation of the source location message, use the -Pragma @code{Discard_Names}. + Test (Obj); -- OK : Type conversion -@cindex Suppression of checks -@cindex Checks, suppression of -@unnumberedsec 11.5(28): Suppression of Checks -@sp 1 -@cartouche -The implementation should minimize the code executed for checks that -have been suppressed. -@end cartouche -Followed. + if Obj in T'Class then -- OK : Membership test + null; + end if; +end Example; +@end smallexample -@cindex Representation clauses -@unnumberedsec 13.1 (21-24): Representation Clauses -@sp 1 -@cartouche -The recommended level of support for all representation items is -qualified as follows: -@end cartouche -@sp 1 -@cartouche -An implementation need not support representation items containing -non-static expressions, except that an implementation should support a -representation item for a given entity if each non-static expression in -the representation item is a name that statically denotes a constant -declared before the entity. -@end cartouche -Followed. In fact, GNAT goes beyond the recommended level of support -by allowing nonstatic expressions in some representation clauses even -without the need to declare constants initialized with the values of -such expressions. -For example: +@node No_Dynamic_Attachment +@unnumberedsubsec No_Dynamic_Attachment +@findex No_Dynamic_Attachment +[RM D.7] This restriction ensures that there is no call to any of the +operations defined in package Ada.Interrupts +(Is_Reserved, Is_Attached, Current_Handler, Attach_Handler, Exchange_Handler, +Detach_Handler, and Reference). + +@node No_Dynamic_Priorities +@unnumberedsubsec No_Dynamic_Priorities +@findex No_Dynamic_Priorities +[RM D.7] There are no semantic dependencies on the package Dynamic_Priorities. + +@node No_Entry_Calls_In_Elaboration_Code +@unnumberedsubsec No_Entry_Calls_In_Elaboration_Code +@findex No_Entry_Calls_In_Elaboration_Code +[GNAT] This restriction ensures at compile time that no task or protected entry +calls are made during elaboration code. As a result of the use of this +restriction, the compiler can assume that no code past an accept statement +in a task can be executed at elaboration time. + +@node No_Enumeration_Maps +@unnumberedsubsec No_Enumeration_Maps +@findex No_Enumeration_Maps +[GNAT] This restriction ensures at compile time that no operations requiring +enumeration maps are used (that is Image and Value attributes applied +to enumeration types). + +@node No_Exception_Handlers +@unnumberedsubsec No_Exception_Handlers +@findex No_Exception_Handlers +[GNAT] This restriction ensures at compile time that there are no explicit +exception handlers. It also indicates that no exception propagation will +be provided. In this mode, exceptions may be raised but will result in +an immediate call to the last chance handler, a routine that the user +must define with the following profile: @smallexample @c ada - X : Integer; - Y : Float; - for Y'Address use X'Address;>> +procedure Last_Chance_Handler + (Source_Location : System.Address; Line : Integer); +pragma Export (C, Last_Chance_Handler, + "__gnat_last_chance_handler"); @end smallexample -@sp 1 -@cartouche -An implementation need not support a specification for the @code{Size} -for a given composite subtype, nor the size or storage place for an -object (including a component) of a given composite subtype, unless the -constraints on the subtype and its composite subcomponents (if any) are -all static constraints. -@end cartouche -Followed. Size Clauses are not permitted on non-static components, as -described above. +The parameter is a C null-terminated string representing a message to be +associated with the exception (typically the source location of the raise +statement generated by the compiler). The Line parameter when nonzero +represents the line number in the source program where the raise occurs. -@sp 1 -@cartouche -An aliased component, or a component whose type is by-reference, should -always be allocated at an addressable location. -@end cartouche -Followed. +@node No_Exception_Propagation +@unnumberedsubsec No_Exception_Propagation +@findex No_Exception_Propagation +[GNAT] This restriction guarantees that exceptions are never propagated +to an outer subprogram scope). The only case in which an exception may +be raised is when the handler is statically in the same subprogram, so +that the effect of a raise is essentially like a goto statement. Any +other raise statement (implicit or explicit) will be considered +unhandled. Exception handlers are allowed, but may not contain an +exception occurrence identifier (exception choice). In addition use of +the package GNAT.Current_Exception is not permitted, and reraise +statements (raise with no operand) are not permitted. -@cindex Packed types -@unnumberedsec 13.2(6-8): Packed Types -@sp 1 -@cartouche -If a type is packed, then the implementation should try to minimize -storage allocated to objects of the type, possibly at the expense of -speed of accessing components, subject to reasonable complexity in -addressing calculations. -@end cartouche -@sp 1 -@cartouche -The recommended level of support pragma @code{Pack} is: +@node No_Exception_Registration +@unnumberedsubsec No_Exception_Registration +@findex No_Exception_Registration +[GNAT] This restriction ensures at compile time that no stream operations for +types Exception_Id or Exception_Occurrence are used. This also makes it +impossible to pass exceptions to or from a partition with this restriction +in a distributed environment. If this exception is active, then the generated +code is simplified by omitting the otherwise-required global registration +of exceptions when they are declared. -For a packed record type, the components should be packed as tightly as -possible subject to the Sizes of the component subtypes, and subject to -any @code{record_representation_clause} that applies to the type; the -implementation may, but need not, reorder components or cross aligned -word boundaries to improve the packing. A component whose @code{Size} is -greater than the word size may be allocated an integral number of words. -@end cartouche -Followed. Tight packing of arrays is supported for all component sizes -up to 64-bits. If the array component size is 1 (that is to say, if -the component is a boolean type or an enumeration type with two values) -then values of the type are implicitly initialized to zero. This -happens both for objects of the packed type, and for objects that have a -subcomponent of the packed type. +@node No_Exceptions +@unnumberedsubsec No_Exceptions +@findex No_Exceptions +[RM H.4] This restriction ensures at compile time that there are no +raise statements and no exception handlers. -@sp 1 -@cartouche -An implementation should support Address clauses for imported -subprograms. -@end cartouche -Followed. -@cindex @code{Address} clauses -@unnumberedsec 13.3(14-19): Address Clauses +@node No_Finalization +@unnumberedsubsec No_Finalization +@findex No_Finalization +[GNAT] This restriction disables the language features described in +chapter 7.6 of the Ada 2005 RM as well as all form of code generation +performed by the compiler to support these features. The following types +are no longer considered controlled when this restriction is in effect: +@itemize @bullet +@item +@code{Ada.Finalization.Controlled} +@item +@code{Ada.Finalization.Limited_Controlled} +@item +Derivations from @code{Controlled} or @code{Limited_Controlled} +@item +Class-wide types +@item +Protected types +@item +Task types +@item +Array and record types with controlled components +@end itemize +The compiler no longer generates code to initialize, finalize or adjust an +object or a nested component, either declared on the stack or on the heap. The +deallocation of a controlled object no longer finalizes its contents. + +@node No_Fixed_Point +@unnumberedsubsec No_Fixed_Point +@findex No_Fixed_Point +[RM H.4] This restriction ensures at compile time that there are no +occurrences of fixed point types and operations. + +@node No_Floating_Point +@unnumberedsubsec No_Floating_Point +@findex No_Floating_Point +[RM H.4] This restriction ensures at compile time that there are no +occurrences of floating point types and operations. + +@node No_Implicit_Conditionals +@unnumberedsubsec No_Implicit_Conditionals +@findex No_Implicit_Conditionals +[GNAT] This restriction ensures that the generated code does not contain any +implicit conditionals, either by modifying the generated code where possible, +or by rejecting any construct that would otherwise generate an implicit +conditional. Note that this check does not include run time constraint +checks, which on some targets may generate implicit conditionals as +well. To control the latter, constraint checks can be suppressed in the +normal manner. Constructs generating implicit conditionals include comparisons +of composite objects and the Max/Min attributes. + +@node No_Implicit_Dynamic_Code +@unnumberedsubsec No_Implicit_Dynamic_Code +@findex No_Implicit_Dynamic_Code +@cindex trampoline +[GNAT] This restriction prevents the compiler from building ``trampolines''. +This is a structure that is built on the stack and contains dynamic +code to be executed at run time. On some targets, a trampoline is +built for the following features: @code{Access}, +@code{Unrestricted_Access}, or @code{Address} of a nested subprogram; +nested task bodies; primitive operations of nested tagged types. +Trampolines do not work on machines that prevent execution of stack +data. For example, on windows systems, enabling DEP (data execution +protection) will cause trampolines to raise an exception. +Trampolines are also quite slow at run time. + +On many targets, trampolines have been largely eliminated. Look at the +version of system.ads for your target --- if it has +Always_Compatible_Rep equal to False, then trampolines are largely +eliminated. In particular, a trampoline is built for the following +features: @code{Address} of a nested subprogram; +@code{Access} or @code{Unrestricted_Access} of a nested subprogram, +but only if pragma Favor_Top_Level applies, or the access type has a +foreign-language convention; primitive operations of nested tagged +types. + +@node No_Implicit_Heap_Allocations +@unnumberedsubsec No_Implicit_Heap_Allocations +@findex No_Implicit_Heap_Allocations +[RM D.7] No constructs are allowed to cause implicit heap allocation. + +@node No_Implicit_Loops +@unnumberedsubsec No_Implicit_Loops +@findex No_Implicit_Loops +[GNAT] This restriction ensures that the generated code does not contain any +implicit @code{for} loops, either by modifying +the generated code where possible, +or by rejecting any construct that would otherwise generate an implicit +@code{for} loop. If this restriction is active, it is possible to build +large array aggregates with all static components without generating an +intermediate temporary, and without generating a loop to initialize individual +components. Otherwise, a loop is created for arrays larger than about 5000 +scalar components. + +@node No_Initialize_Scalars +@unnumberedsubsec No_Initialize_Scalars +@findex No_Initialize_Scalars +[GNAT] This restriction ensures that no unit in the partition is compiled with +pragma Initialize_Scalars. This allows the generation of more efficient +code, and in particular eliminates dummy null initialization routines that +are otherwise generated for some record and array types. + +@node No_IO +@unnumberedsubsec No_IO +@findex No_IO +[RM H.4] This restriction ensures at compile time that there are no +dependences on any of the library units Sequential_IO, Direct_IO, +Text_IO, Wide_Text_IO, Wide_Wide_Text_IO, or Stream_IO. + +@node No_Local_Allocators +@unnumberedsubsec No_Local_Allocators +@findex No_Local_Allocators +[RM H.4] This restriction ensures at compile time that there are no +occurrences of an allocator in subprograms, generic subprograms, tasks, +and entry bodies. + +@node No_Local_Protected_Objects +@unnumberedsubsec No_Local_Protected_Objects +@findex No_Local_Protected_Objects +[RM D.7] This restriction ensures at compile time that protected objects are +only declared at the library level. + +@node No_Local_Timing_Events +@unnumberedsubsec No_Local_Timing_Events +@findex No_Local_Timing_Events +[RM D.7] All objects of type Ada.Timing_Events.Timing_Event are +declared at the library level. + +@node No_Nested_Finalization +@unnumberedsubsec No_Nested_Finalization +@findex No_Nested_Finalization +[RM D.7] All objects requiring finalization are declared at the library level. + +@node No_Protected_Type_Allocators +@unnumberedsubsec No_Protected_Type_Allocators +@findex No_Protected_Type_Allocators +[RM D.7] This restriction ensures at compile time that there are no allocator +expressions that attempt to allocate protected objects. + +@node No_Protected_Types +@unnumberedsubsec No_Protected_Types +@findex No_Protected_Types +[RM H.4] This restriction ensures at compile time that there are no +declarations of protected types or protected objects. + +@node No_Relative_Delay +@unnumberedsubsec No_Relative_Delay +@findex No_Relative_Delay +[RM D.7] This restriction ensures at compile time that there are no delay +relative statements and prevents expressions such as @code{delay 1.23;} from +appearing in source code. + +@node No_Requeue_Statements +@unnumberedsubsec No_Requeue_Statements +@findex No_Requeue_Statements +[RM D.7] This restriction ensures at compile time that no requeue statements +are permitted and prevents keyword @code{requeue} from being used in source +code. + +@node No_Secondary_Stack +@unnumberedsubsec No_Secondary_Stack +@findex No_Secondary_Stack +[GNAT] This restriction ensures at compile time that the generated code +does not contain any reference to the secondary stack. The secondary +stack is used to implement functions returning unconstrained objects +(arrays or records) on some targets. + +@node No_Select_Statements +@unnumberedsubsec No_Select_Statements +@findex No_Select_Statements +[RM D.7] This restriction ensures at compile time no select statements of any +kind are permitted, that is the keyword @code{select} may not appear. + +@node No_Specific_Termination_Handlers +@unnumberedsubsec No_Specific_Termination_Handlers +@findex No_Specific_Termination_Handlers +[RM D.7] There are no calls to Ada.Task_Termination.Set_Specific_Handler +or to Ada.Task_Termination.Specific_Handler. + +@node No_Specification_of_Aspect +@unnumberedsubsec No_Specification_of_Aspect +@findex No_Specification_of_Aspect +[RM 13.12.1] This restriction checks at compile time that no aspect +specification, attribute definition clause, or pragma is given for a +given aspect. + +@node No_Standard_Allocators_After_Elaboration +@unnumberedsubsec No_Standard_Allocators_After_Elaboration +@findex No_Standard_Allocators_After_Elaboration +[RM D.7] Specifies that an allocator using a standard storage pool +should never be evaluated at run time after the elaboration of the +library items of the partition has completed. Otherwise, Storage_Error +is raised. + +@node No_Standard_Storage_Pools +@unnumberedsubsec No_Standard_Storage_Pools +@findex No_Standard_Storage_Pools +[GNAT] This restriction ensures at compile time that no access types +use the standard default storage pool. Any access type declared must +have an explicit Storage_Pool attribute defined specifying a +user-defined storage pool. + +@node No_Stream_Optimizations +@unnumberedsubsec No_Stream_Optimizations +@findex No_Stream_Optimizations +[GNAT] This restriction affects the performance of stream operations on types +@code{String}, @code{Wide_String} and @code{Wide_Wide_String}. By default, the +compiler uses block reads and writes when manipulating @code{String} objects +due to their supperior performance. When this restriction is in effect, the +compiler performs all IO operations on a per-character basis. + +@node No_Streams +@unnumberedsubsec No_Streams +@findex No_Streams +[GNAT] This restriction ensures at compile/bind time that there are no +stream objects created and no use of stream attributes. +This restriction does not forbid dependences on the package +@code{Ada.Streams}. So it is permissible to with +@code{Ada.Streams} (or another package that does so itself) +as long as no actual stream objects are created and no +stream attributes are used. + +Note that the use of restriction allows optimization of tagged types, +since they do not need to worry about dispatching stream operations. +To take maximum advantage of this space-saving optimization, any +unit declaring a tagged type should be compiled with the restriction, +though this is not required. + +@node No_Task_Allocators +@unnumberedsubsec No_Task_Allocators +@findex No_Task_Allocators +[RM D.7] There are no allocators for task types +or types containing task subcomponents. + +@node No_Task_Attributes_Package +@unnumberedsubsec No_Task_Attributes_Package +@findex No_Task_Attributes_Package +[GNAT] This restriction ensures at compile time that there are no implicit or +explicit dependencies on the package @code{Ada.Task_Attributes}. + +@node No_Task_Hierarchy +@unnumberedsubsec No_Task_Hierarchy +@findex No_Task_Hierarchy +[RM D.7] All (non-environment) tasks depend +directly on the environment task of the partition. + +@node No_Tasking +@unnumberedsubsec No_Tasking +@findex No_Tasking +[GNAT] This restriction prevents the declaration of tasks or task types +throughout the partition. It is similar in effect to the use of +@code{Max_Tasks => 0} except that violations are caught at compile time +and cause an error message to be output either by the compiler or +binder. + +@node No_Terminate_Alternatives +@unnumberedsubsec No_Terminate_Alternatives +@findex No_Terminate_Alternatives +[RM D.7] There are no selective accepts with terminate alternatives. + +@node No_Unchecked_Access +@unnumberedsubsec No_Unchecked_Access +@findex No_Unchecked_Access +[RM H.4] This restriction ensures at compile time that there are no +occurrences of the Unchecked_Access attribute. + +@node Simple_Barriers +@unnumberedsubsec Simple_Barriers +@findex Simple_Barriers +[RM D.7] This restriction ensures at compile time that barriers in entry +declarations for protected types are restricted to either static boolean +expressions or references to simple boolean variables defined in the private +part of the protected type. No other form of entry barriers is permitted. + +@node Static_Priorities +@unnumberedsubsec Static_Priorities +@findex Static_Priorities +[GNAT] This restriction ensures at compile time that all priority expressions +are static, and that there are no dependences on the package +@code{Ada.Dynamic_Priorities}. + +@node Static_Storage_Size +@unnumberedsubsec Static_Storage_Size +@findex Static_Storage_Size +[GNAT] This restriction ensures at compile time that any expression appearing +in a Storage_Size pragma or attribute definition clause is static. + +@node Unit-Level Restrictions +@section Unit-Level Restrictions + +@noindent +The second set of restriction identifiers +does not require partition-wide consistency. +The restriction may be enforced for a single +compilation unit without any effect on any of the +other compilation units in the partition. + +@menu +* No_Elaboration_Code:: +* No_Entry_Queue:: +* No_Implementation_Aspect_Specifications:: +* No_Implementation_Attributes:: +* No_Implementation_Identifiers:: +* No_Implementation_Pragmas:: +* No_Implementation_Restrictions:: +* No_Implementation_Units:: +* No_Implicit_Aliasing:: +* No_Obsolescent_Features:: +* No_Recursion:: +* No_Reentrancy:: +* No_Wide_Characters:: +* SPARK:: +* No_Task_Termination:: +@end menu + +@node No_Elaboration_Code +@unnumberedsubsec No_Elaboration_Code +@findex No_Elaboration_Code +[GNAT] This restriction ensures at compile time that no elaboration code is +generated. Note that this is not the same condition as is enforced +by pragma @code{Preelaborate}. There are cases in which pragma +@code{Preelaborate} still permits code to be generated (e.g.@: code +to initialize a large array to all zeroes), and there are cases of units +which do not meet the requirements for pragma @code{Preelaborate}, +but for which no elaboration code is generated. Generally, it is +the case that preelaborable units will meet the restrictions, with +the exception of large aggregates initialized with an others_clause, +and exception declarations (which generate calls to a run-time +registry procedure). This restriction is enforced on +a unit by unit basis, it need not be obeyed consistently +throughout a partition. + +In the case of aggregates with others, if the aggregate has a dynamic +size, there is no way to eliminate the elaboration code (such dynamic +bounds would be incompatible with @code{Preelaborate} in any case). If +the bounds are static, then use of this restriction actually modifies +the code choice of the compiler to avoid generating a loop, and instead +generate the aggregate statically if possible, no matter how many times +the data for the others clause must be repeatedly generated. + +It is not possible to precisely document +the constructs which are compatible with this restriction, since, +unlike most other restrictions, this is not a restriction on the +source code, but a restriction on the generated object code. For +example, if the source contains a declaration: + +@smallexample + Val : constant Integer := X; +@end smallexample + +@noindent +where X is not a static constant, it may be possible, depending +on complex optimization circuitry, for the compiler to figure +out the value of X at compile time, in which case this initialization +can be done by the loader, and requires no initialization code. It +is not possible to document the precise conditions under which the +optimizer can figure this out. + +Note that this the implementation of this restriction requires full +code generation. If it is used in conjunction with "semantics only" +checking, then some cases of violations may be missed. + +@node No_Entry_Queue +@unnumberedsubsec No_Entry_Queue +@findex No_Entry_Queue +[GNAT] This restriction is a declaration that any protected entry compiled in +the scope of the restriction has at most one task waiting on the entry +at any one time, and so no queue is required. This restriction is not +checked at compile time. A program execution is erroneous if an attempt +is made to queue a second task on such an entry. + +@node No_Implementation_Aspect_Specifications +@unnumberedsubsec No_Implementation_Aspect_Specifications +@findex No_Implementation_Aspect_Specifications +[RM 13.12.1] This restriction checks at compile time that no +GNAT-defined aspects are present. With this restriction, the only +aspects that can be used are those defined in the Ada Reference Manual. + +@node No_Implementation_Attributes +@unnumberedsubsec No_Implementation_Attributes +@findex No_Implementation_Attributes +[RM 13.12.1] This restriction checks at compile time that no +GNAT-defined attributes are present. With this restriction, the only +attributes that can be used are those defined in the Ada Reference +Manual. + +@node No_Implementation_Identifiers +@unnumberedsubsec No_Implementation_Identifiers +@findex No_Implementation_Identifiers +[RM 13.12.1] This restriction checks at compile time that no +implementation-defined identifiers occur within language-defined +packages. + +@node No_Implementation_Pragmas +@unnumberedsubsec No_Implementation_Pragmas +@findex No_Implementation_Pragmas +[RM 13.12.1] This restriction checks at compile time that no +GNAT-defined pragmas are present. With this restriction, the only +pragmas that can be used are those defined in the Ada Reference Manual. + +@node No_Implementation_Restrictions +@unnumberedsubsec No_Implementation_Restrictions +@findex No_Implementation_Restrictions +[GNAT] This restriction checks at compile time that no GNAT-defined restriction +identifiers (other than @code{No_Implementation_Restrictions} itself) +are present. With this restriction, the only other restriction identifiers +that can be used are those defined in the Ada Reference Manual. + +@node No_Implementation_Units +@unnumberedsubsec No_Implementation_Units +@findex No_Implementation_Units +[RM 13.12.1] This restriction checks at compile time that there is no +mention in the context clause of any implementation-defined descendants +of packages Ada, Interfaces, or System. + +@node No_Implicit_Aliasing +@unnumberedsubsec No_Implicit_Aliasing +@findex No_Implicit_Aliasing +[GNAT] This restriction, which is not required to be partition-wide consistent, +requires an explicit aliased keyword for an object to which 'Access, +'Unchecked_Access, or 'Address is applied, and forbids entirely the use of +the 'Unrestricted_Access attribute for objects. Note: the reason that +Unrestricted_Access is forbidden is that it would require the prefix +to be aliased, and in such cases, it can always be replaced by +the standard attribute Unchecked_Access which is preferable. + +@node No_Obsolescent_Features +@unnumberedsubsec No_Obsolescent_Features +@findex No_Obsolescent_Features +[RM 13.12.1] This restriction checks at compile time that no obsolescent +features are used, as defined in Annex J of the Ada Reference Manual. + +@node No_Recursion +@unnumberedsubsec No_Recursion +@findex No_Recursion +[RM H.4] A program execution is erroneous if a subprogram is invoked as +part of its execution. + +@node No_Reentrancy +@unnumberedsubsec No_Reentrancy +@findex No_Reentrancy +[RM H.4] A program execution is erroneous if a subprogram is executed by +two tasks at the same time. + +@node No_Wide_Characters +@unnumberedsubsec No_Wide_Characters +@findex No_Wide_Characters +[GNAT] This restriction ensures at compile time that no uses of the types +@code{Wide_Character} or @code{Wide_String} or corresponding wide +wide types +appear, and that no wide or wide wide string or character literals +appear in the program (that is literals representing characters not in +type @code{Character}. + +@node SPARK +@unnumberedsubsec SPARK +@findex SPARK +[GNAT] This restriction checks at compile time that some constructs +forbidden in SPARK are not present. The SPARK version used as a +reference is the same as the Ada mode for the unit, so a unit compiled +in Ada 95 mode with SPARK restrictions will be checked for constructs +forbidden in SPARK 95. Error messages related to SPARK restriction have +the form: + +@smallexample +violation of restriction "SPARK" at + +@end smallexample + +This is not a replacement for the semantic checks performed by the +SPARK Examiner tool, as the compiler only deals currently with code, +not at all with SPARK annotations and does not guarantee catching all +cases of constructs forbidden by SPARK. + +Thus it may well be the case that code which +passes the compiler in SPARK mode is rejected by the SPARK Examiner, +e.g. due to the different visibility rules of the Examiner based on +SPARK @code{inherit} annotations. -@sp 1 -@cartouche -For an array @var{X}, @code{@var{X}'Address} should point at the first -component of the array, and not at the array bounds. -@end cartouche -Followed. +This restriction can be useful in providing an initial filter for +code developed using SPARK, or in examining legacy code to see how far +it is from meeting SPARK restrictions. -@sp 1 -@cartouche -The recommended level of support for the @code{Address} attribute is: +@node No_Task_Termination +@unnumberedsubsec No_Task_Termination +@findex No_Task_Termination +[RM D.7] Tasks which terminate are erroneous. -@code{@var{X}'Address} should produce a useful result if @var{X} is an -object that is aliased or of a by-reference type, or is an entity whose -@code{Address} has been specified. -@end cartouche -Followed. A valid address will be produced even if none of those -conditions have been met. If necessary, the object is forced into -memory to ensure the address is valid. +@c ------------------------ +@node Implementation Advice +@chapter Implementation Advice +@noindent +The main text of the Ada Reference Manual describes the required +behavior of all Ada compilers, and the GNAT compiler conforms to +these requirements. -@sp 1 -@cartouche -An implementation should support @code{Address} clauses for imported -subprograms. -@end cartouche -Followed. +In addition, there are sections throughout the Ada Reference Manual headed +by the phrase ``Implementation advice''. These sections are not normative, +i.e., they do not specify requirements that all compilers must +follow. Rather they provide advice on generally desirable behavior. You +may wonder why they are not requirements. The most typical answer is +that they describe behavior that seems generally desirable, but cannot +be provided on all systems, or which may be undesirable on some systems. -@sp 1 -@cartouche -Objects (including subcomponents) that are aliased or of a by-reference -type should be allocated on storage element boundaries. -@end cartouche -Followed. +As far as practical, GNAT follows the implementation advice sections in +the Ada Reference Manual. This chapter contains a table giving the +reference manual section number, paragraph number and several keywords +for each advice. Each entry consists of the text of the advice followed +by the GNAT interpretation of this advice. Most often, this simply says +``followed'', which means that GNAT follows the advice. However, in a +number of cases, GNAT deliberately deviates from this advice, in which +case the text describes what GNAT does and why. +@cindex Error detection +@unnumberedsec 1.1.3(20): Error Detection @sp 1 @cartouche -If the @code{Address} of an object is specified, or it is imported or exported, -then the implementation should not perform optimizations based on -assumptions of no aliases. +If an implementation detects the use of an unsupported Specialized Needs +Annex feature at run time, it should raise @code{Program_Error} if +feasible. @end cartouche -Followed. +Not relevant. All specialized needs annex features are either supported, +or diagnosed at compile time. -@cindex @code{Alignment} clauses -@unnumberedsec 13.3(29-35): Alignment Clauses +@cindex Child Units +@unnumberedsec 1.1.3(31): Child Units @sp 1 @cartouche -The recommended level of support for the @code{Alignment} attribute for -subtypes is: - -An implementation should support specified Alignments that are factors -and multiples of the number of storage elements per word, subject to the -following: +If an implementation wishes to provide implementation-defined +extensions to the functionality of a language-defined library unit, it +should normally do so by adding children to the library unit. @end cartouche Followed. +@cindex Bounded errors +@unnumberedsec 1.1.5(12): Bounded Errors @sp 1 @cartouche -An implementation need not support specified @code{Alignment}s for -combinations of @code{Size}s and @code{Alignment}s that cannot be easily -loaded and stored by available machine instructions. +If an implementation detects a bounded error or erroneous +execution, it should raise @code{Program_Error}. @end cartouche -Followed. +Followed in all cases in which the implementation detects a bounded +error or erroneous execution. Not all such situations are detected at +runtime. +@cindex Pragmas +@unnumberedsec 2.8(16): Pragmas @sp 1 @cartouche -An implementation need not support specified @code{Alignment}s that are -greater than the maximum @code{Alignment} the implementation ever returns by -default. +Normally, implementation-defined pragmas should have no semantic effect +for error-free programs; that is, if the implementation-defined pragmas +are removed from a working program, the program should still be legal, +and should still have the same semantics. @end cartouche -Followed. +The following implementation defined pragmas are exceptions to this +rule: -@sp 1 -@cartouche -The recommended level of support for the @code{Alignment} attribute for -objects is: +@table @code +@item Abort_Defer +Affects semantics +@item Ada_83 +Affects legality +@item Assert +Affects semantics +@item CPP_Class +Affects semantics +@item CPP_Constructor +Affects semantics +@item Debug +Affects semantics +@item Interface_Name +Affects semantics +@item Machine_Attribute +Affects semantics +@item Unimplemented_Unit +Affects legality +@item Unchecked_Union +Affects semantics +@end table -Same as above, for subtypes, but in addition: -@end cartouche -Followed. +@noindent +In each of the above cases, it is essential to the purpose of the pragma +that this advice not be followed. For details see the separate section +on implementation defined pragmas. +@unnumberedsec 2.8(17-19): Pragmas @sp 1 @cartouche -For stand-alone library-level objects of statically constrained -subtypes, the implementation should support all @code{Alignment}s -supported by the target linker. For example, page alignment is likely to -be supported for such objects, but not for subtypes. +Normally, an implementation should not define pragmas that can +make an illegal program legal, except as follows: @end cartouche -Followed. - -@cindex @code{Size} clauses -@unnumberedsec 13.3(42-43): Size Clauses @sp 1 @cartouche -The recommended level of support for the @code{Size} attribute of -objects is: - -A @code{Size} clause should be supported for an object if the specified -@code{Size} is at least as large as its subtype's @code{Size}, and -corresponds to a size in storage elements that is a multiple of the -object's @code{Alignment} (if the @code{Alignment} is nonzero). +A pragma used to complete a declaration, such as a pragma @code{Import}; @end cartouche -Followed. - -@unnumberedsec 13.3(50-56): Size Clauses @sp 1 @cartouche -If the @code{Size} of a subtype is specified, and allows for efficient -independent addressability (see 9.10) on the target architecture, then -the @code{Size} of the following objects of the subtype should equal the -@code{Size} of the subtype: - -Aliased objects (including components). +A pragma used to configure the environment by adding, removing, or +replacing @code{library_items}. @end cartouche -Followed. +See response to paragraph 16 of this same section. +@cindex Character Sets +@cindex Alternative Character Sets +@unnumberedsec 3.5.2(5): Alternative Character Sets @sp 1 @cartouche -@code{Size} clause on a composite subtype should not affect the -internal layout of components. +If an implementation supports a mode with alternative interpretations +for @code{Character} and @code{Wide_Character}, the set of graphic +characters of @code{Character} should nevertheless remain a proper +subset of the set of graphic characters of @code{Wide_Character}. Any +character set ``localizations'' should be reflected in the results of +the subprograms defined in the language-defined package +@code{Characters.Handling} (see A.3) available in such a mode. In a mode with +an alternative interpretation of @code{Character}, the implementation should +also support a corresponding change in what is a legal +@code{identifier_letter}. @end cartouche -Followed. But note that this can be overridden by use of the implementation -pragma Implicit_Packing in the case of packed arrays. +Not all wide character modes follow this advice, in particular the JIS +and IEC modes reflect standard usage in Japan, and in these encoding, +the upper half of the Latin-1 set is not part of the wide-character +subset, since the most significant bit is used for wide character +encoding. However, this only applies to the external forms. Internally +there is no such restriction. + +@cindex Integer types +@unnumberedsec 3.5.4(28): Integer Types @sp 1 @cartouche -The recommended level of support for the @code{Size} attribute of subtypes is: +An implementation should support @code{Long_Integer} in addition to +@code{Integer} if the target machine supports 32-bit (or longer) +arithmetic. No other named integer subtypes are recommended for package +@code{Standard}. Instead, appropriate named integer subtypes should be +provided in the library package @code{Interfaces} (see B.2). @end cartouche +@code{Long_Integer} is supported. Other standard integer types are supported +so this advice is not fully followed. These types +are supported for convenient interface to C, and so that all hardware +types of the machine are easily available. +@unnumberedsec 3.5.4(29): Integer Types + @sp 1 @cartouche -The @code{Size} (if not specified) of a static discrete or fixed point -subtype should be the number of bits needed to represent each value -belonging to the subtype using an unbiased representation, leaving space -for a sign bit only if the subtype contains negative values. If such a -subtype is a first subtype, then an implementation should support a -specified @code{Size} for it that reflects this representation. +An implementation for a two's complement machine should support +modular types with a binary modulus up to @code{System.Max_Int*2+2}. An +implementation should support a non-binary modules up to @code{Integer'Last}. @end cartouche Followed. +@cindex Enumeration values +@unnumberedsec 3.5.5(8): Enumeration Values @sp 1 @cartouche -For a subtype implemented with levels of indirection, the @code{Size} -should include the size of the pointers, but not the size of what they -point at. +For the evaluation of a call on @code{@var{S}'Pos} for an enumeration +subtype, if the value of the operand does not correspond to the internal +code for any enumeration literal of its type (perhaps due to an +un-initialized variable), then the implementation should raise +@code{Program_Error}. This is particularly important for enumeration +types with noncontiguous internal codes specified by an +enumeration_representation_clause. @end cartouche Followed. -@cindex @code{Component_Size} clauses -@unnumberedsec 13.3(71-73): Component Size Clauses -@sp 1 -@cartouche -The recommended level of support for the @code{Component_Size} -attribute is: -@end cartouche +@cindex Float types +@unnumberedsec 3.5.7(17): Float Types @sp 1 @cartouche -An implementation need not support specified @code{Component_Sizes} that are -less than the @code{Size} of the component subtype. +An implementation should support @code{Long_Float} in addition to +@code{Float} if the target machine supports 11 or more digits of +precision. No other named floating point subtypes are recommended for +package @code{Standard}. Instead, appropriate named floating point subtypes +should be provided in the library package @code{Interfaces} (see B.2). @end cartouche -Followed. +@code{Short_Float} and @code{Long_Long_Float} are also provided. The +former provides improved compatibility with other implementations +supporting this type. The latter corresponds to the highest precision +floating-point type supported by the hardware. On most machines, this +will be the same as @code{Long_Float}, but on some machines, it will +correspond to the IEEE extended form. The notable case is all ia32 +(x86) implementations, where @code{Long_Long_Float} corresponds to +the 80-bit extended precision format supported in hardware on this +processor. Note that the 128-bit format on SPARC is not supported, +since this is a software rather than a hardware format. +@cindex Multidimensional arrays +@cindex Arrays, multidimensional +@unnumberedsec 3.6.2(11): Multidimensional Arrays @sp 1 @cartouche -An implementation should support specified @code{Component_Size}s that -are factors and multiples of the word size. For such -@code{Component_Size}s, the array should contain no gaps between -components. For other @code{Component_Size}s (if supported), the array -should contain no gaps between components when packing is also -specified; the implementation should forbid this combination in cases -where it cannot support a no-gaps representation. +An implementation should normally represent multidimensional arrays in +row-major order, consistent with the notation used for multidimensional +array aggregates (see 4.3.3). However, if a pragma @code{Convention} +(@code{Fortran}, @dots{}) applies to a multidimensional array type, then +column-major order should be used instead (see B.5, ``Interfacing with +Fortran''). @end cartouche Followed. -@cindex Enumeration representation clauses -@cindex Representation clauses, enumeration -@unnumberedsec 13.4(9-10): Enumeration Representation Clauses +@findex Duration'Small +@unnumberedsec 9.6(30-31): Duration'Small @sp 1 @cartouche -The recommended level of support for enumeration representation clauses -is: - -An implementation need not support enumeration representation clauses -for boolean types, but should at minimum support the internal codes in -the range @code{System.Min_Int.System.Max_Int}. +Whenever possible in an implementation, the value of @code{Duration'Small} +should be no greater than 100 microseconds. @end cartouche -Followed. +Followed. (@code{Duration'Small} = 10**(@minus{}9)). -@cindex Record representation clauses -@cindex Representation clauses, records -@unnumberedsec 13.5.1(17-22): Record Representation Clauses @sp 1 @cartouche -The recommended level of support for -@*@code{record_representation_clauses} is: - -An implementation should support storage places that can be extracted -with a load, mask, shift sequence of machine code, and set with a load, -shift, mask, store sequence, given the available machine instructions -and run-time model. +The time base for @code{delay_relative_statements} should be monotonic; +it need not be the same time base as used for @code{Calendar.Clock}. @end cartouche Followed. +@unnumberedsec 10.2.1(12): Consistent Representation @sp 1 @cartouche -A storage place should be supported if its size is equal to the -@code{Size} of the component subtype, and it starts and ends on a -boundary that obeys the @code{Alignment} of the component subtype. +In an implementation, a type declared in a pre-elaborated package should +have the same representation in every elaboration of a given version of +the package, whether the elaborations occur in distinct executions of +the same program, or in executions of distinct programs or partitions +that include the given version. @end cartouche -Followed. +Followed, except in the case of tagged types. Tagged types involve +implicit pointers to a local copy of a dispatch table, and these pointers +have representations which thus depend on a particular elaboration of the +package. It is not easy to see how it would be possible to follow this +advice without severely impacting efficiency of execution. +@cindex Exception information +@unnumberedsec 11.4.1(19): Exception Information @sp 1 @cartouche -If the default bit ordering applies to the declaration of a given type, -then for a component whose subtype's @code{Size} is less than the word -size, any storage place that does not cross an aligned word boundary -should be supported. +@code{Exception_Message} by default and @code{Exception_Information} +should produce information useful for +debugging. @code{Exception_Message} should be short, about one +line. @code{Exception_Information} can be long. @code{Exception_Message} +should not include the +@code{Exception_Name}. @code{Exception_Information} should include both +the @code{Exception_Name} and the @code{Exception_Message}. @end cartouche -Followed. +Followed. For each exception that doesn't have a specified +@code{Exception_Message}, the compiler generates one containing the location +of the raise statement. This location has the form ``file:line'', where +file is the short file name (without path information) and line is the line +number in the file. Note that in the case of the Zero Cost Exception +mechanism, these messages become redundant with the Exception_Information that +contains a full backtrace of the calling sequence, so they are disabled. +To disable explicitly the generation of the source location message, use the +Pragma @code{Discard_Names}. +@cindex Suppression of checks +@cindex Checks, suppression of +@unnumberedsec 11.5(28): Suppression of Checks @sp 1 @cartouche -An implementation may reserve a storage place for the tag field of a -tagged type, and disallow other components from overlapping that place. +The implementation should minimize the code executed for checks that +have been suppressed. @end cartouche -Followed. The storage place for the tag field is the beginning of the tagged -record, and its size is Address'Size. GNAT will reject an explicit component -clause for the tag field. +Followed. +@cindex Representation clauses +@unnumberedsec 13.1 (21-24): Representation Clauses @sp 1 @cartouche -An implementation need not support a @code{component_clause} for a -component of an extension part if the storage place is not after the -storage places of all components of the parent type, whether or not -those storage places had been specified. +The recommended level of support for all representation items is +qualified as follows: @end cartouche -Followed. The above advice on record representation clauses is followed, -and all mentioned features are implemented. - -@cindex Storage place attributes -@unnumberedsec 13.5.2(5): Storage Place Attributes @sp 1 @cartouche -If a component is represented using some form of pointer (such as an -offset) to the actual data of the component, and this data is contiguous -with the rest of the object, then the storage place attributes should -reflect the place of the actual data, not the pointer. If a component is -allocated discontinuously from the rest of the object, then a warning -should be generated upon reference to one of its storage place -attributes. +An implementation need not support representation items containing +non-static expressions, except that an implementation should support a +representation item for a given entity if each non-static expression in +the representation item is a name that statically denotes a constant +declared before the entity. @end cartouche -Followed. There are no such components in GNAT@. +Followed. In fact, GNAT goes beyond the recommended level of support +by allowing nonstatic expressions in some representation clauses even +without the need to declare constants initialized with the values of +such expressions. +For example: + +@smallexample @c ada + X : Integer; + Y : Float; + for Y'Address use X'Address;>> +@end smallexample -@cindex Bit ordering -@unnumberedsec 13.5.3(7-8): Bit Ordering @sp 1 @cartouche -The recommended level of support for the non-default bit ordering is: +An implementation need not support a specification for the @code{Size} +for a given composite subtype, nor the size or storage place for an +object (including a component) of a given composite subtype, unless the +constraints on the subtype and its composite subcomponents (if any) are +all static constraints. @end cartouche +Followed. Size Clauses are not permitted on non-static components, as +described above. + @sp 1 @cartouche -If @code{Word_Size} = @code{Storage_Unit}, then the implementation -should support the non-default bit ordering in addition to the default -bit ordering. +An aliased component, or a component whose type is by-reference, should +always be allocated at an addressable location. @end cartouche -Followed. Word size does not equal storage size in this implementation. -Thus non-default bit ordering is not supported. +Followed. -@cindex @code{Address}, as private type -@unnumberedsec 13.7(37): Address as Private +@cindex Packed types +@unnumberedsec 13.2(6-8): Packed Types @sp 1 @cartouche -@code{Address} should be of a private type. +If a type is packed, then the implementation should try to minimize +storage allocated to objects of the type, possibly at the expense of +speed of accessing components, subject to reasonable complexity in +addressing calculations. @end cartouche -Followed. - -@cindex Operations, on @code{Address} -@cindex @code{Address}, operations of -@unnumberedsec 13.7.1(16): Address Operations @sp 1 @cartouche -Operations in @code{System} and its children should reflect the target -environment semantics as closely as is reasonable. For example, on most -machines, it makes sense for address arithmetic to ``wrap around''. -Operations that do not make sense should raise @code{Program_Error}. +The recommended level of support pragma @code{Pack} is: + +For a packed record type, the components should be packed as tightly as +possible subject to the Sizes of the component subtypes, and subject to +any @code{record_representation_clause} that applies to the type; the +implementation may, but need not, reorder components or cross aligned +word boundaries to improve the packing. A component whose @code{Size} is +greater than the word size may be allocated an integral number of words. @end cartouche -Followed. Address arithmetic is modular arithmetic that wraps around. No -operation raises @code{Program_Error}, since all operations make sense. +Followed. Tight packing of arrays is supported for all component sizes +up to 64-bits. If the array component size is 1 (that is to say, if +the component is a boolean type or an enumeration type with two values) +then values of the type are implicitly initialized to zero. This +happens both for objects of the packed type, and for objects that have a +subcomponent of the packed type. -@cindex Unchecked conversion -@unnumberedsec 13.9(14-17): Unchecked Conversion @sp 1 @cartouche -The @code{Size} of an array object should not include its bounds; hence, -the bounds should not be part of the converted data. +An implementation should support Address clauses for imported +subprograms. @end cartouche Followed. +@cindex @code{Address} clauses +@unnumberedsec 13.3(14-19): Address Clauses @sp 1 @cartouche -The implementation should not generate unnecessary run-time checks to -ensure that the representation of @var{S} is a representation of the -target type. It should take advantage of the permission to return by -reference when possible. Restrictions on unchecked conversions should be -avoided unless required by the target environment. +For an array @var{X}, @code{@var{X}'Address} should point at the first +component of the array, and not at the array bounds. @end cartouche -Followed. There are no restrictions on unchecked conversion. A warning is -generated if the source and target types do not have the same size since -the semantics in this case may be target dependent. +Followed. @sp 1 @cartouche -The recommended level of support for unchecked conversions is: +The recommended level of support for the @code{Address} attribute is: + +@code{@var{X}'Address} should produce a useful result if @var{X} is an +object that is aliased or of a by-reference type, or is an entity whose +@code{Address} has been specified. @end cartouche +Followed. A valid address will be produced even if none of those +conditions have been met. If necessary, the object is forced into +memory to ensure the address is valid. + @sp 1 @cartouche -Unchecked conversions should be supported and should be reversible in -the cases where this clause defines the result. To enable meaningful use -of unchecked conversion, a contiguous representation should be used for -elementary subtypes, for statically constrained array subtypes whose -component subtype is one of the subtypes described in this paragraph, -and for record subtypes without discriminants whose component subtypes -are described in this paragraph. +An implementation should support @code{Address} clauses for imported +subprograms. @end cartouche Followed. -@cindex Heap usage, implicit -@unnumberedsec 13.11(23-25): Implicit Heap Usage @sp 1 @cartouche -An implementation should document any cases in which it dynamically -allocates heap storage for a purpose other than the evaluation of an -allocator. +Objects (including subcomponents) that are aliased or of a by-reference +type should be allocated on storage element boundaries. @end cartouche -Followed, the only other points at which heap storage is dynamically -allocated are as follows: - -@itemize @bullet -@item -At initial elaboration time, to allocate dynamically sized global -objects. - -@item -To allocate space for a task when a task is created. - -@item -To extend the secondary stack dynamically when needed. The secondary -stack is used for returning variable length results. -@end itemize +Followed. @sp 1 @cartouche -A default (implementation-provided) storage pool for an -access-to-constant type should not have overhead to support deallocation of -individual objects. +If the @code{Address} of an object is specified, or it is imported or exported, +then the implementation should not perform optimizations based on +assumptions of no aliases. @end cartouche Followed. +@cindex @code{Alignment} clauses +@unnumberedsec 13.3(29-35): Alignment Clauses @sp 1 @cartouche -A storage pool for an anonymous access type should be created at the -point of an allocator for the type, and be reclaimed when the designated -object becomes inaccessible. +The recommended level of support for the @code{Alignment} attribute for +subtypes is: + +An implementation should support specified Alignments that are factors +and multiples of the number of storage elements per word, subject to the +following: @end cartouche Followed. -@cindex Unchecked deallocation -@unnumberedsec 13.11.2(17): Unchecked De-allocation @sp 1 @cartouche -For a standard storage pool, @code{Free} should actually reclaim the -storage. +An implementation need not support specified @code{Alignment}s for +combinations of @code{Size}s and @code{Alignment}s that cannot be easily +loaded and stored by available machine instructions. @end cartouche Followed. -@cindex Stream oriented attributes -@unnumberedsec 13.13.2(17): Stream Oriented Attributes @sp 1 @cartouche -If a stream element is the same size as a storage element, then the -normal in-memory representation should be used by @code{Read} and -@code{Write} for scalar objects. Otherwise, @code{Read} and @code{Write} -should use the smallest number of stream elements needed to represent -all values in the base range of the scalar type. +An implementation need not support specified @code{Alignment}s that are +greater than the maximum @code{Alignment} the implementation ever returns by +default. @end cartouche +Followed. -Followed. By default, GNAT uses the interpretation suggested by AI-195, -which specifies using the size of the first subtype. -However, such an implementation is based on direct binary -representations and is therefore target- and endianness-dependent. -To address this issue, GNAT also supplies an alternate implementation -of the stream attributes @code{Read} and @code{Write}, -which uses the target-independent XDR standard representation -for scalar types. -@cindex XDR representation -@cindex @code{Read} attribute -@cindex @code{Write} attribute -@cindex Stream oriented attributes -The XDR implementation is provided as an alternative body of the -@code{System.Stream_Attributes} package, in the file -@file{s-stratt-xdr.adb} in the GNAT library. -There is no @file{s-stratt-xdr.ads} file. -In order to install the XDR implementation, do the following: -@enumerate -@item Replace the default implementation of the -@code{System.Stream_Attributes} package with the XDR implementation. -For example on a Unix platform issue the commands: -@smallexample -$ mv s-stratt.adb s-stratt-default.adb -$ mv s-stratt-xdr.adb s-stratt.adb -@end smallexample - -@item -Rebuild the GNAT run-time library as documented in -@ref{GNAT and Libraries,,, gnat_ugn, @value{EDITION} User's Guide}. -@end enumerate - -@unnumberedsec A.1(52): Names of Predefined Numeric Types @sp 1 @cartouche -If an implementation provides additional named predefined integer types, -then the names should end with @samp{Integer} as in -@samp{Long_Integer}. If an implementation provides additional named -predefined floating point types, then the names should end with -@samp{Float} as in @samp{Long_Float}. +The recommended level of support for the @code{Alignment} attribute for +objects is: + +Same as above, for subtypes, but in addition: @end cartouche Followed. -@findex Ada.Characters.Handling -@unnumberedsec A.3.2(49): @code{Ada.Characters.Handling} @sp 1 @cartouche -If an implementation provides a localized definition of @code{Character} -or @code{Wide_Character}, then the effects of the subprograms in -@code{Characters.Handling} should reflect the localizations. See also -3.5.2. +For stand-alone library-level objects of statically constrained +subtypes, the implementation should support all @code{Alignment}s +supported by the target linker. For example, page alignment is likely to +be supported for such objects, but not for subtypes. @end cartouche -Followed. GNAT provides no such localized definitions. +Followed. -@cindex Bounded-length strings -@unnumberedsec A.4.4(106): Bounded-Length String Handling +@cindex @code{Size} clauses +@unnumberedsec 13.3(42-43): Size Clauses @sp 1 @cartouche -Bounded string objects should not be implemented by implicit pointers -and dynamic allocation. -@end cartouche -Followed. No implicit pointers or dynamic allocation are used. +The recommended level of support for the @code{Size} attribute of +objects is: -@cindex Random number generation -@unnumberedsec A.5.2(46-47): Random Number Generation -@sp 1 -@cartouche -Any storage associated with an object of type @code{Generator} should be -reclaimed on exit from the scope of the object. +A @code{Size} clause should be supported for an object if the specified +@code{Size} is at least as large as its subtype's @code{Size}, and +corresponds to a size in storage elements that is a multiple of the +object's @code{Alignment} (if the @code{Alignment} is nonzero). @end cartouche Followed. +@unnumberedsec 13.3(50-56): Size Clauses @sp 1 @cartouche -If the generator period is sufficiently long in relation to the number -of distinct initiator values, then each possible value of -@code{Initiator} passed to @code{Reset} should initiate a sequence of -random numbers that does not, in a practical sense, overlap the sequence -initiated by any other value. If this is not possible, then the mapping -between initiator values and generator states should be a rapidly -varying function of the initiator value. -@end cartouche -Followed. The generator period is sufficiently long for the first -condition here to hold true. +If the @code{Size} of a subtype is specified, and allows for efficient +independent addressability (see 9.10) on the target architecture, then +the @code{Size} of the following objects of the subtype should equal the +@code{Size} of the subtype: -@findex Get_Immediate -@unnumberedsec A.10.7(23): @code{Get_Immediate} -@sp 1 -@cartouche -The @code{Get_Immediate} procedures should be implemented with -unbuffered input. For a device such as a keyboard, input should be -@dfn{available} if a key has already been typed, whereas for a disk -file, input should always be available except at end of file. For a file -associated with a keyboard-like device, any line-editing features of the -underlying operating system should be disabled during the execution of -@code{Get_Immediate}. +Aliased objects (including components). @end cartouche -Followed on all targets except VxWorks. For VxWorks, there is no way to -provide this functionality that does not result in the input buffer being -flushed before the @code{Get_Immediate} call. A special unit -@code{Interfaces.Vxworks.IO} is provided that contains routines to enable -this functionality. +Followed. -@findex Export -@unnumberedsec B.1(39-41): Pragma @code{Export} @sp 1 @cartouche -If an implementation supports pragma @code{Export} to a given language, -then it should also allow the main subprogram to be written in that -language. It should support some mechanism for invoking the elaboration -of the Ada library units included in the system, and for invoking the -finalization of the environment task. On typical systems, the -recommended mechanism is to provide two subprograms whose link names are -@code{adainit} and @code{adafinal}. @code{adainit} should contain the -elaboration code for library units. @code{adafinal} should contain the -finalization code. These subprograms should have no effect the second -and subsequent time they are called. +@code{Size} clause on a composite subtype should not affect the +internal layout of components. @end cartouche -Followed. +Followed. But note that this can be overridden by use of the implementation +pragma Implicit_Packing in the case of packed arrays. @sp 1 @cartouche -Automatic elaboration of pre-elaborated packages should be -provided when pragma @code{Export} is supported. +The recommended level of support for the @code{Size} attribute of subtypes is: @end cartouche -Followed when the main program is in Ada. If the main program is in a -foreign language, then -@code{adainit} must be called to elaborate pre-elaborated -packages. - @sp 1 @cartouche -For each supported convention @var{L} other than @code{Intrinsic}, an -implementation should support @code{Import} and @code{Export} pragmas -for objects of @var{L}-compatible types and for subprograms, and pragma -@code{Convention} for @var{L}-eligible types and for subprograms, -presuming the other language has corresponding features. Pragma -@code{Convention} need not be supported for scalar types. +The @code{Size} (if not specified) of a static discrete or fixed point +subtype should be the number of bits needed to represent each value +belonging to the subtype using an unbiased representation, leaving space +for a sign bit only if the subtype contains negative values. If such a +subtype is a first subtype, then an implementation should support a +specified @code{Size} for it that reflects this representation. @end cartouche Followed. -@cindex Package @code{Interfaces} -@findex Interfaces -@unnumberedsec B.2(12-13): Package @code{Interfaces} @sp 1 @cartouche -For each implementation-defined convention identifier, there should be a -child package of package Interfaces with the corresponding name. This -package should contain any declarations that would be useful for -interfacing to the language (implementation) represented by the -convention. Any declarations useful for interfacing to any language on -the given hardware architecture should be provided directly in -@code{Interfaces}. +For a subtype implemented with levels of indirection, the @code{Size} +should include the size of the pointers, but not the size of what they +point at. @end cartouche -Followed. An additional package not defined -in the Ada Reference Manual is @code{Interfaces.CPP}, used -for interfacing to C++. +Followed. +@cindex @code{Component_Size} clauses +@unnumberedsec 13.3(71-73): Component Size Clauses @sp 1 @cartouche -An implementation supporting an interface to C, COBOL, or Fortran should -provide the corresponding package or packages described in the following -clauses. +The recommended level of support for the @code{Component_Size} +attribute is: @end cartouche -Followed. GNAT provides all the packages described in this section. - -@cindex C, interfacing with -@unnumberedsec B.3(63-71): Interfacing with C @sp 1 @cartouche -An implementation should support the following interface correspondences -between Ada and C@. +An implementation need not support specified @code{Component_Sizes} that are +less than the @code{Size} of the component subtype. @end cartouche Followed. @sp 1 @cartouche -An Ada procedure corresponds to a void-returning C function. +An implementation should support specified @code{Component_Size}s that +are factors and multiples of the word size. For such +@code{Component_Size}s, the array should contain no gaps between +components. For other @code{Component_Size}s (if supported), the array +should contain no gaps between components when packing is also +specified; the implementation should forbid this combination in cases +where it cannot support a no-gaps representation. @end cartouche Followed. +@cindex Enumeration representation clauses +@cindex Representation clauses, enumeration +@unnumberedsec 13.4(9-10): Enumeration Representation Clauses @sp 1 @cartouche -An Ada function corresponds to a non-void C function. +The recommended level of support for enumeration representation clauses +is: + +An implementation need not support enumeration representation clauses +for boolean types, but should at minimum support the internal codes in +the range @code{System.Min_Int.System.Max_Int}. @end cartouche Followed. +@cindex Record representation clauses +@cindex Representation clauses, records +@unnumberedsec 13.5.1(17-22): Record Representation Clauses @sp 1 @cartouche -An Ada @code{in} scalar parameter is passed as a scalar argument to a C -function. +The recommended level of support for +@*@code{record_representation_clauses} is: + +An implementation should support storage places that can be extracted +with a load, mask, shift sequence of machine code, and set with a load, +shift, mask, store sequence, given the available machine instructions +and run-time model. @end cartouche Followed. @sp 1 @cartouche -An Ada @code{in} parameter of an access-to-object type with designated -type @var{T} is passed as a @code{@var{t}*} argument to a C function, -where @var{t} is the C type corresponding to the Ada type @var{T}. +A storage place should be supported if its size is equal to the +@code{Size} of the component subtype, and it starts and ends on a +boundary that obeys the @code{Alignment} of the component subtype. @end cartouche Followed. @sp 1 @cartouche -An Ada access @var{T} parameter, or an Ada @code{out} or @code{in out} -parameter of an elementary type @var{T}, is passed as a @code{@var{t}*} -argument to a C function, where @var{t} is the C type corresponding to -the Ada type @var{T}. In the case of an elementary @code{out} or -@code{in out} parameter, a pointer to a temporary copy is used to -preserve by-copy semantics. +If the default bit ordering applies to the declaration of a given type, +then for a component whose subtype's @code{Size} is less than the word +size, any storage place that does not cross an aligned word boundary +should be supported. @end cartouche Followed. @sp 1 @cartouche -An Ada parameter of a record type @var{T}, of any mode, is passed as a -@code{@var{t}*} argument to a C function, where @var{t} is the C -structure corresponding to the Ada type @var{T}. +An implementation may reserve a storage place for the tag field of a +tagged type, and disallow other components from overlapping that place. @end cartouche -Followed. This convention may be overridden by the use of the C_Pass_By_Copy -pragma, or Convention, or by explicitly specifying the mechanism for a given -call using an extended import or export pragma. +Followed. The storage place for the tag field is the beginning of the tagged +record, and its size is Address'Size. GNAT will reject an explicit component +clause for the tag field. @sp 1 @cartouche -An Ada parameter of an array type with component type @var{T}, of any -mode, is passed as a @code{@var{t}*} argument to a C function, where -@var{t} is the C type corresponding to the Ada type @var{T}. +An implementation need not support a @code{component_clause} for a +component of an extension part if the storage place is not after the +storage places of all components of the parent type, whether or not +those storage places had been specified. @end cartouche -Followed. +Followed. The above advice on record representation clauses is followed, +and all mentioned features are implemented. +@cindex Storage place attributes +@unnumberedsec 13.5.2(5): Storage Place Attributes @sp 1 @cartouche -An Ada parameter of an access-to-subprogram type is passed as a pointer -to a C function whose prototype corresponds to the designated -subprogram's specification. +If a component is represented using some form of pointer (such as an +offset) to the actual data of the component, and this data is contiguous +with the rest of the object, then the storage place attributes should +reflect the place of the actual data, not the pointer. If a component is +allocated discontinuously from the rest of the object, then a warning +should be generated upon reference to one of its storage place +attributes. @end cartouche -Followed. +Followed. There are no such components in GNAT@. -@cindex COBOL, interfacing with -@unnumberedsec B.4(95-98): Interfacing with COBOL +@cindex Bit ordering +@unnumberedsec 13.5.3(7-8): Bit Ordering @sp 1 @cartouche -An Ada implementation should support the following interface -correspondences between Ada and COBOL@. +The recommended level of support for the non-default bit ordering is: @end cartouche -Followed. - @sp 1 @cartouche -An Ada access @var{T} parameter is passed as a @samp{BY REFERENCE} data item of -the COBOL type corresponding to @var{T}. +If @code{Word_Size} = @code{Storage_Unit}, then the implementation +should support the non-default bit ordering in addition to the default +bit ordering. @end cartouche -Followed. +Followed. Word size does not equal storage size in this implementation. +Thus non-default bit ordering is not supported. +@cindex @code{Address}, as private type +@unnumberedsec 13.7(37): Address as Private @sp 1 @cartouche -An Ada in scalar parameter is passed as a @samp{BY CONTENT} data item of -the corresponding COBOL type. +@code{Address} should be of a private type. @end cartouche Followed. +@cindex Operations, on @code{Address} +@cindex @code{Address}, operations of +@unnumberedsec 13.7.1(16): Address Operations @sp 1 @cartouche -Any other Ada parameter is passed as a @samp{BY REFERENCE} data item of the -COBOL type corresponding to the Ada parameter type; for scalars, a local -copy is used if necessary to ensure by-copy semantics. +Operations in @code{System} and its children should reflect the target +environment semantics as closely as is reasonable. For example, on most +machines, it makes sense for address arithmetic to ``wrap around''. +Operations that do not make sense should raise @code{Program_Error}. @end cartouche -Followed. +Followed. Address arithmetic is modular arithmetic that wraps around. No +operation raises @code{Program_Error}, since all operations make sense. -@cindex Fortran, interfacing with -@unnumberedsec B.5(22-26): Interfacing with Fortran +@cindex Unchecked conversion +@unnumberedsec 13.9(14-17): Unchecked Conversion @sp 1 @cartouche -An Ada implementation should support the following interface -correspondences between Ada and Fortran: +The @code{Size} of an array object should not include its bounds; hence, +the bounds should not be part of the converted data. @end cartouche Followed. @sp 1 @cartouche -An Ada procedure corresponds to a Fortran subroutine. +The implementation should not generate unnecessary run-time checks to +ensure that the representation of @var{S} is a representation of the +target type. It should take advantage of the permission to return by +reference when possible. Restrictions on unchecked conversions should be +avoided unless required by the target environment. @end cartouche -Followed. +Followed. There are no restrictions on unchecked conversion. A warning is +generated if the source and target types do not have the same size since +the semantics in this case may be target dependent. @sp 1 @cartouche -An Ada function corresponds to a Fortran function. +The recommended level of support for unchecked conversions is: @end cartouche -Followed. - @sp 1 @cartouche -An Ada parameter of an elementary, array, or record type @var{T} is -passed as a @var{T} argument to a Fortran procedure, where @var{T} is -the Fortran type corresponding to the Ada type @var{T}, and where the -INTENT attribute of the corresponding dummy argument matches the Ada -formal parameter mode; the Fortran implementation's parameter passing -conventions are used. For elementary types, a local copy is used if -necessary to ensure by-copy semantics. +Unchecked conversions should be supported and should be reversible in +the cases where this clause defines the result. To enable meaningful use +of unchecked conversion, a contiguous representation should be used for +elementary subtypes, for statically constrained array subtypes whose +component subtype is one of the subtypes described in this paragraph, +and for record subtypes without discriminants whose component subtypes +are described in this paragraph. @end cartouche Followed. +@cindex Heap usage, implicit +@unnumberedsec 13.11(23-25): Implicit Heap Usage @sp 1 @cartouche -An Ada parameter of an access-to-subprogram type is passed as a -reference to a Fortran procedure whose interface corresponds to the -designated subprogram's specification. +An implementation should document any cases in which it dynamically +allocates heap storage for a purpose other than the evaluation of an +allocator. @end cartouche -Followed. +Followed, the only other points at which heap storage is dynamically +allocated are as follows: + +@itemize @bullet +@item +At initial elaboration time, to allocate dynamically sized global +objects. + +@item +To allocate space for a task when a task is created. + +@item +To extend the secondary stack dynamically when needed. The secondary +stack is used for returning variable length results. +@end itemize -@cindex Machine operations -@unnumberedsec C.1(3-5): Access to Machine Operations @sp 1 @cartouche -The machine code or intrinsic support should allow access to all -operations normally available to assembly language programmers for the -target environment, including privileged instructions, if any. +A default (implementation-provided) storage pool for an +access-to-constant type should not have overhead to support deallocation of +individual objects. @end cartouche Followed. @sp 1 @cartouche -The interfacing pragmas (see Annex B) should support interface to -assembler; the default assembler should be associated with the -convention identifier @code{Assembler}. +A storage pool for an anonymous access type should be created at the +point of an allocator for the type, and be reclaimed when the designated +object becomes inaccessible. @end cartouche Followed. +@cindex Unchecked deallocation +@unnumberedsec 13.11.2(17): Unchecked De-allocation @sp 1 @cartouche -If an entity is exported to assembly language, then the implementation -should allocate it at an addressable location, and should ensure that it -is retained by the linking process, even if not otherwise referenced -from the Ada code. The implementation should assume that any call to a -machine code or assembler subprogram is allowed to read or update every -object that is specified as exported. +For a standard storage pool, @code{Free} should actually reclaim the +storage. @end cartouche Followed. -@unnumberedsec C.1(10-16): Access to Machine Operations +@cindex Stream oriented attributes +@unnumberedsec 13.13.2(17): Stream Oriented Attributes @sp 1 @cartouche -The implementation should ensure that little or no overhead is -associated with calling intrinsic and machine-code subprograms. +If a stream element is the same size as a storage element, then the +normal in-memory representation should be used by @code{Read} and +@code{Write} for scalar objects. Otherwise, @code{Read} and @code{Write} +should use the smallest number of stream elements needed to represent +all values in the base range of the scalar type. @end cartouche -Followed for both intrinsics and machine-code subprograms. +Followed. By default, GNAT uses the interpretation suggested by AI-195, +which specifies using the size of the first subtype. +However, such an implementation is based on direct binary +representations and is therefore target- and endianness-dependent. +To address this issue, GNAT also supplies an alternate implementation +of the stream attributes @code{Read} and @code{Write}, +which uses the target-independent XDR standard representation +for scalar types. +@cindex XDR representation +@cindex @code{Read} attribute +@cindex @code{Write} attribute +@cindex Stream oriented attributes +The XDR implementation is provided as an alternative body of the +@code{System.Stream_Attributes} package, in the file +@file{s-stratt-xdr.adb} in the GNAT library. +There is no @file{s-stratt-xdr.ads} file. +In order to install the XDR implementation, do the following: +@enumerate +@item Replace the default implementation of the +@code{System.Stream_Attributes} package with the XDR implementation. +For example on a Unix platform issue the commands: +@smallexample +$ mv s-stratt.adb s-stratt-default.adb +$ mv s-stratt-xdr.adb s-stratt.adb +@end smallexample + +@item +Rebuild the GNAT run-time library as documented in +@ref{GNAT and Libraries,,, gnat_ugn, @value{EDITION} User's Guide}. +@end enumerate + +@unnumberedsec A.1(52): Names of Predefined Numeric Types @sp 1 @cartouche -It is recommended that intrinsic subprograms be provided for convenient -access to any machine operations that provide special capabilities or -efficiency and that are not otherwise available through the language -constructs. +If an implementation provides additional named predefined integer types, +then the names should end with @samp{Integer} as in +@samp{Long_Integer}. If an implementation provides additional named +predefined floating point types, then the names should end with +@samp{Float} as in @samp{Long_Float}. @end cartouche -Followed. A full set of machine operation intrinsic subprograms is provided. +Followed. +@findex Ada.Characters.Handling +@unnumberedsec A.3.2(49): @code{Ada.Characters.Handling} @sp 1 @cartouche -Atomic read-modify-write operations---e.g.@:, test and set, compare and -swap, decrement and test, enqueue/dequeue. +If an implementation provides a localized definition of @code{Character} +or @code{Wide_Character}, then the effects of the subprograms in +@code{Characters.Handling} should reflect the localizations. See also +3.5.2. @end cartouche -Followed on any target supporting such operations. +Followed. GNAT provides no such localized definitions. +@cindex Bounded-length strings +@unnumberedsec A.4.4(106): Bounded-Length String Handling @sp 1 @cartouche -Standard numeric functions---e.g.@:, sin, log. +Bounded string objects should not be implemented by implicit pointers +and dynamic allocation. @end cartouche -Followed on any target supporting such operations. +Followed. No implicit pointers or dynamic allocation are used. +@cindex Random number generation +@unnumberedsec A.5.2(46-47): Random Number Generation @sp 1 @cartouche -String manipulation operations---e.g.@:, translate and test. +Any storage associated with an object of type @code{Generator} should be +reclaimed on exit from the scope of the object. @end cartouche -Followed on any target supporting such operations. +Followed. @sp 1 @cartouche -Vector operations---e.g.@:, compare vector against thresholds. +If the generator period is sufficiently long in relation to the number +of distinct initiator values, then each possible value of +@code{Initiator} passed to @code{Reset} should initiate a sequence of +random numbers that does not, in a practical sense, overlap the sequence +initiated by any other value. If this is not possible, then the mapping +between initiator values and generator states should be a rapidly +varying function of the initiator value. @end cartouche -Followed on any target supporting such operations. +Followed. The generator period is sufficiently long for the first +condition here to hold true. +@findex Get_Immediate +@unnumberedsec A.10.7(23): @code{Get_Immediate} @sp 1 @cartouche -Direct operations on I/O ports. +The @code{Get_Immediate} procedures should be implemented with +unbuffered input. For a device such as a keyboard, input should be +@dfn{available} if a key has already been typed, whereas for a disk +file, input should always be available except at end of file. For a file +associated with a keyboard-like device, any line-editing features of the +underlying operating system should be disabled during the execution of +@code{Get_Immediate}. @end cartouche -Followed on any target supporting such operations. +Followed on all targets except VxWorks. For VxWorks, there is no way to +provide this functionality that does not result in the input buffer being +flushed before the @code{Get_Immediate} call. A special unit +@code{Interfaces.Vxworks.IO} is provided that contains routines to enable +this functionality. -@cindex Interrupt support -@unnumberedsec C.3(28): Interrupt Support +@findex Export +@unnumberedsec B.1(39-41): Pragma @code{Export} @sp 1 @cartouche -If the @code{Ceiling_Locking} policy is not in effect, the -implementation should provide means for the application to specify which -interrupts are to be blocked during protected actions, if the underlying -system allows for a finer-grain control of interrupt blocking. +If an implementation supports pragma @code{Export} to a given language, +then it should also allow the main subprogram to be written in that +language. It should support some mechanism for invoking the elaboration +of the Ada library units included in the system, and for invoking the +finalization of the environment task. On typical systems, the +recommended mechanism is to provide two subprograms whose link names are +@code{adainit} and @code{adafinal}. @code{adainit} should contain the +elaboration code for library units. @code{adafinal} should contain the +finalization code. These subprograms should have no effect the second +and subsequent time they are called. @end cartouche -Followed. The underlying system does not allow for finer-grain control -of interrupt blocking. +Followed. -@cindex Protected procedure handlers -@unnumberedsec C.3.1(20-21): Protected Procedure Handlers @sp 1 @cartouche -Whenever possible, the implementation should allow interrupt handlers to -be called directly by the hardware. +Automatic elaboration of pre-elaborated packages should be +provided when pragma @code{Export} is supported. @end cartouche -@c SGI info: -@ignore -This is never possible under IRIX, so this is followed by default. -@end ignore -Followed on any target where the underlying operating system permits -such direct calls. +Followed when the main program is in Ada. If the main program is in a +foreign language, then +@code{adainit} must be called to elaborate pre-elaborated +packages. @sp 1 @cartouche -Whenever practical, violations of any -implementation-defined restrictions should be detected before run time. +For each supported convention @var{L} other than @code{Intrinsic}, an +implementation should support @code{Import} and @code{Export} pragmas +for objects of @var{L}-compatible types and for subprograms, and pragma +@code{Convention} for @var{L}-eligible types and for subprograms, +presuming the other language has corresponding features. Pragma +@code{Convention} need not be supported for scalar types. @end cartouche -Followed. Compile time warnings are given when possible. - -@cindex Package @code{Interrupts} -@findex Interrupts -@unnumberedsec C.3.2(25): Package @code{Interrupts} +Followed. +@cindex Package @code{Interfaces} +@findex Interfaces +@unnumberedsec B.2(12-13): Package @code{Interfaces} @sp 1 @cartouche -If implementation-defined forms of interrupt handler procedures are -supported, such as protected procedures with parameters, then for each -such form of a handler, a type analogous to @code{Parameterless_Handler} -should be specified in a child package of @code{Interrupts}, with the -same operations as in the predefined package Interrupts. +For each implementation-defined convention identifier, there should be a +child package of package Interfaces with the corresponding name. This +package should contain any declarations that would be useful for +interfacing to the language (implementation) represented by the +convention. Any declarations useful for interfacing to any language on +the given hardware architecture should be provided directly in +@code{Interfaces}. @end cartouche -Followed. +Followed. An additional package not defined +in the Ada Reference Manual is @code{Interfaces.CPP}, used +for interfacing to C++. -@cindex Pre-elaboration requirements -@unnumberedsec C.4(14): Pre-elaboration Requirements @sp 1 @cartouche -It is recommended that pre-elaborated packages be implemented in such a -way that there should be little or no code executed at run time for the -elaboration of entities not already covered by the Implementation -Requirements. +An implementation supporting an interface to C, COBOL, or Fortran should +provide the corresponding package or packages described in the following +clauses. @end cartouche -Followed. Executable code is generated in some cases, e.g.@: loops -to initialize large arrays. +Followed. GNAT provides all the packages described in this section. -@unnumberedsec C.5(8): Pragma @code{Discard_Names} +@cindex C, interfacing with +@unnumberedsec B.3(63-71): Interfacing with C @sp 1 @cartouche -If the pragma applies to an entity, then the implementation should -reduce the amount of storage used for storing names associated with that -entity. +An implementation should support the following interface correspondences +between Ada and C@. @end cartouche Followed. -@cindex Package @code{Task_Attributes} -@findex Task_Attributes -@unnumberedsec C.7.2(30): The Package Task_Attributes @sp 1 @cartouche -Some implementations are targeted to domains in which memory use at run -time must be completely deterministic. For such implementations, it is -recommended that the storage for task attributes will be pre-allocated -statically and not from the heap. This can be accomplished by either -placing restrictions on the number and the size of the task's -attributes, or by using the pre-allocated storage for the first @var{N} -attribute objects, and the heap for the others. In the latter case, -@var{N} should be documented. +An Ada procedure corresponds to a void-returning C function. @end cartouche -Not followed. This implementation is not targeted to such a domain. - -@cindex Locking Policies -@unnumberedsec D.3(17): Locking Policies +Followed. @sp 1 @cartouche -The implementation should use names that end with @samp{_Locking} for -locking policies defined by the implementation. +An Ada function corresponds to a non-void C function. @end cartouche -Followed. Two implementation-defined locking policies are defined, -whose names (@code{Inheritance_Locking} and -@code{Concurrent_Readers_Locking}) follow this suggestion. +Followed. -@cindex Entry queuing policies -@unnumberedsec D.4(16): Entry Queuing Policies @sp 1 @cartouche -Names that end with @samp{_Queuing} should be used -for all implementation-defined queuing policies. +An Ada @code{in} scalar parameter is passed as a scalar argument to a C +function. @end cartouche -Followed. No such implementation-defined queuing policies exist. +Followed. -@cindex Preemptive abort -@unnumberedsec D.6(9-10): Preemptive Abort @sp 1 @cartouche -Even though the @code{abort_statement} is included in the list of -potentially blocking operations (see 9.5.1), it is recommended that this -statement be implemented in a way that never requires the task executing -the @code{abort_statement} to block. +An Ada @code{in} parameter of an access-to-object type with designated +type @var{T} is passed as a @code{@var{t}*} argument to a C function, +where @var{t} is the C type corresponding to the Ada type @var{T}. @end cartouche Followed. @sp 1 @cartouche -On a multi-processor, the delay associated with aborting a task on -another processor should be bounded; the implementation should use -periodic polling, if necessary, to achieve this. +An Ada access @var{T} parameter, or an Ada @code{out} or @code{in out} +parameter of an elementary type @var{T}, is passed as a @code{@var{t}*} +argument to a C function, where @var{t} is the C type corresponding to +the Ada type @var{T}. In the case of an elementary @code{out} or +@code{in out} parameter, a pointer to a temporary copy is used to +preserve by-copy semantics. @end cartouche Followed. -@cindex Tasking restrictions -@unnumberedsec D.7(21): Tasking Restrictions @sp 1 @cartouche -When feasible, the implementation should take advantage of the specified -restrictions to produce a more efficient implementation. +An Ada parameter of a record type @var{T}, of any mode, is passed as a +@code{@var{t}*} argument to a C function, where @var{t} is the C +structure corresponding to the Ada type @var{T}. @end cartouche -GNAT currently takes advantage of these restrictions by providing an optimized -run time when the Ravenscar profile and the GNAT restricted run time set -of restrictions are specified. See pragma @code{Profile (Ravenscar)} and -pragma @code{Profile (Restricted)} for more details. +Followed. This convention may be overridden by the use of the C_Pass_By_Copy +pragma, or Convention, or by explicitly specifying the mechanism for a given +call using an extended import or export pragma. -@cindex Time, monotonic -@unnumberedsec D.8(47-49): Monotonic Time @sp 1 @cartouche -When appropriate, implementations should provide configuration -mechanisms to change the value of @code{Tick}. +An Ada parameter of an array type with component type @var{T}, of any +mode, is passed as a @code{@var{t}*} argument to a C function, where +@var{t} is the C type corresponding to the Ada type @var{T}. @end cartouche -Such configuration mechanisms are not appropriate to this implementation -and are thus not supported. +Followed. @sp 1 @cartouche -It is recommended that @code{Calendar.Clock} and @code{Real_Time.Clock} -be implemented as transformations of the same time base. +An Ada parameter of an access-to-subprogram type is passed as a pointer +to a C function whose prototype corresponds to the designated +subprogram's specification. @end cartouche Followed. +@cindex COBOL, interfacing with +@unnumberedsec B.4(95-98): Interfacing with COBOL @sp 1 @cartouche -It is recommended that the @dfn{best} time base which exists in -the underlying system be available to the application through -@code{Clock}. @dfn{Best} may mean highest accuracy or largest range. +An Ada implementation should support the following interface +correspondences between Ada and COBOL@. @end cartouche Followed. -@cindex Partition communication subsystem -@cindex PCS -@unnumberedsec E.5(28-29): Partition Communication Subsystem @sp 1 @cartouche -Whenever possible, the PCS on the called partition should allow for -multiple tasks to call the RPC-receiver with different messages and -should allow them to block until the corresponding subprogram body -returns. +An Ada access @var{T} parameter is passed as a @samp{BY REFERENCE} data item of +the COBOL type corresponding to @var{T}. @end cartouche -Followed by GLADE, a separately supplied PCS that can be used with -GNAT. +Followed. @sp 1 @cartouche -The @code{Write} operation on a stream of type @code{Params_Stream_Type} -should raise @code{Storage_Error} if it runs out of space trying to -write the @code{Item} into the stream. +An Ada in scalar parameter is passed as a @samp{BY CONTENT} data item of +the corresponding COBOL type. @end cartouche -Followed by GLADE, a separately supplied PCS that can be used with -GNAT@. +Followed. -@cindex COBOL support -@unnumberedsec F(7): COBOL Support @sp 1 @cartouche -If COBOL (respectively, C) is widely supported in the target -environment, implementations supporting the Information Systems Annex -should provide the child package @code{Interfaces.COBOL} (respectively, -@code{Interfaces.C}) specified in Annex B and should support a -@code{convention_identifier} of COBOL (respectively, C) in the interfacing -pragmas (see Annex B), thus allowing Ada programs to interface with -programs written in that language. +Any other Ada parameter is passed as a @samp{BY REFERENCE} data item of the +COBOL type corresponding to the Ada parameter type; for scalars, a local +copy is used if necessary to ensure by-copy semantics. @end cartouche Followed. -@cindex Decimal radix support -@unnumberedsec F.1(2): Decimal Radix Support +@cindex Fortran, interfacing with +@unnumberedsec B.5(22-26): Interfacing with Fortran @sp 1 @cartouche -Packed decimal should be used as the internal representation for objects -of subtype @var{S} when @var{S}'Machine_Radix = 10. +An Ada implementation should support the following interface +correspondences between Ada and Fortran: @end cartouche -Not followed. GNAT ignores @var{S}'Machine_Radix and always uses binary -representations. +Followed. -@cindex Numerics -@unnumberedsec G: Numerics -@sp 2 +@sp 1 @cartouche -If Fortran (respectively, C) is widely supported in the target -environment, implementations supporting the Numerics Annex -should provide the child package @code{Interfaces.Fortran} (respectively, -@code{Interfaces.C}) specified in Annex B and should support a -@code{convention_identifier} of Fortran (respectively, C) in the interfacing -pragmas (see Annex B), thus allowing Ada programs to interface with -programs written in that language. +An Ada procedure corresponds to a Fortran subroutine. @end cartouche Followed. -@cindex Complex types -@unnumberedsec G.1.1(56-58): Complex Types -@sp 2 +@sp 1 @cartouche -Because the usual mathematical meaning of multiplication of a complex -operand and a real operand is that of the scaling of both components of -the former by the latter, an implementation should not perform this -operation by first promoting the real operand to complex type and then -performing a full complex multiplication. In systems that, in the -future, support an Ada binding to IEC 559:1989, the latter technique -will not generate the required result when one of the components of the -complex operand is infinite. (Explicit multiplication of the infinite -component by the zero component obtained during promotion yields a NaN -that propagates into the final result.) Analogous advice applies in the -case of multiplication of a complex operand and a pure-imaginary -operand, and in the case of division of a complex operand by a real or -pure-imaginary operand. +An Ada function corresponds to a Fortran function. @end cartouche -Not followed. +Followed. @sp 1 @cartouche -Similarly, because the usual mathematical meaning of addition of a -complex operand and a real operand is that the imaginary operand remains -unchanged, an implementation should not perform this operation by first -promoting the real operand to complex type and then performing a full -complex addition. In implementations in which the @code{Signed_Zeros} -attribute of the component type is @code{True} (and which therefore -conform to IEC 559:1989 in regard to the handling of the sign of zero in -predefined arithmetic operations), the latter technique will not -generate the required result when the imaginary component of the complex -operand is a negatively signed zero. (Explicit addition of the negative -zero to the zero obtained during promotion yields a positive zero.) -Analogous advice applies in the case of addition of a complex operand -and a pure-imaginary operand, and in the case of subtraction of a -complex operand and a real or pure-imaginary operand. +An Ada parameter of an elementary, array, or record type @var{T} is +passed as a @var{T} argument to a Fortran procedure, where @var{T} is +the Fortran type corresponding to the Ada type @var{T}, and where the +INTENT attribute of the corresponding dummy argument matches the Ada +formal parameter mode; the Fortran implementation's parameter passing +conventions are used. For elementary types, a local copy is used if +necessary to ensure by-copy semantics. @end cartouche -Not followed. +Followed. @sp 1 @cartouche -Implementations in which @code{Real'Signed_Zeros} is @code{True} should -attempt to provide a rational treatment of the signs of zero results and -result components. As one example, the result of the @code{Argument} -function should have the sign of the imaginary component of the -parameter @code{X} when the point represented by that parameter lies on -the positive real axis; as another, the sign of the imaginary component -of the @code{Compose_From_Polar} function should be the same as -(respectively, the opposite of) that of the @code{Argument} parameter when that -parameter has a value of zero and the @code{Modulus} parameter has a -nonnegative (respectively, negative) value. +An Ada parameter of an access-to-subprogram type is passed as a +reference to a Fortran procedure whose interface corresponds to the +designated subprogram's specification. @end cartouche Followed. -@cindex Complex elementary functions -@unnumberedsec G.1.2(49): Complex Elementary Functions +@cindex Machine operations +@unnumberedsec C.1(3-5): Access to Machine Operations @sp 1 @cartouche -Implementations in which @code{Complex_Types.Real'Signed_Zeros} is -@code{True} should attempt to provide a rational treatment of the signs -of zero results and result components. For example, many of the complex -elementary functions have components that are odd functions of one of -the parameter components; in these cases, the result component should -have the sign of the parameter component at the origin. Other complex -elementary functions have zero components whose sign is opposite that of -a parameter component at the origin, or is always positive or always -negative. +The machine code or intrinsic support should allow access to all +operations normally available to assembly language programmers for the +target environment, including privileged instructions, if any. @end cartouche Followed. -@cindex Accuracy requirements -@unnumberedsec G.2.4(19): Accuracy Requirements @sp 1 @cartouche -The versions of the forward trigonometric functions without a -@code{Cycle} parameter should not be implemented by calling the -corresponding version with a @code{Cycle} parameter of -@code{2.0*Numerics.Pi}, since this will not provide the required -accuracy in some portions of the domain. For the same reason, the -version of @code{Log} without a @code{Base} parameter should not be -implemented by calling the corresponding version with a @code{Base} -parameter of @code{Numerics.e}. +The interfacing pragmas (see Annex B) should support interface to +assembler; the default assembler should be associated with the +convention identifier @code{Assembler}. @end cartouche Followed. -@cindex Complex arithmetic accuracy -@cindex Accuracy, complex arithmetic -@unnumberedsec G.2.6(15): Complex Arithmetic Accuracy - @sp 1 @cartouche -The version of the @code{Compose_From_Polar} function without a -@code{Cycle} parameter should not be implemented by calling the -corresponding version with a @code{Cycle} parameter of -@code{2.0*Numerics.Pi}, since this will not provide the required -accuracy in some portions of the domain. +If an entity is exported to assembly language, then the implementation +should allocate it at an addressable location, and should ensure that it +is retained by the linking process, even if not otherwise referenced +from the Ada code. The implementation should assume that any call to a +machine code or assembler subprogram is allowed to read or update every +object that is specified as exported. @end cartouche Followed. -@c ----------------------------------------- -@node Implementation Defined Characteristics -@chapter Implementation Defined Characteristics - -@noindent -In addition to the implementation dependent pragmas and attributes, and the -implementation advice, there are a number of other Ada features that are -potentially implementation dependent and are designated as -implementation-defined. These are mentioned throughout the Ada Reference -Manual, and are summarized in Annex M@. - -A requirement for conforming Ada compilers is that they provide -documentation describing how the implementation deals with each of these -issues. In this chapter, you will find each point in Annex M listed -followed by a description in italic font of how GNAT -@c SGI info: -@ignore -in the ProDev Ada -implementation on IRIX 5.3 operating system or greater -@end ignore -handles the implementation dependence. +@unnumberedsec C.1(10-16): Access to Machine Operations +@sp 1 +@cartouche +The implementation should ensure that little or no overhead is +associated with calling intrinsic and machine-code subprograms. +@end cartouche +Followed for both intrinsics and machine-code subprograms. -You can use this chapter as a guide to minimizing implementation -dependent features in your programs if portability to other compilers -and other operating systems is an important consideration. The numbers -in each section below correspond to the paragraph number in the Ada -Reference Manual. +@sp 1 +@cartouche +It is recommended that intrinsic subprograms be provided for convenient +access to any machine operations that provide special capabilities or +efficiency and that are not otherwise available through the language +constructs. +@end cartouche +Followed. A full set of machine operation intrinsic subprograms is provided. @sp 1 @cartouche -@noindent -@strong{2}. Whether or not each recommendation given in Implementation -Advice is followed. See 1.1.2(37). +Atomic read-modify-write operations---e.g.@:, test and set, compare and +swap, decrement and test, enqueue/dequeue. @end cartouche -@noindent -@xref{Implementation Advice}. +Followed on any target supporting such operations. @sp 1 @cartouche -@noindent -@strong{3}. Capacity limitations of the implementation. See 1.1.3(3). +Standard numeric functions---e.g.@:, sin, log. @end cartouche -@noindent -The complexity of programs that can be processed is limited only by the -total amount of available virtual memory, and disk space for the -generated object files. +Followed on any target supporting such operations. @sp 1 @cartouche -@noindent -@strong{4}. Variations from the standard that are impractical to avoid -given the implementation's execution environment. See 1.1.3(6). +String manipulation operations---e.g.@:, translate and test. @end cartouche -@noindent -There are no variations from the standard. +Followed on any target supporting such operations. @sp 1 @cartouche -@noindent -@strong{5}. Which @code{code_statement}s cause external -interactions. See 1.1.3(10). +Vector operations---e.g.@:, compare vector against thresholds. @end cartouche -@noindent -Any @code{code_statement} can potentially cause external interactions. +Followed on any target supporting such operations. @sp 1 @cartouche -@noindent -@strong{6}. The coded representation for the text of an Ada -program. See 2.1(4). +Direct operations on I/O ports. @end cartouche -@noindent -See separate section on source representation. +Followed on any target supporting such operations. +@cindex Interrupt support +@unnumberedsec C.3(28): Interrupt Support @sp 1 @cartouche -@noindent -@strong{7}. The control functions allowed in comments. See 2.1(14). +If the @code{Ceiling_Locking} policy is not in effect, the +implementation should provide means for the application to specify which +interrupts are to be blocked during protected actions, if the underlying +system allows for a finer-grain control of interrupt blocking. @end cartouche -@noindent -See separate section on source representation. +Followed. The underlying system does not allow for finer-grain control +of interrupt blocking. +@cindex Protected procedure handlers +@unnumberedsec C.3.1(20-21): Protected Procedure Handlers @sp 1 @cartouche -@noindent -@strong{8}. The representation for an end of line. See 2.2(2). +Whenever possible, the implementation should allow interrupt handlers to +be called directly by the hardware. @end cartouche -@noindent -See separate section on source representation. +@c SGI info: +@ignore +This is never possible under IRIX, so this is followed by default. +@end ignore +Followed on any target where the underlying operating system permits +such direct calls. @sp 1 @cartouche -@noindent -@strong{9}. Maximum supported line length and lexical element -length. See 2.2(15). +Whenever practical, violations of any +implementation-defined restrictions should be detected before run time. @end cartouche -@noindent -The maximum line length is 255 characters and the maximum length of a -lexical element is also 255 characters. +Followed. Compile time warnings are given when possible. + +@cindex Package @code{Interrupts} +@findex Interrupts +@unnumberedsec C.3.2(25): Package @code{Interrupts} @sp 1 @cartouche -@noindent -@strong{10}. Implementation defined pragmas. See 2.8(14). +If implementation-defined forms of interrupt handler procedures are +supported, such as protected procedures with parameters, then for each +such form of a handler, a type analogous to @code{Parameterless_Handler} +should be specified in a child package of @code{Interrupts}, with the +same operations as in the predefined package Interrupts. @end cartouche -@noindent +Followed. -@xref{Implementation Defined Pragmas}. +@cindex Pre-elaboration requirements +@unnumberedsec C.4(14): Pre-elaboration Requirements +@sp 1 +@cartouche +It is recommended that pre-elaborated packages be implemented in such a +way that there should be little or no code executed at run time for the +elaboration of entities not already covered by the Implementation +Requirements. +@end cartouche +Followed. Executable code is generated in some cases, e.g.@: loops +to initialize large arrays. +@unnumberedsec C.5(8): Pragma @code{Discard_Names} @sp 1 @cartouche -@noindent -@strong{11}. Effect of pragma @code{Optimize}. See 2.8(27). +If the pragma applies to an entity, then the implementation should +reduce the amount of storage used for storing names associated with that +entity. @end cartouche -@noindent -Pragma @code{Optimize}, if given with a @code{Time} or @code{Space} -parameter, checks that the optimization flag is set, and aborts if it is -not. +Followed. +@cindex Package @code{Task_Attributes} +@findex Task_Attributes +@unnumberedsec C.7.2(30): The Package Task_Attributes @sp 1 @cartouche -@noindent -@strong{12}. The sequence of characters of the value returned by -@code{@var{S}'Image} when some of the graphic characters of -@code{@var{S}'Wide_Image} are not defined in @code{Character}. See -3.5(37). +Some implementations are targeted to domains in which memory use at run +time must be completely deterministic. For such implementations, it is +recommended that the storage for task attributes will be pre-allocated +statically and not from the heap. This can be accomplished by either +placing restrictions on the number and the size of the task's +attributes, or by using the pre-allocated storage for the first @var{N} +attribute objects, and the heap for the others. In the latter case, +@var{N} should be documented. @end cartouche -@noindent -The sequence of characters is as defined by the wide character encoding -method used for the source. See section on source representation for -further details. +Not followed. This implementation is not targeted to such a domain. + +@cindex Locking Policies +@unnumberedsec D.3(17): Locking Policies @sp 1 @cartouche -@noindent -@strong{13}. The predefined integer types declared in -@code{Standard}. See 3.5.4(25). +The implementation should use names that end with @samp{_Locking} for +locking policies defined by the implementation. @end cartouche -@noindent -@table @code -@item Short_Short_Integer -8 bit signed -@item Short_Integer -(Short) 16 bit signed -@item Integer -32 bit signed -@item Long_Integer -64 bit signed (on most 64 bit targets, depending on the C definition of long). -32 bit signed (all other targets) -@item Long_Long_Integer -64 bit signed -@end table +Followed. Two implementation-defined locking policies are defined, +whose names (@code{Inheritance_Locking} and +@code{Concurrent_Readers_Locking}) follow this suggestion. +@cindex Entry queuing policies +@unnumberedsec D.4(16): Entry Queuing Policies @sp 1 @cartouche -@noindent -@strong{14}. Any nonstandard integer types and the operators defined -for them. See 3.5.4(26). +Names that end with @samp{_Queuing} should be used +for all implementation-defined queuing policies. @end cartouche -@noindent -There are no nonstandard integer types. +Followed. No such implementation-defined queuing policies exist. +@cindex Preemptive abort +@unnumberedsec D.6(9-10): Preemptive Abort @sp 1 @cartouche -@noindent -@strong{15}. Any nonstandard real types and the operators defined for -them. See 3.5.6(8). +Even though the @code{abort_statement} is included in the list of +potentially blocking operations (see 9.5.1), it is recommended that this +statement be implemented in a way that never requires the task executing +the @code{abort_statement} to block. @end cartouche -@noindent -There are no nonstandard real types. +Followed. @sp 1 @cartouche -@noindent -@strong{16}. What combinations of requested decimal precision and range -are supported for floating point types. See 3.5.7(7). +On a multi-processor, the delay associated with aborting a task on +another processor should be bounded; the implementation should use +periodic polling, if necessary, to achieve this. @end cartouche -@noindent -The precision and range is as defined by the IEEE standard. +Followed. +@cindex Tasking restrictions +@unnumberedsec D.7(21): Tasking Restrictions @sp 1 @cartouche -@noindent -@strong{17}. The predefined floating point types declared in -@code{Standard}. See 3.5.7(16). +When feasible, the implementation should take advantage of the specified +restrictions to produce a more efficient implementation. @end cartouche -@noindent -@table @code -@item Short_Float -32 bit IEEE short -@item Float -(Short) 32 bit IEEE short -@item Long_Float -64 bit IEEE long -@item Long_Long_Float -64 bit IEEE long (80 bit IEEE long on x86 processors) -@end table +GNAT currently takes advantage of these restrictions by providing an optimized +run time when the Ravenscar profile and the GNAT restricted run time set +of restrictions are specified. See pragma @code{Profile (Ravenscar)} and +pragma @code{Profile (Restricted)} for more details. +@cindex Time, monotonic +@unnumberedsec D.8(47-49): Monotonic Time @sp 1 @cartouche -@noindent -@strong{18}. The small of an ordinary fixed point type. See 3.5.9(8). +When appropriate, implementations should provide configuration +mechanisms to change the value of @code{Tick}. @end cartouche -@noindent -@code{Fine_Delta} is 2**(@minus{}63) +Such configuration mechanisms are not appropriate to this implementation +and are thus not supported. @sp 1 @cartouche -@noindent -@strong{19}. What combinations of small, range, and digits are -supported for fixed point types. See 3.5.9(10). +It is recommended that @code{Calendar.Clock} and @code{Real_Time.Clock} +be implemented as transformations of the same time base. @end cartouche -@noindent -Any combinations are permitted that do not result in a small less than -@code{Fine_Delta} and do not result in a mantissa larger than 63 bits. -If the mantissa is larger than 53 bits on machines where Long_Long_Float -is 64 bits (true of all architectures except ia32), then the output from -Text_IO is accurate to only 53 bits, rather than the full mantissa. This -is because floating-point conversions are used to convert fixed point. +Followed. @sp 1 @cartouche -@noindent -@strong{20}. The result of @code{Tags.Expanded_Name} for types declared -within an unnamed @code{block_statement}. See 3.9(10). +It is recommended that the @dfn{best} time base which exists in +the underlying system be available to the application through +@code{Clock}. @dfn{Best} may mean highest accuracy or largest range. @end cartouche -@noindent -Block numbers of the form @code{B@var{nnn}}, where @var{nnn} is a -decimal integer are allocated. +Followed. +@cindex Partition communication subsystem +@cindex PCS +@unnumberedsec E.5(28-29): Partition Communication Subsystem @sp 1 @cartouche -@noindent -@strong{21}. Implementation-defined attributes. See 4.1.4(12). +Whenever possible, the PCS on the called partition should allow for +multiple tasks to call the RPC-receiver with different messages and +should allow them to block until the corresponding subprogram body +returns. @end cartouche -@noindent -@xref{Implementation Defined Attributes}. +Followed by GLADE, a separately supplied PCS that can be used with +GNAT. @sp 1 @cartouche -@noindent -@strong{22}. Any implementation-defined time types. See 9.6(6). +The @code{Write} operation on a stream of type @code{Params_Stream_Type} +should raise @code{Storage_Error} if it runs out of space trying to +write the @code{Item} into the stream. @end cartouche -@noindent -There are no implementation-defined time types. +Followed by GLADE, a separately supplied PCS that can be used with +GNAT@. +@cindex COBOL support +@unnumberedsec F(7): COBOL Support @sp 1 @cartouche -@noindent -@strong{23}. The time base associated with relative delays. +If COBOL (respectively, C) is widely supported in the target +environment, implementations supporting the Information Systems Annex +should provide the child package @code{Interfaces.COBOL} (respectively, +@code{Interfaces.C}) specified in Annex B and should support a +@code{convention_identifier} of COBOL (respectively, C) in the interfacing +pragmas (see Annex B), thus allowing Ada programs to interface with +programs written in that language. @end cartouche -@noindent -See 9.6(20). The time base used is that provided by the C library -function @code{gettimeofday}. +Followed. +@cindex Decimal radix support +@unnumberedsec F.1(2): Decimal Radix Support @sp 1 @cartouche -@noindent -@strong{24}. The time base of the type @code{Calendar.Time}. See -9.6(23). +Packed decimal should be used as the internal representation for objects +of subtype @var{S} when @var{S}'Machine_Radix = 10. @end cartouche -@noindent -The time base used is that provided by the C library function -@code{gettimeofday}. +Not followed. GNAT ignores @var{S}'Machine_Radix and always uses binary +representations. -@sp 1 +@cindex Numerics +@unnumberedsec G: Numerics +@sp 2 @cartouche -@noindent -@strong{25}. The time zone used for package @code{Calendar} -operations. See 9.6(24). +If Fortran (respectively, C) is widely supported in the target +environment, implementations supporting the Numerics Annex +should provide the child package @code{Interfaces.Fortran} (respectively, +@code{Interfaces.C}) specified in Annex B and should support a +@code{convention_identifier} of Fortran (respectively, C) in the interfacing +pragmas (see Annex B), thus allowing Ada programs to interface with +programs written in that language. @end cartouche -@noindent -The time zone used by package @code{Calendar} is the current system time zone -setting for local time, as accessed by the C library function -@code{localtime}. +Followed. -@sp 1 +@cindex Complex types +@unnumberedsec G.1.1(56-58): Complex Types +@sp 2 @cartouche -@noindent -@strong{26}. Any limit on @code{delay_until_statements} of -@code{select_statements}. See 9.6(29). +Because the usual mathematical meaning of multiplication of a complex +operand and a real operand is that of the scaling of both components of +the former by the latter, an implementation should not perform this +operation by first promoting the real operand to complex type and then +performing a full complex multiplication. In systems that, in the +future, support an Ada binding to IEC 559:1989, the latter technique +will not generate the required result when one of the components of the +complex operand is infinite. (Explicit multiplication of the infinite +component by the zero component obtained during promotion yields a NaN +that propagates into the final result.) Analogous advice applies in the +case of multiplication of a complex operand and a pure-imaginary +operand, and in the case of division of a complex operand by a real or +pure-imaginary operand. @end cartouche -@noindent -There are no such limits. +Not followed. @sp 1 @cartouche -@noindent -@strong{27}. Whether or not two non-overlapping parts of a composite -object are independently addressable, in the case where packing, record -layout, or @code{Component_Size} is specified for the object. See -9.10(1). +Similarly, because the usual mathematical meaning of addition of a +complex operand and a real operand is that the imaginary operand remains +unchanged, an implementation should not perform this operation by first +promoting the real operand to complex type and then performing a full +complex addition. In implementations in which the @code{Signed_Zeros} +attribute of the component type is @code{True} (and which therefore +conform to IEC 559:1989 in regard to the handling of the sign of zero in +predefined arithmetic operations), the latter technique will not +generate the required result when the imaginary component of the complex +operand is a negatively signed zero. (Explicit addition of the negative +zero to the zero obtained during promotion yields a positive zero.) +Analogous advice applies in the case of addition of a complex operand +and a pure-imaginary operand, and in the case of subtraction of a +complex operand and a real or pure-imaginary operand. @end cartouche -@noindent -Separate components are independently addressable if they do not share -overlapping storage units. +Not followed. @sp 1 @cartouche -@noindent -@strong{28}. The representation for a compilation. See 10.1(2). +Implementations in which @code{Real'Signed_Zeros} is @code{True} should +attempt to provide a rational treatment of the signs of zero results and +result components. As one example, the result of the @code{Argument} +function should have the sign of the imaginary component of the +parameter @code{X} when the point represented by that parameter lies on +the positive real axis; as another, the sign of the imaginary component +of the @code{Compose_From_Polar} function should be the same as +(respectively, the opposite of) that of the @code{Argument} parameter when that +parameter has a value of zero and the @code{Modulus} parameter has a +nonnegative (respectively, negative) value. @end cartouche -@noindent -A compilation is represented by a sequence of files presented to the -compiler in a single invocation of the @command{gcc} command. +Followed. +@cindex Complex elementary functions +@unnumberedsec G.1.2(49): Complex Elementary Functions @sp 1 @cartouche -@noindent -@strong{29}. Any restrictions on compilations that contain multiple -compilation_units. See 10.1(4). +Implementations in which @code{Complex_Types.Real'Signed_Zeros} is +@code{True} should attempt to provide a rational treatment of the signs +of zero results and result components. For example, many of the complex +elementary functions have components that are odd functions of one of +the parameter components; in these cases, the result component should +have the sign of the parameter component at the origin. Other complex +elementary functions have zero components whose sign is opposite that of +a parameter component at the origin, or is always positive or always +negative. @end cartouche -@noindent -No single file can contain more than one compilation unit, but any -sequence of files can be presented to the compiler as a single -compilation. +Followed. +@cindex Accuracy requirements +@unnumberedsec G.2.4(19): Accuracy Requirements @sp 1 @cartouche -@noindent -@strong{30}. The mechanisms for creating an environment and for adding -and replacing compilation units. See 10.1.4(3). +The versions of the forward trigonometric functions without a +@code{Cycle} parameter should not be implemented by calling the +corresponding version with a @code{Cycle} parameter of +@code{2.0*Numerics.Pi}, since this will not provide the required +accuracy in some portions of the domain. For the same reason, the +version of @code{Log} without a @code{Base} parameter should not be +implemented by calling the corresponding version with a @code{Base} +parameter of @code{Numerics.e}. @end cartouche -@noindent -See separate section on compilation model. +Followed. + +@cindex Complex arithmetic accuracy +@cindex Accuracy, complex arithmetic +@unnumberedsec G.2.6(15): Complex Arithmetic Accuracy @sp 1 @cartouche -@noindent -@strong{31}. The manner of explicitly assigning library units to a -partition. See 10.2(2). +The version of the @code{Compose_From_Polar} function without a +@code{Cycle} parameter should not be implemented by calling the +corresponding version with a @code{Cycle} parameter of +@code{2.0*Numerics.Pi}, since this will not provide the required +accuracy in some portions of the domain. @end cartouche +Followed. + +@c ----------------------------------------- +@node Implementation Defined Characteristics +@chapter Implementation Defined Characteristics + @noindent -If a unit contains an Ada main program, then the Ada units for the partition -are determined by recursive application of the rules in the Ada Reference -Manual section 10.2(2-6). In other words, the Ada units will be those that -are needed by the main program, and then this definition of need is applied -recursively to those units, and the partition contains the transitive -closure determined by this relationship. In short, all the necessary units -are included, with no need to explicitly specify the list. If additional -units are required, e.g.@: by foreign language units, then all units must be -mentioned in the context clause of one of the needed Ada units. +In addition to the implementation dependent pragmas and attributes, and the +implementation advice, there are a number of other Ada features that are +potentially implementation dependent and are designated as +implementation-defined. These are mentioned throughout the Ada Reference +Manual, and are summarized in Annex M@. -If the partition contains no main program, or if the main program is in -a language other than Ada, then GNAT -provides the binder options @option{-z} and @option{-n} respectively, and in -this case a list of units can be explicitly supplied to the binder for -inclusion in the partition (all units needed by these units will also -be included automatically). For full details on the use of these -options, refer to @ref{The GNAT Make Program gnatmake,,, gnat_ugn, -@value{EDITION} User's Guide}. +A requirement for conforming Ada compilers is that they provide +documentation describing how the implementation deals with each of these +issues. In this chapter, you will find each point in Annex M listed +followed by a description in italic font of how GNAT +@c SGI info: +@ignore +in the ProDev Ada +implementation on IRIX 5.3 operating system or greater +@end ignore +handles the implementation dependence. + +You can use this chapter as a guide to minimizing implementation +dependent features in your programs if portability to other compilers +and other operating systems is an important consideration. The numbers +in each section below correspond to the paragraph number in the Ada +Reference Manual. @sp 1 @cartouche @noindent -@strong{32}. The implementation-defined means, if any, of specifying -which compilation units are needed by a given compilation unit. See -10.2(2). +@strong{2}. Whether or not each recommendation given in Implementation +Advice is followed. See 1.1.2(37). @end cartouche @noindent -The units needed by a given compilation unit are as defined in -the Ada Reference Manual section 10.2(2-6). There are no -implementation-defined pragmas or other implementation-defined -means for specifying needed units. +@xref{Implementation Advice}. @sp 1 @cartouche @noindent -@strong{33}. The manner of designating the main subprogram of a -partition. See 10.2(7). +@strong{3}. Capacity limitations of the implementation. See 1.1.3(3). @end cartouche @noindent -The main program is designated by providing the name of the -corresponding @file{ALI} file as the input parameter to the binder. +The complexity of programs that can be processed is limited only by the +total amount of available virtual memory, and disk space for the +generated object files. @sp 1 @cartouche @noindent -@strong{34}. The order of elaboration of @code{library_items}. See -10.2(18). +@strong{4}. Variations from the standard that are impractical to avoid +given the implementation's execution environment. See 1.1.3(6). @end cartouche @noindent -The first constraint on ordering is that it meets the requirements of -Chapter 10 of the Ada Reference Manual. This still leaves some -implementation dependent choices, which are resolved by first -elaborating bodies as early as possible (i.e., in preference to specs -where there is a choice), and second by evaluating the immediate with -clauses of a unit to determine the probably best choice, and -third by elaborating in alphabetical order of unit names -where a choice still remains. +There are no variations from the standard. @sp 1 @cartouche @noindent -@strong{35}. Parameter passing and function return for the main -subprogram. See 10.2(21). +@strong{5}. Which @code{code_statement}s cause external +interactions. See 1.1.3(10). @end cartouche @noindent -The main program has no parameters. It may be a procedure, or a function -returning an integer type. In the latter case, the returned integer -value is the return code of the program (overriding any value that -may have been set by a call to @code{Ada.Command_Line.Set_Exit_Status}). +Any @code{code_statement} can potentially cause external interactions. @sp 1 @cartouche @noindent -@strong{36}. The mechanisms for building and running partitions. See -10.2(24). +@strong{6}. The coded representation for the text of an Ada +program. See 2.1(4). @end cartouche @noindent -GNAT itself supports programs with only a single partition. The GNATDIST -tool provided with the GLADE package (which also includes an implementation -of the PCS) provides a completely flexible method for building and running -programs consisting of multiple partitions. See the separate GLADE manual -for details. +See separate section on source representation. @sp 1 @cartouche @noindent -@strong{37}. The details of program execution, including program -termination. See 10.2(25). +@strong{7}. The control functions allowed in comments. See 2.1(14). @end cartouche @noindent -See separate section on compilation model. +See separate section on source representation. @sp 1 @cartouche @noindent -@strong{38}. The semantics of any non-active partitions supported by the -implementation. See 10.2(28). +@strong{8}. The representation for an end of line. See 2.2(2). @end cartouche @noindent -Passive partitions are supported on targets where shared memory is -provided by the operating system. See the GLADE reference manual for -further details. +See separate section on source representation. @sp 1 @cartouche @noindent -@strong{39}. The information returned by @code{Exception_Message}. See -11.4.1(10). +@strong{9}. Maximum supported line length and lexical element +length. See 2.2(15). @end cartouche @noindent -Exception message returns the null string unless a specific message has -been passed by the program. +The maximum line length is 255 characters and the maximum length of a +lexical element is also 255 characters. @sp 1 @cartouche @noindent -@strong{40}. The result of @code{Exceptions.Exception_Name} for types -declared within an unnamed @code{block_statement}. See 11.4.1(12). +@strong{10}. Implementation defined pragmas. See 2.8(14). @end cartouche @noindent -Blocks have implementation defined names of the form @code{B@var{nnn}} -where @var{nnn} is an integer. + +@xref{Implementation Defined Pragmas}. @sp 1 @cartouche @noindent -@strong{41}. The information returned by -@code{Exception_Information}. See 11.4.1(13). +@strong{11}. Effect of pragma @code{Optimize}. See 2.8(27). @end cartouche @noindent -@code{Exception_Information} returns a string in the following format: - -@smallexample -@emph{Exception_Name:} nnnnn -@emph{Message:} mmmmm -@emph{PID:} ppp -@emph{Call stack traceback locations:} -0xhhhh 0xhhhh 0xhhhh ... 0xhhh -@end smallexample - -@noindent -where - -@itemize @bullet -@item -@code{nnnn} is the fully qualified name of the exception in all upper -case letters. This line is always present. - -@item -@code{mmmm} is the message (this line present only if message is non-null) - -@item -@code{ppp} is the Process Id value as a decimal integer (this line is -present only if the Process Id is nonzero). Currently we are -not making use of this field. - -@item -The Call stack traceback locations line and the following values -are present only if at least one traceback location was recorded. -The values are given in C style format, with lower case letters -for a-f, and only as many digits present as are necessary. -@end itemize - -@noindent -The line terminator sequence at the end of each line, including -the last line is a single @code{LF} character (@code{16#0A#}). +Pragma @code{Optimize}, if given with a @code{Time} or @code{Space} +parameter, checks that the optimization flag is set, and aborts if it is +not. @sp 1 @cartouche @noindent -@strong{42}. Implementation-defined check names. See 11.5(27). +@strong{12}. The sequence of characters of the value returned by +@code{@var{S}'Image} when some of the graphic characters of +@code{@var{S}'Wide_Image} are not defined in @code{Character}. See +3.5(37). @end cartouche @noindent -The implementation defined check name Alignment_Check controls checking of -address clause values for proper alignment (that is, the address supplied -must be consistent with the alignment of the type). - -In addition, a user program can add implementation-defined check names -by means of the pragma Check_Name. +The sequence of characters is as defined by the wide character encoding +method used for the source. See section on source representation for +further details. @sp 1 @cartouche @noindent -@strong{43}. The interpretation of each aspect of representation. See -13.1(20). +@strong{13}. The predefined integer types declared in +@code{Standard}. See 3.5.4(25). @end cartouche @noindent -See separate section on data representations. +@table @code +@item Short_Short_Integer +8 bit signed +@item Short_Integer +(Short) 16 bit signed +@item Integer +32 bit signed +@item Long_Integer +64 bit signed (on most 64 bit targets, depending on the C definition of long). +32 bit signed (all other targets) +@item Long_Long_Integer +64 bit signed +@end table @sp 1 @cartouche @noindent -@strong{44}. Any restrictions placed upon representation items. See -13.1(20). +@strong{14}. Any nonstandard integer types and the operators defined +for them. See 3.5.4(26). @end cartouche @noindent -See separate section on data representations. +There are no nonstandard integer types. @sp 1 @cartouche @noindent -@strong{45}. The meaning of @code{Size} for indefinite subtypes. See -13.3(48). +@strong{15}. Any nonstandard real types and the operators defined for +them. See 3.5.6(8). @end cartouche @noindent -Size for an indefinite subtype is the maximum possible size, except that -for the case of a subprogram parameter, the size of the parameter object -is the actual size. +There are no nonstandard real types. @sp 1 @cartouche @noindent -@strong{46}. The default external representation for a type tag. See -13.3(75). +@strong{16}. What combinations of requested decimal precision and range +are supported for floating point types. See 3.5.7(7). @end cartouche @noindent -The default external representation for a type tag is the fully expanded -name of the type in upper case letters. +The precision and range is as defined by the IEEE standard. @sp 1 @cartouche @noindent -@strong{47}. What determines whether a compilation unit is the same in -two different partitions. See 13.3(76). +@strong{17}. The predefined floating point types declared in +@code{Standard}. See 3.5.7(16). @end cartouche @noindent -A compilation unit is the same in two different partitions if and only -if it derives from the same source file. +@table @code +@item Short_Float +32 bit IEEE short +@item Float +(Short) 32 bit IEEE short +@item Long_Float +64 bit IEEE long +@item Long_Long_Float +64 bit IEEE long (80 bit IEEE long on x86 processors) +@end table @sp 1 @cartouche @noindent -@strong{48}. Implementation-defined components. See 13.5.1(15). +@strong{18}. The small of an ordinary fixed point type. See 3.5.9(8). @end cartouche @noindent -The only implementation defined component is the tag for a tagged type, -which contains a pointer to the dispatching table. +@code{Fine_Delta} is 2**(@minus{}63) @sp 1 @cartouche @noindent -@strong{49}. If @code{Word_Size} = @code{Storage_Unit}, the default bit -ordering. See 13.5.3(5). +@strong{19}. What combinations of small, range, and digits are +supported for fixed point types. See 3.5.9(10). @end cartouche @noindent -@code{Word_Size} (32) is not the same as @code{Storage_Unit} (8) for this -implementation, so no non-default bit ordering is supported. The default -bit ordering corresponds to the natural endianness of the target architecture. +Any combinations are permitted that do not result in a small less than +@code{Fine_Delta} and do not result in a mantissa larger than 63 bits. +If the mantissa is larger than 53 bits on machines where Long_Long_Float +is 64 bits (true of all architectures except ia32), then the output from +Text_IO is accurate to only 53 bits, rather than the full mantissa. This +is because floating-point conversions are used to convert fixed point. @sp 1 @cartouche @noindent -@strong{50}. The contents of the visible part of package @code{System} -and its language-defined children. See 13.7(2). +@strong{20}. The result of @code{Tags.Expanded_Name} for types declared +within an unnamed @code{block_statement}. See 3.9(10). @end cartouche @noindent -See the definition of these packages in files @file{system.ads} and -@file{s-stoele.ads}. +Block numbers of the form @code{B@var{nnn}}, where @var{nnn} is a +decimal integer are allocated. @sp 1 @cartouche @noindent -@strong{51}. The contents of the visible part of package -@code{System.Machine_Code}, and the meaning of -@code{code_statements}. See 13.8(7). +@strong{21}. Implementation-defined attributes. See 4.1.4(12). @end cartouche @noindent -See the definition and documentation in file @file{s-maccod.ads}. +@xref{Implementation Defined Attributes}. @sp 1 @cartouche @noindent -@strong{52}. The effect of unchecked conversion. See 13.9(11). +@strong{22}. Any implementation-defined time types. See 9.6(6). @end cartouche @noindent -Unchecked conversion between types of the same size -results in an uninterpreted transmission of the bits from one type -to the other. If the types are of unequal sizes, then in the case of -discrete types, a shorter source is first zero or sign extended as -necessary, and a shorter target is simply truncated on the left. -For all non-discrete types, the source is first copied if necessary -to ensure that the alignment requirements of the target are met, then -a pointer is constructed to the source value, and the result is obtained -by dereferencing this pointer after converting it to be a pointer to the -target type. Unchecked conversions where the target subtype is an -unconstrained array are not permitted. If the target alignment is -greater than the source alignment, then a copy of the result is -made with appropriate alignment +There are no implementation-defined time types. @sp 1 @cartouche @noindent -@strong{53}. The semantics of operations on invalid representations. -See 13.9.2(10-11). +@strong{23}. The time base associated with relative delays. @end cartouche @noindent -For assignments and other operations where the use of invalid values cannot -result in erroneous behavior, the compiler ignores the possibility of invalid -values. An exception is raised at the point where an invalid value would -result in erroneous behavior. For example executing: - -@smallexample @c ada -procedure invalidvals is - X : Integer := -1; - Y : Natural range 1 .. 10; - for Y'Address use X'Address; - Z : Natural range 1 .. 10; - A : array (Natural range 1 .. 10) of Integer; -begin - Z := Y; -- no exception - A (Z) := 3; -- exception raised; -end; -@end smallexample +See 9.6(20). The time base used is that provided by the C library +function @code{gettimeofday}. +@sp 1 +@cartouche @noindent -As indicated, an exception is raised on the array assignment, but not -on the simple assignment of the invalid negative value from Y to Z. +@strong{24}. The time base of the type @code{Calendar.Time}. See +9.6(23). +@end cartouche +@noindent +The time base used is that provided by the C library function +@code{gettimeofday}. @sp 1 @cartouche @noindent -@strong{53}. The manner of choosing a storage pool for an access type -when @code{Storage_Pool} is not specified for the type. See 13.11(17). +@strong{25}. The time zone used for package @code{Calendar} +operations. See 9.6(24). @end cartouche @noindent -There are 3 different standard pools used by the compiler when -@code{Storage_Pool} is not specified depending whether the type is local -to a subprogram or defined at the library level and whether -@code{Storage_Size}is specified or not. See documentation in the runtime -library units @code{System.Pool_Global}, @code{System.Pool_Size} and -@code{System.Pool_Local} in files @file{s-poosiz.ads}, -@file{s-pooglo.ads} and @file{s-pooloc.ads} for full details on the -default pools used. +The time zone used by package @code{Calendar} is the current system time zone +setting for local time, as accessed by the C library function +@code{localtime}. @sp 1 @cartouche @noindent -@strong{54}. Whether or not the implementation provides user-accessible -names for the standard pool type(s). See 13.11(17). +@strong{26}. Any limit on @code{delay_until_statements} of +@code{select_statements}. See 9.6(29). @end cartouche @noindent - -See documentation in the sources of the run time mentioned in paragraph -@strong{53} . All these pools are accessible by means of @code{with}'ing -these units. +There are no such limits. @sp 1 @cartouche @noindent -@strong{55}. The meaning of @code{Storage_Size}. See 13.11(18). +@strong{27}. Whether or not two non-overlapping parts of a composite +object are independently addressable, in the case where packing, record +layout, or @code{Component_Size} is specified for the object. See +9.10(1). @end cartouche @noindent -@code{Storage_Size} is measured in storage units, and refers to the -total space available for an access type collection, or to the primary -stack space for a task. +Separate components are independently addressable if they do not share +overlapping storage units. @sp 1 @cartouche @noindent -@strong{56}. Implementation-defined aspects of storage pools. See -13.11(22). +@strong{28}. The representation for a compilation. See 10.1(2). @end cartouche @noindent -See documentation in the sources of the run time mentioned in paragraph -@strong{53} for details on GNAT-defined aspects of storage pools. +A compilation is represented by a sequence of files presented to the +compiler in a single invocation of the @command{gcc} command. @sp 1 @cartouche @noindent -@strong{57}. The set of restrictions allowed in a pragma -@code{Restrictions}. See 13.12(7). +@strong{29}. Any restrictions on compilations that contain multiple +compilation_units. See 10.1(4). @end cartouche @noindent -All RM defined Restriction identifiers are implemented. The following -additional restriction identifiers are provided. There are two separate -lists of implementation dependent restriction identifiers. The first -set requires consistency throughout a partition (in other words, if the -restriction identifier is used for any compilation unit in the partition, -then all compilation units in the partition must obey the restriction. - -@table @code - -@item Simple_Barriers -@findex Simple_Barriers -This restriction ensures at compile time that barriers in entry declarations -for protected types are restricted to either static boolean expressions or -references to simple boolean variables defined in the private part of the -protected type. No other form of entry barriers is permitted. This is one -of the restrictions of the Ravenscar profile for limited tasking (see also -pragma @code{Profile (Ravenscar)}). - -@item Max_Entry_Queue_Length => Expr -@findex Max_Entry_Queue_Length -This restriction is a declaration that any protected entry compiled in -the scope of the restriction has at most the specified number of -tasks waiting on the entry -at any one time, and so no queue is required. This restriction is not -checked at compile time. A program execution is erroneous if an attempt -is made to queue more than the specified number of tasks on such an entry. - -@item No_Calendar -@findex No_Calendar -This restriction ensures at compile time that there is no implicit or -explicit dependence on the package @code{Ada.Calendar}. - -@item No_Default_Initialization -@findex No_Default_Initialization - -This restriction prohibits any instance of default initialization of variables. -The binder implements a consistency rule which prevents any unit compiled -without the restriction from with'ing a unit with the restriction (this allows -the generation of initialization procedures to be skipped, since you can be -sure that no call is ever generated to an initialization procedure in a unit -with the restriction active). If used in conjunction with Initialize_Scalars or -Normalize_Scalars, the effect is to prohibit all cases of variables declared -without a specific initializer (including the case of OUT scalar parameters). - -@item No_Direct_Boolean_Operators -@findex No_Direct_Boolean_Operators -This restriction ensures that no logical (and/or/xor) are used on -operands of type Boolean (or any type derived -from Boolean). This is intended for use in safety critical programs -where the certification protocol requires the use of short-circuit -(and then, or else) forms for all composite boolean operations. - -@item No_Dispatching_Calls -@findex No_Dispatching_Calls -This restriction ensures at compile time that the code generated by the -compiler involves no dispatching calls. The use of this restriction allows the -safe use of record extensions, classwide membership tests and other classwide -features not involving implicit dispatching. This restriction ensures that -the code contains no indirect calls through a dispatching mechanism. Note that -this includes internally-generated calls created by the compiler, for example -in the implementation of class-wide objects assignments. The -membership test is allowed in the presence of this restriction, because its -implementation requires no dispatching. -This restriction is comparable to the official Ada restriction -@code{No_Dispatch} except that it is a bit less restrictive in that it allows -all classwide constructs that do not imply dispatching. -The following example indicates constructs that violate this restriction. - -@smallexample -package Pkg is - type T is tagged record - Data : Natural; - end record; - procedure P (X : T); - - type DT is new T with record - More_Data : Natural; - end record; - procedure Q (X : DT); -end Pkg; - -with Pkg; use Pkg; -procedure Example is - procedure Test (O : T'Class) is - N : Natural := O'Size;-- Error: Dispatching call - C : T'Class := O; -- Error: implicit Dispatching Call - begin - if O in DT'Class then -- OK : Membership test - Q (DT (O)); -- OK : Type conversion plus direct call - else - P (O); -- Error: Dispatching call - end if; - end Test; - - Obj : DT; -begin - P (Obj); -- OK : Direct call - P (T (Obj)); -- OK : Type conversion plus direct call - P (T'Class (Obj)); -- Error: Dispatching call - - Test (Obj); -- OK : Type conversion - - if Obj in T'Class then -- OK : Membership test - null; - end if; -end Example; -@end smallexample - -@item No_Dynamic_Attachment -@findex No_Dynamic_Attachment -This restriction ensures that there is no call to any of the operations -defined in package Ada.Interrupts. - -@item No_Enumeration_Maps -@findex No_Enumeration_Maps -This restriction ensures at compile time that no operations requiring -enumeration maps are used (that is Image and Value attributes applied -to enumeration types). - -@item No_Entry_Calls_In_Elaboration_Code -@findex No_Entry_Calls_In_Elaboration_Code -This restriction ensures at compile time that no task or protected entry -calls are made during elaboration code. As a result of the use of this -restriction, the compiler can assume that no code past an accept statement -in a task can be executed at elaboration time. - -@item No_Exception_Handlers -@findex No_Exception_Handlers -This restriction ensures at compile time that there are no explicit -exception handlers. It also indicates that no exception propagation will -be provided. In this mode, exceptions may be raised but will result in -an immediate call to the last chance handler, a routine that the user -must define with the following profile: - -@smallexample @c ada -procedure Last_Chance_Handler - (Source_Location : System.Address; Line : Integer); -pragma Export (C, Last_Chance_Handler, - "__gnat_last_chance_handler"); -@end smallexample - -The parameter is a C null-terminated string representing a message to be -associated with the exception (typically the source location of the raise -statement generated by the compiler). The Line parameter when nonzero -represents the line number in the source program where the raise occurs. - -@item No_Exception_Propagation -@findex No_Exception_Propagation -This restriction guarantees that exceptions are never propagated to an outer -subprogram scope). The only case in which an exception may be raised is when -the handler is statically in the same subprogram, so that the effect of a raise -is essentially like a goto statement. Any other raise statement (implicit or -explicit) will be considered unhandled. Exception handlers are allowed, but may -not contain an exception occurrence identifier (exception choice). In addition -use of the package GNAT.Current_Exception is not permitted, and reraise -statements (raise with no operand) are not permitted. - -@item No_Exception_Registration -@findex No_Exception_Registration -This restriction ensures at compile time that no stream operations for -types Exception_Id or Exception_Occurrence are used. This also makes it -impossible to pass exceptions to or from a partition with this restriction -in a distributed environment. If this exception is active, then the generated -code is simplified by omitting the otherwise-required global registration -of exceptions when they are declared. - -@item No_Finalization -@findex No_Finalization -This restriction disables the language features described in chapter 7.6 of the -Ada 2005 RM as well as all form of code generation performed by the compiler to -support these features. The following types are no longer considered controlled -when this restriction is in effect: -@itemize @bullet -@item -@code{Ada.Finalization.Controlled} -@item -@code{Ada.Finalization.Limited_Controlled} -@item -Derivations from @code{Controlled} or @code{Limited_Controlled} -@item -Class-wide types -@item -Protected types -@item -Task types -@item -Array and record types with controlled components -@end itemize -The compiler no longer generates code to initialize, finalize or adjust an -object or a nested component, either declared on the stack or on the heap. The -deallocation of a controlled object no longer finalizes its contents. - -@item No_Implicit_Conditionals -@findex No_Implicit_Conditionals -This restriction ensures that the generated code does not contain any -implicit conditionals, either by modifying the generated code where possible, -or by rejecting any construct that would otherwise generate an implicit -conditional. Note that this check does not include run time constraint -checks, which on some targets may generate implicit conditionals as -well. To control the latter, constraint checks can be suppressed in the -normal manner. Constructs generating implicit conditionals include comparisons -of composite objects and the Max/Min attributes. +No single file can contain more than one compilation unit, but any +sequence of files can be presented to the compiler as a single +compilation. -@item No_Implicit_Dynamic_Code -@findex No_Implicit_Dynamic_Code -@cindex trampoline -This restriction prevents the compiler from building ``trampolines''. -This is a structure that is built on the stack and contains dynamic -code to be executed at run time. On some targets, a trampoline is -built for the following features: @code{Access}, -@code{Unrestricted_Access}, or @code{Address} of a nested subprogram; -nested task bodies; primitive operations of nested tagged types. -Trampolines do not work on machines that prevent execution of stack -data. For example, on windows systems, enabling DEP (data execution -protection) will cause trampolines to raise an exception. -Trampolines are also quite slow at run time. +@sp 1 +@cartouche +@noindent +@strong{30}. The mechanisms for creating an environment and for adding +and replacing compilation units. See 10.1.4(3). +@end cartouche +@noindent +See separate section on compilation model. -On many targets, trampolines have been largely eliminated. Look at the -version of system.ads for your target --- if it has -Always_Compatible_Rep equal to False, then trampolines are largely -eliminated. In particular, a trampoline is built for the following -features: @code{Address} of a nested subprogram; -@code{Access} or @code{Unrestricted_Access} of a nested subprogram, -but only if pragma Favor_Top_Level applies, or the access type has a -foreign-language convention; primitive operations of nested tagged -types. +@sp 1 +@cartouche +@noindent +@strong{31}. The manner of explicitly assigning library units to a +partition. See 10.2(2). +@end cartouche +@noindent +If a unit contains an Ada main program, then the Ada units for the partition +are determined by recursive application of the rules in the Ada Reference +Manual section 10.2(2-6). In other words, the Ada units will be those that +are needed by the main program, and then this definition of need is applied +recursively to those units, and the partition contains the transitive +closure determined by this relationship. In short, all the necessary units +are included, with no need to explicitly specify the list. If additional +units are required, e.g.@: by foreign language units, then all units must be +mentioned in the context clause of one of the needed Ada units. -@item No_Implicit_Loops -@findex No_Implicit_Loops -This restriction ensures that the generated code does not contain any -implicit @code{for} loops, either by modifying -the generated code where possible, -or by rejecting any construct that would otherwise generate an implicit -@code{for} loop. If this restriction is active, it is possible to build -large array aggregates with all static components without generating an -intermediate temporary, and without generating a loop to initialize individual -components. Otherwise, a loop is created for arrays larger than about 5000 -scalar components. +If the partition contains no main program, or if the main program is in +a language other than Ada, then GNAT +provides the binder options @option{-z} and @option{-n} respectively, and in +this case a list of units can be explicitly supplied to the binder for +inclusion in the partition (all units needed by these units will also +be included automatically). For full details on the use of these +options, refer to @ref{The GNAT Make Program gnatmake,,, gnat_ugn, +@value{EDITION} User's Guide}. -@item No_Initialize_Scalars -@findex No_Initialize_Scalars -This restriction ensures that no unit in the partition is compiled with -pragma Initialize_Scalars. This allows the generation of more efficient -code, and in particular eliminates dummy null initialization routines that -are otherwise generated for some record and array types. +@sp 1 +@cartouche +@noindent +@strong{32}. The implementation-defined means, if any, of specifying +which compilation units are needed by a given compilation unit. See +10.2(2). +@end cartouche +@noindent +The units needed by a given compilation unit are as defined in +the Ada Reference Manual section 10.2(2-6). There are no +implementation-defined pragmas or other implementation-defined +means for specifying needed units. -@item No_Local_Protected_Objects -@findex No_Local_Protected_Objects -This restriction ensures at compile time that protected objects are -only declared at the library level. +@sp 1 +@cartouche +@noindent +@strong{33}. The manner of designating the main subprogram of a +partition. See 10.2(7). +@end cartouche +@noindent +The main program is designated by providing the name of the +corresponding @file{ALI} file as the input parameter to the binder. -@item No_Protected_Type_Allocators -@findex No_Protected_Type_Allocators -This restriction ensures at compile time that there are no allocator -expressions that attempt to allocate protected objects. +@sp 1 +@cartouche +@noindent +@strong{34}. The order of elaboration of @code{library_items}. See +10.2(18). +@end cartouche +@noindent +The first constraint on ordering is that it meets the requirements of +Chapter 10 of the Ada Reference Manual. This still leaves some +implementation dependent choices, which are resolved by first +elaborating bodies as early as possible (i.e., in preference to specs +where there is a choice), and second by evaluating the immediate with +clauses of a unit to determine the probably best choice, and +third by elaborating in alphabetical order of unit names +where a choice still remains. -@item No_Relative_Delay -@findex No_Relative_Delay -This restriction ensures at compile time that there are no delay relative -statements and prevents expressions such as @code{delay 1.23;} from appearing -in source code. +@sp 1 +@cartouche +@noindent +@strong{35}. Parameter passing and function return for the main +subprogram. See 10.2(21). +@end cartouche +@noindent +The main program has no parameters. It may be a procedure, or a function +returning an integer type. In the latter case, the returned integer +value is the return code of the program (overriding any value that +may have been set by a call to @code{Ada.Command_Line.Set_Exit_Status}). -@item No_Requeue_Statements -@findex No_Requeue_Statements -This restriction ensures at compile time that no requeue statements are -permitted and prevents keyword @code{requeue} from being used in source code. +@sp 1 +@cartouche +@noindent +@strong{36}. The mechanisms for building and running partitions. See +10.2(24). +@end cartouche +@noindent +GNAT itself supports programs with only a single partition. The GNATDIST +tool provided with the GLADE package (which also includes an implementation +of the PCS) provides a completely flexible method for building and running +programs consisting of multiple partitions. See the separate GLADE manual +for details. -@item No_Secondary_Stack -@findex No_Secondary_Stack -This restriction ensures at compile time that the generated code does not -contain any reference to the secondary stack. The secondary stack is used -to implement functions returning unconstrained objects (arrays or records) -on some targets. +@sp 1 +@cartouche +@noindent +@strong{37}. The details of program execution, including program +termination. See 10.2(25). +@end cartouche +@noindent +See separate section on compilation model. -@item No_Select_Statements -@findex No_Select_Statements -This restriction ensures at compile time no select statements of any kind -are permitted, that is the keyword @code{select} may not appear. -This is one of the restrictions of the Ravenscar -profile for limited tasking (see also pragma @code{Profile (Ravenscar)}). +@sp 1 +@cartouche +@noindent +@strong{38}. The semantics of any non-active partitions supported by the +implementation. See 10.2(28). +@end cartouche +@noindent +Passive partitions are supported on targets where shared memory is +provided by the operating system. See the GLADE reference manual for +further details. -@item No_Standard_Storage_Pools -@findex No_Standard_Storage_Pools -This restriction ensures at compile time that no access types -use the standard default storage pool. Any access type declared must -have an explicit Storage_Pool attribute defined specifying a -user-defined storage pool. +@sp 1 +@cartouche +@noindent +@strong{39}. The information returned by @code{Exception_Message}. See +11.4.1(10). +@end cartouche +@noindent +Exception message returns the null string unless a specific message has +been passed by the program. -@item No_Stream_Optimizations -@findex No_Stream_Optimizations -This restriction affects the performance of stream operations on types -@code{String}, @code{Wide_String} and @code{Wide_Wide_String}. By default, the -compiler uses block reads and writes when manipulating @code{String} objects -due to their supperior performance. When this restriction is in effect, the -compiler performs all IO operations on a per-character basis. +@sp 1 +@cartouche +@noindent +@strong{40}. The result of @code{Exceptions.Exception_Name} for types +declared within an unnamed @code{block_statement}. See 11.4.1(12). +@end cartouche +@noindent +Blocks have implementation defined names of the form @code{B@var{nnn}} +where @var{nnn} is an integer. -@item No_Streams -@findex No_Streams -This restriction ensures at compile/bind time that there are no -stream objects created and no use of stream attributes. -This restriction does not forbid dependences on the package -@code{Ada.Streams}. So it is permissible to with -@code{Ada.Streams} (or another package that does so itself) -as long as no actual stream objects are created and no -stream attributes are used. +@sp 1 +@cartouche +@noindent +@strong{41}. The information returned by +@code{Exception_Information}. See 11.4.1(13). +@end cartouche +@noindent +@code{Exception_Information} returns a string in the following format: -Note that the use of restriction allows optimization of tagged types, -since they do not need to worry about dispatching stream operations. -To take maximum advantage of this space-saving optimization, any -unit declaring a tagged type should be compiled with the restriction, -though this is not required. +@smallexample +@emph{Exception_Name:} nnnnn +@emph{Message:} mmmmm +@emph{PID:} ppp +@emph{Call stack traceback locations:} +0xhhhh 0xhhhh 0xhhhh ... 0xhhh +@end smallexample -@item No_Task_Attributes_Package -@findex No_Task_Attributes_Package -This restriction ensures at compile time that there are no implicit or -explicit dependencies on the package @code{Ada.Task_Attributes}. +@noindent +where -@item No_Task_Termination -@findex No_Task_Termination -This restriction ensures at compile time that no terminate alternatives -appear in any task body. +@itemize @bullet +@item +@code{nnnn} is the fully qualified name of the exception in all upper +case letters. This line is always present. -@item No_Tasking -@findex No_Tasking -This restriction prevents the declaration of tasks or task types throughout -the partition. It is similar in effect to the use of @code{Max_Tasks => 0} -except that violations are caught at compile time and cause an error message -to be output either by the compiler or binder. +@item +@code{mmmm} is the message (this line present only if message is non-null) -@item Static_Priorities -@findex Static_Priorities -This restriction ensures at compile time that all priority expressions -are static, and that there are no dependencies on the package -@code{Ada.Dynamic_Priorities}. +@item +@code{ppp} is the Process Id value as a decimal integer (this line is +present only if the Process Id is nonzero). Currently we are +not making use of this field. -@item Static_Storage_Size -@findex Static_Storage_Size -This restriction ensures at compile time that any expression appearing -in a Storage_Size pragma or attribute definition clause is static. +@item +The Call stack traceback locations line and the following values +are present only if at least one traceback location was recorded. +The values are given in C style format, with lower case letters +for a-f, and only as many digits present as are necessary. +@end itemize -@end table +@noindent +The line terminator sequence at the end of each line, including +the last line is a single @code{LF} character (@code{16#0A#}). +@sp 1 +@cartouche @noindent -The second set of implementation dependent restriction identifiers -does not require partition-wide consistency. -The restriction may be enforced for a single -compilation unit without any effect on any of the -other compilation units in the partition. +@strong{42}. Implementation-defined check names. See 11.5(27). +@end cartouche +@noindent +The implementation defined check name Alignment_Check controls checking of +address clause values for proper alignment (that is, the address supplied +must be consistent with the alignment of the type). -@table @code +In addition, a user program can add implementation-defined check names +by means of the pragma Check_Name. -@item No_Elaboration_Code -@findex No_Elaboration_Code -This restriction ensures at compile time that no elaboration code is -generated. Note that this is not the same condition as is enforced -by pragma @code{Preelaborate}. There are cases in which pragma -@code{Preelaborate} still permits code to be generated (e.g.@: code -to initialize a large array to all zeroes), and there are cases of units -which do not meet the requirements for pragma @code{Preelaborate}, -but for which no elaboration code is generated. Generally, it is -the case that preelaborable units will meet the restrictions, with -the exception of large aggregates initialized with an others_clause, -and exception declarations (which generate calls to a run-time -registry procedure). This restriction is enforced on -a unit by unit basis, it need not be obeyed consistently -throughout a partition. +@sp 1 +@cartouche +@noindent +@strong{43}. The interpretation of each aspect of representation. See +13.1(20). +@end cartouche +@noindent +See separate section on data representations. -In the case of aggregates with others, if the aggregate has a dynamic -size, there is no way to eliminate the elaboration code (such dynamic -bounds would be incompatible with @code{Preelaborate} in any case). If -the bounds are static, then use of this restriction actually modifies -the code choice of the compiler to avoid generating a loop, and instead -generate the aggregate statically if possible, no matter how many times -the data for the others clause must be repeatedly generated. +@sp 1 +@cartouche +@noindent +@strong{44}. Any restrictions placed upon representation items. See +13.1(20). +@end cartouche +@noindent +See separate section on data representations. -It is not possible to precisely document -the constructs which are compatible with this restriction, since, -unlike most other restrictions, this is not a restriction on the -source code, but a restriction on the generated object code. For -example, if the source contains a declaration: +@sp 1 +@cartouche +@noindent +@strong{45}. The meaning of @code{Size} for indefinite subtypes. See +13.3(48). +@end cartouche +@noindent +Size for an indefinite subtype is the maximum possible size, except that +for the case of a subprogram parameter, the size of the parameter object +is the actual size. -@smallexample - Val : constant Integer := X; -@end smallexample +@sp 1 +@cartouche +@noindent +@strong{46}. The default external representation for a type tag. See +13.3(75). +@end cartouche +@noindent +The default external representation for a type tag is the fully expanded +name of the type in upper case letters. +@sp 1 +@cartouche @noindent -where X is not a static constant, it may be possible, depending -on complex optimization circuitry, for the compiler to figure -out the value of X at compile time, in which case this initialization -can be done by the loader, and requires no initialization code. It -is not possible to document the precise conditions under which the -optimizer can figure this out. +@strong{47}. What determines whether a compilation unit is the same in +two different partitions. See 13.3(76). +@end cartouche +@noindent +A compilation unit is the same in two different partitions if and only +if it derives from the same source file. -Note that this the implementation of this restriction requires full -code generation. If it is used in conjunction with "semantics only" -checking, then some cases of violations may be missed. +@sp 1 +@cartouche +@noindent +@strong{48}. Implementation-defined components. See 13.5.1(15). +@end cartouche +@noindent +The only implementation defined component is the tag for a tagged type, +which contains a pointer to the dispatching table. -@item No_Entry_Queue -@findex No_Entry_Queue -This restriction is a declaration that any protected entry compiled in -the scope of the restriction has at most one task waiting on the entry -at any one time, and so no queue is required. This restriction is not -checked at compile time. A program execution is erroneous if an attempt -is made to queue a second task on such an entry. +@sp 1 +@cartouche +@noindent +@strong{49}. If @code{Word_Size} = @code{Storage_Unit}, the default bit +ordering. See 13.5.3(5). +@end cartouche +@noindent +@code{Word_Size} (32) is not the same as @code{Storage_Unit} (8) for this +implementation, so no non-default bit ordering is supported. The default +bit ordering corresponds to the natural endianness of the target architecture. -@item No_Implementation_Attributes -@findex No_Implementation_Attributes -This restriction checks at compile time that no GNAT-defined attributes -are present. With this restriction, the only attributes that can be used -are those defined in the Ada Reference Manual. +@sp 1 +@cartouche +@noindent +@strong{50}. The contents of the visible part of package @code{System} +and its language-defined children. See 13.7(2). +@end cartouche +@noindent +See the definition of these packages in files @file{system.ads} and +@file{s-stoele.ads}. -@item No_Implementation_Pragmas -@findex No_Implementation_Pragmas -This restriction checks at compile time that no GNAT-defined pragmas -are present. With this restriction, the only pragmas that can be used -are those defined in the Ada Reference Manual. +@sp 1 +@cartouche +@noindent +@strong{51}. The contents of the visible part of package +@code{System.Machine_Code}, and the meaning of +@code{code_statements}. See 13.8(7). +@end cartouche +@noindent +See the definition and documentation in file @file{s-maccod.ads}. -@item No_Implementation_Restrictions -@findex No_Implementation_Restrictions -This restriction checks at compile time that no GNAT-defined restriction -identifiers (other than @code{No_Implementation_Restrictions} itself) -are present. With this restriction, the only other restriction identifiers -that can be used are those defined in the Ada Reference Manual. +@sp 1 +@cartouche +@noindent +@strong{52}. The effect of unchecked conversion. See 13.9(11). +@end cartouche +@noindent +Unchecked conversion between types of the same size +results in an uninterpreted transmission of the bits from one type +to the other. If the types are of unequal sizes, then in the case of +discrete types, a shorter source is first zero or sign extended as +necessary, and a shorter target is simply truncated on the left. +For all non-discrete types, the source is first copied if necessary +to ensure that the alignment requirements of the target are met, then +a pointer is constructed to the source value, and the result is obtained +by dereferencing this pointer after converting it to be a pointer to the +target type. Unchecked conversions where the target subtype is an +unconstrained array are not permitted. If the target alignment is +greater than the source alignment, then a copy of the result is +made with appropriate alignment -@item No_Implicit_Aliasing -@findex No_Implicit_Aliasing -This restriction, which is not required to be partition-wide consistent, -requires an explicit aliased keyword for an object to which 'Access, -'Unchecked_Access, or 'Address is applied, and forbids entirely the use of -the 'Unrestricted_Access attribute for objects. Note: the reason that -Unrestricted_Access is forbidden is that it would require the prefix -to be aliased, and in such cases, it can always be replaced by -the standard attribute Unchecked_Access which is preferable. +@sp 1 +@cartouche +@noindent +@strong{53}. The semantics of operations on invalid representations. +See 13.9.2(10-11). +@end cartouche +@noindent +For assignments and other operations where the use of invalid values cannot +result in erroneous behavior, the compiler ignores the possibility of invalid +values. An exception is raised at the point where an invalid value would +result in erroneous behavior. For example executing: -@item No_Wide_Characters -@findex No_Wide_Characters -This restriction ensures at compile time that no uses of the types -@code{Wide_Character} or @code{Wide_String} or corresponding wide -wide types -appear, and that no wide or wide wide string or character literals -appear in the program (that is literals representing characters not in -type @code{Character}. +@smallexample @c ada +procedure invalidvals is + X : Integer := -1; + Y : Natural range 1 .. 10; + for Y'Address use X'Address; + Z : Natural range 1 .. 10; + A : array (Natural range 1 .. 10) of Integer; +begin + Z := Y; -- no exception + A (Z) := 3; -- exception raised; +end; +@end smallexample -@item SPARK -@findex SPARK -This restriction checks at compile time that some constructs forbidden in -SPARK are not present. The SPARK version used as a reference is the same as -the Ada mode for the unit, so a unit compiled in Ada 95 mode with SPARK -restrictions will be checked for constructs forbidden in SPARK 95. -Error messages related to SPARK restriction have the form: +@noindent +As indicated, an exception is raised on the array assignment, but not +on the simple assignment of the invalid negative value from Y to Z. -@smallexample -violation of restriction "Spark" at - -@end smallexample +@sp 1 +@cartouche +@noindent +@strong{53}. The manner of choosing a storage pool for an access type +when @code{Storage_Pool} is not specified for the type. See 13.11(17). +@end cartouche +@noindent +There are 3 different standard pools used by the compiler when +@code{Storage_Pool} is not specified depending whether the type is local +to a subprogram or defined at the library level and whether +@code{Storage_Size}is specified or not. See documentation in the runtime +library units @code{System.Pool_Global}, @code{System.Pool_Size} and +@code{System.Pool_Local} in files @file{s-poosiz.ads}, +@file{s-pooglo.ads} and @file{s-pooloc.ads} for full details on the +default pools used. -This is not a replacement for the semantic checks performed by the -SPARK Examiner tool, as the compiler only deals currently with code, -not at all with SPARK annotations and does not guarantee catching all -cases of constructs forbidden by SPARK. +@sp 1 +@cartouche +@noindent +@strong{54}. Whether or not the implementation provides user-accessible +names for the standard pool type(s). See 13.11(17). +@end cartouche +@noindent -Thus it may well be the case that code which -passes the compiler in SPARK mode is rejected by the SPARK Examiner, -e.g. due to the different visibility rules of the Examiner based on -SPARK @code{inherit} annotations. +See documentation in the sources of the run time mentioned in paragraph +@strong{53} . All these pools are accessible by means of @code{with}'ing +these units. -This restriction can be useful in providing an initial filter for -code developed using SPARK, or in examining legacy code to see how far -it is from meeting SPARK restrictions. +@sp 1 +@cartouche +@noindent +@strong{55}. The meaning of @code{Storage_Size}. See 13.11(18). +@end cartouche +@noindent +@code{Storage_Size} is measured in storage units, and refers to the +total space available for an access type collection, or to the primary +stack space for a task. -@end table +@sp 1 +@cartouche +@noindent +@strong{56}. Implementation-defined aspects of storage pools. See +13.11(22). +@end cartouche +@noindent +See documentation in the sources of the run time mentioned in paragraph +@strong{53} for details on GNAT-defined aspects of storage pools. + +@sp 1 +@cartouche +@noindent +@strong{57}. The set of restrictions allowed in a pragma +@code{Restrictions}. See 13.12(7). +@end cartouche +@noindent +@xref{Implementation Defined Restrictions}. @sp 1 @cartouche @@ -9969,7 +10532,7 @@ of delay expirations for lower priority tasks. @sp 1 @cartouche @noindent -@strong{100}. Implementation defined task dispatching. See D.2.2(18). +@strong{100}. Implementation-defined task dispatching. See D.2.2(18). @end cartouche @noindent @c SGI info: diff --git a/gcc/ada/gnat_ugn.texi b/gcc/ada/gnat_ugn.texi index c9951b7..4d0c01c 100644 --- a/gcc/ada/gnat_ugn.texi +++ b/gcc/ada/gnat_ugn.texi @@ -5472,7 +5472,9 @@ This switch activates warnings for modulus values that seem suspicious. The cases caught are where the size is the same as the modulus (e.g. a modulus of 7 with a size of 7 bits), and modulus values of 32 or 64 with no size clause. The guess in both cases is that 2**x was intended -rather than x. The default is that these warnings are given. +rather than x. In addition expressions of the form 2*x for small x +generate a warning (the almost certainly accurate guess being that +2**x was intended). The default is that these warnings are given. @item -gnatw.M @emph{Disable warnings on suspicious modulus values.} diff --git a/gcc/ada/prj-nmsc.adb b/gcc/ada/prj-nmsc.adb index 2b65c15..284f9f0 100644 --- a/gcc/ada/prj-nmsc.adb +++ b/gcc/ada/prj-nmsc.adb @@ -8175,7 +8175,7 @@ package body Prj.Nmsc is procedure Check_Aggregated (Project : Project_Id; Data : in out Tree_Processing_Data); - -- Check aggregated projets which should not be externally built. + -- Check aggregated projects which should not be externally built. -- What is Data??? if same as outer Data, why passed??? -- What exact check is performed here??? Seems a bad idea to have -- two procedures with such close names ??? diff --git a/gcc/ada/s-dim.ads b/gcc/ada/s-dim.ads index 183aaab..ceb10d4 100644 --- a/gcc/ada/s-dim.ads +++ b/gcc/ada/s-dim.ads @@ -66,4 +66,6 @@ -- 'm' is the symbolic name of dimensioned subtype Length package System.Dim is + pragma Pure; + end System.Dim; diff --git a/gcc/ada/sem_aggr.adb b/gcc/ada/sem_aggr.adb index 1b7822c..9932352 100644 --- a/gcc/ada/sem_aggr.adb +++ b/gcc/ada/sem_aggr.adb @@ -3920,9 +3920,10 @@ package body Sem_Aggr is and then Present (Expression (Parent (Component))) then Expr := - New_Copy_Tree (Expression (Parent (Component)), - New_Scope => Current_Scope, - New_Sloc => Sloc (N)); + New_Copy_Tree + (Expression (Parent (Component)), + New_Scope => Current_Scope, + New_Sloc => Sloc (N)); Add_Association (Component => Component, diff --git a/gcc/ada/sem_dim.adb b/gcc/ada/sem_dim.adb index d28e23f..8e65d22 100644 --- a/gcc/ada/sem_dim.adb +++ b/gcc/ada/sem_dim.adb @@ -311,6 +311,10 @@ package body Sem_Dim is -- Given a dimension vector and a dimension system, return the proper -- string of symbols. + function Is_Dim_IO_Package_Entity (E : Entity_Id) return Boolean; + -- Return True if E is the package entity of System.Dim.Float_IO or + -- System.Dim.Integer_IO. + function Is_Invalid (Position : Dimension_Position) return Boolean; -- Return True if Pos denotes the invalid position @@ -2165,7 +2169,6 @@ package body Sem_Dim is Dims_Of_Actual : Dimension_Type; Etyp : Entity_Id; New_Str_Lit : Node_Id := Empty; - Package_Name : Name_Id; System : System_Type; function Has_Dimension_Symbols return Boolean; @@ -2240,19 +2243,10 @@ package body Sem_Dim is then Ent := Cunit_Entity (Get_Source_Unit (Ent)); - -- Verify that the generic package is System.Dim.Float_IO or - -- System.Dim.Integer_IO. - - if Is_Library_Level_Entity (Ent) then - Package_Name := Chars (Ent); + -- Verify that the generic package is either + -- System.Dim.Float_IO or System.Dim.Integer_IO. - if Package_Name = Name_Float_IO - or else - Package_Name = Name_Integer_IO - then - return Chars (Scope (Ent)) = Name_Dim; - end if; - end if; + return Is_Dim_IO_Package_Entity (Ent); end if; end if; @@ -2501,6 +2495,26 @@ package body Sem_Dim is return Exists (System_Of (Typ)); end Has_Dimension_System; + ------------------------------ + -- Is_Dim_IO_Package_Entity -- + ------------------------------ + + function Is_Dim_IO_Package_Entity (E : Entity_Id) return Boolean is + begin + -- Check the package entity is standard and its scope is either + -- System.Dim.Float_IO or System.Dim.Integer_IO. + + if Is_Library_Level_Entity (E) + and then (Chars (E) = Name_Float_IO + or else Chars (E) = Name_Integer_IO) + then + return Chars (Scope (E)) = Name_Dim + and Chars (Scope (Scope (E))) = Name_System; + end if; + + return False; + end Is_Dim_IO_Package_Entity; + ------------------------------------- -- Is_Dim_IO_Package_Instantiation -- ------------------------------------- @@ -2513,16 +2527,10 @@ package body Sem_Dim is if Is_Entity_Name (Gen_Id) then Ent := Entity (Gen_Id); - -- Is it really OK just to test names ??? why??? + -- Verify that the instantiated package is either System.Dim.Float_IO + -- or System.Dim.Integer_IO. - if Is_Library_Level_Entity (Ent) - and then - (Chars (Ent) = Name_Float_IO - or else - Chars (Ent) = Name_Integer_IO) - then - return Chars (Scope (Ent)) = Name_Dim; - end if; + return Is_Dim_IO_Package_Entity (Ent); end if; return False; -- 2.7.4