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

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

[marxin at gcc dot gnu.org]

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

            Bug ID: 94440
           Summary: [8/9/10 Regression] ICE in check_bool_attrs, at
                    recog.c:2168 since r7-5324-gb8cab8a5492e9639
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---
              Host: x86_64-linux-gnu
            Target: x86_64-linux-gnu

Since the revision I see:

$ cat vect.i
int b;
double c, d;
void fn1() {
  int i;
  for (i = 0; i < b; i++)
    c += i;
}
int __attribute__((optimize(1))) main() {
  double a[0];
  int i;
  for (i = 0; i < 9; i++)
    d += a[i];
}

$ gcc -mfpmath=sse,387 -fexcess-precision=standard -Ofast -fno-graphite
--param=scev-max-expr-size=0 -m32 vect.i -Werror
during RTL pass: reload
vect.i: In function ‘main’:
vect.i:13:1: internal compiler error: in check_bool_attrs, at recog.c:2168
   13 | }
      | ^
0x6d9c02 check_bool_attrs(rtx_insn*)
        /home/marxin/Programming/gcc/gcc/recog.c:2168
0xc86751 lra_update_insn_recog_data(rtx_insn*)
        /home/marxin/Programming/gcc/gcc/lra.c:1257
0xca21e1 process_insn_for_elimination
        /home/marxin/Programming/gcc/gcc/lra-eliminations.c:1304
0xca21e1 lra_eliminate(bool, bool)
        /home/marxin/Programming/gcc/gcc/lra-eliminations.c:1372
0xc88aa5 lra(_IO_FILE*)
        /home/marxin/Programming/gcc/gcc/lra.c:2572
0xc403f1 do_reload
        /home/marxin/Programming/gcc/gcc/ira.c:5523
0xc403f1 execute
        /home/marxin/Programming/gcc/gcc/ira.c:5709
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

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

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
                 CC|                            |ubizjak at gmail dot com
   Last reconfirmed|                            |2020-04-01

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

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2
   Target Milestone|---                         |8.5

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

[ubizjak at gmail dot com]

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

--- Comment #1 from Uroš Bizjak <ubizjak at gmail dot com> ---
Are you sure the bisection is correct?

Fairly current gcc-8 and gcc-9 branches work OK for me, but bisection points to
gcc-7 commit.

Also, I don't see anything wrong with the failing pattern:

#2  0x00000000006ac8f1 in check_bool_attrs (insn=insn@entry=0x7fffea817980) at
/home/uros/git/gcc/gcc/recog.c:1614
1614          gcc_unreachable ();
(gdb) p debug_rtx (insn)
(insn 10 9 11 3 (set (reg:DF 83 [ d_lsm.12 ])
        (plus:DF (reg:DF 83 [ d_lsm.12 ])
            (mem:DF (plus:DI (mult:DI (reg:DI 87 [ i ])
                        (const_int 8 [0x8]))
                    (reg/f:DI 7 sp)) [2 a S8 A64]))) "pr94440.c":12:7 904
{*fop_df_comm}
     (expr_list:REG_DEAD (reg:DI 87 [ i ])
        (nil)))
$1 = void

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

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I need -mfpmath=sse,387 -fexcess-precision=standard -Ofast -msse2
--param=scev-max-expr-size=0 -m32 (-Werror not needed, but -msse2 required) to
reproduce.
The function suggests that the "enabled" attribute on the pattern in question
(*fop_df_comm) violates the documented rules:
"All these attributes should use @code{(const_int 1)} to allow an alternative
or @code{(const_int 0)} to disallow it.  The attributes must be a static
property of the subtarget; they cannot for example depend on the
current operands, on the current optimization level, on the location
of the insn within the body of a loop, on whether register allocation
has finished, or on the current compiler pass."
Seems like the target is the same for both functions - in particular
this_target_recog is the same between f1 and main - default_target_recog in
both cases (the two functions don't have different target attribute).

So, either we need to consider also -ffast-math options to be part of target
and force different this_target_recog if it changes between functions, or the
i386 backend can't use enabled attribute for the fast-math dependent checks.

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
BTW, given that -fexcess-precision= option is marked Optimization, I'd say this
has been a problem even before that commit and one could construct a testcase
where it triggers.
Like one function with __attribute__((optimize ("excess-precision=standard")))
and another one with __attribute__((optimize ("excess-precision=fast"))).
Though, target-globals.[ch] seems to have some (limited?) support also for
optimization_current_node, but it probably isn't invoked on changes to just
optimize attribute and no target attributes changes and not sure if it deals
correctly with target and optimize attribute changes etc.  What a mess.

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

[ubizjak at gmail dot com]

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

--- Comment #4 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Jakub Jelinek from comment #2)
> So, either we need to consider also -ffast-math options to be part of target
> and force different this_target_recog if it changes between functions, or
> the i386 backend can't use enabled attribute for the fast-math dependent
> checks.

By reverting the referred change, we risk PR78738. Considering that -ffast-math
flags are not current optimization level flags, I'd vote for handling these
flags.

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

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=92860

--- Comment #5 from Martin Liška <marxin at gcc dot gnu.org> ---
We do have quite some known issues in PR92860 where a target optimization
influences optimization options (and vice versa). I tried to fix some of them
but yes, it's really a mess and non-trivial.

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

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Guess we should defer for GCC11 then, and figure out a way what
OPTIMIZATION_NODE flags could be relevant for target globals (guess the vast
majority isn't, most of them will be flags affecting FE or GIMPLE optimizations
or what RTL passes are enabled/disabled), mark them some way in *.opt files and
figure out how to force a new target node (or hash that) on switchable targets
if any of those options changes.

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

[law at redhat dot com]

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

Jeffrey A. Law <law at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|8.5                         |11.0
                 CC|                            |law at redhat dot com

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

[dcb314 at hotmail dot com]

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

David Binderman <dcb314 at hotmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dcb314 at hotmail dot com

--- Comment #7 from David Binderman <dcb314 at hotmail dot com> ---
Another test case. 

This C code:

double a;
b;
long double c;
e() { float d = (double)(long double)b; }
__attribute__((optimize(""))) f() { a = c; }

when compiled by recent gcc trunk and compiler flag -ffast-math,
does this:

uring RTL pass: reload
bug634.c: In function ‘f’:
bug634.c:5:44: internal compiler error: in check_bool_attrs, at recog.c:2169
    5 | __attribute__((optimize(""))) f() { a = c; }
      |                                            ^
0xc42e4c check_bool_attrs(rtx_insn*)
        ../../trunk.git/gcc/recog.c:2168
0xafb3fc lra_update_insn_recog_data(rtx_insn*)
        ../../trunk.git/gcc/lra.c:1260
0xb18199 eliminate_regs_in_insn(rtx_insn*, bool, bool, poly_int<1u, long>)
        ../../trunk.git/gcc/lra-eliminations.c:0
0xb18b87 process_insn_for_elimination(rtx_insn*, bool, bool)
        ../../trunk.git/gcc/lra-eliminations.c:1304

This has been going wrong since sometime before date 20200630.

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

[dcb314 at hotmail dot com]

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

--- Comment #8 from David Binderman <dcb314 at hotmail dot com> ---
Nothing has happened on this bug report for more than two months.
Perhaps Uros is best placed to make progress with this bug.

I would be happy to help with any testing of patches.

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

[dcb314 at hotmail dot com]

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

--- Comment #9 from David Binderman <dcb314 at hotmail dot com> ---
No progress for another couple of months.

Can I assume that fixing this bug isn't a priority for the next release of gcc
?

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

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I can't reproduce it anymore.

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

[dcb314 at hotmail dot com]

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

--- Comment #11 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to Jakub Jelinek from comment #10)
> I can't reproduce it anymore.

The code in comment 7 still fails.

$ /home/dcb/gcc/results/bin/gcc -c -w -ffast-math bug634.c 2>&1 | fgrep error:
bug634.c:5:44: internal compiler error: in check_bool_attrs, at recog.c:2190
$ /home/dcb/gcc/results/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/home/dcb/gcc/results/bin/gcc
COLLECT_LTO_WRAPPER=/home/dcb/gcc/results.20201206/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../trunk.git/configure --prefix=/home/dcb/gcc/results.20201206
--disable-bootstrap --disable-multilib --disable-werror
--with-pkgversion=8c23434fdadcf4ca --enable-checking=df,extra,fold,rtl,yes
--enable-languages=c,c++,fortran
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.0.0 20201206 (experimental) (8c23434fdadcf4ca)

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

[marxin at gcc dot gnu.org]

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

--- Comment #12 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #10)
> I can't reproduce it anymore.

I can still reproduce the original example with
g:ebdfd1606da6b5aa586b0cd156b69b659235c9c2.

https://godbolt.org/z/Y1jhf9

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

[hjl.tools at gmail dot com]

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

--- Comment #13 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Jakub Jelinek from comment #10)
> I can't reproduce it anymore.

For r11-5820,

[hjl@gnu-clx-1 gcc]$ cat 1.c
int b;
double c, d;
void fn1() {
  int i;
  for (i = 0; i < b; i++)
    c += i;
}
int __attribute__((optimize(1))) main() {
  double a[0];
  int i;
  for (i = 0; i < 9; i++)
    d += a[i];
}
[hjl@gnu-clx-1 gcc]$ ./xgcc -B./ -mfpmath=sse,387 -fexcess-precision=standard
-Ofast -fno-graphite --param=scev-max-expr-size=0 -m32  1.c
during RTL pass: reload
1.c: In function ??main??:
1.c:13:1: internal compiler error: in check_bool_attrs, at recog.c:2189
   13 | }
      | ^
0x6d21c1 check_bool_attrs(rtx_insn*)
        ../../src-master/gcc/recog.c:2189
0xc568e0 lra_update_insn_recog_data(rtx_insn*)
        ../../src-master/gcc/lra.c:1260
0xc7197b process_insn_for_elimination
        ../../src-master/gcc/lra-eliminations.c:1304
0xc7197b lra_eliminate(bool, bool)
        ../../src-master/gcc/lra-eliminations.c:1372
0xc578d9 lra(_IO_FILE*)
        ../../src-master/gcc/lra.c:2461
0xc13129 do_reload
        ../../src-master/gcc/ira.c:5802
0xc13129 execute
        ../../src-master/gcc/ira.c:5988
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[hjl@gnu-clx-1 gcc]$

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

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Ah, -march=x86-64 or -msse2 is needed for me on top of the specified options.

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org

--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 49699
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49699&action=edit
gcc11-pr94440.patch

I think best would be to get away with the TREE_OPTIMIZATION_NODE vs.
TARGET_OPTIMIZATION_NODE dichotomy and just use one node for both, but that
won't fly in stage3, so this patch essentially forces new target optimization
nodes to cover even the flag_excess_precision and flag_unsafe_math_optimization
stuff, so that the enabled attr etc. can use those.

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

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-5855-ge401db7bfd8cf86d3833805a81b1252884eb1c9d
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.

[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]

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)

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[8/9/10 Regression] ICE in  |[8/9 Regression] ICE in
                   |check_bool_attrs, at        |check_bool_attrs, at
                   |recog.c:2168 since          |recog.c:2168 since
                   |r7-5324-gb8cab8a5492e9639   |r7-5324-gb8cab8a5492e9639

--- Comment #18 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed for 10.3+ too.

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|11.0                        |11.2

--- Comment #19 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 11.1 has been released, retargeting bugs to GCC 11.2.

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

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|11.2                        |11.3

--- Comment #20 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 11.2 is being released, retargeting bugs to GCC 11.3

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

[ubizjak at gmail dot com]

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

--- Comment #21 from Uroš Bizjak <ubizjak at gmail dot com> ---
Fixed?

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

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|11.3                        |11.4

--- Comment #22 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 11.3 is being released, retargeting bugs to GCC 11.4.

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|11.4                        |11.5

--- Comment #23 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 11.4 is being released, retargeting bugs to GCC 11.5.