On Wed, Jan 18, 2023 at 11:17 AM Andreas Schwab via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
> The -funwind-tables and -fasynchronous-unwind-tables options are relevant
> for the output pass, thus they need to be passed through by the lto
> wrapper.

They are already stored per function, and ...

> gcc/
>         * lto-wrapper.cc (merge_and_complain): Pass through
>         -funwind-tables and -fasynchronous-unwind-tables.
>         (append_compiler_options): Likewise.
> ---
>  gcc/lto-wrapper.cc | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/gcc/lto-wrapper.cc b/gcc/lto-wrapper.cc
> index 11c4d1b38a4..627e8238606 100644
> --- a/gcc/lto-wrapper.cc
> +++ b/gcc/lto-wrapper.cc
> @@ -314,6 +314,8 @@ merge_and_complain (vec<cl_decoded_option> 
> &decoded_options,
>         case OPT_fshow_column:
>         case OPT_fcommon:
>         case OPT_fgnu_tm:
> +       case OPT_funwind_tables:
> +       case OPT_fasynchronous_unwind_tables:

this would pick -fno-unwind-tables if picked up first?

If in global/IPA context the setting of flag_unwind_tables matters
then should we
compute it in lto1 from the set of functions in the partition instead?
 Thus enable
it when the user requested unwind tables from at least one function?

Handling of options in lto-wrapper that are marked Optimization and thus
streamed per function is somewhat dubious.

What exactly are you fixing?

Richard.

>         case OPT_g:
>           /* Do what the old LTO code did - collect exactly one option
>              setting per OPT code, we pick the first we encounter.
> @@ -737,6 +739,8 @@ append_compiler_options (obstack *argv_obstack, 
> vec<cl_decoded_option> opts)
>         case OPT_fopenacc_dim_:
>         case OPT_foffload_abi_:
>         case OPT_fcf_protection_:
> +       case OPT_funwind_tables:
> +       case OPT_fasynchronous_unwind_tables:
>         case OPT_g:
>         case OPT_O:
>         case OPT_Ofast:
> --
> 2.39.1
>
>
> --
> Andreas Schwab, SUSE Labs, sch...@suse.de
> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
> "And now for something completely different."

Reply via email to