On Sunday, 23 December 2018 at 10:15:53 UTC, Walter Bright wrote:
> On 12/22/2018 6:29 PM, Thomas Mader wrote:
>> To me it looks like fp.c has the implementation and evalu8 is using it.
>> The name mangling of fp.c compiled with g++ is different from evalu8.d compiled with ldc.
>
> I wonder why you're compile some parts with g++ and some with ldc.

You are right I also like to keep things the same and less complex but to be honest I tried to use clang but failed. The std environment in Nix on Linux is gcc and I don't know yet how to properly overwrite it.
I also think that this might be one solution to the problem.
Still, it's unclear to me what is going on.

> When I have trouble with name mangling variations, I use 'grep' to see what the name mangling is in the various object files, then I fiddle with the declarations until they line up.

Well the problem is that the mangling produced by g++ is _Z7_moduloee but the mangling produced with ldc 1.13.0 on my environment is _Z7_moduloeS_ .
The first is a valid mangling according to some online demanglers but the last one isn't.
I then tried to compile evalu8 [1] with ldc 1.11.0 and dmd 2.081.2 and they both produced the correct name mangling.
I tried to change the llvm version used when building ldc but that didn't solve my problem or introduced new ones.
I will now try to try again with ldc 1.11.0 but with a fresh build so I am sure that the environment for building 1.11.0 is exactly the same as for 1.13.0.
If that still doesn't fail the problem must be somewhere in ldc 1.13.0 in combination with the environment I am using.

[1] ldmd2 -c -of../generated/linux/release/64/evalu8.o  -version=MARS -fPIC -J../generated/linux/release/64 -w -de -O -release -inline -m64 -mv=dmd.backend=dmd/backend -betterC dmd/backend/evalu8.d

On Sunday, 23 December 2018 at 12:16:53 UTC, Thomas Mader wrote:
> I also think that this might be one solution to the problem.
> Still, it's unclear to me what is going on.

No it's not a solution. The same problem is reproducible on OSX and the std environment of Nix is clang.

On Sunday, 23 December 2018 at 12:16:53 UTC, Thomas Mader wrote:
> On Sunday, 23 December 2018 at 10:15:53 UTC, Walter Bright wrote:
>> On 12/22/2018 6:29 PM, Thomas Mader wrote:
>>> To me it looks like fp.c has the implementation and evalu8 is using it.
>>> The name mangling of fp.c compiled with g++ is different from evalu8.d compiled with ldc.
>>
>> I wonder why you're compile some parts with g++ and some with ldc.
>
> You are right I also like to keep things the same and less complex but to be honest I tried to use clang but failed. The std environment in Nix on Linux is gcc and I don't know yet how to properly overwrite it.

It is normal to use g++ with ldc. You should use your system compiler with ldc, and that's of course not necessarily clang.

The mangling is done by LDC itself, not LLVM, and so it is a bug in LDC. In this particular case, the second argument of _modulo is the same as the first and the mangler is (incorrectly) replacing the type of the second with a backreference to the first type. That's what the mangler should do for user types, but not for builtin types.

-Johan

On Sunday, 23 December 2018 at 13:05:06 UTC, Johan Engelen wrote:
> The mangling is done by LDC itself, not LLVM, and so it is a bug in LDC.

I came to the same conclusion after finishing my tests.
I created a bug: https://github.com/ldc-developers/ldc/issues/2954

On Sunday, 23 December 2018 at 14:48:29 UTC, Thomas Mader wrote:
> On Sunday, 23 December 2018 at 13:05:06 UTC, Johan Engelen wrote:
>> The mangling is done by LDC itself, not LLVM, and so it is a bug in LDC.
>
> I came to the same conclusion after finishing my tests.
> I created a bug: https://github.com/ldc-developers/ldc/issues/2954

According to Johan, this bug was introduced by a pull kinke and I wrote to add support for a different real mangling on Android/x64, which broke your mangling that wasn't covered by the test suite:

https://github.com/ldc-developers/ldc/pull/2917/files

It appears he is fixing both issues ATM. I suggest you either stick with LDC 1.12 as the compiler building DMD for now, or backport his eventual patch to LDC 1.13 if you can.