fix Issue 19499 - __c_long_double has exact match with double

[WalterBright]

This reverts #8632 which was an attempt to fix https://issues.dlang.org/show_bug.cgi?id=19201 but dmd source code should be fixed instead of changing the language semantics.

[dlang-bot]

Thanks for your pull request, @WalterBright!

Bugzilla references

Auto-close	Bugzilla	Severity	Description
✓	19499	regression	__c_long_double has exact match with double

⚠️⚠️⚠️ Warnings ⚠️⚠️⚠️

• Regression or critical bug fixes should always target the stable branch. Learn more about rebasing to stable or the D release process.

To target stable perform these two steps:

1. Rebase your branch to upstream/stable:

git rebase --onto upstream/stable upstream/master

2. Change the base branch of your PR to stable

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub fetch digger
dub run digger -- build "master + dmd#9117"

[thewilsonator]

Target stable.

[ibuclaw]

This will cause a bootstrap build regression.

Without checking, first point of call for changing dmd would be the sinteger_t aliases.

alias sinteger_t = int64_t;
alias uinteger_t = uint64_t;

So there wouldn't be any implicit D long <-> C long conversions in the first place.

Can work backwards from there to find less breaking ways to fix dmd source.

[WalterBright]

You listed about 4 places in dmd source, why not just insert a cast in those places?

[ibuclaw]

Looks like druntime has mitigated this, so no longer reproducible on Linux (dlang/druntime#2302). But will still fail to build on OSX.

You listed about 4 places in dmd source, why not just insert a cast in those places?

There are explicit casts in all linked places, the kinds of errors I was seeing:

gcc/d/dmd/dcast.d:381:52: error: cannot cast expression ‘cast(long)value’ of type ‘long’ to ‘longdouble’
                 const f = cast(T) cast(sinteger_t) value;
                                                    ^
gcc/d/dmd/dcast.d:459:22: error: template instance ‘dmd.dcast.implicitConvTo.ImplicitConvTo.visit.isLosslesslyConvertibleToFP!(longdouble)’ error instantiating
                 if (!isLosslesslyConvertibleToFP!real_t)
                      ^

Casts would mean adding overrides where implicit long -> int64_t conversion is rejected.

static if (!is(int32_t == int))
    void set()(int d) { return this.set(cast(int32_t)d); }
static if (!is(uint32_t == uint))
    void set()(uint d) { return this.set(cast(uint32_t)d); }
static if (!is(int64_t == long))
    void set()(long d) { return this.set(cast(int64_t)d); }
static if (!is(uint64_t == ulong))
    void set()(ulong d) { return this.set(cast(uint64_t)d); }

It seems odd however that implicit conversion may work on some, but fail on other host systems depending on what druntime bindings are aliasing today.

[WalterBright]

@ibuclaw I don't really understand your comment. What I need is can you fix the dmd code to fix the bootstrap errors you're seeing? Can you submit a PR for that?

[ibuclaw]

The bootstrap errors are no longer reproducible since druntime changed aliases of int64_t and uint64_t in dlang/druntime#2302.

[ibuclaw]

The bootstrap errors are in places where there's already appropriate casting.

f = cast(longdouble) cast(long) value;

The errors are local to the longdouble implementation which only has overrides for int64_t/uint64_t, not long/ulong.

What I posted is what adding long and ulong overrides would look like in gdc's longdouble. Which just looks silly.

[WalterBright]

It doesn't matter if it looks silly in the dmd source code. What does matter is adding an "exact" match of __c_long_double with double, which will cause no end of grief.

[ibuclaw]

Well I am not happy that conversely, having long and int64_t not match will cause the same level of grief.

This isn't just compiling dmd itself, but anyone interfacing with a C++ library that uses int64_t/uint64_t in its public API.

[WalterBright]

Well I am not happy that conversely, having long and int64_t not match will cause the same level of grief. This isn't just compiling dmd itself, but anyone interfacing with a C++ library that uses int64_t/uint64_t in its public API.

This issue affects C++ as well, because it affects C++ name mangling. Different integer types with the same size can have different mangling. D code should use core.stdc.stdint's definitions of int64_t and uint64_t to match the C++ mangling.

[ibuclaw]

Well it's no good if getting the correct C++ mangling means making code that uses it uncompilable.

import core.stdc.stdint;

void func(uint64_t r);
void func(int64_t r);

void main()
{
    func(0L);
}

It is not ambiguous here as to which overload should be called. if the special enum types don't solve this, then there is no point to having them in the first place.