From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4920 invoked by alias); 25 Jul 2011 13:33:10 -0000 Received: (qmail 4911 invoked by uid 22791); 25 Jul 2011 13:33:09 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,TW_TM X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 25 Jul 2011 13:32:52 +0000 From: "razya at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/49471] cactusADM/dealII build with autopar fails on x86, and fails on power7 when -m32 is enabled. X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: razya at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: razya at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Summary Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Mon, 25 Jul 2011 13:33:00 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2011-07/txt/msg02118.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49471 razya at gcc dot gnu.org changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|cactusADM build with |cactusADM/dealII build with |autopar fails on x86, and |autopar fails on x86, and |fails on power7 when -m32 |fails on power7 when -m32 |is enabled. |is enabled. --- Comment #6 from razya at gcc dot gnu.org 2011-07-25 13:31:50 UTC --- (In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > (In reply to comment #2) > > > > (In reply to comment #1) > > > > > Why is > > > > > D.7313_5 = MEM[(struct *).paral_data_param_1(D)].D.7288; /* Number of loop > > > > > iterations. */ > > > > > of type __int128? That looks bogus. > > > > > > > > the size of 128 was determined according to the precision of the ivs in > > > > canonicalize_loop_ivs: > > > > > > > > canonicalize_loop_ivs (struct loop *loop, tree *nit, bool bump_in_latch) > > > > { > > > > unsigned precision = TYPE_PRECISION (TREE_TYPE (*nit)); > > > > for (psi = gsi_start_phis (loop->header); > > > > !gsi_end_p (psi); gsi_next (&psi)) > > > > { > > > > gimple phi = gsi_stmt (psi); > > > > tree res = PHI_RESULT (phi); > > > > > > > > if (is_gimple_reg (res) && TYPE_PRECISION (TREE_TYPE (res)) > precision) > > > > precision = TYPE_PRECISION (TREE_TYPE (res)); > > > > } > > > > > > > > type = lang_hooks.types.type_for_size (precision, 1); // precision == 128 > > > > ... > > > > } > > > > > > > > Does it seem that the precision should not determine the new type size, or that > > > > the precision itself being 128 is strange? > > > Well, autopar seems to introduce this 128 bit type in the first place, > > > and I wonder why it does that. And it definitely should avoid doing this. > > What happens is that autopar calls canonicalize_loop_ivs() when it is starting > > to change the loop. > > Here's a part of the documentation of canonicalize_loop_ivs(): > > " When the IV type precision has to be larger > > than *NIT type precision, *NIT is converted to the larger type, the > > conversion code is inserted before the loop, and *NIT is updated to > > the new definition. " > > In this case of cactusADM, one of the loop's IVs indeed has a precision of 128, > > and therefore a conversion to a type of 128 bit is created. > > I checked the precision of the loop's IVs a few passes before autopar, and even > > when I disable autopar, and indeed there is an IV that has a type with 128 > > precision. > I tried to build cactusADM on linux-x86 with autopar enabled, and I get > segmentation fault due to the same reason. > It happens when either -m32c or -m64 is enabled. > /Develop/razya/gcc-cactus/bin/gcc -c -o PUGHReduce/ReductionNormInf.o > -DSPEC_CPU -DNDEBUG -Iinclude -I../include -DCCODE -O2 > -ftree-parallelize-loops=4 -ffast-math -DSPEC_CPU_LP64 > PUGHReduce/ReductionNormInf.c > PUGHReduce/ReductionNormInf.c: In function 'PUGH_ReductionNormInf': > PUGHReduce/ReductionNormInf.c:207:12: internal compiler error: Segmentation > fault > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > specmake: *** [PUGHReduce/ReductionNormInf.o] Error 1 > The type is NULL at line 1218 in canonicalize_loop_ivs: > 1214 type = lang_hooks.types.type_for_size (precision, 1); > 1215 > 1216 if (original_precision != precision) > 1217 { > 1218 *nit = fold_convert (type, *nit); > 1219 *nit = force_gimple_operand (*nit, &stmts, true, NULL_TREE); > 1220 if (stmts) > 1221 gsi_insert_seq_on_edge_immediate (loop_preheader_edge (loop), > stmts); > 1222 } > The size according to which the type is supposed to be created (line 1214) is > 80. dealII has the exact same behavior as cactusADM when autopar is enabled on x86, or together with -m32 on powerpc.