Incompatibility to Delphi / Kylix regarding operations on unsigned numbers

Original Reporter info from Mantis: theo @theo222

• Reporter name:

Description:

procedure TForm1.Button1Click(Sender: TObject);
var a,b:Byte;
begin
{.$Q+}
a:=91;
b:=84;
Edit1.text:=(intToStr(a + b - 256)); // Delphi: -81, FPC: 4294967215
end;

Delphi/Kylix always returns "-81", no matter whether Overflow checking is on.
FPC returns "4294967215" resp. with {$Q+} "EIntOverflow".

Mantis conversion info:

• Mantis ID: 8321
• Fixed in version: 2.2.0
• Fixed in revision: 6586 (#9a37c041)

added CategoryCompiler label

changed milestone to %Version 2.2.0

Converted from Mantis. Note by Peter Vreman

• Mantis submitter username: Peter
• Mantis submitter real name: Peter Vreman

---

I can't find any consistency in Delphi's handling of unsigned operations. Fixing this bug will break test tw3490. See the small program below with the outputs of FPC and Kylix.

var
 A,A2: byte;
 W : word;
 B,B2: cardinal;
  I : smallint;
begin
 B := $ffffffed;
 B2 := $fffffffd;
 Writeln(B-B2);

 W:=65535;
 A:=20;
 // FPC converts signed operations to DWord, a*w -> Dword type
 // Not sure what delphi does here....
 Writeln(a * w - 256000000);
end.

Kylix:
4294967280
-254689300

FPC unpatched:
4294967280
4040277996

FPC with patch to use int64 calculations for cardinal-cardinal:
-16
-254689300

Converted from Mantis. Note by theo @theo222

• Mantis submitter username: theo @theo222
• Mantis submitter real name: theo

---

Yes, you're probably right.
I've read:
http://www.efg2.com/Lab/Library/Delphi/MathInfo/#FloatingPointNumbers
and
http://www.efg2.com/Lab/Library/UseNet/1998/0712.txt

Still it's hard to find these problems when porting large code from Delphi.

Converted from Mantis. Note by Jonas Maebe @jmaebe

• Mantis submitter username: Jonas @jmaebe
• Mantis submitter real name: Jonas Maebe

---

The problem is that we cannot make it Delphi compatible if we don' know what the rules are.

And even if we can, it's quite possible it will break again when we/you move to 64 bit. E.g.:

{$q+}
var
  b: byte;
  w: word;
  c: cardinal;
begin
  b := 100;
  w := 100;
  c := 100;
  inc(b,-1); // generates overflow error at run time in Delphi
  inc(w,-1); // generates overflow error at run time in Delphi
  inc(c,-1); // does not generate any error at all in Delphi
end.

A big problem with this is: what do we do in FPC on 64 bit platforms? Currently, give an error for inc(c,-1) there, but we do not give one for inc(qword_var,-1). This is Delphi-incompatible, but what can you do when you have nonsensical behaviour like this?

Converted from Mantis. Note by theo @theo222

• Mantis submitter username: theo @theo222
• Mantis submitter real name: theo

---

I've checked your code with K3:

All three generate an EIntOverflow, but only with Optimization off or if you actually use the var e.g. writeln(b,' ',w,' ',c);

With overflow checking off, the results however are "what you would expect"
like: 99 99 99

But I see the problem.
The best thing FPC could do is probably throwing "Incompatibilty Warnings" (if possible) or Runtime errors like it does now.

Converted from Mantis. Note by Peter Vreman

• Mantis submitter username: Peter
• Mantis submitter real name: Peter Vreman

---

I think the best solution for FPC is to add the fix to make cardinal-cardinal return as int64. That gives the most predictive results and is consistent with the behavior of word-word and byte-byte.

From the linked news posts it is only written that it is not seen as a delphi bug. But the rules are not written clearly either.

And as last the remark of "optimization off" makes it clearly a delphi issue, because the optimizer should change behavior of the program.

Converted from Mantis. Note by theo @theo222

• Mantis submitter username: theo @theo222
• Mantis submitter real name: theo

---

I agree about cardinal-cardinal.

But your remark about "optimization off" is not fair.
The sample code from Jonas does not produce any result or anything.
So the Kylix compiler does not generate ANY code for this in {$O+}.
You can see it in the CPU Window.
As soon as these variables are finally "used" for something, for example
writeln(b,w,c); it does generate code.

Converted from Mantis. Note by Jonas Maebe @jmaebe

• Mantis submitter username: Jonas @jmaebe
• Mantis submitter real name: Jonas Maebe

---

This optimization comment is quite interesting. The current behaviour partially stems from bug #6081 (closed). But the first inc() statement in that program indeed doesn't generate an overflow under Delphi only because it's optimized away. If you add a writeln(v), it indeed does generate an overflow under Delphi.

Converted from Mantis. Note by Florian @FPK2

• Mantis submitter username: Florian @FPK2
• Mantis submitter real name: Florian

---

Being holier than the pope one could even say the delphi optimizer is buggy. Statements with side effects shouldn't be optimized away and those inc definitively have a side effect (throwing an exception).

Converted from Mantis. Note by theo @theo222

• Mantis submitter username: theo @theo222
• Mantis submitter real name: theo

---

I really wouldn't like to argue with you, because I have almost no idea about the great work you're doing.
But doesn't this get a bit philosophic now?
I see it like this:
Jonas Code "does" nothing in the end.
So it can safely be optimized away without side effect.
It's as good as no code at all, but no code doesn't use CPU time.
If you want to know what it "would do, if it did something" ;-) for debugging purpose you can always switch to {$O-}

Converted from Mantis. Note by Jonas Maebe @jmaebe

• Mantis submitter username: Jonas @jmaebe
• Mantis submitter real name: Jonas Maebe

---

The point is simply that "throwing an exception" is also doing something :) So Delphi is not only optimizing away an inc-statement, but also a raise-statement.

Converted from Mantis. Note by Florian @FPK2

• Mantis submitter username: Florian @FPK2
• Mantis submitter real name: Florian

---

Well, it's a border and I think the decision to remove the statement is correct. It's like FPC deciding to change the order how parameters are evaluted if it generates better code then.

Converted from Mantis. Note by Peter Vreman

• Mantis submitter username: Peter
• Mantis submitter real name: Peter Vreman

---

Cardinal-cardinal is now calculated using int64.

closed

locked this issue

mentioned in issue #9408 (closed)

marked this issue as related to #12236 (closed)

mentioned in issue #12236 (closed)

marked this issue as related to #24312 (closed)