No, the `=` function code is generated as __fastcall, and `&` function call `=`
as __fastcall.
If the `&` is not inlined in function `main` with compiler option `/Ob1` or
`/Ob0`, then all is fine. But when the function `&` is inlined in function
`main`, the code is generated as __stdcall to cal
Win32 default convention for API is __stdcall, could it be related? We might be
missing some declspec in the codegen.
I don't think so.
1. With x64, the call convention is all same.
2. The __fastcall is fast than __cdecl indeed.
3. The lastest compiler from vs 2013 has fixed this bug.
4. This is only happened with vcc.
5. It happened rarely.
Very interesting! This could also be the cause for the mysterious other
problems with VCC. :-)
Yesterday, I am testing nim destructor thing, and find a strange bug.
Look at the code modified from tests/destrcutor/tcustomstrings.nim
type
mystring = object
len, cap: int
data: ptr UncheckedArray[char]
var
allocCount, deallocCount: int
