From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 35CF03938C03; Tue, 5 Jan 2021 15:38:51 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 35CF03938C03 From: "cvs-commit at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/98514] ICE in insert_operand_rank Date: Tue, 05 Jan 2021 15:38:50 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 11.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: cvs-commit at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: jakub at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- 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, 05 Jan 2021 15:38:51 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D98514 --- Comment #4 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:4ddee425b8c427d3cc13c49b26f442313e239572 commit r11-6473-g4ddee425b8c427d3cc13c49b26f442313e239572 Author: Jakub Jelinek Date: Tue Jan 5 16:37:40 2021 +0100 reassoc: Fix reassociation on 32-bit hosts with > 32767 bbs [PR98514] Apparently reassoc ICEs on large functions (more than 32767 basic blocks with something to reassociate in those). The problem is that the pass uses long type to store the ranks, and the bb ranks are (number of SSA_NAMEs with default defs + 2 + bb->index= ) << 16, so with many basic blocks we overflow the ranks and we then have assert= ions rank is not negative. The following patch just uses int64_t instead of long in the pass, yes, it means slightly higher memory consumption (one array indexed by bb->index is twice as large, and one hash_map from trees to the ranks will grow by 50%, but I think it is better than punting on large functi= ons the reassociation on 32-bit hosts and making it inconsistent e.g. when cross-compiling. Given vec.h uses unsigned for vect element counts, we don't really support more than 4G of SSA_NAMEs or more than 2G of ba= sic blocks in a function, so even with the << 16 we can't really overflow t= he int64_t rank counters. 2021-01-05 Jakub Jelinek PR tree-optimization/98514 * tree-ssa-reassoc.c (bb_rank): Change type from long * to int64_t *. (operand_rank): Change type from hash_map to hash_map. (phi_rank): Change return type from long to int64_t. (loop_carried_phi): Change block_rank variable type from long to int64_t. (propagate_rank): Change return type, rank parameter type and op_rank variable type from long to int64_t. (find_operand_rank): Change return type from long to int64_t and change slot variable type from long * to int64_t *. (insert_operand_rank): Change rank parameter type from long to int64_t. (get_rank): Change return type and rank variable type from long= to int64_t. Use PRId64 instead of ld to print the rank. (init_reassoc): Change rank variable type from long to int64_t and adjust correspondingly bb_rank and operand_rank initializat= ion.=