Changing a value in an inline routine

[Okoba]

Hello,

I have a case that I can not explain except it is a bug, but it should not happen at all as it seems an obvious one and I never faced anything like this even though I am using this style of code a lot. So I am unsure if this is a bug or I am missing something?
As you can see Test1Inner must not change the C, but because both are inline it does!

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

1. program project1;
2.  
3.   procedure Test1Inner(V: Integer); inline;
4.   begin
5.     V := 0;
6.   end;
7.  
8.   procedure Test1; inline;
9.   var
10.     V: Integer;
11.   begin
12.     V := 1;
13.     WriteLn('Before: ', V); //1
14.     Test1Inner(V);
15.     WriteLn('After: ', V); //0
16.   end;
17.  
18.   procedure Test2Inner(V: Integer);
19.   begin
20.     V := 0;
21.   end;
22.  
23.   procedure Test2; inline;
24.   var
25.     V: Integer;
26.   begin
27.     V := 1;
28.     WriteLn('Before: ', V); //1
29.     Test2Inner(V);
30.     WriteLn('After: ', V); //1
31.   end;
32.  
33.   procedure Test3Inner(V: Integer); inline;
34.   begin
35.     V := 0;
36.   end;
37.  
38.   procedure Test3;
39.   var
40.     V: Integer;
41.   begin
42.     V := 1;
43.     WriteLn('Before: ', V); //1
44.     Test3Inner(V);
45.     WriteLn('After: ', V); //1
46.   end;
47.  
48. begin
49.   Test1;
50.   Test2;
51.   Test3;
52.   ReadLn;
53. end.

[winni]

Hi!

Here is the error, change it to

 

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

1. procedure Test2Inner(var V: Integer);

The same for procedure Test3Inner

Winni

[Martin_fr]

@winni: He does NOT want to change it.


@Okoba

I would say it's a bug is FPC.
And it is still present in FPC 3.3.1 from earlier this month.

[PascalDragon]

I have a case that I can not explain except it is a bug, but it should not happen at all as it seems an obvious one and I never faced anything like this even though I am using this style of code a lot. So I am unsure if this is a bug or I am missing something?

That is strange... from the assembly code it looks like Test1Inner should work like Test3Inner and in both cases V from the outer procedure should stay 1, but yet it doesn't in the first case... Please report as a bug.

[Okoba]

Exactly. Weird enough I didn't see this before, it does happen only in this case for me as I use this type of code a lot, meaning inline routines change the inner value.
I would appreciate if you could look into it as I feel unsafe even looking at it 
Reported, 39908

[Martin_fr]

That is strange... from the assembly code it looks like Test1Inner should work like Test3Inner and in both cases V from the outer procedure should stay 1, but yet it doesn't in the first case...

TestInner1 looks good, even Test1. But the inlined form of Test1 (in PASCALMAIN)

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

1. # [49] Test1;
2.  

That does indeed overwrite the value

"V1" is at
   movl   $1,-4(%rbp)

But after the call to   fpc_write_text_sint
"V1" from TestInner1
   movl   $0,-4(%rbp)

[PascalDragon]

That is strange... from the assembly code it looks like Test1Inner should work like Test3Inner and in both cases V from the outer procedure should stay 1, but yet it doesn't in the first case...

TestInner1 looks good, even Test1. But the inlined form of Test1 (in PASCALMAIN)

Ah, I didn't notice that Test1 is inlined as well! Yes, there is the difference, though the why is the next question of course... But since Okoba already reported it...

[BobDog]

I get

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

1. Before: 1
2. After: 1
3. Before: 1
4. After: 1
5. Before: 1
6. After: 1
7.  

But if I change to
{$mode objfpc} (or delphi)
I get

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

1. Before: 1
2. After: 0
3. Before: 1
4. After: 1
5. Before: 1
6. After: 1
7.  

(Geany ide, no default mode objfpc).
So mode FPC is OK.
(just an observation)

[Okoba]

I tested with all three fpc, objfpc and delphi modes and problem persists.
What is your version of FPC?

[Zath]

Do you have the {$inline on} set ?

https://www.freepascal.org/docs-html/ref/refsu77.html

[Okoba]

Yes the problem is inlining.

[Okoba]

Today I was struggling with a weird bug and after hours of debugging, checking assembly code and playing with inline, I found out that this bug is again the cause.
For now, I fixed it with a temporary var in the function, but this bug seems more dangerous than it looks.
I wished I had enough knowledge of the compiler to fix this, but for now I hope one of the members can fix this nasty one.

[PascalDragon]

I wished I had enough knowledge of the compiler to fix this, but for now I hope one of the members can fix this nasty one.

To be fair you'd probably need in depth knowledge for this.

[Okoba]

I guessed but this bug frustrated me, as it hides itself and some times in some cases, in a function it happens.