ldc
ldc copied to clipboard
ldc-developers
32-bit ltsmaster cannot bootstrap 1.13+: core.bitop.bsf not callable using ulong
I encountered the following error when compiling ldc "master" using a freshly built ldc "ltsmaster":
ldc/dmd/builtin.d(254): Error function core.bitop.bsf (uint v) is not callable using argument types (ulong) (and corresponding for bcf)
System: Rasbery Pi 3B+ Arch Linux 4.14.31 LDC 0.17.6 LLVM 7.0.0 armv71-unknown-linux-gnueabihf cortex-a53
Note: Patching the sources locally with an ugly cast it was possible to compile the rest.
Ah, seems like master (probably since v2.083 or 2.082) isn't compilable with a 32-bit ltsmaster host compiler (not just ARM), because ltsmaster's druntime only provides bs{f,r}(size_t). [An additional intermediate compiler (~2.080) should work.]
Should be easy to fix, but maybe it's time to just stop ltsmaster instead. I avoided using it when bringing up Android/x86 and Android/x64 recently, too much of a pain to backport porting patches from master, got by fine. First ported the stdlib by cross-compiling the stdlib test runners, then cross-compiled ldc master itself, finally built ldc master on the target with that cross-compiled ldc.
Only issue recently has been lower-precision CTFE reals on host screwing up some cross-compiled stdlib tests on target, would be nice if we could move all CTFE reals to IEEE Quadruple precision.
Yeah I've always been reluctant wrt. backporting stuff to ltsmaster. As it only concerns 32-bit host compilers, I don't really care. ;)
would be nice if we could move all CTFE reals to IEEE Quadruple precision
Sounds like a reasonable choice, precision-wise. AFAIK, GDC uses a software real_t type on all hosts, so I guess we don't have to care much about compile-time performance.
Only issue recently has been lower-precision CTFE reals on host screwing up some cross-compiled stdlib tests on target
Hmm, could you try rebuilding LDC yet another time, with the LDC generated by the cross-compiled LDC? I'd have hoped that overflows and inaccuracies don't propagate from the host to the target, at least not across 2 hops. Your current final LDC probably still features wrong values for embedded constants, as those have been computed by the cross-compiler with limited 80-bit real_t precision (edit: that's almost certainly incorrect and should only apply to the first cross-compiled LDC; I'd still be interested in another hop though).
Edit2: Ah, your current final LDC is linked against druntime/Phobos compiled with the 1st cross-compiled LDC, that may likely be the problem, and make another hop interesting.
I'd have hoped that overflows and inaccuracies don't propagate from the host to the target, at least not across 2 hops
No, you're reading too far into it, that's fine, as the DMD frontend doesn't really use druntime/Phobos much and I doubt it has any constant reals.
I was talking strictly about the first porting step, ie cross-compiling the test runners from x64 to a platform with IEEE Quadruple real precision.
No, you're reading too far into it, that's fine, as the DMD frontend doesn't really use druntime/Phobos much and I doubt it has any constant reals.
Ah okay, all good then. The CTFE stuff switched back to the C runtime; we've been using host Phobos for some LDC versions. While I don't like that C/Phobos divergence (slightly different CTFE/runtime results quite possible), it makes bootstrapping a lot easier.
There are some real constants, e.g., FP type properties (T.{nan,max,min,epsilon,...}), but those are normally overridden via LLVM's APFloat (and those values likely over/underflow when cross-compiling to a target with higher precision).
Ok, for the specific 32-bit non cross compilation problem... I got as far as LDC tagged v1.12.0 but going further, trying to recompile itself or later versions, gave other errors: "include/d/std/datetime/date.d(41): Error: package name 'std.datetime' conflicts with usage... in file include/d/std/datetime.d" (similar for systime(32) and timezone(28) )
Earlier version often failed due to, I think, LLVM7.0.0 was too new. I did not try every intermediate version though, it takes time on the poor Pi.
Thinking about going 64-bit also but it seem to be rare yet on the Pi platforms. Cross compiling is the right way but it's very convenient to try small stuff directly on target.
@JudgeFish About the datetime issue: the file std/datetime.d no longer exists. So it should not be there in your source tree. Probably something went wrong with your git checkout such that old files are lingering there.
That's most likely caused by installing different versions of LDC into the same directory, without removing it first - the imports are simply copied there, overwriting previous versions, but if something (std.datetime) turns from monster module to package, you get these problems; I had them too. ;)
Yes, that was the cause... I just used "make install" back-to-back. Thanks
