On Thursday, 17 July 2014 at 10:58:59 UTC, Konstantinos Margaritis via digitalmars-d-ldc wrote:
> On Tue, 15 Jul 2014 10:35:22 +0000
> Kai Nacke via digitalmars-d-ldc <digitalmars-d-ldc@puremagic.com> wrote:
>> No. The real type with maximum precision on PowerPC is called doubledouble. Basically, 2 64-bit doubles are combined to give roughly the precision of a 128-bit double. In this case the mantissa has a precision of 106 digits. The assertion simply states that the case "real.mant_dig==106" is not implemented.
>
> Hi Kai,
>
> Is there any way I can help with that?
>
> Regards
>
> Konstantinos

Hi Konstantinos,

you can have a look at std.math source. I am not an expert in PPC double-double type so every help here is welcome.

Regards,
Kai

On Thursday, 17 July 2014 at 12:25:19 UTC, Konstantinos Margaritis via digitalmars-d-ldc wrote:
> On Thu, 17 Jul 2014 11:38:07 +0000
> David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc@puremagic.com>
> wrote:
>
>> On Tuesday, 15 July 2014 at 19:01:49 UTC, Konstantinos Margaritis via digitalmars-d-ldc wrote:
>> > So, I guess in most cases where "version( linux )" is used, an
>> > equivalent "version ( glibc )" might be used that would cater for both OSes.
>> 
>> This seems like a promising direction as we have a very similar problem with Android, although it's the other way round there (Linux Kernel, but Bionic instead of glibc).
>> 
>> If anybody is interested in taking this up, please be sure to coordinate this with upstream druntime, as all compilers would benefit from that.
>
> I can give it a shot locally and at least find out if it works at all,
> by replacing linux with glibc. If it does work on kfreebsd, I could
> attempt to send a patch upstream.

I thought about mentioning the Android connection, but didn't because I figured you probably didn't want to do that work.  Replacing linux with glibc might work for kfreebsd, but it's not going to be accepted upstream, because right now "linux" really means "linux kernel and glibc."  Simply renaming it to "glibc" doesn't really solve the problem, that we need to separate out the linux kernel APIs from the glibc APIs.

Since I've been working on an Android port of D, I've offered to help with this a couple times, by separating the bionic APIs that are currently lumped with linux kernel APIs, if someone else pitched in on separating linux+glibc, but never found anyone who was interested.  If you are, let me know.