[Bug fortran/32817] MODULE functions are not inlined

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32817
Bug 32817 depends on bug 25708, which changed state.

Bug 25708 Summary: [F95] Module loading is not good at all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25708

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

[Bug fortran/32817] MODULE functions are not inlined

[jv244 at cam dot ac dot uk]

--- Comment #10 from jv244 at cam dot ac dot uk  2010-07-24 17:58 ---
with -fwhole-file being the default this testcase

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32817#c5 

gets properly inlined at -O2. Yeah!

I think this can be closed, but probably one would like to add a testcase to
the testsuite


-- 

jv244 at cam dot ac dot uk changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu dot
   ||org
 Status|SUSPENDED   |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32817

[Bug fortran/32817] MODULE functions are not inlined

[mikael at gcc dot gnu dot org]

--- Comment #8 from mikael at gcc dot gnu dot org  2010-05-10 17:16 ---
(In reply to comment #7)
 With -fwhole-file I now get the same timings either way. I call that fixed.
 
Unless there is one other bug tracking inlining of use-associated functions,
one cannot close this yet. 
The comment #5 case is still not inlined


-- 

mikael at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32817

[Bug fortran/32817] MODULE functions are not inlined

[mikael at gcc dot gnu dot org]

--- Comment #9 from mikael at gcc dot gnu dot org  2010-05-10 18:42 ---
This depends on the double decl problem, which is : 
if a module is both defined and used in the same file, we create new symbols
when we load the module, instead of reusing/sharing them.  

(In reply to comment #8)
 one cannot close this yet. 
 
I'll mark as waiting for pr25708


-- 

mikael at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn||25708
 Status|REOPENED|SUSPENDED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32817

[Bug fortran/32817] MODULE functions are not inlined

[dfranke at gcc dot gnu dot org]

--- Comment #7 from dfranke at gcc dot gnu dot org  2010-05-09 10:02 ---
With -fwhole-file I now get the same timings either way. I call that fixed.


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

OtherBugsDependingO||40011
  nThis||
 Status|NEW |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32817

[Bug fortran/32817] MODULE functions are not inlined

[fxcoudert at gcc dot gnu dot org]

--- Comment #5 from fxcoudert at gcc dot gnu dot org  2009-05-02 16:26 
---
Now, inlining of non-CONTAINED procedures works when -fwhole-file is used (it
will be the default when the remaining bugs are fixed).

However, functions from used modules are still not inlined; a reduced testcase
is:

  module foomod
  contains
integer function bar()
  bar = 1
end function
  end module

  subroutine gee
use foomod
if (bar() == 0) call abort
  end subroutine

In this, the call to bar() should be inlined, but it is not (compile with -O2
-fdump-tree-optimized -fwhole-file and check the .optimized tree dump). The
same code, with a non-module global function, has the call inlined:

  integer function bar()
bar = 1
  end function

  subroutine gee
integer, external :: bar
if (bar() == 0) call abort
  end subroutine


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu dot
   ||org
   Last reconfirmed|2007-07-24 16:03:03 |2009-05-02 16:26:23
   date||
Summary|inline (pure) accessor  |MODULE functions are not
   |functions   |inlined


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32817

[Bug fortran/32817] MODULE functions are not inlined

[fxcoudert at gcc dot gnu dot org]

--- Comment #6 from fxcoudert at gcc dot gnu dot org  2009-05-02 16:42 
---
The cause of that is that module procedure are never entered into the global
symbol list (gfc_gsym_root). I think they should be there, under their mangled
name.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32817