On Tue, Nov 2, 2021 at 4:11 PM Martin Liška <mli...@suse.cz> wrote:
>
> On 11/2/21 15:33, Richard Biener wrote:
> > I think -gtoggle matches a Defered option and thus should be processed
> > in handle_common_deferred_options.
>
> Well, that's quite problematic as I handle_common_deferred_options is called
> after decode_options (that calls finish_options).
>
> Note there's direct dependency at very end of finish_options in between
> -gtoggle
> and debug_nonbind_markers_p:
>
>
> if (flag_gtoggle)
> {
> if (debug_info_level == DINFO_LEVEL_NONE)
> {
> debug_info_level = DINFO_LEVEL_NORMAL;
>
> if (write_symbols == NO_DEBUG)
> write_symbols = PREFERRED_DEBUGGING_TYPE;
> }
> else
> debug_info_level = DINFO_LEVEL_NONE;
> }
>
> if (!OPTION_SET_P (debug_nonbind_markers_p))
> debug_nonbind_markers_p
> = (optimize
> && debug_info_level >= DINFO_LEVEL_NORMAL
> && dwarf_debuginfo_p ()
> && !(flag_selective_scheduling || flag_selective_scheduling2));
>
> I don't see who you mean the possible fix?
So at first I thought we might have a place that post-processes
'decoded_options' so we could reflect -gtoggle on those but
out-of-order (removing/adding -g). But that's going to be mightly
complicated as well.
I wonder what the original issue is you fix? You say we ap;ly
it for a second time but we should apply it onto the same
state as previously since we restore that for optimize attribute
processing?
Richard.
>
> Martin
