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.
