I switched to using ldc merge-2.064 branch for all my iOS hacking. The newer std.math has some nice static asserts that failed because dmd is using the compile host "long double" type for determing the properties of type real.  Thank you for static assertions!

Mac x86_64 long double != Arm long double

I hacked dmd to make longdouble = double so I could cross compile this newer phobos to iOS.  But are there other things like real types that dmd code is learning from host, but should be told what the target is using?

Anyway, this seems like more of a dmd thing.  What is the best approach to solve?  I am ok for now with hacking on my own branch but wishing for a better solution.

Thanks,
-- 
Dan

Hi Dan!

On Monday, 10 February 2014 at 16:55:47 UTC, Dan Olson wrote:
> I switched to using ldc merge-2.064 branch for all my iOS hacking. The
> newer std.math has some nice static asserts that failed because dmd is
> using the compile host "long double" type for determing the properties
> of type real.  Thank you for static assertions!
>
> Mac x86_64 long double != Arm long double
>
> I hacked dmd to make longdouble = double so I could cross compile this
> newer phobos to iOS.  But are there other things like real types that
> dmd code is learning from host, but should be told what the target is
> using?
>
> Anyway, this seems like more of a dmd thing.  What is the best approach
> to solve?  I am ok for now with hacking on my own branch but wishing for
> a better solution.
>
> Thanks,

I know this annoying issue. It also prevents cross compiling from x86_64 to ppc64 because 80bit floats are not 128bit floats. It's issue #259 (https://github.com/ldc-developers/ldc/issues/259).

I don't have a workaround. But I am working on a solution. :-)

As discussed in the issue, I replace the real_t data type with a wrapper around llvm::APFloat. Then it is possible to configure the float properties based on the target architecture.

I have a first prototype already implemented. With the refactorings of dmd 2.065 (see my other post from today) it is much easier to integrate: it is now more obvious how to disable some built-in functions. (E.g. I have an implementation of sqrt() which still has a 1-bit difference compared to sqrtl() on x86_64. IMHO it is better to disable CTFE for these functions then to introduce some subtle differences between CTFE and runtime.)

I'll post it here when it is integrated.

Regards,
Kai

On Monday, 10 February 2014 at 19:47:32 UTC, Kai Nacke wrote:
>
> I don't have a workaround. But I am working on a solution. :-)
>

See here: https://github.com/ldc-developers/ldc/pull/587

Will be part of version 0.14.0.

Regards,
Kai

"Kai Nacke" <kai@redstar.de> writes:

> On Monday, 10 February 2014 at 19:47:32 UTC, Kai Nacke wrote:
>>
>> I don't have a workaround. But I am working on a solution. :-)
>>
>
> See here: https://github.com/ldc-developers/ldc/pull/587
>
> Will be part of version 0.14.0.
>
> Regards,
> Kai

Very cool Kai.  I am looking forward to using with the iOS.

Dan Olson <zans.is.for.cans@yahoo.com> writes:

> "Kai Nacke" <kai@redstar.de> writes:
>
>> On Monday, 10 February 2014 at 19:47:32 UTC, Kai Nacke wrote:
>>>
>>> I don't have a workaround. But I am working on a solution. :-)
>>>
>>
>> See here: https://github.com/ldc-developers/ldc/pull/587
>>
>> Will be part of version 0.14.0.
>>
>> Regards,
>> Kai
>
> Very cool Kai.  I am looking forward to using with the iOS.

Kai, just checking to see if this pull got in to some version of LDC.  I am updating my LDC fork supporting iOS and I don't see the new files like gen/ldc-real.h in master.

Thanks,
Dan

On Friday, 9 January 2015 at 17:03:13 UTC, Dan Olson wrote:
> Dan Olson <zans.is.for.cans@yahoo.com> writes:
>
>> "Kai Nacke" <kai@redstar.de> writes:
>>
>>> On Monday, 10 February 2014 at 19:47:32 UTC, Kai Nacke wrote:
>>>>
>>>> I don't have a workaround. But I am working on a solution. :-)
>>>>
>>>
>>> See here: https://github.com/ldc-developers/ldc/pull/587
>>>
>>> Will be part of version 0.14.0.
>>>
>>> Regards,
>>> Kai
>>
>> Very cool Kai.  I am looking forward to using with the iOS.
>
> Kai, just checking to see if this pull got in to some version of LDC.  I
> am updating my LDC fork supporting iOS and I don't see the new files
> like gen/ldc-real.h in master.

I don't think Kai sees forum posts that are not responses to his posts, as he's likely accessing this forum through email.

I don't think the linked pull got in, as the files you're looking for are not in git, but some of the files deleted in that pull have also been deleted in git.  So you'll need to update the patch from that pull in order to apply it to latest git master.

"Joakim" <dlang@joakim.fea.st> writes:

> On Friday, 9 January 2015 at 17:03:13 UTC, Dan Olson wrote:
>> Dan Olson <zans.is.for.cans@yahoo.com> writes:
>>
>>> "Kai Nacke" <kai@redstar.de> writes:
>>>
>>>> On Monday, 10 February 2014 at 19:47:32 UTC, Kai Nacke wrote:
>>>>>
>>>>> I don't have a workaround. But I am working on a solution. :-)
>>>>>
>>>>
>>>> See here: https://github.com/ldc-developers/ldc/pull/587
>>>>
>>>> Will be part of version 0.14.0.
>>>>
>>>> Regards,
>>>> Kai
>>>
>>> Very cool Kai.  I am looking forward to using with the iOS.
>>
>> Kai, just checking to see if this pull got in to some version of
>> LDC.  I
>> am updating my LDC fork supporting iOS and I don't see the new files
>> like gen/ldc-real.h in master.
>
> I don't think Kai sees forum posts that are not responses to his posts, as he's likely accessing this forum through email.
>
> I don't think the linked pull got in, as the files you're looking for are not in git, but some of the files deleted in that pull have also been deleted in git.  So you'll need to update the patch from that pull in order to apply it to latest git master.

Hi Joakim - It appears that Kai's work is still in progress on branch:

https://github.com/redstar/ldc/tree/longdouble2

I am kind of excited for it because pretty much everything is functionally working for D on iOS except for some floating-point stuff. In fact, of 8 failing phobos unittests on iOS, I think 6 are math related.

Last year I hacked together a kludge in ldc to get real == double when compiling on x86_64, but there are some off-by-one precision problems produced by functions such as

  to!double("3673.562") != 3673.562

where as C's strtod("3673.562", null) == 3673.562.  Since conv.d uses real type for some of its math, I want to rule out that before doing more work to figure out what is going wrong.

On Sunday, 11 January 2015 at 16:37:21 UTC, Dan Olson wrote:
> Hi Joakim - It appears that Kai's work is still in progress on branch:
>
> https://github.com/redstar/ldc/tree/longdouble2

Yes, this is still work in progress. There are some unit test failures in std.math. And I have trouble to find numerical algorithms for sin(), cos() tan() etc. which deliver the required accuracy. (This is used in CTFE.)

Regards,
Kai

"Kai Nacke" <kai@redstar.de> writes:

> On Sunday, 11 January 2015 at 16:37:21 UTC, Dan Olson wrote:
>> Hi Joakim - It appears that Kai's work is still in progress on branch:
>>
>> https://github.com/redstar/ldc/tree/longdouble2
>
> Yes, this is still work in progress. There are some unit test failures
> in std.math. And I have trouble to find numerical algorithms for
> sin(), cos() tan() etc. which deliver the required accuracy. (This is
> used in CTFE.)
>
> Regards,
> Kai

Maybe I can help?  I can pull in longdouble2 branch and see what it fixes for me and see if anything new breaks.

On Thursday, 15 January 2015 at 17:26:53 UTC, Dan Olson wrote:
> "Kai Nacke" <kai@redstar.de> writes:
>
>> On Sunday, 11 January 2015 at 16:37:21 UTC, Dan Olson wrote:
>>> Hi Joakim - It appears that Kai's work is still in progress on
>>> branch:
>>>
>>> https://github.com/redstar/ldc/tree/longdouble2
>>
>> Yes, this is still work in progress. There are some unit test failures
>> in std.math. And I have trouble to find numerical algorithms for
>> sin(), cos() tan() etc. which deliver the required accuracy. (This is
>> used in CTFE.)
>>
>> Regards,
>> Kai
>
> Maybe I can help?  I can pull in longdouble2 branch and see what it
> fixes for me and see if anything new breaks.

You're welcome! I rebased the PR after the 0.15.1 release so it should be almost up to date. The failing test(s) in std.math should be easy to spot (just look at the Travis output). The other failing unit test is the CTFE test which grumble on the numerical precising of the results.

Regards,
Kai