EDA.org Mantis
Mantis Bugtracker
Main | My View | View Issues | Docs | Wiki
  

Viewing Issue Simple Details [ Jump to Notes ] [ Wiki ] [ View Advanced ] [ Issue History ] [ Print ]
ID Category Severity Date Submitted Last Update
0002380 [SystemVerilog P1800] SV-EC major 2008-05-07 03:10 2009-07-25 14:52
Reporter shalom View Status public  
Assigned To Jonathan Bromley
Priority immediate Resolution fixed  
Status closed   Product Version P1800-2008/D5
Summary 0002380: Ballot Comment #33, 34, 56 6.22.3: array assignment compatibility not described
Description 6.22.3 ("Assignment compatible") says,

"All equivalent types, and all nonequivalent types that have implicit casting rules defined between them, are assignment-compatible types. For example, all integral types are assignment compatible. Conversion between assignment-compatible types can involve loss of data by truncation or rounding."

This is not quite true for array assignments.

7.6 ("Array assignments") says,
"Assigning to a fixed-size unpacked array requires that the source and the target both be arrays with the same number of unpacked dimensions, the length of each dimension be the same, and each element be of an equivalent type."

In particular, this requires that the source and target element types be equivalent, whereas 6.22.3 allows nonequivalent types if implicit casting rules are defined for them. An example of the difference is two arrays where one has elements of an integral type whereas the other's elements are of a real type. They are not equivalent types, but implicit casting rules between integral types and real types are defined.

7.6 takes precedence, but if one looks at 6.22.3, he would be confused and might not even think to look at 7.6.
Additional Information Version 2 of the proposal is the subject of SV-EC email vote ending 11 June 2009.
Tags No tags attached.
Type Errata
Attached Files pdf file icon 2380-proposal-v2.pdf [^] (47,849 bytes) 2009-06-08 07:21
pdf file icon 2380-proposal-v2A.pdf [^] (49,376 bytes) 2009-06-12 01:33

- Relationships
related to 0002303new Champions feedback on Mantis item 1447 
related to 0002533resolvedshalom Equivalent to what? 
related to 0002802new Associative array assignment compatibility 
child of 0002356new Master issue for SV-BC Array issues 
child of 0002736new Parent mantis item for SV-EC ballot feedback - P1800-2009 

-  Notes
User avatar (0007083)
shalom (manager)
2008-06-24 04:37

 See thread beginning http://www.eda-stds.org/sv-ec/hm/6079.html [^]
User avatar (0007887)
shalom (manager)
2009-02-18 04:39

 The situation has become more complicated. While 7.6 (Draft 8) says,

"Assigning to a fixed-size unpacked array requires that the source and the target both be arrays with the same number of unpacked dimensions, the length of each dimension be the same, and each element be of an *equivalent type*,"

it also says,

"Fixed-size unpacked arrays, dynamic arrays and queues are assignment compatible with each other under the following conditions:
— Their element types shall be assignment compatible."

I've seen complaints about requiring equivalence as being awkward and inconsistent.
User avatar (0007980)
shalom (manager)
2009-04-13 01:25

 Ballot comment #33:

7.6, second paragraph, first sentence states that each element of a fixed-size unpacked array has to be of equivalent type in source and target arrays for array assignment.
The last sentence on the same page says fixed unpacked arrays, queues and dynamic arrays are assignment compatible if their element types are assignment compatible.

Proposed Change:

The assignment compatibility rule at the bottom of the page should be modified to state:

"Fixed-size unpacked arrays, dynamic arrays and queues are assignment compatible with each other under the following conditions:

- If the element types are themselves an array, then these element types have to be assignment compatible. This is a recursive condition as long as the element types are found to be of array type.

- If the element types are not array type then they must be equivalent types

- If the destination size is fixed, then the source and destination sizes shall be equal.

When assigning dynamic-sized array to a dynamic-size array, the following rules shall apply:

- elements of source array are copied to the destination array by assigning each element of the source array to the corresponding element of the target array.

- element correspondence is defined as leftmost to leftmost, and rightmost to rightmost"

Must Be Satsified? Yes
User avatar (0007981)
shalom (manager)
2009-04-13 01:42

 Ballot Comment #34:

Last bullet on page says that assignment compatible array element types need only be assignment compatible. Other text in this section and elsewhere (e.g. 6.22) requires that they be equivalent. This is contradictory.

Proposed Change:

Replace "shall be assignment compatible" with "shall match". Alternately, find and change the many other places that contradict this one.

Must Be Satisfied? Yes
User avatar (0007982)
shalom (manager)
2009-04-13 01:44

 Ballot Comment #56:

LRM is contradictory on whether unpacked array assignment requires element type equivalence or assignment compatiblity. See 0002380.

Proposed Change:

Resolve inconsistency. Assignment compatibility is preferred.

Must Be Satisfied? Yes
User avatar (0008356)
Brad Pierce (developer)
2009-05-29 08:41

 See thread beginning at

  http://www.eda-stds.org/sv-bc/hm/9558.html [^]
User avatar (0008357)
Jonathan Bromley (developer)
2009-05-30 14:51

 Proposal uploaded. PLEASE NOTE: this proposal raises a significant back-compatibility issue vs. 1800-2005, described in the introduction to the proposal.
User avatar (0008459)
Jonathan Bromley (developer)
2009-06-08 07:24

 Uploaded proposal 2380-proposal-v2.pdf with element-equivalence required.
User avatar (0008478)
Jonathan Bromley (developer)
2009-06-10 05:32

 Version 1 of the proposal deleted after SV-EC discussion on 8-June-2009.
User avatar (0008518)
Jonathan Bromley (developer)
2009-06-12 01:34

 Version 2A of the proposal uploaded to address various errata pointed out in email discussion.
User avatar (0008543)
mehdi_mohtashemi (manager)
2009-06-15 22:53

 The proposal 2380-proposal-v2A.pdf was unanimously approved by the sv-ec in
the conference call held on June 15th, 2009.
[Ballot ids: 33, 34, 56]
User avatar (0008674)
Dave Rich (manager)
2009-07-01 10:37

 The Champions have voted unanimously to approve this issue on June 29, 2009
User avatar (0008808)
Dave Rich (manager)
2009-07-02 10:50

 This issue was approved in the WG meeting held on July 2, 2009 for change in the next revision of the LRM.
User avatar (0008898)
Stuart Sutherland (manager)
2009-07-10 10:34

 Requested changes were added to P1800/D9-prelim2.
User avatar (0009024)
Jonathan Bromley (developer)
2009-07-25 14:51

 Reviewed in draft9-prelim2. No issues found.

- Issue History
Date Modified Username Field Change
2008-05-07 03:10 shalom New Issue
2008-05-07 03:10 shalom Type => Errata
2008-05-07 03:11 shalom Issue Monitored: shalom
2008-05-07 03:11 shalom Relationship added child of 0002356
2008-05-26 02:02 shalom Relationship added parent of 0002397
2008-05-26 02:05 shalom Relationship deleted parent of 0002397
2008-06-24 04:37 shalom Note Added: 0007083
2008-06-29 06:29 shalom Relationship added related to 0002303
2009-02-18 04:39 shalom Note Added: 0007887
2009-04-13 01:25 shalom Note Added: 0007980
2009-04-13 01:42 shalom Note Added: 0007981
2009-04-13 01:44 shalom Note Added: 0007982
2009-04-13 03:53 shalom Relationship added child of 0002685
2009-05-11 10:55 Brad Pierce Assigned To => Cliff Cummings
2009-05-11 10:55 Brad Pierce Status new => assigned
2009-05-11 10:55 Brad Pierce Category SV-BC => SV-EC
2009-05-13 11:57 mmaidment Relationship deleted child of 0002685
2009-05-19 10:00 Neil Korpusik Summary 6.22.3: array assignment compatibility not described => Ballot Comment #33, 34, 56 6.22.3: array assignment compatibility not described
2009-05-19 10:01 Neil Korpusik Relationship added child of 0002736
2009-05-20 00:38 Daniel Mlynek Issue Monitored: Daniel Mlynek
2009-05-29 08:41 Brad Pierce Note Added: 0008356
2009-05-30 14:49 Jonathan Bromley File Added: 2380-proposal-v1.pdf
2009-05-30 14:51 Jonathan Bromley Note Added: 0008357
2009-06-08 07:21 Jonathan Bromley File Added: 2380-proposal-v2.pdf
2009-06-08 07:24 Jonathan Bromley Note Added: 0008459
2009-06-08 07:24 Jonathan Bromley Additional Information Updated
2009-06-08 22:33 shalom Relationship added related to 0002533
2009-06-08 22:36 shalom Assigned To Cliff Cummings => Jonathan Bromley
2009-06-08 22:36 shalom Priority normal => immediate
2009-06-10 05:30 Jonathan Bromley File Deleted: 2380-proposal-v1.pdf
2009-06-10 05:32 Jonathan Bromley Note Added: 0008478
2009-06-10 05:32 Jonathan Bromley Additional Information Updated
2009-06-12 01:33 Jonathan Bromley File Added: 2380-proposal-v2A.pdf
2009-06-12 01:34 Jonathan Bromley Note Added: 0008518
2009-06-15 22:53 mehdi_mohtashemi Note Added: 0008543
2009-06-15 22:53 mehdi_mohtashemi Status assigned => resolved
2009-06-15 22:53 mehdi_mohtashemi Resolution open => fixed
2009-06-30 04:17 shalom Relationship added related to 0002802
2009-07-01 10:37 Dave Rich Note Added: 0008674
2009-07-01 10:44 Dave Rich Note Added: 0008725
2009-07-01 12:19 Dave Rich Note Deleted: 0008725
2009-07-02 10:43 Dave Rich Status resolved => approved
2009-07-02 10:50 Dave Rich Note Added: 0008808
2009-07-10 10:34 Stuart Sutherland Note Added: 0008898
2009-07-10 10:34 Stuart Sutherland Status approved => completed
2009-07-10 10:34 Stuart Sutherland Fixed in Version => P1800-2009/D9 Recirc
2009-07-25 14:51 Jonathan Bromley Note Added: 0009024
2009-07-25 14:51 Jonathan Bromley Status completed => closed

Mantis 1.1.7[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker