TREE_PUBLIC for module symbols?

[Damian Rouson]

> On Jul 1, 2015, at 3:42 AM, Paul Richard Thomas <paul.richard.thomas@gmail.com> wrote:
> 
> Dear Tobias,
> 
> Following the latest version of my submodule patch, I have managed to
> overcome the difficulty of making private symbols available to
> submodules in a reasonably economical fashion. Of course, the solution
> makes these symbols visible in the module file, albeit in a different
> section to public symbols.

How does this impact the compiler cascade?  If private entities appear in the module file, then won’t that cause other program scopes to be recompiled whenever there are changes to private symbols in the module file change.  My understanding is that preventing unnecessary compiler cascades was one of the primary motivations for submodules. If not preventing them is the cost of an economical solution, then it might be worth redefining economical to include the costs of compiling. :)

> 
> Since private symbols are now visible in the module files, the meaning
> or usefulness of privacy becomes rather moot, as already discussed on
> the list.

In light of what I wrote above, it might be time to consider paths other than storing private symbols in the module file.  However, as you know, I’m a fan of progressive steps.  It would be reasonable to accept otherwise unnecessary compiler cascades as a necessary evil of getting submodules into the compiler expediently, but I hope there will be subsequent consideration of a redesign after the initial submodule support is complete.

> This conundrum is made still worse because module variables
> have to be set TREE_PUBLIC, otherwise they disappear at any level of
> optimization and leave the linker complaining verbosely.

Ouch.  I think most Fortran programmers would rank runtime performance above compile-time performance.  Hmm… I guess it wouldn’t be the first time a new language construct didn’t achieve its intended purpose (preventing cascades), but let’s hope someone can propose a way to get both.

> 
> Consider an example:
> module foo
> 
>  private
> 
>  public bar
> 
>  integer :: a = 1
> 
>  interface
>    module subroutine bar
>    end subroutine
>  end interface
> 
> contains
> end module
> 
> submodule(foo) fooson
> 
> contains
>  module subroutine bar
>    print *, a
>    a = a+1
>  end subroutine
> end submodule
> 
> program test
>  use foo
>  call bar
>  call bar
>  call bar
>  call bar
>  call bar
> end program test
> 
> Unless 'a' is forced to be TREE_PUBLIC the link stage fails at -O1 and
> above. Is there an alternative to TREE_PUBLIC? If not, what are the
> ramifications of making all module entities TREE_PUBLIC?

An explanation for the layperson would be great if you don’t mind.

Damian