This is a summary of discussions relative to the merge request created by
Christopher Bazley (chris.bazley) <[email protected]> titled
c-family: Prevent optimize attribute from undoing target attribute
since its creation.
Description: 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.
The full and up to date discussion can be found at
https://forge.sourceware.org/gcc/gcc-TEST/pulls/150
The merge request has been closed without being merged directly on the forge
repository.
On 2026-05-13 09:25:04+00:00, Richard Earnshaw (rearnsha) wrote:
You've added a Kind/Bug label to this, but not referenced a PR.
On 2026-05-13 20:20:58+00:00, Drea Pinski (pinskia) wrote:
@rearnsha wrote in
https://forge.sourceware.org/gcc/gcc-TEST/pulls/150#issuecomment-5881:
> You've added a Kind/Bug label to this, but not referenced a PR.
I think that was my fault. I will remove the kind in a few.
On 2026-05-14 09:15:40+00:00, Christopher Bazley (chris.bazley) wrote:
@pinskia wrote in
https://forge.sourceware.org/gcc/gcc-TEST/pulls/150#issuecomment-5894:
> I think that was my fault. I will remove the kind in a few.
I added the label. Yesterday, I was trying to gather enough information to
write a reproducer and report the problem in Bugzilla but it is difficult.
On 2026-06-01 19:56:48+00:00, Joseph Myers (jsm28) <[email protected]> approved
the changes:
OK.
