[llvm-dev] Need help with code generation

[David Blaikie via llvm-dev]

On Mon, Mar 21, 2016 at 4:44 PM, Rui Ueyama <ruiu at google.com> wrote:

> On Tue, Mar 22, 2016 at 12:41 AM, David Blaikie via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>>
>>
>> On Mon, Mar 21, 2016 at 4:35 PM, Rafael Espíndola <
>> rafael.espindola at gmail.com> wrote:
>>
>>>
>>> On Mar 21, 2016 5:49 PM, "David Blaikie" <dblaikie at gmail.com> wrote:
>>> >
>>> >
>>> >
>>> > On Mon, Mar 21, 2016 at 2:46 PM, Rafael Espíndola <
>>> llvm-dev at lists.llvm.org> wrote:
>>> >>
>>> >> On 21 March 2016 at 17:34, Tim Northover via llvm-dev
>>> >> <llvm-dev at lists.llvm.org> wrote:
>>> >> >> My understanding is that clang and llvm themselves are designed
>>> this way
>>> >> >> (crash when the unexpected happens).
>>> >> >
>>> >> > I don't think so. I'd view any Clang crash as a bug (probably to be
>>> >> > prioritised below silent CodeGen and many others, but not "working
>>> as
>>> >> > designed").
>>> >> >
>>> >> >> For example the fact that clang forks itself to be able to report
>>> diagnostics
>>> >> >
>>> >> > That seems like just trying to make our own job easier to me. I
>>> think
>>> >> > the entire point of the fork is to get a backtrace we can fix, and
>>> >> > point out where the user should send it.
>>> >> >
>>> >> >> llvm is full of report_fatal_error() (or worse, assertions that
>>> can fire on unexpected user input).
>>> >> >
>>> >> > A bit of a grey area since LLVM isn't itself a user-facing tool,
>>> but I
>>> >> > think I'd still say that a report_fatal_error that's not actionable
>>> by
>>> >> > the user is actually an LLVM bug. And a segfault definitely so.
>>> >>
>>> >> It is completely trivial to crash llvm. A case I wrote today in
>>> >> another thread while waiting for tests to run:
>>> >>
>>> >> target triple = "x86_64-unknown-linux-gnu"
>>> >> @".data" = global i32 42
>>> >>
>>> >> That will crash "llc -filetype=obj". The fact that it is considered a
>>> >> bug doesn't mean much if there is no coordinated effort to fix them.
>>> >
>>> >
>>> > 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 -
>>>
>>> I am pretty sure clang crashes if you translate the above example to C.
>>>
>>> Philosophical question: what is the difference of a non bug and a bug of
>>> such low priority that it is never fixed?
>>>
>>  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.
>>
>> It changes who's willing to contribute to the project, or build tools
>> based on it.
>>
>
> The documented policy should handle that issue.
>

I was referring to Rafael's position:

"If someone really cares (I don't), they can write a patch. Such a
patch would be evaluated on its cost and benefits. Given that its
benefits are close to nothing (don't crash when someone is playing
with hexedit?), the cost would have to be *really* low. Also, we are
not even in a position to evaluate the cost right now, since we still
have actual features to implement."


>
>
>> - David
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160321/3e7e66b8/attachment.html>