RE: [sv-bc] Re: Mandated warnings -- was Re: [sv-ec] Mantis 2701, ballot ID #44 - Arturo's feedback

 

It hard to see that it should be left to tool developers since having
different tools warn about different things is quite painful for users.
It means that code that is clean on one tool is not on others. So when a
new tool is used either we have to open up the code and fix things or
turn we just off warnings.  This is one of the few legitimate reasons
for turning off warnings.  If warnings are clearly captured in the LRM
this problem becomes a lot less significant.  

 

Of course there are not-so-sensible users about but shouldn't we can to
support sensible users in doing the right thing.

 

...Stephen

 

 

________________________________

From: Vreugdenhil, Gordon [mailto:gordon_vreugdenhil@mentor.com] 
Sent: Saturday, May 02, 2009 5:44 PM
To: Stephen Hill; Bresticker, Shalom
Cc: Jonathan Bromley; sv-ec@server.eda.org; SV_BC List; Vreugdenhil,
Gordon
Subject: RE: [sv-bc] Re: Mandated warnings -- was Re: [sv-ec] Mantis
2701, ballot ID #44 - Arturo's feedback

 

 

I'm not sure there is a disconnect -- there is just a
big difference in opinion as to what is appropriate for
an LRM as opposed to a user guide or customer/vendor
discussion.

I have no problem having customers ask for additional
warnings, etc. and will make business/implementation
decisions about implementation and defaults based
on the very wide user community.

I have pretty substantial objections to an LRM mandating,
as in the 2701 proposal, that exactly one warning be
issued for a particular construct.  That is way beyond
what the LRM should be trying to dictate.

In addition, if many users will just turn off the warnings,
(which is reality) why mandate the warning at all?  If we
really want to reflect reality, shouldn't we really just
mandate suppression of such warnings at time 0?  That is
the primary reason that users turn off warnings.  Oh,
and if we do that, shouldn't we .....

Gord.


-----Original Message-----
From: Stephen Hill [mailto:Stephen.Hill@arm.com]
Sent: Sat 5/2/2009 4:23 AM
To: Vreugdenhil, Gordon; Bresticker, Shalom
Cc: Jonathan Bromley; sv-ec@server.eda.org; SV_BC List; Stephen Hill
Subject: RE: [sv-bc] Re: Mandated warnings -- was Re: [sv-ec] Mantis
2701, ballot ID #44 - Arturo's feedback

Hi Gord,

I think there is a significant disconnect here.  No one is suggesting
implementing warnings without control to let users express their design
intent.  They key is giving the users the case-by-case option. Not
fixing this as always-on or always-off.

The question is really over whether the default should be warning "on"
or "off".

I suspect the "on" behavior is by far the most desirable, at least in
synthesizable code.

Currently I have to tell people that they should really create an
assertion for every array write to spot these problems... unsurprisingly
their reaction is incredulous. It just feels like something that should
be automatic not manual.  The assertion should be there automatically
and overridden by users in the rare case when something else is needed.

On the optimization front - of course it's good to optimize tools but
taking a step back it well be more efficient for the users to run
slightly more slowly but not have to debug hard-to-find masked problems
like this.

Cheers,

...Stephen

Stephen Hill           
ARM R&D                        
EMail: Stephen.Hill@arm.com    
 

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Gordon Vreugdenhil
Sent: Friday, May 01, 2009 3:26 PM
To: Bresticker, Shalom
Cc: jonathan.bromley@doulos.com; sv-ec@server.eda.org; SV_BC List
Subject: [sv-bc] Re: Mandated warnings -- was Re: [sv-ec] Mantis 2701,
ballot ID #44 - Arturo's feedback


Bresticker, Shalom wrote:
> I also find the following
>
>> The recent vote in SV-BC where vendors
>> unanimously opposed a warning on any array bound write violation
>> and users unanimously supported the warning
>
> very disturbing and not "a good indicator" at all. It indicates a bad
disconnect between vendors and users.


That was actually my point -- it is a good indicator
that there is a problem.  I've stated my position on
the problem.

Gord.



>
> Shalom
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>

--
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com


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

--
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy
the information in any medium.  Thank you.

-- 
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.

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