<div style="font-family: arial, helvetica, sans-serif; font-size: 10pt">I'll leave all the ubsan-relevant part to Richard. Just a general comment:<div>I think you'd need driver support for these flags (especially if you follow Jordan's idea).</div>
<div>Your flags targets -fsanitize=undefined, but it wouldn't make any sense for e.g. -fsanitize=address</div><div>(as it cannot recover from errors by design).</div><div><div><br><div class="gmail_quote">On Fri, Nov 30, 2012 at 4:28 PM, Will Dietz <span dir="ltr"><<a href="mailto:willdtz@gmail.com" target="_blank">willdtz@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Forgive me, the previous patches erroneously aborted on a dynamic type<br>
cache miss, updated patches attached.  Only the clang patch has<br>
changed: added a parameter specifying this call should *always* be<br>
recovered from.<br>
<br>
Thanks!<br>
<div class="HOEnZb"><div class="h5"><br>
On Fri, Nov 30, 2012 at 5:58 PM, Will Dietz <<a href="mailto:willdtz@gmail.com">willdtz@gmail.com</a>> wrote:<br>
> Many of ubsan's checks are recoverable, and it'd be great to support<br>
> doing so when possible.  Example use-case might be trying<br>
> -fsanitize=undefined on a new code base that has many errors, where<br>
> recovery would allow fixing them in bulk and require fewer<br>
> build/test/fix cycles.<br>
><br>
> This has been discussed a bit previously, and one of the biggest<br>
> arguments against this was that making these paths recoverable might<br>
> have a negative impact on performance.<br>
><br>
> To help address this concern, attached are patches that add a<br>
> -fsanitize-recover /cc1/ flag to enable performance tests with and<br>
> without recovery enabled.  Suggestions on how to proceed with such<br>
> testing would be appreciated :).<br>
><br>
> If performance testing proves the difference is not a concern, the<br>
> next step would be making recovery the default and<br>
> -fsanitize-no-recover a driver-level flag (with no need for<br>
> -fsanitize-recover).  It's certainly important to enable users to<br>
> specify they want program execution halted on the first detected error<br>
> as is presently the default.<br>
><br>
> The "recover" phrasing is used (as opposed to "abort" of "trap"<br>
> terminology) because many checks cannot be recovered from, so a flag<br>
> like -fsanitize-no-abort would be misleading what it does.<br>
><br>
> Review and feedback on this approach and its direction would be much<br>
> appreciated.<br>
><br>
> Thanks!<br>
><br>
> ~Will<br>
</div></div><br>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Alexey Samsonov, MSK</div><br>
</div></div></div>