Re: [PATCH] Record that -gtoggle is already used in gcc_options.

[Richard Biener <richard.guenther@gmail.com>]

On Thu, Nov 4, 2021 at 1:51 PM Martin Liška <mliska@suse.cz> wrote:
>
> On 11/2/21 17:45, Richard Biener wrote:
> > On Tue, Nov 2, 2021 at 4:11 PM Martin Liška <mliska@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
>