Forum > FPC development

Note: Call to subroutine "function any;" marked as inline is not inlined

(1/5) > >>

Ñuño_Martínez:
I've found that any INLINE subroutine isn't inlined anymore, no matter if I use the -Si option or not.

This seems to be a bug, actually I've found bug 37241 that seems similar but it says that it raises an internal error and that it is fixed in 3.2.0 but that's the compiler I'm using and it is not fixed (by the way I found Bug Tracker quite confusing).

Not sure what to do: Is it a feature or a bug? Is it fixed? Is it a new one?

Bart:
AFAIK "inline" does not guarantee that the compiler actually inlines the function.
It merely treats it as a request to inline, if it sees fit.

Bart

winni:
Hi!

Yes, Bart is right: Every inline instruction is only a question to the compiler if it can do.

But when this is not possible a hint is shown like "open array not yet supported"  or "nested procedures not yet supported".

Winni

Martin_fr:
About the bug tracker:

"Product version" is the version in which the reporter found the bug. Or in which it the developper confirmed it. In short: the version with the bug.

There should be a field "Fixed in Version", but mantis has its own issues and it is not visible.
If it was set, it can be seen in the "issue history" at the bottom.  Also, if it is set, its usually set to trunk (e.g. here fpc 3.3.1) or indicate the hope of the developer to get the fix copied to an earlier release.
In this issue it is not set.

The same for FpcTarget or LazTarget fields.

---
Note "copied to an earlier release"
All developers work on "trunk". Therefore all fixes are first made to trunk.
If
- a developer believes the fix should be made available before the next major release (in this case the next major fpc release is 3.4)
- and there is an earlier release (either an already branched major release, like 3.2 was / or a minor release like 3.2.2 will be)
then the developer will initiate the "merge process" for this.
This means if possible the fix will be copied to that earlier release.

The only sure way to find out what happened to the fix, is the revision number.
With that you can find the fix in SVN.
You can download it as patch, and apply yourself.
You can search the "svn fixes" branches, and see if the revision was merged.
You do not know if it maybe will still be merged. For that you have to ask on the mailing list.

Sorry this is still a lot to take in. But that is the development process. (well approximately)

PascalDragon:

--- Quote from: Ñuño_Martínez on July 13, 2020, 09:53:57 pm ---I've found that any INLINE subroutine isn't inlined anymore, no matter if I use the -Si option or not.

This seems to be a bug, actually I've found bug 37241 that seems similar but it says that it raises an internal error and that it is fixed in 3.2.0 but that's the compiler I'm using and it is not fixed (by the way I found Bug Tracker quite confusing).

Not sure what to do: Is it a feature or a bug? Is it fixed? Is it a new one?

--- End quote ---

Before 3.2 the compiler did not report if it did not inline a function that was marked as inline. It simply didn't do it. Now it does report that and more often than not even with a reason. This way one can see what is really inlined and what is not.

One common reason (especially if no other reason was given) is that the function or method body has not yet been parsed (another reason are methods using inherited). Look at the following:


--- Code: Pascal  [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---{$mode objfpc} type  TTest = class    procedure MethodA; inline;    procedure MethodB;    procedure MethodC;  end; procedure TTest.MethodB;begin  MethodA; // "call not inlined"end; procedure TTest.MethodA;beginend; procedure TTest.MethodC;begin  MethodA; // no warningend; beginend.

--- Quote from: Martin_fr on July 13, 2020, 11:37:05 pm ---About the bug tracker:

"Product version" is the version in which the reporter found the bug. Or in which it the developper confirmed it. In short: the version with the bug.

There should be a field "Fixed in Version", but mantis has its own issues and it is not visible.
If it was set, it can be seen in the "issue history" at the bottom.  Also, if it is set, its usually set to trunk (e.g. here fpc 3.3.1) or indicate the hope of the developer to get the fix copied to an earlier release.
In this issue it is not set.

The same for FpcTarget or LazTarget fields.

--- End quote ---

It seems that the bug reporter themselves closed the issue instead of us resolving it with maybe some revision number that originally fixed the issue. Thus this bug report might fly under the radar and we don't merge anything... :'(

Navigation

[0] Message Index

[#] Next page

Go to full version