[fpc-pascal] About the bug report #9408...

[mm]

Peter Vreman a écrit :
>> Compelling FPC 2.1.4 to behave like FPC 2.0.4 is not very difficult.
>> In a program where you have "A := B - C;" (A,B,C being Longwords), it
>> is sufficient to write "A := Longword(Longint(B) - Longint(C));" and all
>> is right. The most difficult is to find which lines of code has to be
>> modified. FPC signals most of them ("Possible loss of data ...") but not
>> all. For instance, "if (A and (A-1)) = ..." is silently converted as a
>> 64-bit operation.
>>
>> But the problem is not just an efficiency problem, it is also a 'result'
>> problem. For instance, try this with both FPC 2.0.4 and 2.1.4 :
>>
>>    B := 1111;
>>    C := 1112;
>>    D := 311;
>>    A := (B - C) div D;
>>
>> You will get two different values for A.
>> With 2.0.4, you compute ((B - C) mod 2^32) div D; with 2.1.4, you
>> compute (B - C) div D where (B - C) is a 64-bit signed parameter. These
>> are two different operations.
> 
> We did a lot of experiments regarding this. There is no clear description how to calculate the
> longwords.

The only thing that is clear in all that stuff, this is the situation :
we inherit the mess initiated by Borland in the 80's. If, at that time,
someone at Borland decided to follow some standard (the ADA one, for
instance), today things would certainly be a little less lame.

> The current behavior of 2.1.4 is the best effort we could do that is both the same on 32-bit and
> 64-bit platforms. In 2.0.4 there was a difference between 32-bit and 64-bit platforms and fpc was
> also not always compatible with delphi.

I understand that your work is not easy, there is no good solution.
Either you follow Borland, i.e., you go on with the current mess, or you
try to rationalize things but, in this case, you can no more be fully
compatible with what was previously done.

mm