[llvm-dev] Need help with code generation

[Hal Finkel via llvm-dev]

----- Original Message -----
> From: "Lang Hames via llvm-dev" <llvm-dev at lists.llvm.org>
> To: "Rui Ueyama" <ruiu at google.com>
> Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Bruce Hoult" <bruce at hoult.org>
> Sent: Monday, March 21, 2016 5:00:02 PM
> Subject: Re: [llvm-dev] Need help with code generation
> 
> Hi All,
> 
> 
> My understanding of the earlier thread is that it ended with "We
> agree to disagree for now, and (potentially) revisit this later".
> 

This was also my impression.

 -Hal

> 
> I'm not interested in starting any new discussions at the moment, but
> I want to make sure we avoid the echo chamber effect too, so: The
> position of the mach-o tool developers is that crashing on malformed
> input should be considered a bug, and to that end we're working to
> improve our error detection and reporting.
> 
> 
> - Lang.
> 
> 
> 
> On Mon, Mar 21, 2016 at 2:54 PM, Rui Ueyama via llvm-dev <
> llvm-dev at lists.llvm.org > wrote:
> 
> 
> 
> 
> 
> 
> 
> On Mon, Mar 21, 2016 at 10:49 PM, David Blaikie via llvm-dev <
> llvm-dev at lists.llvm.org > 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 - 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.
> 
> 
> 
> I think this is the same from the user's point of view. If LLVM is
> not crash-bug-free in the version you are using, you need some
> precaution such as forking in order to protect your program from
> crashing if you need 100% guarantee.
> 
> 
> 
> 
> 
> 
> - Dave
> 
> 
> 
> Cheers,
> Rafael
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory