Recent

Author Topic: possible fpc bug  (Read 1519 times)

paulvanderlinden

  • New Member
  • *
  • Posts: 14
possible fpc bug
« on: March 21, 2023, 03:12:47 pm »
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

  • Hero Member
  • *****
  • Posts: 3158
    • StrumPract is the musicians best friend
Re: possible fpc bug
« Reply #1 on: March 21, 2023, 03:58:54 pm »
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.
« Last Edit: March 21, 2023, 04:06:35 pm by Fred vS »
I use Lazarus 2.2.0 32/64 and FPC 3.2.2 32/64 on Debian 11 64 bit, Windows 10, Windows 7 32/64, Windows XP 32,  FreeBSD 64.
Widgetset: fpGUI, MSEgui, Win32, GTK2, Qt.

https://github.com/fredvs
https://gitlab.com/fredvs
https://codeberg.org/fredvs

Laksen

  • Hero Member
  • *****
  • Posts: 724
    • J-Software
Re: possible fpc bug
« Reply #2 on: March 21, 2023, 04:25:32 pm »
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;
« Last Edit: March 21, 2023, 04:28:33 pm by Laksen »

jamie

  • Hero Member
  • *****
  • Posts: 6090
Re: possible fpc bug
« Reply #3 on: March 21, 2023, 10:24:28 pm »
Works fine in all optimizers 0..4 with fpc 3.0.4

of course that is on Windows 64 bit.
« Last Edit: March 21, 2023, 10:26:22 pm by jamie »
The only true wisdom is knowing you know nothing

tetrastes

  • Sr. Member
  • ****
  • Posts: 473
Re: possible fpc bug
« Reply #4 on: March 21, 2023, 11:20:47 pm »
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

  • Hero Member
  • *****
  • Posts: 724
    • J-Software
Re: possible fpc bug
« Reply #5 on: March 21, 2023, 11:54:07 pm »
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

  • Sr. Member
  • ****
  • Posts: 473
Re: possible fpc bug
« Reply #6 on: March 22, 2023, 12:11:28 am »
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

  • Sr. Member
  • ****
  • Posts: 473
Re: possible fpc bug
« Reply #7 on: March 22, 2023, 12:31:51 am »
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

  • New Member
  • *
  • Posts: 14
Re: possible fpc bug
« Reply #8 on: March 22, 2023, 08:54:13 am »
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

  • Sr. Member
  • ****
  • Posts: 325
Re: possible fpc bug
« Reply #9 on: March 22, 2023, 11:05:41 am »
@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

  • New Member
  • *
  • Posts: 14
Re: possible fpc bug
« Reply #10 on: March 22, 2023, 11:19:48 am »
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

  • Sr. Member
  • ****
  • Posts: 325
Re: possible fpc bug
« Reply #11 on: March 22, 2023, 11:25:35 am »
...

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

  • Full Member
  • ***
  • Posts: 143
Re: possible fpc bug
« Reply #12 on: May 09, 2023, 02:02:09 am »
It's bug in absolute. I made patch for this bug and two issue solved.

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

 

TinyPortal © 2005-2018