From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25620 invoked by alias); 6 Nov 2015 10:39:26 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 25600 invoked by uid 89); 6 Nov 2015 10:39:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx2.suse.de Received: from mx2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Fri, 06 Nov 2015 10:39:24 +0000 Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id D2859AAD0; Fri, 6 Nov 2015 10:39:00 +0000 (UTC) Date: Fri, 06 Nov 2015 10:39:00 -0000 From: Richard Biener To: Alan Lawrence cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Fix PR68067 In-Reply-To: <563C817D.1060107@arm.com> Message-ID: References: <563C817D.1060107@arm.com> User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1609908220-1211300465-1446806361=:10078" X-SW-Source: 2015-11/txt/msg00580.txt.bz2 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1609908220-1211300465-1446806361=:10078 Content-Type: TEXT/PLAIN; charset=WINDOWS-1252 Content-Transfer-Encoding: 8BIT Content-length: 3771 On Fri, 6 Nov 2015, Alan Lawrence wrote: > On 28/10/15 13:38, Richard Biener wrote: > > > > Applied as follows. > > > > Bootstrapped / tested on x86_64-unknown-linux-gnu. > > > > Richard. > > > > 2015-10-28 Richard Biener > > > > * fold-const.c (negate_expr_p): Adjust the division case to > > properly avoid introducing undefined overflow. > > (fold_negate_expr): Likewise. > > Since this we've been seeing an ICE compiling polynom.c from 254.gap in > SPEC2000 on aarch64-linux-gnu with -O3 -ffast-math -mcpu=cortex-a53 (or -Ofast > -mcpu=cortex-a53), on both native (bootstrapped and --disable-bootstrap) and > cross-linux builds. > > A number of options prevent the ICE, e.g. any of -fno-thread-jumps, > -fno-strict-overflow, -fdump-tree-alias or -fdump-tree-ealias (!). Similarly, > dropping the -mcpu=cortex-a53, or changing to -mcpu=cortex-a57. > > (I have a recent build in a chroot for which -fno-strict-overflow does *not* > fix the ICE but haven't yet figured out exactly what the difference in the > chroot environment is.) > > Moreover, preprocessing in a separate step (i.e. piping preprocessed output > via a file with -E), also avoids the ICE. (This is hindering my efforts to > reduce the testcase!). So my hypothesis is that this is a > front-end/preprocessor bug, rather than anything directly due to this commit. > > The error message in full (line refs from that commit, r229479) is: > ===== > ../spec2000/benchspec/CINT2000/254.gap/src/polynom.c: In function > ‘NormalizeCoeffsListx’: > ../spec2000/benchspec/CINT2000/254.gap/src/polynom.c:358:11: error: > incompatible types in PHI argument 0 > TypHandle NormalizeCoeffsListx ( hdC ) > ^ > long int > > int > > ../spec2000/benchspec/CINT2000/254.gap/src/polynom.c:358:11: error: location > references block not in block tree > l1_279 = PHI <1(28), l1_299(33)> ^^^ this is the error to look at! It means that the GC heap will be corrupted quite easily. > ../spec2000/benchspec/CINT2000/254.gap/src/polynom.c:358:11: error: invalid > PHI argument which means this could be a followup error. We do have a bugreport (or two) about similar issues that were tracked down to different patches. Somebody needs to sit down and debug this properly ;) > ../spec2000/benchspec/CINT2000/254.gap/src/polynom.c:358:11: internal compiler > error: tree check: expected class ‘type’, have ‘declaration’ (namespace_decl) > in useless_type_conversion_p, at gimple-expr.c:84 > 0xd110ef tree_class_check_failed(tree_node const*, tree_code_class, char > const*, int, char const*) > ../../gcc-fsf/gcc/tree.c:9643 > 0x82561b tree_class_check > ../../gcc-fsf/gcc/tree.h:3042 > 0x82561b useless_type_conversion_p(tree_node*, tree_node*) > ../../gcc-fsf/gcc/gimple-expr.c:84 > 0xaca043 verify_gimple_phi > ../../gcc-fsf/gcc/tree-cfg.c:4673 > 0xaca043 verify_gimple_in_cfg(function*, bool) > ../../gcc-fsf/gcc/tree-cfg.c:4967 > 0x9c2e0b execute_function_todo > ../../gcc-fsf/gcc/passes.c:1967 Interesting would be for which pass this happens - just print *pass at this point. > 0x9c360b do_per_function > ../../gcc-fsf/gcc/passes.c:1659 > 0x9c3807 execute_todo > ../../gcc-fsf/gcc/passes.c:2022 > Please submit a full bug report, > with preprocessed source if appropriate. > ===== > which looks like an "incompatible types from PHI argument" from a first call > to verify_gimple_phi, then a second call to verify_gimple_phi prints "invalid > phi argument" and ICEs in the test just before possibly printing a second > incompatible_types message. > > > --Alan > > -- Richard Biener SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) ---1609908220-1211300465-1446806361=:10078--