[PATCH] Record that -gtoggle is already used in gcc_options.
Thu Nov 4 12:51:03 GMT 2021
On 11/2/21 17:45, Richard Biener wrote:
> On Tue, Nov 2, 2021 at 4:11 PM Martin Liška <firstname.lastname@example.org> 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;
>> debug_info_level = DINFO_LEVEL_NONE;
>> if (!OPTION_SET_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.
That would be very complicated.
> 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
Well, finish_options is always called once we parse options and we want to finalize them.
So that happens from toplev where we create initial global options. Later on, after the pragma
is parsed (where we start with current global options), the finish_options is called.
Problem of -gtoggle is that it does not directly influence an option, but it negates it.
That said, I think my patch with gtoggle_used is a reasonable workaround.
More information about the Gcc-patches