To start with, I have very sittle info, so this may not lead anywhere. But then again, I was unable to reproduce it myself. So I would appreciate any hint what I may be looking for...

I discovered this while debugging a PascalScript issue.

The environment:
- A macbook. 64 bit intel (Owned by Mattias)
- FPC 2.7.1 - 32 bit - exact revision unknown - supposedly build without any extra arguments to make

In unit classes is the following procedure

function Point(AX, AY: Integer): TPoint;
begin
   with Result do
   begin
     X := AX;
     Y := AY;
   end;
end;

Being called from PascalScript it did not work.
A copy taken to a new unit and compiled with the very same fpc, and it did.

Stopping in the disassemble view (using asm single stepping) the point in classes had the below asm:

CLASSES_POINT$LONGINT$LONGINT$$TPOINT
0010BAF0 83ec0c sub $0xc,%esp 0010BAF3 890424 mov %eax,(%esp) 0010BAF6 89542404 mov %edx,0x4(%esp) 0010BAFA 8b0424 mov (%esp),%eax 0010BAFD 8b542404 mov 0x4(%esp),%edx 0010BB01 83c40c add $0xc,%esp 0010BB04 c3 ret

I don't have the exact copy of the asm for the case where the function was compiled in a unit outside the RTL, but it used eax,ecx,edx. And eax would be the pointer to the record (result:TPoint). Above the result is at -12(esp)

For now, my question is: What settings could get fpc to generate the above code?

It's the default setting on Darwin/i386 and iPhoneSim/i386, because that's how its ABI prescribes that small records should be returned. Apparently there's a check for cdecl/cppdecl/mwpascal missing in the parameter manager for that platform, although until now nobody noticed.

All those custom calling conventions on i386 are a real pain, especially on platforms where they have absolutely no use or right of existence other than the fact that everyone and their uncle insists on writing inline assembler code in when programming in FPC/Delphi/TP.

Jonas

Ok.

Then my next question.

As indicated, compiling a copy and paste of this code, using the same compiler, it produced asm using eax as pointer to the result.

Is that possible or allowed? If so how?

And if so then how would

   type TPointProc =  function(AX, AY: Integer): TPoint;

work?

If dereferenced any were in code

   SomePointProc(1,1);

how would it know which calling convention (if there are 2 to choose from)

By not compiling it for Darwin/i386, or by using a different definition of TPoint that is no longer 8 bytes. Anyway, I've committed a fix so that darwin/i386 and iphonesim/i386 now behave the same as other platforms as far as the function return location is concerned when not using cdecl/cppdecl/mwpascal calling conventions.

Jonas