<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 21, 2016 at 4:44 PM, Rui Ueyama <span dir="ltr"><<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5">On Tue, Mar 22, 2016 at 12:41 AM, David Blaikie via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Mon, Mar 21, 2016 at 4:35 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><p dir="ltr"><br>
On Mar 21, 2016 5:49 PM, "David Blaikie" <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
> On Mon, Mar 21, 2016 at 2:46 PM, Rafael Espíndola <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
>><br>
>> On 21 March 2016 at 17:34, Tim Northover via llvm-dev<br>
>> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
>> >> My understanding is that clang and llvm themselves are designed this way<br>
>> >> (crash when the unexpected happens).<br>
>> ><br>
>> > I don't think so. I'd view any Clang crash as a bug (probably to be<br>
>> > prioritised below silent CodeGen and many others, but not "working as<br>
>> > designed").<br>
>> ><br>
>> >> For example the fact that clang forks itself to be able to report diagnostics<br>
>> ><br>
>> > That seems like just trying to make our own job easier to me. I think<br>
>> > the entire point of the fork is to get a backtrace we can fix, and<br>
>> > point out where the user should send it.<br>
>> ><br>
>> >> llvm is full of report_fatal_error() (or worse, assertions that can fire on unexpected user input).<br>
>> ><br>
>> > A bit of a grey area since LLVM isn't itself a user-facing tool, but I<br>
>> > think I'd still say that a report_fatal_error that's not actionable by<br>
>> > the user is actually an LLVM bug. And a segfault definitely so.<br>
>><br>
>> It is completely trivial to crash llvm. A case I wrote today in<br>
>> another thread while waiting for tests to run:<br>
>><br>
>> target triple = "x86_64-unknown-linux-gnu"<br>
>> @".data" = global i32 42<br>
>><br>
>> That will crash "llc -filetype=obj". The fact that it is considered a<br>
>> bug doesn't mean much if there is no coordinated effort to fix them.<br>
><br>
><br>
> I think it does, actually - that patches will be accepted to fix pretty much any crash in LLVM. (llc isn't a user facing tool, so that's a praticularly low priority - <br></p>
</span><p dir="ltr">I am pretty sure clang crashes if you translate the above example to C. </p>
<p dir="ltr">Philosophical question: what is the difference of a non bug and a bug of such low priority that it is never fixed?</p></blockquote></div></div><div> One where contributors are encouraged to provide patches to fix things, versus one where contributors are told that there is a high bar to get such a patch contributed seems like a pretty big difference to me.<br><br>It changes who's willing to contribute to the project, or build tools based on it.<br></div></div></div></div></blockquote><div><br></div></div></div><div>The documented policy should handle that issue.</div></div></div></div></blockquote><div><br></div><div>I was referring to Rafael's position:<br><br>"<span style="font-family:monospace">If someone really cares (I don't), they can write a patch. Such a</span></div><span style="font-family:monospace">patch would be evaluated on its cost and benefits. Given that its</span><br style="font-family:monospace"><span style="font-family:monospace">benefits are close to nothing (don't crash when someone is playing</span><br style="font-family:monospace"><span style="font-family:monospace">with hexedit?), the cost would have to be *really* low. Also, we are</span><br style="font-family:monospace"><span style="font-family:monospace">not even in a position to evaluate the cost right now, since we still</span><br style="font-family:monospace"><span style="font-family:monospace">have actual features to implement."</span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br>- David</div></div></div></div><span class="">
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br></span></blockquote></div><br></div></div>
</blockquote></div><br></div></div>