[Bug rtl-optimization/94440] [8/9/10 Regression] ICE in check_bool_attrs, at recog.c:2168 since r7-5324-gb8cab8a5492e9639

["cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #17 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:a9a0d654006df98dd2c29b907c83571819c49727

commit r10-9218-ga9a0d654006df98dd2c29b907c83571819c49727
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Dec 8 15:44:10 2020 +0100

    i386: Fix up X87_ENABLE_{FLOAT,ARITH} in conditions [PR94440]

    The documentation says
         For a named pattern, the condition may not depend on the data in
         the insn being matched, but only the target-machine-type flags.
    The i386 backend violates that by using flag_excess_precision and
    flag_unsafe_math_optimizations in the conditions too, which is bad
    when optimize attribute or pragmas are used.  The problem is that the
    middle-end caches the enabled conditions for the optabs for a particular
    switchable target, but multiple functions can share the same
    TARGET_OPTION_NODE, but have different TREE_OPTIMIZATION_NODE with
different
    flag_excess_precision or flag_unsafe_math_optimizations, so the enabled
    conditions then match only one of those.

    I think best would be to just have a single options node for both the
    generic and target options, then such problems wouldn't exist, but that
    would be very risky at this point and quite large change.

    So, instead the following patch just shadows flag_excess_precision and
    flag_unsafe_math_optimizations values for uses in the instruction
conditions
    in TargetVariable and during set_cfun artificially creates new
    TARGET_OPTION_NODE if flag_excess_precision and/or
    flag_unsafe_math_optimizations change from what is recorded in their
    TARGET_OPTION_NODE.  The target nodes are hashed, so worst case we can get
4
    times as many target option nodes if one would for each unique target
option
    try all the flag_excess_precision and flag_unsafe_math_optimizations
values.

    2020-12-08  Jakub Jelinek  <jakub@redhat.com>

            PR target/94440
            * config/i386/i386.opt (ix86_excess_precision,
            ix86_unsafe_math_optimizations): New TargetVariables.
            * config/i386/i386.h (X87_ENABLE_ARITH, X87_ENABLE_FLOAT): Use
            ix86_unsafe_math_optimizations instead of
            flag_unsafe_math_optimizations and ix86_excess_precision instead of
            flag_excess_precision.
            * config/i386/i386.c (ix86_excess_precision): Rename to ...
            (ix86_get_excess_precision): ... this.
            (TARGET_C_EXCESS_PRECISION): Define to ix86_get_excess_precision.
            * config/i386/i386-options.c (ix86_valid_target_attribute_tree,
            ix86_option_override_internal): Update
ix86_unsafe_math_optimization
            from flag_unsafe_math_optimizations and ix86_excess_precision
            from flag_excess_precision when constructing target option nodes.
            (ix86_set_current_function): If flag_unsafe_math_optimizations
            or flag_excess_precision is different from the one recorded
            in TARGET_OPTION_NODE, create a new target option node for the
            current function and switch to that.

    (cherry picked from commit e401db7bfd8cf86d3833805a81b1252884eb1c9d)