[sv-bc] Re: [sv-ec] RE: areas of implementation divergence

Macros are certainly highly problematic.

A few others off the top of my head:
    - typename (many, many issues)
    - class virtual methods during construction (C++ vs sort-of Java)
    - order of initialization of class data members (related to virt 
methods)
    - legality of a pure virtual overriding a (non-pure) virtual method
    - various things related to interfaces/virtual interfaces, particularly
       type rules
    - configurations related to interfaces, virtual interfaces, and bind
    - relationship of virtual interfaces to nested interface declarations
    - how "precise" are class specialization matching rules wrt size/value

As Dave said, it would take a while to go through the (many!)
implementation divergences that we know about and figure
out which the committee would consider ambiguous vs
extensions/illegal behavior.  The ones I listed above are more
obviously ambiguous/inconsistent/incomplete.

Gord


On 3/2/15 11:20 PM, Rich, Dave wrote:
> This list is going to be hard to produce in time for Friday's meeting while many of us are at DVCon.
>
> If you look at only the SV-BC category, there are 173 open issues. Many of these are slightly above editorial LRM issues. Some are as simple as 4759 (is '0 allowed in a concat) The divergence is one tool produces an error, another tools allows it. Here it's easy to assume that allowing it will interpret it to mean 1'b0.
>
> Then there are all the Macro issues.
>
> I don't have time to add more to this list, I could spend hours.
>
> -----Original Message-----
> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Steven Sharp
> Sent: Monday, March 02, 2015 5:03 PM
> To: erik.seligman@intel.com; Maidment, Matthew R; sv-bc@eda.org; sv-ec@eda.org
> Subject: [sv-ec] RE: areas of implementation divergence
>
> I think this is in a slightly different category.  The LRM is clear that this is not allowed, so this is not ill-defined.
>
> There may be divergence because some implementations have chosen to support non-standard extensions to the LRM.  Some of those could be considered to be the "fault" of the LRM, for being unnecessarily restrictive or inconsistent.  But it still isn't the same as the language being ill-defined by the LRM.
>
>
> -----Original Message-----
> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Seligman, Erik
> Sent: Monday, March 02, 2015 1:36 PM
> To: Maidment, Matthew R; sv-bc@eda.org; sv-ec@eda.org
> Subject: [sv-ec] RE: areas of implementation divergence
>
> The question of whether a bound [N] is supported in packed array declarations, as in http://www.eda.org/svdb/view.php?id=325 , might be an example here.
>
> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Maidment, Matthew R
> Sent: Monday, March 02, 2015 12:03 AM
> To: sv-bc@eda.org; sv-ec@eda.org
> Subject: [sv-bc] areas of implementation divergence
>
> All.
>
> During discussions about the next PAR, it has been raised several times that there are problematic areas in the language that are causing implementation divergence.  Would some of you please reply to this thread identifying specific areas of the language that are ill-defined and are leading to this divergence?
>
>
> Thanks.
>
> Matt
>
>
> --
> This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
>
>
>
>
> --
> This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
>
>
>
>
> --
> This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
>
>
>
>

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Verification Technologies, Mentor Graphics        gordonv@model.com


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.