Who can explain this ?

[J-G]

A simple arithmetic calculation is returning a peculiar result.

Given :-

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

1. var
2.   Sh_X,Sh_Y : SmallInt;
3.   m,n,o,p   : Single;
4.   q,r       : SmallInt;
5. begin
6.   m := Tri_Data.ExCirc.X_Off;
7.   n := Tri_Data.InCirc.X_Off;
8.   o := Tri_Data.ExCirc.Y_Off;
9.   p := Tri_Data.InCirc.Y_Off;
10.  
11.   q := trunc(m-n);
12.   r := trunc(o-p);
13.  
14.   Sh_X := trunc(Tri_Data.ExCirc.X_Off - Tri_Data.InCirc.X_Off);
15.   Sh_Y := trunc(Tri_Data.ExCirc.Y_Off - Tri_Data.InCirc.Y_Off);
16. end;
17.  

Sh_Y returns a number which makes no sense.

m = 200,  n = 300,   o = -150 and p = -100

Correctly q returns  -100 and r returns -50

Sh_X returns -100 (as expected)  but Sh_Y returns  4978  ????????

Obviously this is a fragment of code but all the salient infomation is there, I've simply added the m,n,o,p,q & r  to enable a test  -  the last two lines are the real code with the X_Off & Y_Off declared as SmallInt;

[Paolo]

But what is the type of x_off and y_off ?

[MathMan]

Just remembering the last instance of 'unexplainable' results ... 

How did you verify the value of Sh_Y - inserted a writeln, or via debugger?

[marcov]

Using trunc on integers is a bit weird ?

[J-G]

Just remembering the last instance of 'unexplainable' results ... 

How did you verify the value of Sh_Y - inserted a writeln, or via debugger?

 Via Debugger

[J-G]

Using trunc on integers is a bit weird ?

I agree - but I have found (in the past) that when there is any calculation between two variables that casts to an integer the compiler spits it out  - - - - -  I've just re-compiled without the trunc  -  no compiler error but the result for Sh_Y is still 4978  ????

[J-G]

But what is the type of x_off and y_off ?

as stated  - SmallInt

[Martin_fr]

And that is either one of, or both of (iirc still gdb)

FPC 3.0.0 - Lazarus 1.6 &
FPC 3.2.2  - Lazarus 2.2.0

Well, gdb should get it right, but better double check.
Especially if you compiled with -O1 (or worse O2?)

IIRC older compilers would (with O1) get debug info wrong, so value would only show after one extra single step (the next line would not yet have the value, in rare cases). That was an issue in some older FPC, not sure how much older.

In anycase, you likely debugged that because some other error came from it. So something would have to be wrong.


The problem is you can have any amount of other issues. Your sample does not give that error. So something that is not in your sample affects it. Even if you are sure it couldn't possible.
- dangling pointer or out of range access, overwriting memory
- compiler issue (try both of your setups, and compile with -O-)
- ...

[J-G]

And that is either one of, or both of (iirc still gdb)

FPC 3.0.0 - Lazarus 1.6 &
FPC 3.2.2  - Lazarus 2.2.0

Well, gdb should get it right, but better double check.
Especially if you compiled with -O1 (or worse O2?)

IIRC older compilers would (with O1) get debug info wrong, so value would only show after one extra single step (the next line would not yet have the value, in rare cases). That was an issue in some older FPC, not sure how much older.

In anycase, you likely debugged that because some other error came from it. So something would have to be wrong.


The problem is you can have any amount of other issues. Your sample does not give that error. So something that is not in your sample affects it. Even if you are sure it couldn't possible.
- dangling pointer or out of range access, overwriting memory
- compiler issue (try both of your setups, and compile with -O-)
- ...

Re-compiling with -O-  (rather than -01)  fixed the error !!   

I have no idea what could create such an issue but I would appreciate some explanation as to why I should - or should not - use optimization?  I cannot recall ever changing that setting.

If it is at all relevant I can confirm that I'm using Laz 2.2.0.

I'm not debugging to correct errors, I'm mearly 'stepping through' to confirm that particular parts of the code ARE being accessed and the figures returned are as expected.

[Martin_fr]

Re-compiling with -O-  (rather than -01)  fixed the error !!   

then it might be the "peephole optimizer" (you can disable that by option or directive).

I have no idea what could create such an issue but I would appreciate some explanation as to why I should - or should not - use optimization?  I cannot recall ever changing that setting.

If it is at all relevant I can confirm that I'm using Laz 2.2.0.

This is more about the FPC version. But even 3.2.2 has some issues with that.

There are 2 general areas:

1) not affecting your code, just what the debugger displays.
Normally if a variable is computed, that happens in a register, which is then stored to mem. If the next line of code uses the same value then that may write code like
- store res to mem
- read mem to res (for next line)
the 2nd obviously is not needed (if it is the same reg) => but when fpc optimized that it would mix up line numbers for the debugger (not sure that may be fixed in 3.2.2). So the debugger would not see the value having been stored to mem, and show the old mem content. However your program would run correctly.

2) Actual code generation bugs. Unfortunately there are one or two.
IIRC under some condition, if a value (as in the above) is still in a register (and a copy is hold there, while other lines are executed), the compiler would forget, and use the register incorrectly => so the generated exe is broken.

The latter, that 2nd happens really rare. But it can happen.

- As far as I know they are fixed in 3.2.3
- there is a known issue with inlining going wrong, and that still happens in 3.3.1 (happens when inlined code contains other inlined code, and a couple of other conditions are true at the same time , search the bug tracker for inline)

For Windows there are builds of 4.6 and 4.8 with 3.2.4-branch (same as 3.2.3 for all practical purposes)
https://sourceforge.net/projects/lazarus-snapshots/files/
It may be possible to point an older Lazarus to use that newer compiler....

[J-G]

Thanks for your time and patience in providing feedback @Martin_Fr  -  at least I am now a little more aware as to what is going on when in 'Debug' mode.

I'm sure you will appreciate that without the deep knowledge that you (and many others, I'm sure) possess, it was quite disconcerting to come across this peculiarity. I've never before seen such and I've been using Lazarus (on and off) for many years.

I may well have never seen the issue if I'd done just a little more coding, I looked at Sh_Y using the [hover over the variable] facility when the dubugger had moved to the next line which happened to be the end of the proc. so, as you suggest, it's likely that it hadn't moved on.

It seems that I am unlikely to see any adverse effects by having no optimization - nothing I code has any need for speed - so I'll leave well alone (retaining the -O- setting).

In a previous post you made reference to 'gdb' which I believe is an older debugger, I am currently using Dwarf2 (-gw2)  -  whether that has any significance, I know not !

[J-G]

Using trunc on integers is a bit weird ?

Just a follow up @marcov - to confirm that I am not as daft as you might now imagine.

The fragment of code that I posted was just that - a fragment;  I've now progressed and I do indeed need trunc because there has to be a multiplcation of the result due to 'scaling'. I'm also not interested in the 'sign' only the magnitude - hence the ABS.

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

1.   Sh_X := trunc(ABS(Tri_Data.ExCirc.X_Off - Tri_Data.InCirc.X_Off)*prScale);
2.  

It may well help anyone interested to get a better understanding of what I need to calculate if they view the attached drawing - the Sh_X & Sh_Y are the distances between the Red & Blue [Dots].