https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113719

--- Comment #20 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Alexandre Oliva
<aol...@gcc.gnu.org>:

https://gcc.gnu.org/g:52959e34c8a7a0473784ca044487d05e791286c1

commit r13-8916-g52959e34c8a7a0473784ca044487d05e791286c1
Author: Alexandre Oliva <ol...@adacore.com>
Date:   Tue Jul 16 06:48:36 2024 -0300

    [i386] adjust flag_omit_frame_pointer in a single function [PR113719]

    The first two patches for PR113719 have each regressed
    gcc.dg/ipa/iinline-attr.c on a different target.  The reason for this
    instability is that there are competing flag_omit_frame_pointer
    overriders on x86:

    - ix86_recompute_optlev_based_flags computes and sets a
      -f[no-]omit-frame-pointer default depending on
      USE_IX86_FRAME_POINTER and, in 32-bit mode, optimize_size

    - ix86_option_override_internal enables flag_omit_frame_pointer for
      -momit-leaf-frame-pointer to take effect

    ix86_option_override[_internal] calls
    ix86_recompute_optlev_based_flags before setting
    flag_omit_frame_pointer.  It is called during global process_options.

    But ix86_recompute_optlev_based_flags is also called by
    parse_optimize_options, during attribute processing, and at that
    point, ix86_option_override is not called, so the final overrider for
    global options is not applied to the optimize attributes.  If they
    differ, the testcase fails.

    In order to fix this, we need to process all overriders of this option
    whenever we process any of them.  Since this setting is affected by
    optimization options, it makes sense to compute it in
    parse_optimize_options, rather than in process_options.


    for  gcc/ChangeLog

            PR target/113719
            * config/i386/i386-options.cc (ix86_option_override_internal):
            Move flag_omit_frame_pointer final overrider...
            (ix86_recompute_optlev_based_flags): ... here.

    (cherry picked from commit bf8e80f9d164f8778d86a3dc50e501cf19a9eff1)

Reply via email to