Re: Plan for removing global state from GCC's internals

["Joseph S. Myers" <joseph at codesourcery dot com>]

For a shared library you need a well-defined namespace for GCC functions / 
variables so it doesn't interfere with users.  Are you going to put 
everything inside a "gcc" namespace or similar?  (You also need to avoid 
host libraries such as libiberty - which have C interfaces - interfering 
with users of the shared library.  If the initial hosts for shared library 
builds are ELF, I suppose you can do that with a version map to hide 
everything not in the "gcc" namespace.)

Some observations specifically on your top-40 globals:

* global_options: where available, using a pointer to a gcc_options 
structure is of course better than using a universe (some attributes could 
be implemented more cleanly if there were per-function gcc_options 
pointers, for example).  Note also the various TARGET_* macros that are 
generated to AND a variable with a mask - really, such macros should gain 
a parameter that is a pointer to a struct gcc_options (and then you'd pass 
&global_options to them if no more specific structure is available).

* For dump_file and associated variables such as dump_flags, I sort of 
think there should be a proper API for code writing to dumps rather than 
directly accessing dump_file all over the compiler.  That should massively 
reduce the number of places needing to access those fields of the 
universe.

* For targetm, make it const (which would move any further enhancements to 
it firmly into the domain of Andrew MacLeod's proposal and out of yours, 
because once it's const it's not global state for a compiler only 
supporting one target at a time).  There are only a few places, for a few 
targets, that write to targetm at runtime; I think it should be possible 
to fix those by e.g. changing some data hooks in targetm into function 
hooks.

* For stderr and stdout, really the compiler should only be using them 
through narrow diagnostic interfaces and not other code using them 
directly.  Put them in global_dc (which would, I suppose, in turn go in 
the universe)?  A shared library user should be able to replace them with 
streams opened with open_memstream, for example, rather than having 
diagnostics go direct to stderr/stdout at all.  Yes, this requires dealing 
with implicit uses through functions such as printf as well as explicit 
references directly in GCC.

* For input_location, you no doubt know we want almost everywhere to use 
the location of some well-defined source-code construct instead of the 
global (the diagnostic functions that implicitly use input_location should 
go away completely, for example).  But changing that is a lot of work so 
things probably do need to start by putting it in the universe as you 
suggest.

* For flag_isoc99 and associated variables defined in c-common.c, move 
them to Variable entries in c.opt (i.e., into global_options).  In 
general, if a variable describes state determined by command-line options, 
moving it into global_options is probably sensible.

* For asm_out_file, see dump_file, stdout and stderr above - there should 
be a well-defined API for writing assembler output and only the 
implementation of that API should refer directly to this global.

* For lang_hooks, see targetm and make it const.  Some hooks are 
deliberately modified in free_lang_data - the answer to that is, I think, 
to stop using those hooks directly except via a wrapper that checks 
whether free_lang_data has been called (one new global) and decides 
whether to call the langhook based on that.

-- 
Joseph S. Myers
joseph@codesourcery.com