This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug tree-optimization/49471] ICE when -ftree-parallelize-loops is enabled together with -m32 on power7


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49471

--- Comment #2 from razya at il dot ibm.com 2011-06-20 12:31:32 UTC ---
(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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]