[llvm-dev] Need help with code generation

[Rafael Espíndola via llvm-dev]

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?

Cheers,
Rafael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160321/b489f3da/attachment.html>