Remove IN_GCC code for xopCmp/xopEquals in compiler and library #465
Conversation
|
As per testsuite, there are cases where this would still be broken. Probably reversing args for |
ibuclaw
force-pushed
the
rm-xopcmp-bug
branch
from
495ced0
to
7de7a0f
Compare
|
Testing this PR: dlang/druntime#1417 |
| * using the C calling convention, for which the arguments are never | ||
| * reversed (contrary to `extern (D)`). | ||
| */ | ||
| extern (C) bool function(in void*, in void*) xopEquals; |
There was a problem hiding this comment.
xopEquals is now in the global namespace. I wonder whether we should prefix all (new) extern(C) druntime functions with something?
There was a problem hiding this comment.
I don't think the frontend cares about that. As it makes the call through a function pointer, so this only changes ABI of how parameters are expected to be passed.
I didn't check the code in clone.d, but when I spoke to Daniel about it, I recall him saying that it's just an abi hack. The compiler sees xopCmp as a C function internally, but reverses the arguments as its really calling a D method.
This reversing of arguments never worked for gdc.
...
However I should check something about this, as it appears that the test for xopCmp parameter order was removed or no longer uses the generated xopCmp call.
There was a problem hiding this comment.
Oh, you're right, I totally forgot that this is just a pointer to a generated function (which then obviously has a unique name) 👍
Does the frontend emit these xopCmp functions as extern(C) or extern(D)?
There was a problem hiding this comment.
That is just what I've pushed a test for. The __xopCmp function is marked as LINKd at least.
There was a problem hiding this comment.
Although, now I think about it, it doesn't really matter for us as LINKd and LINKc are the same...
ibuclaw
force-pushed
the
rm-xopcmp-bug
branch
from
7de7a0f
to
1fc3411
Compare
ibuclaw
force-pushed
the
rm-xopcmp-bug
branch
from
1fc3411
to
e648a90
Compare
@yebblies - Just doing this out of curiosity...