Upgrade to D v2.081.0 #2752
Upgrade to D v2.081.0 #2752
Conversation
|
I included upstream's/Rainer's new |
|
Semaphore CI (Ubuntu 18.04) is doing extremely well without self-compilation cycle, only |
…nlined As `std.string.fromStringz()` is now a template. Use `std.math.nextDown(double)` instead.
The AST now features special-ref result variables (storage classes:
ref, temp, result) after rewriting out contracts; from dmd/func.d:
/* out(id1) { statements1... }
* out(id2) { statements2... }
* ...
* becomes:
* out(__result) { { ref id1 = __result; { statements1... } }
* { ref id2 = __result; { statements2... } } ... }
*/
We are talking about the `id1` and `id2` variables here.
There's an existing assertion that we don't set a special-ref variable's
lvalue (T**) to the sret pointer (T*) which was already triggered when
compiling Phobos without unittests.
|
Only Wrt. crashing self-compiled LDC, I guess that's due to the numerous |
Use more robust LLVM inline assembly, which works around a `mov` issue in DMD-style inline asm (at least on Win64) - additional dereferencing when moving a `longdouble_soft` parameter (passed indirectly by value in a GP register) to RAX instead of just copying the address.
And revise the Win64 ABI return rules in this function. Required to make dmd/root/longdouble.d (mostly extern(C++)) compile.
Move the unittest block before the module-level `pure:`, as a pure unittest function cannot access mutable globals.
|
With |
There's a new need to access a class' vtable symbol, see dlang/dmd#8362. Use it as alias to the actual vtable symbol with different type (dummy: `i8*`, actual: `[N x i8*]`) and mangled name. I tried matching the special symbol's mangled name and using an appropriate static array front-end type for it, but then casting the symbol address for the assignment leads to issues if the ctor is @safe. So I decided to handle it in DtoSymbolAddress(). Unfortunately, this seems not to solve the extern(C++) issues exposed by LDC self-compilation yet.
dlang/dmd#8359 introduces direct call expressions for struct methods (which cannot be virtual anyway and are so always called directly). Our previous code relied on the instance being a class. There are multiple ways to fix this; I went with this one.
|
Merging stable and fixing the resulting regressions turned out to be almost as much work as merging beta1. ;) Unfortunately it didn't fix the self-compilation issues. The |
|
Just to confirm, did you see Iain's recent fixes? |
|
Nope, thx for the hint. I only checked stable, those all sadly made it into master. I neglected C++ header regressions because it's working fine with all other host compilers, just not with itself. |
|
Ah, good point. |
|
Oh, I see we have an LDC-specific non-final (but |
It's the only dtor for all front-end classes. Make sure it doesn't mess up the vtable, as dtors of extern(C++) classes now need an explicit `final` to be non-virtual. This fixes the self-compilation issues.
The TypeInfo may need an extern(D) wrapper accounting for ABI differences wrt. extern(C++) dtor implementations. This fixes `runnable/cppa.d` for 32-bit x86 targets.
|
A new Windows-only debuginfo test ( OSX also fails due to a new, OSX-specific debuginfo test ( The rest should work. |
That's correct. But these files are more used to ship debug symbols with a released application to the users than used during development. During development the linker inserts references to the object files, the debugger will read the references, find the object files on disk and finally read the debug info from the object files. That's why the debugger works with a D compiler even though no
I implemented the current approach because not using BTW, please ping me in the future for anything macOS related, like this. I might be able to help and explaining, this might have saved you guys some time instead of having to figuring out this again after I already figured out how it works. |
I think it would be set in a similar way like this [1]. In that example [1] Line 83 in 8f4027f |
|
@jacob-carlborg Could you try and see whether you can make it work for LDC? We can then add a flag that allows users to switch between the two possibilities. Having to run dsymutil is a little annoying (I ran into it when doing ASan work), and not many people may know about it (clang runs it for the user) so I'm in favor of having the default be the same as DMD. But I think it's good to be able to switch to dsymutil-based workflow. |
|
@JohanEngelen any hints to where this need to be changed/set in LDC? |
Will do, but you already did help a lot via the very detailed commit message, thanks!
I was thinking about other code analyzers too, profilers etc., but I'm not familiar with Mac.
That's the main issue. While
Manually, of course; I meant doing it like clang and invoking it automatically after linking; but thinking about it, that would defeat the original idea behind these separate debuginfos (faster linking during iterative development). |
True. But I'm not sure which tools would read the debug info. |
Cross-checked against LLVM 6.0.0.
When installing the static lib archived by LDC (1 D object file, 1 C++ one) via CMake, `ranlib` is apparently invoked for the installed copy, which may corrupt it, e.g., reproduced via CircleCI SSH with Xcode 9.2 (.a file size unchanged after (successful) ranlib run): /Applications/Xcode-9.2.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm: foo.a truncated or malformed archive (terminator characters in archive member "c_" not the correct "`\n" values for the archive member header at offset 784) We already encountered this or a very similar bug (with LLVM 5 and some Xcode version IIRC). Copy the file manually for now as hopefully robust workaround.
I've done some digging in LLVM and this is what I came up with: the section attribute is set in in the A The |
|
@jacob-carlborg: Thanks a lot for checking. There is one viable option - we have our own LLVM fork (mainly used for CI and the prebuilt release packages; the [We could also enable more LLVM targets for that build. Linux distros seem to default to including all targets.] |
I.e., druntime and Phobos too, not just ldc-jit-rt. [Only affecting MULTILIB=OFF builds, as the fat libs are generated and copied manually anyway).
kinke
changed the title
I was thinking of that as well, not sure how much customization you're willing to make. As far as I can see there are two ways to patch this: either change the attribute directly or remove the |
|
A third option could be, not sure if it's possible to do for LDC, is to duplicate the data in |
Making the flags configurable at runtime would be nice, but is surely more complicated (we need to remain fully compatible with vanilla LLVM). Edit: well maybe not; couldn't we simply add a Boolean global to
I guess this would be doable via some late extra LLVM pass, but having the (potentially large) debug data twice in the object files seems undesirable. |
I thought you weren't, that's why you're using a fork? |
[macOS] CMake: Work around ranlib potentially corrupting static libs
|
Nope, the fork is just used for more advanced features not available (or not properly working) with vanilla LLVM ( |
|
Oh I just realized LLVM 6.0.1 has already been tagged (annoyingly, no tags in git mirrors...). I merged it into our fork and included a Mach-O section hack: ldc-developers/llvm@7798278 |
|
I also found the culprit for sporadic std.experimental.allocator unittest failures on Win64 (and OSX too IIRC, not sure about Linux): dlang/phobos#6622 |
…thods I happened to stumble upon this by accident.
|
Oh, that |
[Very early stage, Phobos doesn't compile yet, apparently due to NRVO and special ref variable - at least on Win64; no problem for Linux x64 apparently.]