digitalmars.D.ldc - Using the real target "real" type (cross compiling)
- Dan Olson (15/15) Feb 10 2014 I switched to using ldc merge-2.064 branch for all my iOS hacking. The
- Kai Nacke (19/40) Feb 10 2014 I know this annoying issue. It also prevents cross compiling from
- Kai Nacke (5/6) Mar 14 2014 See here: https://github.com/ldc-developers/ldc/pull/587
- Dan Olson (2/10) Mar 17 2014 Very cool Kai. I am looking forward to using with the iOS.
- Dan Olson (6/19) Jan 09 2015 Kai, just checking to see if this pull got in to some version of LDC. I
- Joakim (7/29) Jan 10 2015 I don't think Kai sees forum posts that are not responses to his
- Dan Olson (14/43) Jan 11 2015 Hi Joakim - It appears that Kai's work is still in progress on branch:
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
Feb 10 2014
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 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
Feb 10 2014
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
Mar 14 2014
"Kai Nacke" <kai redstar.de> writes:On Monday, 10 February 2014 at 19:47:32 UTC, Kai Nacke wrote:Very cool Kai. I am looking forward to using with the iOS.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
Mar 17 2014
Dan Olson <zans.is.for.cans yahoo.com> writes:"Kai Nacke" <kai redstar.de> writes: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, DanOn Monday, 10 February 2014 at 19:47:32 UTC, Kai Nacke wrote:Very cool Kai. I am looking forward to using with the iOS.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
Jan 09 2015
On Friday, 9 January 2015 at 17:03:13 UTC, Dan Olson wrote:Dan Olson <zans.is.for.cans yahoo.com> writes: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."Kai Nacke" <kai redstar.de> writes: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.On Monday, 10 February 2014 at 19:47:32 UTC, Kai Nacke wrote:Very cool Kai. I am looking forward to using with the iOS.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
Jan 10 2015
"Joakim" <dlang joakim.fea.st> writes:On Friday, 9 January 2015 at 17:03:13 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 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.Dan Olson <zans.is.for.cans yahoo.com> writes: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."Kai Nacke" <kai redstar.de> writes: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.On Monday, 10 February 2014 at 19:47:32 UTC, Kai Nacke wrote:Very cool Kai. I am looking forward to using with the iOS.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
Jan 11 2015
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/longdouble2Yes, 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
Jan 14 2015
"Kai Nacke" <kai redstar.de> writes:On Sunday, 11 January 2015 at 16:37:21 UTC, Dan Olson wrote:Maybe I can help? I can pull in longdouble2 branch and see what it fixes for me and see if anything new breaks.Hi Joakim - It appears that Kai's work is still in progress on branch: https://github.com/redstar/ldc/tree/longdouble2Yes, 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
Jan 15 2015
On Thursday, 15 January 2015 at 17:26:53 UTC, Dan Olson wrote:"Kai Nacke" <kai redstar.de> writes: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, KaiOn Sunday, 11 January 2015 at 16:37:21 UTC, Dan Olson wrote:Maybe I can help? I can pull in longdouble2 branch and see what it fixes for me and see if anything new breaks.Hi Joakim - It appears that Kai's work is still in progress on branch: https://github.com/redstar/ldc/tree/longdouble2Yes, 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
Jan 16 2015
"Kai Nacke" <kai redstar.de> writes:Kai, I got your longdouble2 branch merged into my local repo with iOS support. I did have to make a few additions to the ldc::longdouble class, probably due to my build env with different headers (MacOS SDK bundled with Xcode). I'll share the updates once the dust settles. Good news it that longdouble2 works and I get same unittest results as my exiting kludge to hardcode real to double (6 module unittests fail due to real value miscompare on my iPad mini). I think it is time for me to look closer at the failures: at least one is even documented that it only works for 80-bit reals. -- DanMaybe 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
Jan 24 2015
Dan Olson <zans.is.for.cans yahoo.com> Dan Olson <zans.is.for.cans yahoo.com> writes:Kai, I got your longdouble2 branch merged into my local repo with iOS support. I did have to make a few additions to the ldc::longdouble class, probably due to my build env with different headers (MacOS SDK bundled with Xcode). I'll share the updates once the dust settles. Good news it that longdouble2 works and I get same unittest results as my exiting kludge to hardcode real to double (6 module unittests fail due to real value miscompare on my iPad mini). I think it is time for me to look closer at the failures: at least one is even documented that it only works for 80-bit reals.It appears that some others unittests fail because ARM Cortex uses flush-to-zero mode by default instead of subnormal floats. Seems many unittests are on the boundary of normal and subnormal. I'll stomp these out one at a time by either disabling or changing the unittest for ARM.
Jan 24 2015
Hi Dan! On Saturday, 24 January 2015 at 23:20:00 UTC, Dan Olson wrote:Kai, I got your longdouble2 branch merged into my local repo with iOS support. I did have to make a few additions to the ldc::longdouble class, probably due to my build env with different headers (MacOS SDK bundled with Xcode). I'll share the updates once the dust settles.Really nice!Good news it that longdouble2 works and I get same unittest results as my exiting kludge to hardcode real to double (6 module unittests fail due to real value miscompare on my iPad mini). I think it is time for me to look closer at the failures: at least one is even documented that it only works for 80-bit reals. -- DanYes, not all tests are implement for all floating point types. Regards, Kai
Jan 26 2015