[llvm-dev] lld/mach-o x86_64 asserts

[Carlo Kok via llvm-dev]

That sounds quite reasaonable; how does one usually go about doing that?
a repro zip that hits both asserts?

On Wed, Jul 11, 2018, at 03:11, Rui Ueyama wrote:
> Carlo,
> 
> Thank you for your contribution! We don't usually commit any feature
> without a test, so can you write a test for us? Then I think I can
> commit this for you.> 
> On Tue, Jul 10, 2018 at 12:33 PM Andrew Kelley via llvm-dev <llvm-
> dev at lists.llvm.org> wrote:>> I confirm that this passes the Zig test suite. This solves the 1
>> outstanding patch that Zig has against LLD, and if this is merged, we
>> can go back to using LLD releases instead of a fork.>> 
>> On Tue, Jul 10, 2018 at 3:40 AM, Carlo Kok via llvm-dev <llvm-
>> dev at lists.llvm.org> wrote:>>> On LLD mach/o x86_64 LLD calls dataInCodeTransitionStart and
>>> dataInCodeTransitionEnd, which aren't implemented (and thus return
>>> the defautl value 0), later in applyFixupFinal it reaches the
>>> default: unreachable causing miscompiles depending on the optimizer.>>> 
>>>  Attached is a simple patch that fixes this. 
>>> 
>>>  It also fixes the read8 method, as object files inside .a files
>>>  aren't 8 byte aligned when memory mapped.>>> 
>>> _______________________________________________
>>>  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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180711/ec54bb22/attachment.html>