Re: Confusion in setting default options for non-C/C++ languages

[Richard Guenther <rguenther at suse dot de>]

On Sun, 30 Jan 2011, Ian Lance Taylor wrote:

> Currently toplev_main calls
>   init_options_once
>   init_options_struct
>   lang_hooks.init_options_struct
> which all make sense.  It then calls
>   decode_options
> which calls
>   default_options_optimization
> which sets various options based on the optimization level.
> 
> That is fine provided all languages agree on which options are
> optimization-dependent and which are not.  Unfortunately, they do not
> agree.  For example, both Fortran and Go do
>   opts->x_flag_errno_math = 0;
> in the init_options_struct language hook.  That is a useless step now,
> as that is overridden by default_options_optimization, which sets either
> -ffast-math or -fno-fast-math based on whether -Ofast is used, and
> -fno-fast-math implies -ferrno-math.  Similarly, Java does
>   opts->x_flag_trapping_math = 0;
> and that too is now ineffective.
> 
> I think that the call to lang_hooks.init_option_struct must be moved
> after the call to default_options_optimization, one way or another.

Hmm.  It indeed looks like if init_options_struct should be called
after default_options_optimization.  Joseph, can we somehow disentangle
this by marking an option already "default-initialized" now?

Ideally we'd have a Fortran testcase that verifies the default settings.

Richard.