Upgrade frontend & libs to v2.096.0+

[kinke]

No description provided.

[JohanEngelen]

Hi @kinke . I see that on the macOS tester, there are warnings in compiling the memory.cpp stdcpp testcase. I'm confused, the C++ compiler is called with -std=c++98, but the code cannot be compiled in that mode because it contains unique_ptr. How can that work for DMD ? Somehow the compiler is still generating the program, because the output program is run (and then fails) ?

Edit: dlang/druntime#3420

[kinke]

Hi Johan, thx. Does this fix the seemingly clang/libc++-specific failure?

[JohanEngelen]

Hi Johan, thx. Does this fix the seemingly clang/libc++-specific failure?

I did not test it. It probably doesn't fix it, because it already worked for DMD... I'll look into it tonight.

[JohanEngelen]

The issue with the stdcpp memory test on macOS: we do a double delete. I simplified the testcase a bit:

// In C++:
void doNothing(std::unique_ptr<int> x)
{
    printf("cpp: %p\n", x.get());
    x.reset();
    printf("cpp: %p\n", x.get());
}

// In D:
    unique_ptr!int up = make_unique!int(10);
    printf("%p\n", up.get);
    doNothing(up.move);

Running that (compiled with -std=c++11), the output is:

0x7fa53f4029c0
cpp: 0x7fa53f4029c0
cpp: 0x0
memory(15935,0x7fffad95a380) malloc: *** error for object 0x7fa53f4029c0: pointer being freed was not allocated

A backtrace shows that the double free happens while running a unique_ptr!int dtor on the D side on the line with doNothing.

[JohanEngelen]

I think I found the problem. The IR looks like this:

  %3 = bitcast %"core.stdcpp.memory.unique_ptr!(int, default_delete!int).unique_ptr"* %.hidden_copy_for_IndirectByvalRewrite to i8* ; [#uses = 1]
  %4 = bitcast %"core.stdcpp.memory.unique_ptr!(int, default_delete!int).unique_ptr"* %__pfx6 to i8* ; [#uses = 1]
  call void @llvm.memcpy.p0i8.p0i8.i64(i8* align 8 %3, i8* align 8 %4, i64 8, i1 false)
  call void @_Z9doNothingNSt3__110unique_ptrIiNS_14default_deleteIiEEEE(%"core.stdcpp.memory.unique_ptr!(int, default_delete!int).unique_ptr"* noalias nocapture align 8 %.hidden_copy_for_IndirectByvalRewrite) #1
  br label %dtor.__pfx6

Note that the temporary for the doNothing call parameter is stored on address %__pfx6 and %4. However we make an extra copy of the temporary and store in at %3 and pass that to doNothing. Hence the C++ code is working with the 2nd temporary on %3 and is modifying it (setting the .ptr to null by the reset call in the C++ code). What should happen is that back on the D side, the temporary now has null in .ptr. But we continue with calling the dtor on the 1st temporary, completely ignoring that we passed the 2nd temporary to C++. I don't know why we make the hidden copy, but we shouldn't.

[kinke]

Ah thx for digging. C++ interop wrt. non-PODs passed by value has been fixed on non-Windows with v2.096, making the caller responsible for destructing the arg (passed by ref under the hood). IndirectByvalRewrite ought to figure out that __pfx6 is a temporary and can thus be passed directly without bitcopy...