Re: Options initialization rearrangement

[Andrew Haley <aph at redhat dot com>]

On 10/07/2010 04:21 PM, Joseph S. Myers wrote:
> This patch (including changes to the various front ends) makes some
> changes to how options-related initialization is carried out, with a
> view to separating code that acts on a gcc_options structure (to be
> shared with the driver, except for the front-end parts) from code with
> other global effects (generally not to be shared with the driver).
> 
> The general idea is that a gcc_options structure is initialized,
> updated in the course of processing options, then finalized, and other
> compiler state is configured either at an early point without using
> the structure, or after it is finalized.  As I noted in
> <http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02689.html>, "target"
> and "optimize" attributes ought to work using a copy of the structure
> from *before* finalization in order to work reliably.
> 
> This patch makes the first steps in that general direction rather than
> implementing it completely; subsequent patches will build on it.
> 
> * The static initializers for options now go in a separate
>   global_options_init which is copied to global_options in the
>   initialization step, reflecting that there will be more than one
>   gcc_options structure to initialize in future.
> 
> * There are explicit init_options_once, init_options_struct and
>   lang_hooks.init_options_struct steps, each of which has some parts
>   moved out from the previous functions.  Thus various parts of
>   initialization are reordered, but this is not intended to change the
>   behavior of the compiler.
> 
> * The Fortran gfc_init_options hook set flag_short_enums to a
>   target-dependent default.  This was too early to set it, since the
>   target-dependent default may depend on command-line options; the
>   default is set in language-independent code in process_options,
>   which should suffice for all languages, so the front-end setting is
>   removed.  (I think that front-end setting was a relic of when
>   Fortran used its own short-enums flag instead of the
>   language-independent one.)
> 
> * Several variables that are naturally set in the structure
>   initialization hooks are moved into the gcc_options structure.  Some
>   of these have enum types from flags.h.  This means that options.h
>   always has to be included after the enum declarations in flags.h.
>   Most files just include flags.h and get options.h from there; some
>   include options.h (unnecessarily) after flags.h; those that included
>   options.h only were changed to include flags.h instead.  Various
>   parts of flags.h and options.h were disabled for target libraries
>   because including flags.h instead of options.h in target code (via
>   tm.h) caused some problems there.  (I'm not sure what was being used
>   in target code, but probably some TARGET_* macro definitions from
>   options.h.)
> 
> * The setting of options based on the optimization level was moved
>   into a new default_options_optimization function.  This is simply a
>   convenience separation of functions; it hasn't yet been modified to
>   work directly on options structures so asserts that global_options
>   and global_options_set are in use.  (It doesn't in fact use the _set
>   information at all - but if it (and the target_option.optimization
>   hooks) did so, that would provide 90% of a solution to PR 38716
>   regarding how optimize attributes work with explicitly overridden
>   options.  A full solution would require dealing with cases where a
>   -f option is implied by another -f option (which takes precedence
>   over implication by a -O option); that would involve _set storing
>   information about the closeness of an option that implied another
>   option, for the notion of closeness I mentioned in appendix 1 to my
>   original multilibs proposal, rather than just storing a binary
>   explicit/implicit state.)
> 
> * Similarly, what decode_options does after calling option handlers is
>   moved into finish_options.  This also has yet to be converted to use
>   options structures explicitly, or to be separated into parts working
>   on options structures versus those using other state.  Also, there
>   is some initialization after decode_options, including in
>   process_options called from do_compile and in the target option
>   override hook, which again should be split up and moved into the two
>   parts of finish_options.
> 
> * The rearrangements in this patch eliminate most checks on the
>   first_time_p variable that was in decode_options.  It is now in
>   finish_options and only checked for flag_pic/flag_shlib
>   initialization.  This variable serves to distinguish the initial
>   call from calls from "optimize" attributes.  If those attributes
>   worked with the options structure from before finish_options, it
>   would not be a problem for finish_options to be called more than
>   once without needing any checks there on first_time_p.
> 
> Bootstrapped with no regressions on x86_64-unknown-linux-gnu.  OK to
> commit?

OK for Java.

Andrew.