On Sun, Sep 28, 2014 at 10:28 PM, FX wrote: >> It looks like parse_optimize_options has nothing c-family specific in >> it, so it could be moved to attribs.c. Then you'd use >> build_optimization_node to set DECL_FUNCTION_SPECIFIC_OPTIMIZATION, as >> done in c-common.c:handle_optimize_attribute. > > Yep, I’ve done it that way, it works fine. > > There’s one surprise: a few flags (flag_finite_math_only, flag_signed_zeros, > flag_trapping_math, flag_unsafe_math_optimizations) seem to appear or > disappear when I set specific flags for a function.
I suspect this has something to do with the following set of flags: options.c: false, /* frontend_set_flag_associative_math */ options.c: false, /* frontend_set_flag_cx_limited_range */ options.c: false, /* frontend_set_flag_finite_math_only */ options.c: false, /* frontend_set_flag_errno_math */ options.c: false, /* frontend_set_flag_reciprocal_math */ options.c: false, /* frontend_set_flag_rounding_math */ options.c: false, /* frontend_set_flag_signaling_nans */ options.c: false, /* frontend_set_flag_signed_zeros */ options.c: false, /* frontend_set_flag_trapping_math */ options.c: false, /* frontend_set_flag_unsafe_math_optimizations */ > What I do is this: > > -------------------- > static void > add_ieee_options (tree fndecl) > { > struct cl_optimization cur_opts; > > /* Save current options. */ > cl_optimization_save (&cur_opts, &global_options); > > /* Parse options, and update the vector. */ > /* parse_optimize_options (opts, true);*/ > DECL_FUNCTION_SPECIFIC_OPTIMIZATION (fndecl) > = build_optimization_node (&global_options); > > debug_tree (optimization_current_node); > debug_tree (DECL_FUNCTION_SPECIFIC_OPTIMIZATION (fndecl)); > > /* Restore current options. */ > cl_optimization_restore (&global_options, &cur_opts); > } > -------------------- Looks perfectly reasonable. > So, even if I don’t change anything to the local options (global is: -O3 > -ffast-math), I see some differences between “optimization_current_node” and > "DECL_FUNCTION_SPECIFIC_OPTIMIZATION (fndecl)”: > >> 1,3d0 >> < align_functions (0x10) >> < align_jumps (0x10) >> < align_loops (0x10) >> 26d22 >> < flag_finite_math_only (0x1) >> 71a68 >> > flag_signed_zeros (0x1) >> 78a76 >> > flag_trapping_math (0x1) >> 113d110 >> < flag_unsafe_math_optimizations (0x1) > > > Is that a bug in optimization handling, or am I missing something? The saving/restoring of options includes those flags, so the problem is probably not there. I suspect that parse_optimize_options doesn't handle those frontend_set_flag_* options. That would be a bug, IMHO. The fortran front end sets two of those front-end flags: fortran/options.c: opts->frontend_set_flag_errno_math = true; fortran/options.c: opts->frontend_set_flag_associative_math = true; The effect of these frontend_set_flag_* is that the shared options handling system (opts.c) defers setting those flags to (surprise) the front end. Perhaps parse_optimize_options goes through the shared option handling, and you need to re-setup the frontend_set_flag_* flags manually somehow. Seems backward, though, but GDB should be able to help you out (the flags after parse_optimize_options would be different from the settings in the initial global_options). Unfortunately I can't find if/where there is some explanation for these frontend_set_flag_* options -- how they're supposed to work and who's responsible for setting them. Ciao! Steven