Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] Fix mangling of extern(C++) function with two real arguments. #2953

Closed

Conversation

JohanEngelen
Copy link
Member

The only mangling I am not sure of is the Windows mangling of extern (C++) void withreal(real a, real b). @kinke Can you confirm the check WINDOWS: define {{.*}}?withreal@@YAX_T0@Z makes sense? The online demangler I tested with cannot demangle it; but I don't know what exactly we want to be doing for real arguments on windows w.r.t. mangling.

To be safe for some future platform where real would be mangled by more than one character, I forward to the old default behavior (including type mangling substitution, such as is done for other types whose mangling consists of multiple characters like cfloat).

See also: https://forum.dlang.org/post/[email protected]

dmd/cppmangle.d Outdated
if (cptr[1] != 0)
goto default;
c = cptr[0];
break;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the better fix would be fixing the default case - checking for > 1 chars OR t.isConst(), that's what writeBasicType() does.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The thing is: I don't know what the default case is there for and whether it is tested. So I don't want to muck with that. Perhaps it is needed to do substitutions for single char default-case types.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also don't understand the isConst check btw, because I haven't been able to trigger it (C++ mangling discards const on basic type parameters).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In our case it's simple - the default case errors out if cppTypeMangle() returns null, and we're only handling this Tfloat80 case there at the moment. But if you're unsure about that > 1 chars rule, sure, leave as-is.

Btw, I've just seen that we don't handle Timaginary80 and Tcomplex80 specially for Android; pinging @joakim-noah.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've just seen that we don't handle Timaginary80 and Tcomplex80 specially for Android

Indeed, that's probably needed too, and then it makes more sense to have a general solution for the default case substitution problem...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess you mean Android/x64. I considered those manglings of complex numbers, but figured this is such a niche platform, I didn't want to deal with it. I had to do real because building LDC itself needs it.

@@ -0,0 +1,23 @@
// Tests that repeated `real` return types are treated as built-in types in C++ mangling (no substitution).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Extending a dmd-testsuite test (e.g., runnable/cppa.d) would be better, as that makes really sure linking C++ and D succeeds, instead of testing an assumption of a correct hardcoded mangle, which already proved not to work too well before (I converted some according tests upstream not too long ago).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But then I cannot test Windows, Linux, and Android on one single dev platform. Lit-tests are better for that.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, but you're only testing an assumption, which may break with newer C++ ABIs, and at the same time exclude OSX and exotic other OS from being tested.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, true. So I'll add it to cppa aswell then...

What to do for real on Windows? It won't match C++ long double, is that a bug or intended?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is real even guaranteed to link to C++ long double? Or must people always use c_long_double for that guarantee?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm good question. I would have assumed real to match long double for Windows/MSVC though, so that's probably a bug.

@JohanEngelen
Copy link
Member Author

Upstream PR: dlang/dmd#9129

@kinke
Copy link
Member

kinke commented Dec 23, 2018

Lgtm, upstream too, thx. I added a fix for MSVC.

@@ -178,7 +178,10 @@ public:
case Tuns64:
case Tint128:
case Tuns128:
version (LDC) {} else
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice fix.
But shouldn't these be IN_LLVM? (LDC is for detecting the host compiler, right?)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Argh yeah, will amend.

Mangle as native Visual C++ long double. DMD has to special-case, as
it's using 80-bit extended precision.
@JohanEngelen
Copy link
Member Author

Upstream fix has been merged. All good?
This may be good reason to prepare a 1.13.1 release...

@kinke
Copy link
Member

kinke commented Dec 25, 2018

Yep, should be all good. - 1.13.1 would probably make sense, given that DMD cannot be built with 1.13.0. I'm on vacation though, not using my dev box, so my possibilities are somewhat limited. In any case, I'd wait a bit with 1.13.1, as there may be more issues popping up (I'd have expected some more issues wrt. shipped MinGW libs to pop up tbh).

@JohanEngelen
Copy link
Member Author

JohanEngelen commented Dec 27, 2018

about 1.13.1: weka's code is also having some runtime problems with 1.13... haven't figured out yet what it is. All is good with LDC 1.13.0 ! (with Weka mod for template instantiation)

@JohanEngelen JohanEngelen changed the title Fix mangling of extern(C++) function with two real arguments. [WIP] Fix mangling of extern(C++) function with two real arguments. Dec 31, 2018
@JohanEngelen
Copy link
Member Author

JohanEngelen commented Dec 31, 2018

Needs updating according to: dlang/dmd#9138 and dlang/dmd#9185

@kinke
Copy link
Member

kinke commented Apr 5, 2019

I guess we can close this as there's probably not that much point in backporting the fix and releasing a v1.13.1 now.

@JohanEngelen
Copy link
Member Author

yeah, let's not spend time on this right now

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants