Hello FPC-Pascal,

Can anybody explain me if this code is expected to fail with a SIGFPE in 64 bits windows 2.2.4 fpc:

procedure test;
var
  i6: int64;
  qw: QWord;
  r: int64;
begin
  i6:=40;
  qw:=40;
  r:=(integer(-1)*i6) div qw;
end;

Replacing "qw" with an int64 runs fine.

Hi,

I compiled this with fpc -al .. under linux 64.
The difference is, "r := <integer> div <qword>" results in an "divq" instruction wich is for unsigned integer division only. "r := <integer> div <int64>" results in "idivq" which is for signed integer division.
On execution this results in an error (i've got divbyzero on amd64) for the first one, which is a result of the signed/unsigned integer conversion and division mix.

Short: Use int64 types for the signed division for quotient and divisor

Hello FPC-Pascal,

Friday, October 2, 2009, 1:38:30 AM, you wrote:

MK> I compiled this with fpc -al .. under linux 64. MK> The difference is, "r := <integer> div <qword>" results in an "divq" MK> instruction wich is for unsigned integer division only. "r := MK> <integer> div <int64>" results in "idivq" which is for signed integer MK> division.
MK> On execution this results in an error (i've got divbyzero on amd64) MK> for the first one, which is a result of the signed/unsigned integer MK> conversion and division mix.

MK> Short: Use int64 types for the signed division for quotient and divisor

That's exactly my supposition, the problem raises as the quotient should never be negative, but due unexpected flow, it takes a -1 value instead zero (already fixed) but no problem in 32 bits using integer and DWORD instead int64 and QWORD.

In the other hand the question is if that pascal code should work or raise an error in 64 bits because I think that this code:

a := NativeInteger div NativeUnsignedInteger;

should have the same behaviour in 32 and 64 bits, so I do not know if I must fill a bug report or not :-?

Thank you for your help.

Fill a bug report, this should clarify if its expected or not. On my opinion, this is a problem and at least a compile time hint about possible Problems would be nice.

Regards,
Matthias

It is not possible to have the same behaviour in 32 and 64 bits until the compiler supports 128 bit arithmetic. The compiler can convert "longint div cardinal" to "int64 div int64", but in case of "int64 div qword" it must either convert the int64 to qword, or the qword to int64. Range checking should catch such errors.

Jonas