specifying the data type

[tetrastes]

But I specified the data usage type, and in the case of s := Single(n)—no conversion should occur!

It seems that you want s := PSingle(@n)^ ?

There is such thing as absolute also.

[jamie]

Strange, when i do it the results is correct eitherway, i dont need to use pointers

Asm code is the same in both and results correct.

Fp3.2.2 laz 64 bit windows

[tetrastes]

Strange, when i do it the results is correct eitherway, i dont need to use pointers

Asm code is the same in both and results correct.

Fp3.2.2 laz 64 bit windows

This is in $mode delphi or tp (in trunk is only for tp), but in $mode objfpc or fpc or iso the results are different.

[Thaddy]

@tetrastes

Now I am confused: the mode should not matter in this case: it is not object pascal, but clean pascal. Tests here, but it is Friday, show me there is no difference. My first answer works alike in both Delphi and ObjPas modes: there is no need to specify a mode, so TP also works as does the default FPC mode.

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

1. // add or remove dots.
2. // all dots means fpc mode.
3. {.$mode delphi}
4. {$mode TP}
5. {.$mode objfpc}
6. var
7.   v: single = pi;
8. begin
9.   v := Single(PCardinal(@v)^ xor $80000000); // performs the flip
10.   writeln(v); // different value
11. end.

BTW the release does not matter, at least since fpc 2.6.x
[IMPORTANT EDIT]
I can reproduce the issue with the above code on trunk. That indicates a bug. Probably even a regression.

[tetrastes]

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

1. // add or remove dots.
2. // all dots means fpc mode.
3. {.$mode delphi}
4. {$mode TP}
5. {.$mode objfpc}
6. var
7.   v: single = pi;

This is not compiled in TP mode.

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

1.   var x: single;
2.       n: longint;
3.  
4. begin
5.     n := 123;
6.     x := n;
7.     WriteLn(x);
8.     x := single(n);
9.     WriteLn(x);
10.     x := Psingle(@n)^;
11.     WriteLn(x);
12. end.

Outputs in stable and trunk FPC, OBJFPC, ISO and in trunk DELPHI modes:
 1.230000000e+02
 1.230000000e+02
 1.723597111e-43

Outputs in stable DELPHI and TP and in trunk TP modes:
 1.230000000e+02
 1.723597111e-43
 1.723597111e-43

[Thaddy]

Yes, I have seen that. Now we have to search for the explanation: it should not matter. Later today I can do some replays on Linux.
The code is correct (as long as all of you agree that there is no expected error) so where is the regression, and is it platform?

[LeP]

In (stable) DELPHI mode there is an know issue (that is for double ... but surely is also with single): https://gitlab.com/freepascal.org/fpc/source/-/work_items/35886