Given this example (http://pastebin.com/JQVqF7SV):

==============================
program project1;
{$mode objfpc}{$H+}
uses
  SysUtils;
const
  BIG_A = $AB09CD87EF653412;
  BIG_B = qword($AB09CD87EF653412);
var
  q : qword;
begin
  writeln('BIG_A: $', IntToHex(BIG_A, sizeof(BIG_A) * 2));
  writeln('BIG_B: $', IntToHex(BIG_B, sizeof(BIG_B) * 2));
  q := BIG_A;
  write('q:     $', IntToHex(q, sizeof(q) * 2), '   ');
  if (q = BIG_A) then begin
    writeln('same');
  end else begin
    writeln('different');
  end;
  q := BIG_B;
  write('q:     $', IntToHex(q, sizeof(q) * 2), '   ');
  if (q = BIG_B) then begin
    writeln('same');
  end else begin
    writeln('different');
  end;
end.
==============================

A recent change to fixes_2_4 (I think it was rev 15403) has broken this example. With yesterday's code the code prints out "same" both times (which is correct), but after pulling today's revision it only works if the constant is cast as a qword (it fails in the first example, works in the second). It should work correctly whether I cast the constant or not.

I was going to log a bug on it but mantis isn't letting me, bug_report_page.php keeps just coming up blank for me.

-SG

I'm not sure about that. The reason it doesn't work is because a) $AB09CD87EF653412 is interpreted as an int64 constant (this was already the case before the change) b) int64($AB09CD87EF653412) < 0
c) hence, qwordvar = $AB09CD87EF653412 can never be true.

The code also refuses to compile with range checking enabled (and prints a warning without range checking on).

It's the same situation as this code:

var
  c: cardinal;
begin
  c:=high(cardinal);
  if c=-1 then
    writeln('c = -1')
  else
    writeln('c  -1');
end.

This prints, also with FPC 2.4.0, "c -1".

Jonas

My problem connecting to mantis has somehow resolved itself, so I did log the bug. Apologies for reporting it here as well as there.

http://bugs.freepascal.org/view.php?id=16694

-SG

Jonas wrote

I'm not sure about that. The reason it doesn't work is because a) $AB09CD87EF653412 is interpreted as an int64 constant (this was already the case before the change)

If that's the case, then I can accept that and just cast the constant as a qword. I just reported it because the behavior of the code between yesterday and today changed.

Thanks.

-SG