-
-
Notifications
You must be signed in to change notification settings - Fork 262
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
Conversation
dmd/cppmangle.d
Outdated
if (cptr[1] != 0) | ||
goto default; | ||
c = cptr[0]; | ||
break; |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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...
There was a problem hiding this comment.
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). |
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
Upstream PR: dlang/dmd#9129 |
Lgtm, upstream too, thx. I added a fix for MSVC. |
dmd/cppmanglewin.d
Outdated
@@ -178,7 +178,10 @@ public: | |||
case Tuns64: | |||
case Tint128: | |||
case Tuns128: | |||
version (LDC) {} else |
There was a problem hiding this comment.
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?)
There was a problem hiding this comment.
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.
a54898d
to
31db68a
Compare
Upstream fix has been merged. All good? |
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). |
|
real
arguments.real
arguments.
Needs updating according to: dlang/dmd#9138 and dlang/dmd#9185 |
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. |
yeah, let's not spend time on this right now |
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 checkWINDOWS: 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 forreal
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 likecfloat
).See also: https://forum.dlang.org/post/[email protected]