[Bug middle-end/125327] Target option state can be lost when an optimization attribute implicitly updates target options

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Christopher Bazley
<chrbaz01@gcc.gnu.org>:

https://gcc.gnu.org/g:86ab82906baff66d2372b797a7980aea35078584

commit r17-1218-g86ab82906baff66d2372b797a7980aea35078584
Author: Christopher Bazley <chris.bazley@arm.com>
Date:   Wed Apr 29 12:33:05 2026 +0000

    c-family: Prevent optimize attribute from undoing target attribute

    This patch fixes a bug reported as PR c/125327.

    Previously, function attributes such as
    __attribute__ ((target ("vsx"), optimize("O2"))) could
    be applied wrongly because correct processing of the
    optimize attribute relied on at least one of the following to
    be true:

    1. The function had no function-specific target options, or
    2. changing optimization options did not have the side-effect
       of modifying target options, or
    3. the target option modified as a side-effect of changing
       optimization options was not saved in the cl_target_option
       struct.

    Assumptions 2 and 3 are not generally guaranteed to be true.
    The implementation of the handle_optimize_attribute function
    already implicitly acknowledged that by rebuilding the target
    options after parsing optimization options, and replacing the
    current target option node if that rebuilding resulted in
    a fresh target option node. However, any target options
    already associated with the function being modified were not
    applied before parsing optimization options, therefore they
    were lost if that function's target option node was replaced.
    Moreover, the decision about whether to replace any existing
    target option node was flawed because it was based on a
    comparison with a fake node built from ambient global state
    instead of a comparison with the current target node.

    Assumption 3 is true for i386 because the i386 definition of
    munroll-only-small-loops does not have the "Save" tag,
    therefore its value cannot differ from the ambient global state
    and the target node of the function was not replaced.
    The rs6000 and s390 definitions of munroll-only-small-loops
    (which is likewise implicitly enabled at -O2 and above)
    *do* have the "Save" tag but the 'target' attribute is not
    supported on s390, therefore the bug can only be reproduced
    on rs6000.

    For the bug to manifest, the target option node needed to be
    replaced. For rs6000, that could happen if the newly-saved
    value of munroll-only-small-loops differed from the ambient
    global state (which was wrongly used as the baseline for the
    comparison) even if the newly-saved value did not differ from
    the value previously saved in the target option node of the
    function whose 'optimize' attribute was being applied.

    gcc/c-family/ChangeLog:

            * c-attribs.cc (handle_optimize_attribute):
            Save the global target options before modifying
            them. If the function with the optimize attribute
            already has a target option node then restore those
            target options as the global options, so that they
            are used as the basis for any new optimization and
            target options attached to the function.

    gcc/d/ChangeLog:

            * d-attribs.cc (d_handle_optimize_attribute):
            Save the global target options before modifying
            them. If the function with the optimize attribute
            already has a target option node then restore those
            target options as the global options, so that they
            are used as the basis for any new optimization and
            target options attached to the function.

    gcc/testsuite/ChangeLog:

            * gcc.target/powerpc/pr125327.c: New test.