llvm dev - Mar 2016 - Need help with code generation

Of course I'm not happy. And I hope that you understood that that is
unusual. Having said that, I'd say it's however reasonable.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160321/09a66758/attachment.html>

Rafael,

How can a high quality product crash by design? I understand the lack of
structured error handling, and I understand asserting (which in release
mode would be silent) on internal errors. But on an input? How can an
application be taken seriously when crashes are design features?

And I certainly didn't see consensus or in fact the suggestion of this in
the other thread, unless I glazed over an important part.

James
On Mon, 21 Mar 2016 at 21:16, Rui Ueyama <ruiu at google.com> wrote:
> Of course I'm not happy. And I hope that you understood that that is
> unusual. Having said that, I'd say it's however reasonable.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160321/c30e0a39/attachment.html>

On 21 March 2016 at 17:20, James Molloy via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Rafael,
>
> How can a high quality product crash by design? I understand the lack of
> structured error handling, and I understand asserting (which in release
mode
> would be silent) on internal errors. But on an input? How can an
application
> be taken seriously when crashes are design features?
>
> And I certainly didn't see consensus or in fact the suggestion of this
in
> the other thread, unless I glazed over an important part.
>
It can crash because .o files are not user input. They are generated.
To get one you need a broken assembler or a broken hardware.

Sorry if lld is not the linker you want, but that is the one we are writing.

As for how it will be taken seriously, well, we seem to be on good
track to be able to link freebsd and to do so faster than gold.

Cheers,
Rafael