Upgrade front-end & libs to v2.089.0-beta.1

[kinke]

No description provided.

[kinke]

Early showstoppers (after the usual C++ header regressions):

• Renovate core.atomic, improve and simplify the constraints on functions dlang/druntime#2745 (comment) wrt. extra LDC-specific core.atomic unittest.
• When working around that one, linker errors for the druntime test runner wrt. move template (possibly due to -dip1000, which in turn is required for some new @safe unittests?):

druntime-ldc-unittest-debug.lib(atomic.obj) : error LNK2019: unresolved external symbol _D4core8lifetime__T4moveTSQy6atomic__T10TailSharedTOSQBzQBc20__unittest_L1210_C24FNaNbNfZ2S2ZQCdZQDaFNaNbNiNfMNkKQDkZQDo referenced in function _D4core6atomic__T10atomicLoadVEQBdQBb11MemoryOrderi5TSQCaQBy20__unittest_L1210_C24FNaNbNfZ2S2ZQCzFNaNbNiNeKOxSQEeQEcQCeFNaNbNfZQBlZSQFaQEy__T10TailSharedTOSQFyQFwQDyFNaNbNfZQDfZQBk
druntime-ldc-unittest-debug.lib(atomic.obj) : error LNK2019: unresolved external symbol _D4core8lifetime__T4moveTSQy6atomic__T10TailSharedTOSQBzQBc20__unittest_L1210_C24FNaNbNfZ2S3ZQCdZQDaFNaNbNiNfMNkKQDkZQDo referenced in function _D4core6atomic__T10atomicLoadVEQBdQBb11MemoryOrderi5TSQCaQBy20__unittest_L1210_C24FNaNbNfZ2S3ZQCzFNaNbNiNeKOxSQEeQEcQCeFNaNbNfZQBlZSQFaQEy__T10TailSharedTOSQFyQFwQDyFNaNbNfZQDfZQBk
druntime-ldc-unittest-debug.lib(atomic.obj) : error LNK2019: unresolved external symbol _D4core8lifetime__T4moveTOCQz6atomic20__unittest_L1210_C24FNaNbNfZ1CZQByFNaNbNiNfMNkKOQCiZOQCn referenced in function _D4core6atomic__T10atomicLoadVEQBdQBb11MemoryOrderi5TCQCaQBy20__unittest_L1210_C24FNaNbNfZ1CZQCyFNaNbNiNeKOxCQEdQEbQCdFNaNbNfZQBkZOCQFaQEyQDaFNaNbNfZQCh

[kinke]

The druntime-test-runner linker errors are worked around, but the underlying issue of course persists.

[kinke]

Single remaining failure for x86, failing runnable/interpret.d, is due to a smelly AST change:

class Test109C { this(){ this.c = this; } Test109C c; }
const t109c = new Test109C();

void main()
{
    assert(t109c.c is t109c);
}

Previous -vcg-ast output for the global:

const const(Test109C) t109c = Test109C(Test109C(<recursion>));

New (where we end up with 2 static objects):

const const(Test109C) t109c = Test109C(Test109C(Test109C(<recursion>)));

[kinke]

@rainers: Maybe you can help - our code here relies on the identity of the ClassReferenceExp.value (a StructLiteralExp); i.e., if 2 static class references share the identical struct literal, we use the same global.

Previously:

* * DtoConstExpInit(targetType = const(Test109C), exp = Test109C(Test109C(<recursion>)))
* * * ClassReferenceExp::toConstElem: Test109C(Test109C(<recursion>)) @ const(Test109C)
* * * * Getting initializer for: c
* * * * * ClassReferenceExp::toConstElem: Test109C(Test109C(<recursion>)) @ current.Test109C
* * * * * * Using existing global: @.classref = internal global %current.Test109C

The 1st inner class reference now apparently uses another StructLiteralExp:

* * DtoConstExpInit(targetType = const(Test109C), exp = Test109C(Test109C(Test109C(<recursion>))))
* * * ClassReferenceExp::toConstElem: Test109C(Test109C(Test109C(<recursion>))) @ const(Test109C)
* * * * Getting initializer for: c
* * * * * ClassReferenceExp::toConstElem: Test109C(Test109C(<recursion>)) @ current.Test109C
* * * * * * Getting initializer for: c
* * * * * * * ClassReferenceExp::toConstElem: Test109C(Test109C(<recursion>)) @ current.Test109C
* * * * * * * * Using existing global: @.classref.1 = internal global %current.Test109C

I'm thinking it might have to do with the new CTFE regions and hope you have some insight into that.

[kinke]

@rainers: Never mind, StructLiteralExp.origin seems to do just fine.

[rainers]

@rainers: Never mind, StructLiteralExp.origin seems to do just fine.

Good to hear, I had no idea what this all meant ;-)

[kinke]

Hmm, for Shippable on AArch64, negating a NaN yields the same NaN, the sign bit isn't flipped, regardless of precision (float/double/real). LLVM 10 will introduce an fneg instruction, which replaces the current -0 - NaN implementation and which should fix exactly this corner case, according to http://lists.llvm.org/pipermail/llvm-dev/2018-September/126017.html.