http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49471
--- Comment #5 from razya at gcc dot gnu.org 2011-07-13 15:06:50 UTC ---
(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 <http://gcc.gnu.org/bugs.html> 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.
