LDC 1.13.0-beta2

Joakim dlang at joakim.fea.st
Thu Nov 29 12:21:15 UTC 2018


On Thursday, 22 November 2018 at 16:54:55 UTC, Joakim wrote:
> On Thursday, 22 November 2018 at 16:36:22 UTC, H. S. Teoh wrote:
>> On Thu, Nov 22, 2018 at 01:25:53PM +0000, Joakim via 
>> Digitalmars-d-announce wrote:
>>> On Wednesday, 21 November 2018 at 10:43:55 UTC, kinke wrote:
>>> > Glad to announce the second beta for LDC 1.13:
>>> > 
>>> > * Based on D 2.083.0+ (yesterday's DMD stable).
>> [...]
>>> I've added native builds for Android, including 
>>> Android/x86_64 for the first time. Several tests for 
>>> std.variant segfault, likely because of the 128-bit real 
>>> causing x64 codegen issues, but most everything else passes.
>> [...]
>>
>> What's the status of cross-compiling to 64-bit ARM?  On the 
>> wiki you wrote that it doesn't fully work yet.  Does it work 
>> with this new release?
>
> It's been mostly working since 1.11. That note on the wiki 
> links to this tracker issue that lists the few remaining holes, 
> mostly just extending Phobos support for 80-bit precision out 
> to full 128-bit Quadruple precision in a few spots and 
> finishing off the C/C++ compatibility:
>
> https://github.com/ldc-developers/ldc/issues/2153

Btw, if you ever want to check the current status of the AArch64 
port, all you have to do is look at the logs for the latest run 
of the ldc AArch64 CI, which kinke setup and is run for every ldc 
PR, on this dashboard:

https://app.shippable.com/github/ldc-developers/ldc/dashboard

Clicking on the last job on the master branch, expanding the 
build_ci output in the log, then doing the same for the stdlib 
tests, I see only five Phobos modules with failing tests. Three 
are mentioned in the tracker issue above, while std.complex has a 
single assert that trips, because it's a few bits off at 113-bit 
precision, which is still much more accurate than the 64-bit 
precision (or less) it's normally run at on x86/x64.

Also, a single assert on std.algorithm.sorting trips for the same 
reason as a handful of tests in std.math: -real.nan at 
compile-time is output as real.nan by ldc running natively on 
AArch64, though not when cross-compiling. 
std.internal.math.gammafunction works fine at 64-bit precision on 
AArch64, but only a couple of the 100 or so constant reals it 
uses are at full 113-bit precision, so several tests assert that 
only allow a couple bits to be off from full real precision. 
Obviously that only matters if you need full 113-bit precision 
from that module.

kinke recently disabled the tests for core.thread on the CI 
because they're super-flaky on linux/glibc/AArch64, while I 
haven't had that problem with Bionic/AArch64. You will see more 
tests failing if you cross-compile from x64, because of the 
mismatch between 64-bit precision for compile-time reals and 
113-bit precision for runtime reals on AArch64. Also, you can see 
the 10-12 modules that assert in the dmd compiler testsuite 
earlier in that log, most because of missing 
core.stdc.stdarg.va_arg support to call C varargs on AArch64.

That's about it: help is appreciated on tightening those last few 
screws.


More information about the Digitalmars-d-announce mailing list