[Bug tree-optimization/49471] cactusADM/dealII build with autopar fails on x86, and fails on power7 when -m32 is enabled.

["razya at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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 <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.

dealII has the exact same behavior as cactusADM when autopar is enabled
on x86, or together with -m32 on powerpc.