Open dnadlinger opened 7 years ago
I don't remember exactly, but there might have been some extra issues with bfd for Shippable, and switching to gold improved things. I may be misremembering though, it's been some time.
Any progress?
I have another $2000 USD bounty waiting for PayPal eCheck to pass, aimed at rewarding a full test suite in AArch64 support
I have another $2000 USD bounty waiting for PayPal eCheck to pass, aimed at rewarding a full test suite in AArch64 support
This sound interesting! Would passing it on GNU/Linux be enough, or do you require Android/iOS support?
There needs to be a tracking issue for Android/iOS + AArch64 so that I can put a bounty for it separately, but I think this would be a good milestone to just have it working for GNU/Linux.
Are there any test failures still? It seems already pretty good for real applications. I've been using LDC (mostly on GtkD projects) on FreeBSD/aarch64 for over a year now, haven't noticed any arch specific issues.
Are there any test failures still?
Yes, mostly related to ABI and lacking core.stdc.stdarg
support for C-style varargs, and a few remaining Phobos issues wrt. quadruple precision, i.e., basically the remaining ticks in the initial tracker posting. And the debug runtime libraries seem unusable (possibly related to hanging core.thread.fiber
tests?).
Shippable AArch64 CI (on Ubuntu 16.04) is green because test failures are ignored for now; the logs show what's still missing.
@dnadlinger: Are you working on this? I could look into the AArch64 ABI for a start.
Hey, as an outsider I wanted to hook into this discussion to see where things stand at in terms of stability - is it considered stable enough to use it in commercial development for the Play Store? ARM64 is a requirement as of August iirc due to Google now forcing every APK to have 64 bit natives.
I have no experience with D at all, nor with compiler development, but if there are things I can do to help I'm willing to get my hands dirty!
where things stand at in terms of stability - is it considered stable enough to use it in commercial development for the Play Store?
That's difficult to answer. With the upcoming AArch64 ABI fixes (will be in the next beta in a few weeks), I'd think that the compiler side should be pretty complete, leaving the few library issues.
Wrt. Android, the bigger problem is that we have no test results - neither from CI, nor recent ones from a manual run. A full testrun requires testing a native Android LDC on the device, which requires a clang toolchain for linking too, which AFAIK again means that one has to resort to a regular-Linux-emulating app like Termux (edit: for which there's an LDC package I'm 'maintaining' without ever running or testing it myself :])...
Update: ABI issues hopefully fixed for good (at least for non-Apple), incl. C(++) interop and varargs.
Current testsuite status for Shippable CI on Ubuntu 16.04:
std/algorithm/mutation.d(2796): Swap: lhs internal pointer.
- probably related to failing unittest below)core.thread.fiber
probably still hangs (only most of the time?) - disabled for CIThe dmd-testsuite-release test driver failure is probably a regular Phobos bug and unrelated to AArch64. Also sporadically seen for DMD CI, e.g., there.
Update: dmd-testsuite-release is now tested and all green, see https://github.com/ldc-developers/ldc/commit/36e19119c48a056360bcc6d37f51c886f6decae2.
The issue still is, see my latest posts; the bounty less so in the sense of the few remaining parts IMO definitely not justifying the full bounty.
@etcimon: I don't quite remember how Bountysource works (just that I thought they were bought out by some … weird entity at some point), but are you already out of pocket for your generous donation? If no, maybe we should just call it quits; if yes, maybe those of us having done major amounts of work so far can push through to full support and then split the bounty up somehow so that it isn't "lost". (Edit: Also see https://github.com/bountysource/core/issues/1539.)
I'm currently on-off working on
aarch64-unknown-linux-gnu
and have a large part of the test suite passing already, includingstd.math
(IEEE 754 quad-precision real support). The idea is to get anltsmaster
compiler that passes the whole test suite first. See the log of the latest AArch64 CI builds for the current status of the test suite.Open items:
core.stdc.stdarg.va_arg
supportstd.conv
support for quad-precision reals - dlang/phobos#6633core.internal.convert
support for CTFE conversion of Quadruple reals to a ubyte array - dlang/druntime#2257std.numeric.CustomFloat
support for Quadruple realsstd.internal.math.gammafunction
-NaN
that trips some asserts instd.math
andstd.algorithm.sorting
, but only when natively compiling on AArch64Upstream PRs to integrate into
ltsmaster
:[x] dlang/phobos#5947
@redstar: How is your
cent
work progressing?