public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "rakdver at atrey dot karlin dot mff dot cuni dot cz" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/21029] [4.1 Regression] vrp miscompiles Ada front-end, drops loop exit test in well-defined wrap-around circumstances
Date: Sat, 30 Apr 2005 07:54:00 -0000	[thread overview]
Message-ID: <20050430075415.9907.qmail@sourceware.org> (raw)
In-Reply-To: <20050414201608.21029.aoliva@gcc.gnu.org>


------- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni dot cz  2005-04-30 07:54 -------
Subject: Re: [PR tree-optimization/21029, RFC] harmful chrec type conversions

Hello,

> Alexandre Oliva wrote:
> > 
> > This is not a final patch; if the idea is considered sound, I'd simply
> > remove the if and the then-dead remaining code in chrec_convert.
> 
> The code following the if is not dead, at least it still is used in
> some cases after hand inlining count_ev_in_wider_type.  I would
> propose this patch that is about the same as yours
> 
> > Index: gcc/ChangeLog
> > from  Alexandre Oliva  <aoliva@redhat.com>
> > 
> > 	PR tree-optimization/21029
> > 	* tree-chrec.c (chrec_convert): Handle same-precision integral
> > 	types that differ in signedness like widening conversions.
> > 
> 
> with some more changes as follow:
> 
> 	* tree-chrec.c (chrec_convert): Handle same-precision integral
> 	types that differ in signedness like widening conversions.
> 	Inline count_ev_in_wider_type.
> 	* tree-chrec.h (count_ev_in_wider_type): Remove declaration.
> 	* tree-scalar-evolution.c (count_ev_in_wider_type): Removed.
> 
> Zdenek, does this change look right to you?

no.  There is one major bug -- 

> !   if (!evolution_function_is_affine_p (chrec))
>       {
> !       switch (TREE_CODE (chrec))
> ! 	{
> ! 	case POLYNOMIAL_CHREC:
> ! 	  return build_polynomial_chrec (CHREC_VARIABLE (chrec),
> ! 					 chrec_convert (type,
> ! 							CHREC_LEFT (chrec)),
> ! 					 chrec_convert (type,
> ! 							CHREC_RIGHT (chrec)));
> ! 

this is completely bogus -- you will always convert the
POLYNOMIAL_CHREC with nonconstant step, regardless of the correctness.

There are also a few minor changes that would be recommendable for the
final patch:

1) The can_count_ev_in_wider_type should be renamed to more appropriate
   name, given that it is now used even for shortening the value.
2) This function should be extended to really handle such conversions
   efficiently. I.e. to always allow shortening to unsigned types,
   and to always allow shortening to arbitrary types with -fwrapv.
   Also, I am not quite sure at the moment that the current code of
   can_count_ev_in_wider_type really works if the required conversion
   is not extending, this should be checked.

Zdenek

> 
> Index: tree-chrec.c
> ===================================================================
> RCS file: /cvs/gcc/gcc/gcc/tree-chrec.c,v
> retrieving revision 2.15
> diff -c -3 -p -r2.15 tree-chrec.c
> *** tree-chrec.c	21 Apr 2005 08:48:51 -0000	2.15
> --- tree-chrec.c	29 Apr 2005 19:31:51 -0000
> *************** tree 
> *** 1036,1085 ****
>   chrec_convert (tree type, 
>   	       tree chrec)
>   {
> !   tree ct;
> !   
>     if (automatically_generated_chrec_p (chrec))
>       return chrec;
> !   
>     ct = chrec_type (chrec);
>     if (ct == type)
>       return chrec;
>   
> !   if (TYPE_PRECISION (ct) < TYPE_PRECISION (type))
> !     return count_ev_in_wider_type (type, chrec);
> ! 
> !   switch (TREE_CODE (chrec))
>       {
> !     case POLYNOMIAL_CHREC:
> !       return build_polynomial_chrec (CHREC_VARIABLE (chrec),
> ! 				     chrec_convert (type,
> ! 						    CHREC_LEFT (chrec)),
> ! 				     chrec_convert (type,
> ! 						    CHREC_RIGHT (chrec)));
> ! 
> !     default:
> !       {
> ! 	tree res = fold_convert (type, chrec);
> ! 
> ! 	/* Don't propagate overflows.  */
> ! 	TREE_OVERFLOW (res) = 0;
> ! 	if (CONSTANT_CLASS_P (res))
> ! 	  TREE_CONSTANT_OVERFLOW (res) = 0;
> ! 
> ! 	/* But reject constants that don't fit in their type after conversion.
> ! 	   This can happen if TYPE_MIN_VALUE or TYPE_MAX_VALUE are not the
> ! 	   natural values associated with TYPE_PRECISION and TYPE_UNSIGNED,
> ! 	   and can cause problems later when computing niters of loops.  Note
> ! 	   that we don't do the check before converting because we don't want
> ! 	   to reject conversions of negative chrecs to unsigned types.  */
> ! 	if (TREE_CODE (res) == INTEGER_CST
> ! 	    && TREE_CODE (type) == INTEGER_TYPE
> ! 	    && !int_fits_type_p (res, type))
> ! 	  res = chrec_dont_know;
> ! 
> ! 	return res;
> !       }
>       }
>   }
>   
>   /* Returns the type of the chrec.  */
> --- 1036,1104 ----
>   chrec_convert (tree type, 
>   	       tree chrec)
>   {
> !   tree ct, base, step;
> !   struct loop *loop;
> ! 
>     if (automatically_generated_chrec_p (chrec))
>       return chrec;
> ! 
>     ct = chrec_type (chrec);
>     if (ct == type)
>       return chrec;
>   
> !   if (!evolution_function_is_affine_p (chrec))
>       {
> !       switch (TREE_CODE (chrec))
> ! 	{
> ! 	case POLYNOMIAL_CHREC:
> ! 	  return build_polynomial_chrec (CHREC_VARIABLE (chrec),
> ! 					 chrec_convert (type,
> ! 							CHREC_LEFT (chrec)),
> ! 					 chrec_convert (type,
> ! 							CHREC_RIGHT (chrec)));
> ! 
> ! 	default:
> ! 	  {
> ! 	    tree res = fold_convert (type, chrec);
> ! 
> ! 	    /* Don't propagate overflows.  */
> ! 	    TREE_OVERFLOW (res) = 0;
> ! 	    if (CONSTANT_CLASS_P (res))
> ! 	      TREE_CONSTANT_OVERFLOW (res) = 0;
> ! 
> ! 	    /* But reject constants that don't fit in their type after
> ! 	       conversion.  This can happen if TYPE_MIN_VALUE or
> ! 	       TYPE_MAX_VALUE are not the natural values associated
> ! 	       with TYPE_PRECISION and TYPE_UNSIGNED, and can cause
> ! 	       problems later when computing niters of loops.  Note
> ! 	       that we don't do the check before converting because we
> ! 	       don't want to reject conversions of negative chrecs to
> ! 	       unsigned types.  */
> ! 	    if (TREE_CODE (res) == INTEGER_CST
> ! 		&& TREE_CODE (type) == INTEGER_TYPE
> ! 		&& !int_fits_type_p (res, type))
> ! 	      res = chrec_dont_know;
> ! 
> ! 	    return res;
> ! 	  }
> ! 	}
>       }
> + 
> +   /* BASE and STEP are INTEGER_CSTs.  */
> +   base = CHREC_LEFT (chrec);
> +   step = CHREC_RIGHT (chrec);
> +   loop = current_loops->parray[CHREC_VARIABLE (chrec)];
> + 
> +   /* TODO -- if we knew the statement at that the conversion occurs,
> +      we could pass it to can_count_iv_in_wider_type and get a better
> +      result.  */
> +   step = can_count_iv_in_wider_type (loop, type, base, step, NULL_TREE);
> +   if (!step)
> +     return fold_convert (type, chrec);
> + 
> +   base = chrec_convert (type, base);
> + 
> +   return build_polynomial_chrec (CHREC_VARIABLE (chrec), base, step);
>   }
>   
>   /* Returns the type of the chrec.  */
> Index: tree-chrec.h
> ===================================================================
> RCS file: /cvs/gcc/gcc/gcc/tree-chrec.h,v
> retrieving revision 2.8
> diff -c -3 -p -r2.8 tree-chrec.h
> *** tree-chrec.h	28 Apr 2005 05:38:34 -0000	2.8
> --- tree-chrec.h	29 Apr 2005 19:31:51 -0000
> *************** extern tree chrec_fold_plus (tree, tree,
> *** 68,74 ****
>   extern tree chrec_fold_minus (tree, tree, tree);
>   extern tree chrec_fold_multiply (tree, tree, tree);
>   extern tree chrec_convert (tree, tree);
> - extern tree count_ev_in_wider_type (tree, tree);
>   extern tree chrec_type (tree);
>   
>   /* Operations.  */
> --- 68,73 ----
> Index: tree-scalar-evolution.c
> ===================================================================
> RCS file: /cvs/gcc/gcc/gcc/tree-scalar-evolution.c,v
> retrieving revision 2.21
> diff -c -3 -p -r2.21 tree-scalar-evolution.c
> *** tree-scalar-evolution.c	21 Apr 2005 08:48:53 -0000	2.21
> --- tree-scalar-evolution.c	29 Apr 2005 19:31:52 -0000
> *************** find_var_scev_info (tree var)
> *** 350,382 ****
>     return &res->chrec;
>   }
>   
> - /* Tries to express CHREC in wider type TYPE.  */
> - 
> - tree
> - count_ev_in_wider_type (tree type, tree chrec)
> - {
> -   tree base, step;
> -   struct loop *loop;
> - 
> -   if (!evolution_function_is_affine_p (chrec))
> -     return fold_convert (type, chrec);
> - 
> -   base = CHREC_LEFT (chrec);
> -   step = CHREC_RIGHT (chrec);
> -   loop = current_loops->parray[CHREC_VARIABLE (chrec)];
> - 
> -   /* TODO -- if we knew the statement at that the conversion occurs,
> -      we could pass it to can_count_iv_in_wider_type and get a better
> -      result.  */
> -   step = can_count_iv_in_wider_type (loop, type, base, step, NULL_TREE);
> -   if (!step)
> -     return fold_convert (type, chrec);
> -   base = chrec_convert (type, base);
> - 
> -   return build_polynomial_chrec (CHREC_VARIABLE (chrec),
> - 				 base, step);
> - }
> - 
>   /* Return true when CHREC contains symbolic names defined in
>      LOOP_NB.  */
>   
> --- 350,355 ----


-- 


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


  parent reply	other threads:[~2005-04-30  7:54 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-14 20:16 [Bug tree-optimization/21029] New: " aoliva at gcc dot gnu dot org
2005-04-14 20:19 ` [Bug tree-optimization/21029] " dnovillo at redhat dot com
2005-04-14 20:19 ` aoliva at gcc dot gnu dot org
2005-04-14 20:25 ` [Bug tree-optimization/21029] [4.1 Regression] " pinskia at gcc dot gnu dot org
2005-04-14 20:42 ` pinskia at gcc dot gnu dot org
2005-04-15  2:40 ` aoliva at gcc dot gnu dot org
2005-04-15  5:56 ` aoliva at redhat dot com
2005-04-15 13:10 ` giovannibajo at libero dot it
2005-04-15 13:39 ` pinskia at gcc dot gnu dot org
2005-04-15 20:44 ` laurent at guerby dot net
2005-04-16 13:47 ` pinskia at gcc dot gnu dot org
2005-04-29 19:52 ` sebastian dot pop at cri dot ensmp dot fr
2005-04-30  7:54 ` rakdver at atrey dot karlin dot mff dot cuni dot cz [this message]
2005-05-13 18:20 ` dnovillo at gcc dot gnu dot org
2005-05-26 18:17 ` pinskia at gcc dot gnu dot org
2005-06-02  2:59 ` cvs-commit at gcc dot gnu dot org
2005-06-02  3:14 ` dnovillo at gcc dot gnu dot org
2005-06-02  8:51 ` schwab at suse dot de
2005-06-02 17:15 ` dnovillo at gcc dot gnu dot org
2005-06-08  9:45 ` schwab at suse dot de
2005-06-08 12:30 ` pinskia at gcc dot gnu dot org
2005-09-10 18:10 ` pinskia at gcc dot gnu dot org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050430075415.9907.qmail@sourceware.org \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).