Here is output from the 2.4.5 Compiler and the 2.62 compiler. of the following program compiled the same way.

It has always been possible to eliminate runtime checking when incrementing a byte/word in this way (if one wants the byte to roll over).
This is not possible with the 2.6.2 compiler. Is there a reason for this.

Carsten

program test_arm9;
Var
  b:byte;
begin
  b:=byte(succ(b));
end.

Free Pascal Compiler version 2.4.5 [2012/06/19] for arm # [6] b:=byte(succ(b));
ldr r0,.Lj5
ldrb r0,[r0]
add r0,r0,#1
and r0,r0,#255
ldr r1,.Lj5
strb r0,[r1]
.stabn 68,0,7,.Ll3 - main

Free Pascal Compiler version 2.6.2 [2013/07/16] for arm # [6] b:=byte(succ(b));
ldr r0,.Lj5
ldrb r0,[r0]
adds r1,r0,#1
bcc .Lj6
bl FPC_OVERFLOW
.Lj6:
mov r0,r1
add r0,r0,#0
cmp r0,#255
bls .Lj7
bl FPC_RANGEERROR
.Lj7:
and r0,r1,#255
ldr r1,.Lj5
strb r0,[r1]
.stabn 68,0,7,_$TEST_ARM9$_Ll3 - main

At least http://www.freepascal.org/docs-html/ref/refsu5.html states that it should generate a range check error, and so does http://delphi.about.com/od/objectpascalide/l/aa012500a.htm ("Note: If we try to use Succ when at the last element Delphi will generate a run-time exception if the range checking is on.")

This is not possible with the 2.6.2 compiler. Is there a reason for this.

The implementation of succ() may have been internally remapped on top of another primitive which already had support for range checking. I don't think it was a conscious decision, but it does seem correct to me.

Jonas

Range checking was simply missing for Succ/Pred before 2.6.0 and thus it was a bug that needed to be fixed. It happened in context of http://bugs.freepascal.org/view.php?id=16770

If you rely on this behavior you need to disable overflow and rangechecks for these code parts, e.g.:

=== code begin ===

begin
{$push}
{$Q-,R-}
   b := Byte(Succ(b));
{$pop}
end;

=== code end ===

Regards,
Sven

Ehm... Jonas... it was a conscious decision by you. ^^ (see http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revision&revision=15474 )

Regards,
Sven