Recent

Author Topic: Note: Call to subroutine "function any;" marked as inline is not inlined  (Read 7615 times)

Ñuño_Martínez

  • Hero Member
  • *****
  • Posts: 1186
    • Burdjia
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?
Are you interested in game programming? Join the Pascal Game Development community!
Also visit the Game Development Portal

Bart

  • Hero Member
  • *****
  • Posts: 5275
    • Bart en Mariska's Webstek
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

  • Hero Member
  • *****
  • Posts: 3197
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

  • Administrator
  • Hero Member
  • *
  • Posts: 9791
  • Debugger - SynEdit - and more
    • wiki
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

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
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?

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  [Select][+][-]
  1. {$mode objfpc}
  2.  
  3. type
  4.   TTest = class
  5.     procedure MethodA; inline;
  6.     procedure MethodB;
  7.     procedure MethodC;
  8.   end;
  9.  
  10. procedure TTest.MethodB;
  11. begin
  12.   MethodA; // "call not inlined"
  13. end;
  14.  
  15. procedure TTest.MethodA;
  16. begin
  17. end;
  18.  
  19. procedure TTest.MethodC;
  20. begin
  21.   MethodA; // no warning
  22. end;
  23.  
  24. begin
  25. end.

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.

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... :'(

Ñuño_Martínez

  • Hero Member
  • *****
  • Posts: 1186
    • Burdjia
But anyway compiler should tell why it didn't inline inlined subroutines so they may be fixed or if it isn't possible to remove the INLINE keyword, shouldn't it?

Anyway I've revised all my INLINE subroutines and I can't see why they cannot be inlined.  For example, why next code can't be inlined?  I don't think it is just because it isn't parsed yet because it is used by several units, and units are parsed before they're used, aren't they?

Code: Pascal  [Select][+][-]
  1. (* Find game state. *)
  2.   FUNCTION TmngGameStateManager.FindState (aName: STRING): TmngGameState;
  3.   VAR
  4.     lNdx: INTEGER;
  5.   BEGIN
  6.     lNdx := SELF.IndexOfState (aName);
  7.     IF lNdx < 0 THEN
  8.       RAISE mngGameStateNotFoundException.CreateFmt (STATE_NOT_FOUND, [aName]);
  9.     RESULT := TmngGameState (fStates[lNdx])
  10.   END;

...
Thanks for the explanation.  I still find it confusing but I have a better view about what happens.
« Last Edit: July 14, 2020, 12:19:46 pm by Ñuño_Martínez »
Are you interested in game programming? Join the Pascal Game Development community!
Also visit the Game Development Portal

Renat.Su

  • Full Member
  • ***
  • Posts: 230
    • Renat.Su
There are always too many same hints in the compiler message list after compilation. And it is unknown how to fix it. I have to search for the necessary hints through an infinite number of such hints

Thaddy

  • Hero Member
  • *****
  • Posts: 14197
  • Probably until I exterminate Putin.
It is quite easy to turn them off, e.g:
Code: Pascal  [Select][+][-]
  1. {$push}{$warn 5024 off}//some code that causes hint note or warning{$pop}
I explained that in the wiki a few years ago.
Note this 5024 is another one, not the inline one. But you can obtain the correct number by compilng with -vwnhel
Using the -v<w,h,n><xxx>- switch you can also do it globally (not recommended)
See the wiki:
https://wiki.freepascal.org/Turn_warnings_and_hints_on_or_off
« Last Edit: July 14, 2020, 12:46:53 pm by Thaddy »
Specialize a type, not a var.

Renat.Su

  • Full Member
  • ***
  • Posts: 230
    • Renat.Su
It is quite easy to turn them off, e.g:
Code: Pascal  [Select][+][-]
  1. {$push}{$warn 5024 off}//some code that causes hint note or warning{$pop}
I explained that in the wiki a few years ago.
It is not worksing:
Code: Pascal  [Select][+][-]
  1. {$WARN 6058 off : Call to subroutine "$1" marked as inline is not inlined}
This does not works too
Code: Pascal  [Select][+][-]
  1. {$push}{$warn 5024 off}//some code that causes hint note or warning{$pop}
This does not works too for the entire project -vm3123 also

Renat.Su

  • Full Member
  • ***
  • Posts: 230
    • Renat.Su
In all other cases, the hiding of hints works. I use it actively

Thaddy

  • Hero Member
  • *****
  • Posts: 14197
  • Probably until I exterminate Putin.
See https://wiki.freepascal.org/Turn_warnings_and_hints_on_or_off as I wrote. It DOES work with notes too... If it doesn't file a bug report about the note

(I just see that my wiki entry is heavily vandalized by a beginner and I will restore the missing parts)
« Last Edit: July 14, 2020, 12:54:46 pm by Thaddy »
Specialize a type, not a var.

Renat.Su

  • Full Member
  • ***
  • Posts: 230
    • Renat.Su
See https://wiki.freepascal.org/Turn_warnings_and_hints_on_or_off as I wrote. It DOES work with notes too... If it doesn't file a bug report about the note
It works only via porject properties form interface (check off the options)

Thaddy

  • Hero Member
  • *****
  • Posts: 14197
  • Probably until I exterminate Putin.
See my last remark: the wiki was cpmplete and correct but is vandalized by nitwits. ( Huntingkashket contribs will be reversed by me )
« Last Edit: July 14, 2020, 01:00:02 pm by Thaddy »
Specialize a type, not a var.

Renat.Su

  • Full Member
  • ***
  • Posts: 230
    • Renat.Su
See my last remark: the wiki was cpmplete and correct but is vandalized by nitwits. ( Huntingkashket contribs will be reversed by me )
Ok. Thanks

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
But anyway compiler should tell why it didn't inline inlined subroutines so they may be fixed or if it isn't possible to remove the INLINE keyword, shouldn't it?

Anyway I've revised all my INLINE subroutines and I can't see why they cannot be inlined.  For example, why next code can't be inlined?  I don't think it is just because it isn't parsed yet because it is used by several units, and units are parsed before they're used, aren't they?

Is the hint triggered when called in a different unit or the same unit? If the same unit, then see my example: if you want FindState to be inlined then any callsite inside the same unit needs to be after FindState.

Other possibility: is STATE_NOT_FOUND global or local to the unit?

 

TinyPortal © 2005-2018