Re: [PATCH] PR fortran/9972

[Zack Weinberg <zack at codesourcery dot com>]

David Edelsohn <dje@watson.ibm.com> writes:

> 	This patch is a proposed fix to the current Fortran testsuite
> failure of 980520-1.f.  It was introduced by Honza's change to RTL
> compilation deferal in early March.  The earlier patch tested
> flag_inline_functions, but Fortran does not set that flag, so the compiler
> was acting as if Tree inlining would be performed.
>
> 	This patch tests flag_inline_trees along with
> flag_inline_functions to determine if Tree inlining may be enabled.  I
> needed to move the definition of flag_inline_trees to toplev.c because
> referencing it in other languages pulled in tree-inline.o, which created
> undefined references to other cgraph object files not being linked for
> those languages.

This is not really the right way to fix this.  As previously
discussed, what's wanted is to decouple "is inlining happening?"
from "which inliner is in use?".  The former is an optimization
toggle, properly expressed with a flag_ variable; the latter is a
property of each front end, that should be expressed with a boolean in
the langhooks structure.

>         if (inlinable
>   	  || (DECL_INLINE (decl)
> - 	      && flag_inline_functions
> + 	      && (flag_inline_functions || flag_inline_trees == 0)
>   	      && ((! TREE_PUBLIC (decl) && ! TREE_ADDRESSABLE (decl)
>   		   && ! TREE_SYMBOL_REFERENCED (DECL_ASSEMBLER_NAME (decl))
>   		   && ! flag_keep_inline_functions)

Further, I don't understand this, which seems to be the key component
of the change.  Could you please explain why 
  (flag_inline_functions || flag_inline_trees == 0)
is the proper test?

zw