View Issue Details

IDProjectCategoryView StatusLast Update
0025797FPC[All Projects] Generalpublic2017-11-28 16:43
ReporterMichlAssigned To 
PrioritynormalSeverityminorReproducibilityalways
Status confirmedResolutionopen 
PlatformAllOSOS Version
Product VersionProduct Build44287 
Target VersionFixed in Version 
Summary0025797: After changing code in a inline function, unit is not recompiled
DescriptionIn a saved project (a new project dont show this behaviour), the unit is not recompiled when changing an inline function, despite that the unit is marked as changed (indicated by *).

Recompile all (Shift+F9) works.
Steps To Reproducenew Project empty Form, with a button and a second unit, save it in a seperate directory (or simple use attached zip):

Unit1/Form:
procedure TForm1.Button1Click(Sender: TObject);
begin
  Caption:=IntToStr(Test(1))
end;

Unit2:
unit Unit2;

{$mode objfpc}{$H+}

interface

function Test(i: Integer): Integer; inline;

implementation

function Test(i: Integer): Integer; inline;
begin
  Result:=i;
end;

end.

First run, Caption shows "1"
Now change function Test to:

function Test(i: Integer): Integer; inline;
begin
  Result:=i*10;
end;

Next run, expected Result is now 10, but Caption shows a "1"
Additional InformationDiscussion at german forum:
http://www.lazarusforum.de/viewtopic.php?f=5&t=7547
TagsNo tags attached.
Fixed in Revision
FPCOldBugId
FPCTarget
Attached Files

Relationships

related to 0032739 new Lazarus Edited generic package code not in executable. 

Activities

Michl

2014-02-28 13:45

reporter  

inlinebug.zip (3,305 bytes)

Juha Manninen

2014-02-28 18:39

reporter   ~0073370

It sounds like a problem in FPC instead of in Lazarus.

Vojtech Cihak

2014-03-08 11:55

reporter   ~0073555

I think it is a Lazarus issue. AFAIK Lazarus don't compile everything from scratch on quick Run (F9) but uses already compiled *.ppu and *.o files to build the executable. Unit2 is recompiled but Unit1 does not really call function "Test" - the function is already inlined in unit1.ppu (or unit1.o). Code of unit1.pas does not change => Lazarus does not recompiles it.

Juha Manninen

2014-03-08 14:19

reporter   ~0073558

Last edited: 2014-03-08 16:56

View 2 revisions

> Code of unit1.pas does not change => Lazarus does not recompiles it.

Technically speaking Lazarus does not compile anything, only FPC does.
FPC checks the need for compilation based on .ppu (or .o) files. That is my understanding anyway.
I still claim that this issue belongs to FPC.

Vojtech Cihak

2014-03-08 17:43

reporter   ~0073562

I am able to reproduce this issue on pure-fpc demo. It is related to smartlinking, i.e. compiler options -CX and -XX are guilty.

How to:
...unpack the zip...
$ fpc -XX InlineTest.pas
$ ./InlineTest
1
....
now change 1=>10 in unit2.pas, SAVE the file and remove unit2.ppu, unit2.o and executable.
Now compile unit2 with -CX:
$ fpc -CX unit2.pas
This generates unit2.ppu+unit2.o again.
Now recompile and run:
$ fpc -XX InlineTest.pas
$ ./InlineTest
1

Output is 1 although there's 10 in unit2.pas. because the old code remains inlined in unit1.ppu and unit1.o files.

So I really think that it is Lazarus issue.

Vojtech Cihak

2014-03-08 17:44

reporter  

Inline.zip (739 bytes)

Juha Manninen

2014-03-08 18:20

reporter   ~0073563

Vojtech, your first and last sentences are contradictory. First:

> I am able to reproduce this issue on pure-fpc demo.

Which IMO proves that this is FPC issue, but then your conclusion is:

> So I really think that it is Lazarus issue.

Can you explain please.

Vojtech Cihak

2014-03-08 18:50

reporter   ~0073564

I mean that fpc only obtains command (from Lazarus) and do the job.
Only Lazarus (Source Editor) knows which files were actually changed.

IMO it is the point of smartlinking. If your Lazarus project consists from 100 units and you change only one, you recompile only changed one and executable is created from existing *.ppu and *.o files. Therefore it is so fast. FPC does not care which unit uses inline function of other unit when you compile with -XX.

Just my opinion ... :)

Bart Broersma

2014-03-08 23:40

reporter   ~0073566

Last edited: 2014-03-08 23:56

View 2 revisions

This bug is independant of -CX or -XX options.
I can reproduce it without them, my current options are:
-MObjFPC -Scghi -Cirot -O1 -g -gl -gh -vewnhi -l -dLCL -dLCLwin32
(Lazarus 1.3 r44198 FPC 2.6.4RC1 i386-win32-win32/win64)

Compiling a pure fpc example with the same options does not show the bug.

Juha Manninen

2014-03-09 12:05

reporter   ~0073569

> Compiling a pure fpc example with the same options does not show the bug.

What could cause it then? Lazarus IDE only saves all source files and calls FPC with given options. There is no extra information passed from editor to FPC about changed files. FPC uses timestamps of source and .ppu files to decide what must be compiled.
How could Lazarus give wrong info when it does not give any info?

I have no time to investigate this further, sorry.

ocean

2014-03-09 16:15

reporter   ~0073572

It's compiler bug, also present in 2.7.1

>Compiling a pure fpc example with the same options does not show the bug.

Yes it does (atleast here)

Jonas Maebe

2014-03-12 23:02

manager   ~0073653

Fixing this right now leads to the same issue described in Peter's comment in 0007370 (endless recompilations, compiler crashes). It requires improvements to the unit loading infrastructures first.

Vojtech Cihak

2014-03-13 09:47

reporter   ~0073663

Last edited: 2014-03-13 09:53

View 2 revisions

It seems I was wrong with my opinion that it's a Lazarus issue. Recompilations works differently than I thought. Sorry for confusion.

Note: I believed that only possible solution is that Lazarus (Source Editor) will detect changes in inline methods and scan all units where these methods are used and mark them * as changed too.

Marco van de Voort

2014-03-13 12:57

manager   ~0073666

Point is that Delphi can. There are real life examples of such trouble, e.g. in Indy.

http://forum.lazarus.freepascal.org/index.php/topic,23528.msg140755.html#msg140755

Jonas Maebe

2014-03-13 13:14

manager   ~0073668

I know, there is even already an open bug report about that: 0024121

But that is about problems that occur already even today with our extremely limited automatic recompilation related to inline functions. As mentioned before, fixing the issue reported here without fixing the unit reloading would only serve to make things many times worse.

Sven Barth

2014-03-17 14:03

manager   ~0073776

@Vojtech: your solution would not help, because marking units as changed is only inside the IDE. The compiler does not know about anything the IDE does. So the only workaround possible would be to have the IDE pass "-B" to the compiler if it detects a changed inline function... don't know how feasible this would be for the Lazarus devs.

Regards,
Sven

Issue History

Date Modified Username Field Change
2014-02-28 13:45 Michl New Issue
2014-02-28 13:45 Michl File Added: inlinebug.zip
2014-02-28 18:10 Bart Broersma LazTarget => -
2014-02-28 18:10 Bart Broersma Status new => confirmed
2014-02-28 18:39 Juha Manninen Note Added: 0073370
2014-03-08 11:55 Vojtech Cihak Note Added: 0073555
2014-03-08 14:19 Juha Manninen Note Added: 0073558
2014-03-08 16:56 Juha Manninen Note Edited: 0073558 View Revisions
2014-03-08 17:43 Vojtech Cihak Note Added: 0073562
2014-03-08 17:44 Vojtech Cihak File Added: Inline.zip
2014-03-08 18:20 Juha Manninen Note Added: 0073563
2014-03-08 18:50 Vojtech Cihak Note Added: 0073564
2014-03-08 23:40 Bart Broersma Note Added: 0073566
2014-03-08 23:56 Bart Broersma Note Edited: 0073566 View Revisions
2014-03-09 12:05 Juha Manninen Note Added: 0073569
2014-03-09 12:11 Maxim Ganetsky Summary After changing code in a inline function, unit is not new compiled => After changing code in a inline function, unit is not recompiled
2014-03-09 16:15 ocean Note Added: 0073572
2014-03-09 19:50 Maxim Ganetsky Project Lazarus => FPC
2014-03-09 19:50 Maxim Ganetsky Category IDE => General
2014-03-12 23:02 Jonas Maebe Note Added: 0073653
2014-03-13 09:47 Vojtech Cihak Note Added: 0073663
2014-03-13 09:53 Vojtech Cihak Note Edited: 0073663 View Revisions
2014-03-13 12:57 Marco van de Voort Note Added: 0073666
2014-03-13 13:14 Jonas Maebe Note Added: 0073668
2014-03-17 14:03 Sven Barth Note Added: 0073776
2017-11-28 16:43 Juha Manninen Relationship added related to 0032739