On 14 September 2018 at 09:51, Joakim via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > On Wednesday, 12 September 2018 at 22:41:31 UTC, Iain Buclaw wrote: >> >> On 12 September 2018 at 10:09, Joakim via Digitalmars-d >> <digitalmars-d@puremagic.com> wrote: >>> >>> I think their model of having an open ISA with proprietary extensions >>> will inevitably win out for hardware, just as a similar model has basically >>> won already for software, but that doesn't mean that RISC-V will be the one >>> to do it. Someone else might execute that model better. >>> >> >> POWER9 has been making some headway, for instance finally they have a >> sensible real type (IEEE Quadruple). Though the developers working on glibc >> support seem to be making a shambles of it, where they want to support both >> new and old long double types at the same time at run-time! It seems that >> no one thought about Fortran, Ada, or D when it came to long double support >> in the C runtime library *sigh*. >> >> For us, I think we can choose to ignore the old IBM 128-bit float, and so >> remove any supporting code from our library, focusing instead only on >> completing IEEE 128-bit float support (LDC, upstream your local patches >> before i start naming and shaming you). > > > All the pulls linked from that AArch64 tracker issue above were submitted > upstream first before merging into the ldc repo. Only one patch that I know > of hasn't been merged upstream yet: my commit to add IEEE Quadruple support > to core.internal.convert, only because I want to add another Android commit > to that pull soon, but the patch is available in the open druntime pulls. > > If you know of some other patches that need to be upstreamed, let us know, > AFAIK they were all upstreamed first. >
Can you send me links to any open PR you have? These should not be sitting around for months without merge. The 128-bit float support was particularly annoying as I nearly wasted a day implementing it myself without knowing someone already had done the work.