These are also in the repository. Chuck Swart -------------BEGINNING OF IR---------------- VHDL Issue Number: 2097 Language_Version VHDL-2002 Classification Language Definition Problem Summary Operations with Array aggregates Relevant_LRM_Sections Related_Issues Key_Words_and_Phrases Authors_Name Jim Lewis Authors_Phone_Number 503-590-4787 Authors_Fax_Number Authors_Email_Address jim@synthworks.com Authors_Affiliation SynthWorks Authors_Address1 Authors_Address2 Authors_Address3 Current Status: Analyzed Superseded By: ------------------------ Date Submitted: 13 June 2006 Date Analyzed: 22 September 2006 Author of Analysis: Lance Thompson Revision Number: 2 Date Last Revised: 13 June 2006 Description of Problem ---------------------- The following code is a desirable hardware coding style, however, currently I have an issue with it in that some synthesis implementations accept it and others don't. signal ASel, BSel : std_logic; signal Y, A, B : std_logic_vector(7 downto 0) ; Y <= (A and (A'range => ASel)) or (B and (B'range => BSel)) ; It would be helpful to know if one or the other is correct. Proposed Resolution ------------------- TBD VASG-ISAC Analysis & Rationale ------------------------------ Given the following object declarations, signal ASel, BSel : std_logic; signal Y, A, B : std_logic_vector(7 downto 0) ; The submitter asks if this statement is legal Y <= (A and (A'range => ASel)) or (B and (B'range => BSel)) ; Taking the statement in sections, y <= ( expression ) or ( expression) is certainly ok, so the question must revolve around the expression "A and ( A’range => ASel )" and its counterpart for B. The form "name and aggregate" is a permitted form of the call to the AND function. The reviewer supposes that the question is focused on the aggregate portion of the expression. Pertinent LRM clauses are copied below for the readers convenience. One of the permissible forms of aggregate described in 7.3.2 resolves to ( discrete_range => expression ) ASel is a name which is a valid expression fits the criteria for the right hand portion of the aggregate. For the left hand portion, we look to the description of the predefined attribute a'range. A’range is defined to return the range of the object A. The range is of a form that satisfies the definition of a discrete range. 7.3.2 also states that the type of the aggregate must be solely determinable from its context. If overload resolution has determined that function "and"( l, r : std_ulogic_vector ) return std_ulogic_vector; is the only applicable function, then the type of the aggregate is determined by the type required by that AND function. Clause 7.3.2.2 goes on to describe how the bounds and direction are determined. The direction is "to" because the index subtype of the base type (std_ulogic_vector) of the aggregate is natural and natural’s direction is to. Note that the direction is not derived from the direction specified in the discrete range of the aggregate. The left and right bounds are 0 and 7 respectively, the smallest and largest numbers in the discrete range. So, the form of the expression appears reasonable. But another issue may be whether or not the correct AND function can be determined. 10.5 rule a specifies that rules requiring names or expressions to have a required type are considered. Starting with the statement, the assignment to y requires that the result of the expression be a std_ulogic_vector. There is only 1 OR function that satisfies that rule assuming that ieee.std_logic_1164 is the only package in play. That OR function requires that it’s left and right expressions be std_ulogic_vector’s thus requiring the single and function: function "and"( l, r : std_ulogic_vector ) return std_ulogic_vector; The right expression of the and function must be a std_ulogic_vector, so that establishes the type required by the aggregate expression used in that position. So, it would seem that all the language requirements have been met and the statement is quite legal. 3.2.1.1 For a formal parameter of a subprogram that is of an unconstrained array type and that is associated in whole (see 4.3.2.2), the index ranges are obtained from the corresponding association element in the applicable subprogram call. 4.3.2.2 An association list establishes correspondences between formal or local generic, port, or parameter names on the one hand and local or actual names or expressions on the other. association_list ::= association_element { , association_element } association_element ::= [ formal_part => ] actual_part formal_part ::= formal_designator | function_name ( formal_designator ) | type_mark ( formal_designator ) formal_designator ::= generic_name | port_name | parameter_name actual_part ::= actual_designator | function_name ( actual_designator ) | type_mark ( actual_designator ) actual_designator ::= expression | signal_name | variable_name | file_name | open Each association element in an association list associates one actual designator with the corresponding interface element in the interface list of a subprogram declaration, component declaration, entity declaration, or block statement. The corresponding interface element is determined either by position or by name. An association element is said to be named if the formal designator appears explicitly; otherwise, it is said to be positional. For a positional association, an actual designator at a given position in an association list corresponds to the interface element at the same position in the interface list. Named associations can be given in any order, but if both positional and named associations appear in the same association list, then all positional associations must occur first at their normal position. Hence once a named association is used, the rest of the association list must use only named associations. In the following paragraphs, the term actual refers to an actual designator, and the term formal refers to a formal designator. The formal part of a named association element may be in the form of a function call, where the single argument of the function is the formal designator itself, if and only if the mode of the formal is out, inout, buffer, or linkage, and if the actual is not open. In this case, the function name must denote a function whose single parameter is of the type of the formal and whose result is the type of the corresponding actual. Such a conversion function provides for type conversion in the event that data flows from the formal to the actual. Alternatively, the formal part of a named association element may be in the form of a type conversion, where the expression to be converted is the formal designator itself, if and only if the mode of the formal is out, inout, buffer, or linkage, and if the actual is not open. In this case, the base type denoted by the type mark must be the same as the base type of the corresponding actual. Such a type conversion provides for type conversion in the event that data flows from the formal to the actual. It is an error if the type of the formal is not closely related to the type of the actual. (See 7.3.5.) Similarly, the actual part of a (named or positional) association element may be in the form of a function call, where the single argument of the function is the actual designator itself, if and only if the mode of the formal is in, inout, or linkage, and if the actual is not open. In this case, the function name must denote a function whose single parameter is of the type of the actual, and whose result is the type of the corresponding formal. In addition, the formal must not be of class constant for this interpretation to hold (the actual is interpreted as an expression that is a function call if the class of the formal is constant). Such a conversion function provides for type conversion in the event that data flows from the actual to the formal. Alternatively, the actual part of a (named or positional) association element may be in the form of a type conversion, where the expression to be type converted is the actual designator itself, if and only if the mode of the formal is in, inout, or linkage, and if the actual is not open. In this case, the base type denoted by the type mark must be the same as the base type of the corresponding formal. Such a type conversion provides for type conversion in the event that data flows from the actual to the formal. It is an error if the type of the actual is not closely related to the type of the formal. The type of the actual (after applying the conversion function or type conversion, if present in the actual part) must be the same as the type of the corresponding formal, if the mode of the formal is in, inout, or linkage, and if the actual is not open. Similarly, if the mode of the formal is out, inout, buffer, or linkage, and if the actual is not open, then the type of the formal (after applying the conversion function or type conversion, if present in the formal part) must be the same as the corresponding actual. For the association of signals with corresponding formal ports, association of a formal of a given composite type with an actual of the same type is equivalent to the association of each scalar subelement of the formal with the matching subelement of the actual, provided that no conversion function or type conversion is present in either the actual part or the formal part of the association element. If a conversion function or type conversion is present, then the entire formal is considered to be associated with the entire actual. Similarly, for the association of actuals with corresponding formal subprogram parameters, association of a formal parameter of a given composite type with an actual of the same type is equivalent to the association of each scalar subelement of the formal parameter with the matching subelement of the actual. Different parameter passing mechanisms may be required in each case, but in both cases the associations will have an equivalent effect. This equivalence applies provided that no actual is accessible by more than one path (see 2.1.1.1). A formal must be either an explicitly declared interface object or member (see Clause 3) of such an interface object. In the former case, such a formal is said to be associated in whole. In the latter cases, named association must be used to associate the formal and actual; the subelements of such a formal are said to be associated individually. Furthermore, every scalar subelement of the explicitly declared interface object must be associated exactly once with an actual (or subelement thereof) in the same association list, and all such associations must appear in a contiguous sequence within that association list. Each association element that associates a slice or subelement (or slice thereof) of an interface object must identify the formal with a locally static name. If an interface element in an interface list includes a default expression for a formal generic, for a formal port of any mode other than linkage, or for a formal variable or constant parameter of mode in, then any corresponding association list need not include an association element for that interface element. If the association element is not included in the association list, or if the actual is open, then the value of the default expression is used as the actual expression or signal value in an implicit association element for that interface element. It is an error if an actual of open is associated with a formal that is associated individually. An actual of open counts as the single association allowed for the corresponding formal, but does not supply a constant, signal, or variable (as is appropriate to the object class of the formal) to the formal. NOTES 1-It is a consequence of these rules that, if an association element is omitted from an association list in order to make use of the default expression on the corresponding interface element, all subsequent association elements in that association list must be named associations. 2-Although a default expression can appear in an interface element that declares a (local or formal) port, such a default expression is not interpreted as the value of an implicit association element for that port. Instead, the value of the expression is used to determine the effective value of that port during simulation if the port is left unconnected (see 12.6.2). 3-Named association may not be used when invoking implicitly defined operators, since the formal parameters of these operators are not named (see 7.2). 4-Since information flows only from the actual to the formal when the mode of the formal is in, and since a function call is itself an expression, the actual associated with a formal of object class constant is never interpreted as a conversion function or a type conversion converting an actual designator that is an expression. Thus, the following association element is legal: Param => F (open) under the conditions that Param is a constant formal and F is a function returning the same base type as that of Param and having one or more parameters, all of which may be defaulted. It is an error if a conversion function or type conversion appears in the actual part when the actual designator is open. 7.3.2 An aggregate is a basic operation (see the introduction to Clause 3) that combines one or more values into a composite value of a record or array type. aggregate ::= ( element_association { , element_association } ) element_association ::= [ choices => ] expression choices ::= choice { | choice } choice ::= simple_expression | discrete_range | element_simple_name | others Each element association associates an expression with elements (possibly none). An element association is said to be named if the elements are specified explicitly by choices; otherwise, it is said to be positional. For a positional association, each element is implicitly specified by position in the textual order of the elements in the corresponding type declaration. Both named and positional associations can be used in the same aggregate, with all positional associations appearing first (in textual order) and all named associations appearing next (in any order, except that it is an error if any associations follow an others association). Aggregates containing a single element association must always be specified using named association in order to distinguish them from parenthesized expressions. An element association with a choice that is an element simple name is only allowed in a record aggregate. An element association with a choice that is a simple expression or a discrete range is only allowed in an array aggregate: a simple expression specifies the element at the corresponding index value, whereas a discrete range specifies the elements at each of the index values in the range. The discrete range has no significance other than to define the set of choices implied by the discrete range. In particular, the direction specified or implied by the discrete range has no significance. An element association with the choice others is allowed in either an array aggregate or a record aggregate if the association appears last and has this single choice; it specifies all remaining elements, if any. Each element of the value defined by an aggregate must be represented once and only once in the aggregate. The type of an aggregate must be determinable solely from the context in which the aggregate appears, excluding the aggregate itself but using the fact that the type of the aggregate must be a composite type. The type of an aggregate in turn determines the required type for each of its elements. 7.3.2.2 For an aggregate of a one-dimensional array type, each choice must specify values of the index type, and the expression of each element association must be of the element type. An aggregate of an n-dimensional array type, where n is greater than 1, is written as a one-dimensional aggregate in which the index subtype of the aggregate is given by the first index position of the array type, and the expression specified for each element association is an (n-1)-dimensional array or array aggregate, which is called a subaggregate. A string or bit string literal is allowed as a subaggregate in the place of any aggregate of a one-dimensional array of a character type. Apart from a final element association with the single choice others, the rest (if any) of the element associations of an array aggregate must be either all positional or all named. A named association of an array aggregate is allowed to have a choice that is not locally static, or likewise a choice that is a null range, only if the aggregate includes a single element association and this element association has a single choice. An others choice is locally static if the applicable index constraint is locally static. The subtype of an array aggregate that has an others choice must be determinable from the context. That is, an array aggregate with an others choice must appear only in one of the following contexts: a) As an actual associated with a formal parameter or formal generic declared to be of a constrained array subtype (or subelement thereof) b) As the default expression defining the default initial value of a port declared to be of a constrained array subtype c) As the result expression of a function, where the corresponding function result type is a constrained array subtype d) As a value expression in an assignment statement, where the target is a declared object, and the subtype of the target is a constrained array subtype (or subelement of such a declared object) e) As the expression defining the initial value of a constant or variable object, where that object is declared to be of a constrained array subtype f) As the expression defining the default values of signals in a signal declaration, where the corresponding subtype is a constrained array subtype g) As the expression defining the value of an attribute in an attribute specification, where that attribute is declared to be of a constrained array subtype h) As the operand of a qualified expression whose type mark denotes a constrained array subtype i) As a subaggregate nested within an aggregate, where that aggregate itself appears in one of these contexts The bounds of an array that does not have an others choice are determined as follows. If the aggregate appears in one of the contexts in the preceding list, then the direction of the index subtype of the aggregate is that of the corresponding constrained array subtype; otherwise, the direction of the index subtype of the aggregate is that of the index subtype of the base type of the aggregate. For an aggregate that has named associations, the leftmost and rightmost bounds are determined by the direction of the index subtype of the aggregate and the smallest and largest choices given. For a positional aggregate, the leftmost bound is determined by the applicable index constraint if the aggregate appears in one of the contexts in the preceding list; otherwise, the leftmost bound is given by S'LEFT where S is the index subtype of the base type of the array. In either case, the rightmost bound is determined by the direction of the index subtype and the number of elements. The evaluation of an array aggregate that is not a subaggregate proceeds in two steps. First, the choices of this aggregate and of its subaggregates, if any, are evaluated in some order (or lack thereof) that is not defined by the language. Second, the expressions of the element associations of the array aggregate are evaluated in some order that is not defined by the language; the expression of a named association is evaluated once for each associated element. The evaluation of a subaggregate consists of this second step (the first step is omitted since the choices have already been evaluated). For the evaluation of an aggregate that is not a null array, a check is made that the index values defined by choices belong to the corresponding index subtypes, and also that the value of each element of the aggregate belongs to the subtype of this element. For a multidimensional aggregate of dimension n, a check is made that all (n-1)-dimensional subaggregates have the same bounds. It is an error if any one of these checks fails. 12.3.1.4 Elaboration of an object declaration that declares an object other than a file object or an object of a protected type proceeds as follows: a) The subtype indication is first elaborated; this establishes the subtype of the object. b) If the object declaration includes an explicit initialization expression, then the initial value of the object is obtained by evaluating the expression. It is an error if the value of the expression does not belong to the subtype of the object; if the object is an array object, then an implicit subtype conversion is first performed on the value unless the object is a constant whose subtype indication denotes an unconstrained array type. Otherwise, any implicit initial value for the object is determined. c) The object is created. d) Any initial value is assigned to the object. The initialization of such an object (either the declared object or one of its subelements) involves a check that the initial value belongs to the subtype of the object. For an array object declared by an object declaration, an implicit subtype conversion is first applied as for an assignment statement, unless the object is a constant whose subtype is an unconstrained array type. The elaboration of a file object declaration consists of the elaboration of the subtype indication followed by the creation of the object. If the file object declaration contains file open information, then the implicit call to FILE_OPEN is then executed (see 4.3.1.4). The elaboration of an object of a protected type consists of the elaboration of the subtype indication, followed by creation of the object. Creation of the object consists of elaborating, in the order given, each of the declarative items in the protected type body. NOTES 1-These rules apply to all object declarations other than port and generic declarations, which are elaborated as outlined in 12.2.1 through 12.2.4. 2-The expression initializing a constant object need not be a static expression. 3-Each object whose type is a protected type creates an instance of the shared objects. VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- No changes needed. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- No changes needed. -------------END OF IR---------------- -------------BEGINNING OF IR---------------- VHDL Issue Number: 2099 Language_Version VHDL-2002 Classification Language Definition Problem Summary Alias declarations introduce homographs Relevant_LRM_Sections 4.3.3.2 Nonobject aliases 10.3 Visibility Related_Issues Key_Words_and_Phrases nonobject aliases, homographs Authors_Name Peter Ashenden Authors_Phone_Number +61 414 709 106 Authors_Fax_Number Authors_Email_Address peter@ashenden.com.au Authors_Affiliation Ashenden Designs Authors_Address1 Authors_Address2 Authors_Address3 Current Status: Analyzed Superseded By: ------------------------ Date Submitted: 14 June 2006 Date Analyzed: 26 September 2006 Author of Analysis: Chuck Swart Revision Number: 2 Date Last Revised: Description of Problem ---------------------- This issue was originally raised by John Ries in the Accellera VHDL-TC review of P1076-2006/D2.11 and entered as Bugzilla bug #44: Description: [reply] Opened: 2006-06-07 06:03 On page 114 in non-object alias it states : c) If the name denotes an enumeration type or a subtype of an enumeration type, then one implicit alias declaration for each of the literals of the base type immediately follows the alias declaration for the enumeration type; each such implicit declaration has, as its alias designator, the simple name or character literal of the literal and has, as its name, a name constructed by taking the name of the alias for the enumeration type or subtype and substituting the simple name or character literal being aliased for the simple name of the type or subtype. Each implicit alias has a signature that matches the parameter and result type profile of the literal being aliased. d) Alternatively, if the name denotes a subtype of a physical type, then one implicit alias declaration for each of the units of the base type immediately follows the alias declaration for the physical type; each such implicit declaration has, as its alias designator, the simple name of the unit and has, as its name, a name constructed by taking the name of the alias for the subtype of the physical type and substituting the simple name of the unit being aliased for the simple name of the subtype. e) Finally, if the name denotes a type or a subtype, then implicit alias declarations for each predefined operator operation for the type immediately follow the explicit alias declaration for the type or subtype and, if present, any implicit alias declarations for literals or units of the type. Each implicit alias has a signature that matches the parameter and result type profile of the implicit operation being aliased. What happens if there is a homograph already declared or aliased? For example type my_logic is ( '0', '1', 'X', 'Z'); function "="( a, b: my_logic) return boolean; alias alt_logic is my_logic; -- the following alias are implicit alias '0' is '0' [ return my_logic]; alias '1' is '1' [ return my_logic]; alias 'X' is 'X' [ return my_logic]; alias 'Z' is 'Z' [ return my_logic]; alias "/=" is "/=" [ my_logic, my_logic, return boolean]; alias "=" is "=" [ my_logic, my_logic, return boolean]; -- note implicit "=" not explicit one. It seams to me that all the alias are homographs. In all cases except the "=" these aliases denote the exact same objects so is this an error?. In the case of "=" these are different functions the alias is to the predefined "=" and there is an explicit "=" already declared. Is this an error? What happens if the explicit "=" is declared after the alias? This also raises the question, after I declare an alias to a type is it legal to define an explicit version of a predefined operator on the aliased type? For example library ieee; package mycompare is alias std_logic is ieee.std_logic_1164.std_logic; -- there is an implicit alias alias "=" is ieee.std_logic_1164."="[ieee.std_logic_1164.std_ulogic, ieee.std_logic_1164.std_ulogic, return ieee.std_logic_1164.std_ulogic]; -- Is this legal?? function "=" ( a, b : std_logic) return boolean; .... Does clause 10.3 statement Two declarations that occur immediately within the same declarative region, other than the declarative region of a block implied by a component instantiation or the declarative region of a generic-mapped package or subprogram equivalent to a package instance or a subprogram instance,28 must not be homographs, unless exactly one of them is the implicit declaration of a predefined operation. In such cases, a predefined operation is always hidden by the other homograph. Apply here? ------- Additional Comment #1 From Peter Ashenden 2006-06-11 23:31 [reply] ------- It would appear that the rules for non-object aliases were written under the assumption that the name being aliased is declared in a different declarative region. The example in the LRM illustrates that, with the name BIT being declared in STD.STANDARD. Aliasing a name declared in the same declarative region introduces the issue you raise. I would say that the rule of 10.3 that you quote covers (serendipitously) the case of the explicit declaration of an operation hiding the implicit declaration introduced by the alias declaration. However, it doesn't address the fact that the implicit declaration introduced by the alias declaration is a homograph of the implicit declaration introduced by the type declaration. This is not a new problem; it was latent in the previous revision of the LRM. It might be best to address this through ISAC. ------- Additional Comment #2 From John Ries 2006-06-13 07:57 [reply] ------- This needs to be resolved because the numeric_std package defines two aliases to types. They are alias U_UNSIGNED is UNRESOLVED_UNSIGNED; and alias U_SIGNED is UNRESOLVED_SIGNED; Since the mean of this is unclear, the LRM needs to either remove the aliases from the package or define the behavior ------- Additional Comment #3 From Peter Ashenden 2006-06-14 18:31 [reply] ------- In the LRM-SC telecon of 13-Jun-2006, we agreed that issues relating to aspects of VHDL-2002 would continue to be addressed by the IEEE ISAC, and issues relating to changes added for VHDL-2006 would be addressed by the LRM-SC. Since this issue is inherent in VHDL-2002, I'll raise an ISAC IR on it, and mark this bug as resolved/later. That will remind us to revisit it in a subsequent round, possibly by means of an ISAC recommendation. Proposed Resolution ------------------- VASG-ISAC Analysis & Rationale ------------------------------ There are genuine issues in this area. There are several cases which were inadvertently missed in the LRM. Here are some of the cases which need to be covered (using the submitter's examples as a starting point): case 1: type my_logic is ( '0', '1', 'X', 'Z'); alias alt_logic is my_logic; case 2: alias std_logic1 is ieee.std_logic_1164.std_logic; alias std_logic2 is ieee.std_logic_1164.std_logic; case 3: type my_logic is ( '0', '1', 'X', 'Z'); function "="( a, b: my_logic) return boolean; alias alt_logic is my_logic; case 4: type my_logic is ( '0', '1', 'X', 'Z'); alias alt_logic is my_logic; function "="( a, b: my_logic) return boolean; case 5: package p1 is function "=" (a,b: ieee.std_logic_1164.std_logic ) return boolean; ... end package p1; use work.p1.all; ... alias std_logic is ieee.std_logic_1164.std_logic; CASE 6: package p1 is type my_logic is ( '0', '1', 'X', 'Z'); end package use p1.all; package p2 is alias alt_logic is my_logic; function "="( a, b: my_logic) return boolean; end package. [ John Ries: In this case the implicit alias to "="[my_logic, my_logic, return boolean] does occur so now we have two confliciting declarations. I think that case 6 should be legal. It seems to me that the rule should be If an implicit alias is a homograph of an object declared within the same scope, then the implicit alias isn't done or hidden. This rule is suppose to be similar the the implicit/explicit operator declarations. One last thing to consider that isn't in the bugzilla report is] CASE 7: package p1 is type my_logic is ( '0', '1', 'X', 'Z'); end package use p1.all; package p2 is alias alt_logic is my_logic; end package; use p1.all; use p2.all; package p4 is constant C : atl_logic := 'X'; end package; [John Ries: Is this legal or illegal. With the current visibility rules in VHDL-2002 it should be illegal because Neither the declaration of p1.'X' or p2.'X' is directly visible because they are homographs. In VHDL-200X it may be legal because of the change to visiblity to allow for explicit declarations to "hide" implicit declaration when made visible through a use clause (the signed/unsigned package problem)] CASE 8: package p1 is type my_logic is ( '0', '1', 'X', 'Z'); end package use p1.all; package p2 is alias alt_logic is my_logic; end package; use p1.all; package p3 is alias other_logic is my_logic; end package; use p3.all; use p2.all; package p4 is constant C : atl_logic := 'X'; end package; [John ries: I believe case 8 is illegal with both VHDL-200X and VHDL-2002 visiblity rules.] There are two principles which the LRM should be reworded to reflect: Principle One: The reason for the implicit declarations is so that if a design aliases a type the design also get automatic access to the associated operators. It is reasonable that if these operators (or homographs of them) are already visible, then the implicit declarations are either unnecessary or problematic. Principle Two: Explicit declarations should override implicit declarations. This principle should be extended to aliases and to the implicit declarations potentially made visible by aliases. "An alias declaration for a type introduces implicit declarations for each associated predefined operator provided that it is not a homograph of another declaration declared (either explicitly or implicitly) in the same declarative region." For case 1, since the predefined operators are already visible there is no need for the implicit declarations for the alias. Principle One applies. For case 2, since the alias of std_logic1 makes the implicit operators visible, there is no need for the implicit declarations for the second alias, std_logic2. Principle One applies. For case 3, since an overloaded "=" operator already is visible, there is no need for an implicit declaration of the "=" operator associated with the alias alt_logic. The other predefined operators do have implicit declarations. For case 4, it is legal to overload the implicitly declared "=" operator associated with the alias alt_logic. For case 5, the alias of the predefined "=" operator for std_logic is implicitly declared immediately after the alias declaration. From that point on, the overloaded "=" function from package p1 is no longer visible, following the normal rules for USE clauses. The new wording of the LRM must reflect these three principles. I can come up with wording that captures the first two, but I don't immediately see how to get wording that supports the third principle and case 5. "An alias declaration for a type introduces implicit declarations for each associated predefined operator provided that it is not a homograph of another declaration declared (either explicitly or implicitly) in the same declarative region." For case 6, Principle Two applies: The explicitly declared "=" function in package p2 legally overrides the implicitly declared homographic alias. For case 7, its not completely clear what the correct answer is. First, I think that there is a oversight in the LRM (all versions). Consider the following example: package p1 is function f1(a:integer) return integer; end package p1; package p2 is function f1(a:integer) return integer; end package p2; use work.p1.all; use work.p2.all; package p3 is -- is f1 visible here? end package p3; It seems clear that f1 should not be visible, but the applicable subclause 10.4 paragraph labeled c) doesn't seem to apply: "Potentially visible declarations that have the same designator are not made directly visible unless each of them is either an enumeration literal specification of the declaration of a subprogram (either by a subprogram dclaration or by an implicit declaration.)" This paragraph should be changed to disallow direct visibility of subprograms which are homographs. As for Case 7, if the paragraph allows direct visibility of enumeration literals which are homographs, then the example is legal. Otherwise it should not be legal. CASE 8 is a variation on CASE 7 in which the two "competing" operators are both implicitly declared aliases. We might want CASE 7 to be legal, but CASE 8 to be illegal. VASG-ISAC Recommendation for IEEE Std 1076-2002 ----------------------------------------------- TBD VASG-ISAC Recommendation for Future Revisions --------------------------------------------- TBD -------------END OF IR----------------Received on Thu Sep 28 19:04:27 2006
This archive was generated by hypermail 2.1.8 : Thu Sep 28 2006 - 19:04:29 PDT