On Thu, Nov 4, 2021 at 1:51 PM Martin Liška <mli...@suse.cz> wrote:
>
> 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.
But we shouldn't start with the current global options but with ones
we saved for
optimize attribute/pragma processing, no?
> 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.
Well, then we could as well unset flag_gtoggle after processing it, no?
Thanks,
Richard.
> Cheers,
> Martin
>
> >
> > Richard.
> >
> >>
> >> Martin
>
