possible fpc bug

[paulvanderlinden]

got the following program:

Code: Pascal  [Select][+][-]

1. program project1;
2.  
3. {$mode objfpc}{$H+}
4.  
5. var ind:integer=0;
6. const vals:array[0..1] of integer=(1052909725,1092805937);
7.  
8. function GetLong:integer;
9. begin
10.   Result := vals[ind];
11.   inc(ind);
12. end;
13.  
14. function GetDouble: double;
15. type TpDoubleRec=packed record v1,v2:integer;end;
16. var V:TpDoubleRec absolute Result;
17. begin
18.   V.v1 := GetLong;
19.   V.v2 := GetLong;
20. end;
21.  
22. var r:double;
23. begin
24.   r := GetDouble;
25.   if round(r*100000)<>61916062257 then
26.     writeln('wrong')
27.   else
28.     writeln('ok');
29. end.
30.  

Compiling on windows as i386-win32:
  without optimizing or with -O3: writes ok to console
Compiling on linux as x86_63-linux:
  without optimizing: writes ok to console
  with -O3: writes wrong to console (and r is widely off, its roughly 2.15320923002915E-317)

Am I doing something wrong here, or is it indeed a bug?

Paul

[Fred vS]

Hello.

I confirm, here on x86_64-linux, with fpc 3.2.2, using -O- and -O1, the result is "ok".

But with -O2, -O3, -O4 the result is "wrong".

[EDIT] Tested with last trunk fpc 3.3.1 and same result as fpc 3.2.2.

[Laksen]

It's a bug yes. It's not handling the absolute reference to the implicit result variable correctly

Edit: And probably easy to fix since the following works:

Code: [Select]

function GetDouble: double;
type TpDoubleRec=packed record v1,v2:integer;end;
     PpDoubleRec = ^TpDoubleRec;
var V:PpDoubleRec;
begin
  v:=@result;
  V^.v1 := GetLong;
  V^.v2 := GetLong;
end;


[jamie]

Works fine in all optimizers 0..4 with fpc 3.0.4

of course that is on Windows 64 bit.

[tetrastes]

It's a bug yes. It's not handling the absolute reference to the implicit result variable correctly

The matter is not in the implicit result.

This code works with -O2/3/4 (fpc 3.2.2 x86_64-linux):

Code: Pascal  [Select][+][-]

1. function GetDouble: double;
2. type TpDoubleRec=packed record v1,v2:integer;end;
3. var
4.     V: TpDoubleRec;
5.     d: double absolute V;
6. begin
7.     V.v1 := GetLong;
8.     V.v2 := GetLong;
9.     Result := d;
10. end;
11.  

But this does not:

Code: Pascal  [Select][+][-]

1. function GetDouble: double;
2. type TpDoubleRec=packed record v1,v2:integer;end;
3. var
4.     d: double;
5.     V: TpDoubleRec absolute d;
6. begin
7.     V.v1 := GetLong;
8.     V.v2 := GetLong;
9.     Result := d;
10. end;
11.  

[Laksen]

The matter is not in the implicit result.

It is. Your example shows the same thing just that d and result are getting coalesced or treated the same way.

The bug is that the handling of the absolute variable should mark whatever value it is pointing at as not regable so the variable will be forced on the stack.

[tetrastes]

The matter is not in the implicit result.

It is. Your example shows the same thing just that d and result are getting coalesced or treated the same way.

My example shows that the problem is with any variable, not only implicit result, as you had written.
And most importantly, it is related to the order in which variables are declared.

[tetrastes]

In fact the problem is related to packed record somehow, because this code

Code: Pascal  [Select][+][-]

1. function GetDouble: double;
2. //type TpDoubleRec=packed record v1,v2:integer;end;
3. type TpDoubleRec=array[0..1] of integer;
4. var
5.     d: double;
6.     V: TpDoubleRec absolute d;
7. begin
8.     V[0] := GetLong;
9.     V[1] := GetLong;
10.     Result := d;
11. end;

and (naturally) this

Code: Pascal  [Select][+][-]

1. function GetDouble: double;
2. //type TpDoubleRec=packed record v1,v2:integer;end;
3. type TpDoubleRec=array[0..1] of integer;
4. var
5.     V: TpDoubleRec absolute Result;
6. begin
7.     V[0] := GetLong;
8.     V[1] := GetLong;
9. end;

work with -O2/3/4.

[paulvanderlinden]

Thanks guys for the confirmation and workarounds.
Filed a bug here: https://gitlab.com/freepascal.org/fpc/source/-/issues/40212

btw, is there any list of isssues of fpc where things go silently wrong (like f.e. this case)?
That way I can proactively try to find those cases in my source instead of bumping into them when manual testing... (unfortunately test-coverage is pretty low)

[MathMan]

@paulvanderlinde

Beside the point about the FPC compiler error, I wonder what you want to achieve and why you implemented it the way you did. One obvious issue with this is, that it will fail on little endian machines. I personally would have implemented a variant record e.g. like (beware, unchecked)

Code: [Select]

type
  record case byte of
    0: f64: double;
    1: U64: UInt64;
    2:
    {$ifdef ENDIAN_LITTLE}
      Hi: UInt32;
      Lo: UInt32;
    {$else}
      Lo: UInt32;
      Hi: UInt32;
    {$endif}
  end;

Cheers,
MathMan

[paulvanderlinden]

well, its part of my WKBReader where I read coordinates from WKB.

In my code I do consider the BigEndian/LittleEndian cases properly but I wanted to make my example as small as possible.

[MathMan]

...

In my code I do consider the BigEndian/LittleEndian cases properly but I wanted to make my example as small as possible.

Thanks for the clarification - actually the Big/Little issue was my main concern.

[parcel]

It's bug in absolute. I made patch for this bug and two issue solved.

https://gitlab.com/freepascal.org/fpc/source/-/issues/40239