[PATCH][1/n][C] Do not sign-extend sizetypes

[PATCH][1/n][C] Do not sign-extend sizetypes

[Richard Guenther]

This is another try at making sizetype behavior more consistent with
other integral types.  In particular this series will eventually
succeed in making TYPE_UNSIGNED tell the truth for sizetypes ...

This first patch replaces a hack in the C frontend to handle
zero-sized arrays (int a[] = {}) by setting the upper bound of
the domain to integer_minus_one_node.  This works by luck only
as the code later calls build_index_type which happily combines
(and converts) this with a sizetype zero lower bound.  Simply
using an integer typed domain fixes this, so the patch makes
the C frontend use build_range_type instead.

Similarly the stor-layout.c code fails to properly use
signed arithmetic when it needs to.  The present code presumably
already handles some cases, but not that special case of
adding one to -1.

The rest of the patch is simple stuff I noticed when going over
the code.

Bootstrapped and tested on x86_64-unknown-linux-gnu for all
languages including Ada and Objective-C++.

Are the c-family changes ok?

Thanks,
Richard.

2011-04-11  Richard Guenther  <rguenther@suse.de>

	* stor-layout.c (layout_type): Compute all array index size operations
	in the original type.
	(initialize_sizetypes): Add comment.
	(set_sizetype): Do not set TREE_TYPE of a TREE_VEC.

	c-family/
	* c-common.c (complete_array_type): Build a range type of
	proper type.

Index: trunk/gcc/stor-layout.c
===================================================================
*** trunk.orig/gcc/stor-layout.c	2011-04-06 10:51:40.000000000 +0200
--- trunk/gcc/stor-layout.c	2011-04-11 14:30:23.000000000 +0200
*************** layout_type (tree type)
*** 1996,2010 ****
  	    if (integer_zerop (element_size))
  	      length = size_zero_node;
  
! 	    /* The initial subtraction should happen in the original type so
  	       that (possible) negative values are handled appropriately.  */
  	    else
  	      length
! 		= size_binop (PLUS_EXPR, size_one_node,
! 			      fold_convert (sizetype,
! 					    fold_build2 (MINUS_EXPR,
! 							 TREE_TYPE (lb),
! 							 ub, lb)));
  
  	    TYPE_SIZE (type) = size_binop (MULT_EXPR, element_size,
  					   fold_convert (bitsizetype,
--- 1996,2011 ----
  	    if (integer_zerop (element_size))
  	      length = size_zero_node;
  
! 	    /* The computation should happen in the original type so
  	       that (possible) negative values are handled appropriately.  */
  	    else
  	      length
! 		= fold_convert (sizetype,
! 				fold_build2 (PLUS_EXPR, TREE_TYPE (lb),
! 					     build_int_cst (TREE_TYPE (lb), 1),
! 					     fold_build2 (MINUS_EXPR,
! 							  TREE_TYPE (lb),
! 							  ub, lb)));
  
  	    TYPE_SIZE (type) = size_binop (MULT_EXPR, element_size,
  					   fold_convert (bitsizetype,
*************** initialize_sizetypes (void)
*** 2249,2255 ****
    TYPE_SIZE_UNIT (t) = build_int_cst (t, GET_MODE_SIZE (SImode));
    TYPE_PRECISION (t) = precision;
  
!   set_min_and_max_values_for_integral_type (t, precision, true);
  
    sizetype = t;
    bitsizetype = build_distinct_type_copy (t);
--- 2250,2257 ----
    TYPE_SIZE_UNIT (t) = build_int_cst (t, GET_MODE_SIZE (SImode));
    TYPE_PRECISION (t) = precision;
  
!   set_min_and_max_values_for_integral_type (t, precision,
! 					    /*is_unsinged=*/true);
  
    sizetype = t;
    bitsizetype = build_distinct_type_copy (t);
*************** set_sizetype (tree type)
*** 2284,2290 ****
    /* We want to use sizetype's cache, as we will be replacing that type.  */
    TYPE_CACHED_VALUES (t) = TYPE_CACHED_VALUES (sizetype);
    TYPE_CACHED_VALUES_P (t) = TYPE_CACHED_VALUES_P (sizetype);
-   TREE_TYPE (TYPE_CACHED_VALUES (t)) = type;
    TYPE_UID (t) = TYPE_UID (sizetype);
    TYPE_IS_SIZETYPE (t) = 1;
  
--- 2286,2291 ----
Index: trunk/gcc/c-family/c-common.c
===================================================================
*** trunk.orig/gcc/c-family/c-common.c	2011-04-11 10:56:06.000000000 +0200
--- trunk/gcc/c-family/c-common.c	2011-04-11 14:27:17.000000000 +0200
*************** complete_array_type (tree *ptype, tree i
*** 8810,8816 ****
       TYPE_LANG_FLAG_? bits that the front end may have set.  */
    main_type = build_distinct_type_copy (TYPE_MAIN_VARIANT (type));
    TREE_TYPE (main_type) = unqual_elt;
!   TYPE_DOMAIN (main_type) = build_index_type (maxindex);
    layout_type (main_type);
  
    /* Make sure we have the canonical MAIN_TYPE. */
--- 8810,8818 ----
       TYPE_LANG_FLAG_? bits that the front end may have set.  */
    main_type = build_distinct_type_copy (TYPE_MAIN_VARIANT (type));
    TREE_TYPE (main_type) = unqual_elt;
!   TYPE_DOMAIN (main_type)
!     = build_range_type (TREE_TYPE (maxindex),
! 			build_int_cst (TREE_TYPE (maxindex), 0), maxindex);
    layout_type (main_type);
  
    /* Make sure we have the canonical MAIN_TYPE. */

Re: [PATCH][1/n][C] Do not sign-extend sizetypes

[Jay Foad]

On 11 April 2011 15:25, Richard Guenther <rguenther@suse.de> wrote:
> !   set_min_and_max_values_for_integral_type (t, precision,
> !                                           /*is_unsinged=*/true);

s/ng/gn/

Jay.

Re: [PATCH][1/n][C] Do not sign-extend sizetypes

[Joseph S. Myers]

On Mon, 11 Apr 2011, Richard Guenther wrote:

> 	c-family/
> 	* c-common.c (complete_array_type): Build a range type of
> 	proper type.

OK.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH][1/n][C] Do not sign-extend sizetypes

[H.J. Lu]

On Mon, Apr 11, 2011 at 7:25 AM, Richard Guenther <rguenther@suse.de> wrote:
>
> This is another try at making sizetype behavior more consistent with
> other integral types.  In particular this series will eventually
> succeed in making TYPE_UNSIGNED tell the truth for sizetypes ...
>
> This first patch replaces a hack in the C frontend to handle
> zero-sized arrays (int a[] = {}) by setting the upper bound of
> the domain to integer_minus_one_node.  This works by luck only
> as the code later calls build_index_type which happily combines
> (and converts) this with a sizetype zero lower bound.  Simply
> using an integer typed domain fixes this, so the patch makes
> the C frontend use build_range_type instead.
>
> Similarly the stor-layout.c code fails to properly use
> signed arithmetic when it needs to.  The present code presumably
> already handles some cases, but not that special case of
> adding one to -1.
>
> The rest of the patch is simple stuff I noticed when going over
> the code.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu for all
> languages including Ada and Objective-C++.
>
> Are the c-family changes ok?
>
> Thanks,
> Richard.
>
> 2011-04-11  Richard Guenther  <rguenther@suse.de>
>
>        * stor-layout.c (layout_type): Compute all array index size operations
>        in the original type.
>        (initialize_sizetypes): Add comment.
>        (set_sizetype): Do not set TREE_TYPE of a TREE_VEC.
>
>        c-family/
>        * c-common.c (complete_array_type): Build a range type of
>        proper type.
>

This caused:

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

-- 
H.J.