On 11/2/21 17:45, Richard Biener wrote:
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.
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
processing?
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.
Cheers,
Martin
Richard.
Martin
