[fpc-devel]I suggest a new FPC feature

[Pavel V. Ozerski]

Hello,
Althoufh my patches are done, I continue to test them.

First problem:
(today's 1.1 version):

If constructors are declared as stdcall, calling this constructor causes run-time error 216
(that is true also for non-patched compiler, but in non-patched compiler this declaration is possible only
with "stdcall" keyword. After my patch the compiler automatically sets defauts calling convention to stdcall,
therefore I must use my option -Ccpascal or -Ccpopstack to create usable exe-files).
Example:

{$ifdef fpc}
{$mode objfpc}
{$endif}
{$apptype console}
program TEST;
type
 tA=class
  constructor create(x1,x2:longint);stdcall;
 end;
constructor tA.create(x1,x2:longint);stdcall;
 begin
 end;
var
 A:tA;
begin
 A:=tA.Create(1,2);
 A.destroy;
end.

Interesting that unpatched compiler generates different asm output depend on existing "stdcall" keyword.
Here is entry point and tail of constructor tA.create:
1) if "stdcall" keyword presents:

.globl	_$$_TA_$$_CREATE$LONGINT$LONGINT
_$$_TA_$$_CREATE$LONGINT$LONGINT:
	pushl	%ebp
	movl	%esp,%ebp
	subl	$4,%esp
	pushl	%edi
	pushl	%esi
	pushl	%ebx
	call	FPC_NEW_CLASS
................................................................
	testl	%esi,%esi
	popl	%ebx
	popl	%esi
	popl	%edi
	leave
	ret	$16

2) after I recompiled my example without "stdcall" keywords:

.globl	_$$_TA_$$_CREATE$LONGINT$LONGINT
_$$_TA_$$_CREATE$LONGINT$LONGINT:
	pushl	%ebp
	movl	%esp,%ebp
	subl	$4,%esp
	call	FPC_NEW_CLASS
................................................................
	testl	%esi,%esi
	leave
	ret	$16

BTW, I think, second variant is more similar to stdcall... What is its name in FPC now? Then I must make it default instead stdcall.


Second problem:
(today's 1.1 version):
Appliing cdecl calling conventions ("cdecl" keyword) to virtual/override methods causes errors at compiling stage:
(e.g. test2.pp(22,2) Error: Asm: Duplicate label _Any) because all methods with the same name get also the same mangled name.
Using popstack or cppdecl would be a bad solution because Delphi supports "cdecl" here. But, maybe, there are exists a reason,
to automatically interpret cdecl object/class methods as cppdecl (ANSI C does not support classes, therefore this solution seems
to be at least logical).

Third problem:

If calling conventions of a method are defined in class description body, Delphi does not require its repeated definition in method
header, but FPC finds an error if it is missing. This example could be compiled with Delphi but not with FPC:

{$ifdef fpc}
{$mode objfpc}
{$endif}
{$apptype console}
program TEST;
type
 tA=class
  constructor create(x1,x2:longint);
  procedure X(x1,x2:longint);pascal;
 end;
constructor tA.create(x1,x2:longint);
 begin
 end;

procedure tA.X(x1,x2:longint);
 begin
 end;
var
 A:tA;
begin
 A:=tA.Create(1,2);
 A.destroy;
end.


Sincerely, Pavel