llvm dev - Mar 2016 - Need help with code generation

> 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.

Cheers.

Tim.

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.

Right now lld is already harder to crash than llvm. We are just being
honest about the fact that it is possible to craft a .o file that will
crash it.

Cheers,
Rafael

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 - but as a general library (I assume your example
also crashes Clang, which would be where this would surface in a more
important way) it's pretty well accepted that crashes are bugs, I think)

> Right now lld is already harder to crash than llvm. We are just being
> honest about the fact that it is possible to craft a .o file that will
> crash it.
>
But the difference seems to be you know about these cases and don't
consider them to be bugs/anything to fix. In LLVM if they're known,
they're
at least considered bugs and often/usually considered by someone to be
worth fixing at some point.

- Dave

>
> Cheers,
> Rafael
> _______________________________________________
> 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/09347234/attachment.html>