From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id E7B52396EC83; Tue, 8 Dec 2020 14:44:39 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E7B52396EC83 From: "cvs-commit at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/94440] [8/9/10/11 Regression] ICE in check_bool_attrs, at recog.c:2168 since r7-5324-gb8cab8a5492e9639 Date: Tue, 08 Dec 2020 14:44:39 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: rtl-optimization X-Bugzilla-Version: 10.0 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: cvs-commit at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: jakub at gcc dot gnu.org X-Bugzilla-Target-Milestone: 11.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 14:44:40 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D94440 --- Comment #16 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:e401db7bfd8cf86d3833805a81b1252884eb1c9d commit r11-5855-ge401db7bfd8cf86d3833805a81b1252884eb1c9d Author: Jakub Jelinek 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 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 instea= d 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_precisio= n. * 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 node= s. (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.=