host_integerp vs [] decls

host_integerp vs [] decls

[DJ Delorie]

This trivial test case segv's gcc:

void test() {
  int a[][0] = {{1}};
}

Program received signal SIGSEGV, Segmentation fault.
0x82e2dc4 in host_integerp (t=0x0, pos=0) at /uberbuild/src/gcc/tree.c:3471
3471      return (TREE_CODE (t) == INTEGER_CST

[ gdb ] where
#0  0x82e2dc4 in host_integerp (t=0x0, pos=0) at /uberbuild/src/gcc/tree.c:3471
#1  0x811873c in store_constructor (exp=0x4012f280, target=0x4013b250, align=32, cleared=0, size=0)
    at /uberbuild/src/gcc/expr.c:4714
#2  0x8117dc4 in store_constructor_field (target=0x4013b250, bitsize=0, bitpos=0, mode=BLKmode, 
    exp=0x4012f280, type=0x40137bd0, align=32, cleared=0, alias_set=0)
    at /uberbuild/src/gcc/expr.c:4496
...

Re: host_integerp vs [] decls

[Richard Henderson]

On Fri, Sep 14, 2001 at 03:54:07PM -0400, DJ Delorie wrote:
> void test() {
>   int a[][0] = {{1}};
> }
[...]
> #1  0x811873c in store_constructor (...)
>     at /uberbuild/src/gcc/expr.c:4714

Yep, we've forgotten that [] arrays have no MAX_VALUE in the array.

Should be something like

      int const_bounds_p = (TYPE_MIN_VALUE (domain) && TYPE_MAX_VALUE (domain)
			    && host_integerp (TYPE_MIN_VALUE (domain), 0)
                            && host_integerp (TYPE_MAX_VALUE (domain), 0));


r~

Re: host_integerp vs [] decls

[DJ Delorie]

Another `obvious' fix is to have host_integerp return false when given
NULL.  Not sure if that would fix or hide other problems ;-)

Re: host_integerp vs [] decls

[Richard Henderson]

On Fri, Sep 14, 2001 at 05:47:33PM -0400, DJ Delorie wrote:
> Another `obvious' fix is to have host_integerp return false when given
> NULL.  Not sure if that would fix or hide other problems ;-)

I don't think that is such a great idea...


r~

Re: host_integerp vs [] decls

[DJ Delorie]

> Should be something like

Bootstrapped, tested, no regressions, on Red Hat Linux 6.2.

2001-09-14  DJ Delorie  <dj@redhat.com>

	* expr.c (store_constructor): Handle empty arrays.

Index: expr.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/expr.c,v
retrieving revision 1.351
diff -p -3 -r1.351 expr.c
*** expr.c	2001/09/06 08:59:36	1.351
--- expr.c	2001/09/15 01:32:17
*************** store_constructor (exp, target, align, c
*** 4710,4716 ****
        int need_to_clear;
        tree domain = TYPE_DOMAIN (type);
        tree elttype = TREE_TYPE (type);
!       int const_bounds_p = (host_integerp (TYPE_MIN_VALUE (domain), 0)
  			    && host_integerp (TYPE_MAX_VALUE (domain), 0));
        HOST_WIDE_INT minelt = 0;
        HOST_WIDE_INT maxelt = 0;
--- 4710,4717 ----
        int need_to_clear;
        tree domain = TYPE_DOMAIN (type);
        tree elttype = TREE_TYPE (type);
!       int const_bounds_p = (TYPE_MIN_VALUE (domain) && TYPE_MAX_VALUE (domain)
! 			    && host_integerp (TYPE_MIN_VALUE (domain), 0)
  			    && host_integerp (TYPE_MAX_VALUE (domain), 0));
        HOST_WIDE_INT minelt = 0;
        HOST_WIDE_INT maxelt = 0;

Re: host_integerp vs [] decls

[Richard Henderson]

On Fri, Sep 14, 2001 at 09:33:14PM -0400, DJ Delorie wrote:
> 	* expr.c (store_constructor): Handle empty arrays.

Err, incidentally, the original test case

  int a[][0] = {{1}};

is bogus.  This should be handled in the same way that

  int a[][1] = {{1,2}};

is rejected.  The only initializer case that might
be allowable is

  int a[][0] = {{}};


r~

Re: host_integerp vs [] decls

[DJ Delorie]

> Yep, we've forgotten that [] arrays have no MAX_VALUE in the array.
> 
> Should be something like
> 
>       int const_bounds_p = (TYPE_MIN_VALUE (domain) && TYPE_MAX_VALUE (domain)
> 			    && host_integerp (TYPE_MIN_VALUE (domain), 0)
>                             && host_integerp (TYPE_MAX_VALUE (domain), 0));

Is it time for this change yet?  If so, should I get rid of all the
`constructor_max_index == 0' tests too, and just assume it's never
zero?

Index: c-typeck.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/c-typeck.c,v
retrieving revision 1.137
diff -p -3 -r1.137 c-typeck.c
*** c-typeck.c	2001/09/16 00:48:52	1.137
--- c-typeck.c	2001/09/19 19:17:08
*************** push_init_level (implicit)
*** 5356,5365 ****
  	    = convert (bitsizetype, 
  		       TYPE_MIN_VALUE (TYPE_DOMAIN (constructor_type)));
  
! 	  /* ??? For GCC 3.1, remove special case initialization of
! 	     zero-length array members from pop_init_level and set
! 	     constructor_max_index such that we get the normal
! 	     "excess elements" warning.  */
  	}
        else
  	constructor_index = bitsize_zero_node;
--- 5356,5364 ----
  	    = convert (bitsizetype, 
  		       TYPE_MIN_VALUE (TYPE_DOMAIN (constructor_type)));
  
! 	  /* Detect non-empty initializations of zero-length arrays.  */
! 	  if (constructor_max_index == NULL_TREE)
! 	    constructor_max_index = build_int_2 (-1, -1);
  	}
        else
  	constructor_index = bitsize_zero_node;

Re: host_integerp vs [] decls

[Richard Henderson]

On Wed, Sep 19, 2001 at 03:21:05PM -0400, DJ Delorie wrote:
> Is it time for this change yet?  If so, should I get rid of all the
> `constructor_max_index == 0' tests too, and just assume it's never
> zero?

There had to have been something complicated here that caused
me not to write that obvious two liner.  Have you run the
test suite on this?


r~

Re: host_integerp vs [] decls

[DJ Delorie]

> There had to have been something complicated here that caused
> me not to write that obvious two liner.  Have you run the
> test suite on this?

Not yet.  I'll start a run asap...

Re: host_integerp vs [] decls

[DJ Delorie]

> There had to have been something complicated here that caused
> me not to write that obvious two liner.

Perhaps http://gcc.gnu.org/ml/gcc-patches/2001-01/msg00323.html ?

Re: host_integerp vs [] decls

[Richard Henderson]

On Wed, Sep 19, 2001 at 04:09:51PM -0400, DJ Delorie wrote:
> > There had to have been something complicated here that caused
> > me not to write that obvious two liner.
> 
> Perhaps http://gcc.gnu.org/ml/gcc-patches/2001-01/msg00323.html ?

Ah yes.  Now I remember.

However, please follow the directions of the comment and remove the
special case from pop_level_1.  Also update the documentation such
that "deprecated" is now "illegal".


r~

Re: host_integerp vs [] decls

[DJ Delorie]

> However, please follow the directions of the comment and remove the
> special case from pop_level_1.  Also update the documentation such
> that "deprecated" is now "illegal".

It took a while to get the right warnings for flexible vs zero-length
arrays, and I had to adjust some of the test cases to detect the right
warnings, but here it all is.  No regressions on x86 linux.

2001-09-19  DJ Delorie  <dj@redhat.com>

	* c-typeck.c (really_start_incremental_init): Discriminate
	between zero-length arrays and flexible arrays.
	(push_init_level): Detect zero-length arrays and handle them
	like fixed-sized arrays.
	* expr.c (store_constructor): Handle zero-length arrays and
	flexible arrays correctly.
	* doc/extend.texi: Update zero-length array notes.

2001-09-19  DJ Delorie  <dj@redhat.com>

	* gcc.dg/20000926-1.c: Update expected warning messages.
	* gcc.dg/array-2.c: Likewise, and test for warnings too.
	* gcc.dg/array-4.c: Likewise, and don't verify the zero-length
	array.

Index: c-typeck.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/c-typeck.c,v
retrieving revision 1.137
diff -p -3 -r1.137 c-typeck.c
*** c-typeck.c	2001/09/16 00:48:52	1.137
--- c-typeck.c	2001/09/20 00:58:55
*************** really_start_incremental_init (type)
*** 5190,5196 ****
  	    = TYPE_MAX_VALUE (TYPE_DOMAIN (constructor_type));
  
  	  /* Detect non-empty initializations of zero-length arrays.  */
! 	  if (constructor_max_index == NULL_TREE)
  	    constructor_max_index = build_int_2 (-1, -1);
  
  	  constructor_index
--- 5190,5197 ----
  	    = TYPE_MAX_VALUE (TYPE_DOMAIN (constructor_type));
  
  	  /* Detect non-empty initializations of zero-length arrays.  */
! 	  if (constructor_max_index == NULL_TREE
! 	      && TYPE_SIZE (constructor_type))
  	    constructor_max_index = build_int_2 (-1, -1);
  
  	  constructor_index
*************** push_init_level (implicit)
*** 5352,5365 ****
  	{
  	  constructor_max_index
  	    = TYPE_MAX_VALUE (TYPE_DOMAIN (constructor_type));
  	  constructor_index
  	    = convert (bitsizetype, 
  		       TYPE_MIN_VALUE (TYPE_DOMAIN (constructor_type)));
- 
- 	  /* ??? For GCC 3.1, remove special case initialization of
- 	     zero-length array members from pop_init_level and set
- 	     constructor_max_index such that we get the normal
- 	     "excess elements" warning.  */
  	}
        else
  	constructor_index = bitsize_zero_node;
--- 5353,5367 ----
  	{
  	  constructor_max_index
  	    = TYPE_MAX_VALUE (TYPE_DOMAIN (constructor_type));
+ 
+ 	  /* Detect non-empty initializations of zero-length arrays.  */
+ 	  if (constructor_max_index == NULL_TREE
+ 	      && TYPE_SIZE (constructor_type))
+ 	    constructor_max_index = build_int_2 (-1, -1);
+ 
  	  constructor_index
  	    = convert (bitsizetype, 
  		       TYPE_MIN_VALUE (TYPE_DOMAIN (constructor_type)));
  	}
        else
  	constructor_index = bitsize_zero_node;
*************** pop_init_level (implicit)
*** 5438,5456 ****
  	    constructor_type = NULL_TREE;
  	}
        else
! 	{
! 	  warning_init ("deprecated initialization of zero-length array");
! 
! 	  /* We must be initializing the last member of a top-level struct.  */
! 	  if (TREE_CHAIN (constructor_fields) != NULL_TREE)
! 	    {
! 	      error_init ("initialization of zero-length array before end of structure");
! 	      /* Discard the initializer so that we do not abort later.  */
! 	      constructor_type = NULL_TREE;
! 	    }
! 	  else if (constructor_depth > 2)
! 	    error_init ("initialization of zero-length array inside a nested context");
! 	}
      }
  
    /* Warn when some struct elements are implicitly initialized to zero.  */
--- 5440,5448 ----
  	    constructor_type = NULL_TREE;
  	}
        else
! 	/* Zero-length arrays are no longer special, so we should no longer
! 	   get here.  */
! 	abort();
      }
  
    /* Warn when some struct elements are implicitly initialized to zero.  */
Index: expr.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/expr.c,v
retrieving revision 1.351
diff -p -3 -r1.351 expr.c
*** expr.c	2001/09/06 08:59:36	1.351
--- expr.c	2001/09/20 00:59:23
*************** store_constructor (exp, target, align, c
*** 4710,4716 ****
        int need_to_clear;
        tree domain = TYPE_DOMAIN (type);
        tree elttype = TREE_TYPE (type);
!       int const_bounds_p = (host_integerp (TYPE_MIN_VALUE (domain), 0)
  			    && host_integerp (TYPE_MAX_VALUE (domain), 0));
        HOST_WIDE_INT minelt = 0;
        HOST_WIDE_INT maxelt = 0;
--- 4710,4718 ----
        int need_to_clear;
        tree domain = TYPE_DOMAIN (type);
        tree elttype = TREE_TYPE (type);
!       int const_bounds_p = (TYPE_MIN_VALUE (domain)
! 			    && TYPE_MAX_VALUE (domain)
! 			    && host_integerp (TYPE_MIN_VALUE (domain), 0)
  			    && host_integerp (TYPE_MAX_VALUE (domain), 0));
        HOST_WIDE_INT minelt = 0;
        HOST_WIDE_INT maxelt = 0;
Index: doc/extend.texi
===================================================================
RCS file: /cvs/gcc/gcc/gcc/doc/extend.texi,v
retrieving revision 1.23
diff -p -3 -r1.23 extend.texi
*** extend.texi	2001/08/18 21:02:43	1.23
--- extend.texi	2001/09/20 00:59:42
*************** of zero-length arrays, @code{sizeof} eva
*** 1303,1319 ****
  
  @item
  Flexible array members may only appear as the last member of a
! @code{struct} that is otherwise non-empty.  GCC currently allows
! zero-length arrays anywhere.  You may encounter problems, however,
! defining structures containing only a zero-length array.  Such usage
! is deprecated, and we recommend using zero-length arrays only in
! places in which flexible array members would be allowed.
  @end itemize
  
  GCC versions before 3.0 allowed zero-length arrays to be statically
! initialized.  In addition to those cases that were useful, it also
! allowed initializations in situations that would corrupt later data.
! Non-empty initialization of zero-length arrays is now deprecated.
  
  Instead GCC allows static initialization of flexible array members.
  This is equivalent to defining a new structure containing the original
--- 1303,1319 ----
  
  @item
  Flexible array members may only appear as the last member of a
! @code{struct} that is otherwise non-empty.
  @end itemize
  
  GCC versions before 3.0 allowed zero-length arrays to be statically
! initialized, as if they were flexible arrays.  In addition to those
! cases that were useful, it also allowed initializations in situations
! that would corrupt later data.  Non-empty initialization of zero-length
! arrays is now treated like any case where there are more initializer
! elements than the array holds, in that a suitable warning about "excess
! elements in array" is given, and the excess elements (all of them, in
! this case) are ignored.
  
  Instead GCC allows static initialization of flexible array members.
  This is equivalent to defining a new structure containing the original
Index: testsuite/gcc.dg/20000926-1.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/testsuite/gcc.dg/20000926-1.c,v
retrieving revision 1.4
diff -p -3 -r1.4 20000926-1.c
*** 20000926-1.c	2001/01/10 23:57:55	1.4
--- 20000926-1.c	2001/09/20 00:59:54
*************** struct PLAYBOOK playbook  =
*** 22,27 ****
  {
    "BookName",
    {
!     { 1, "PName0" },
!   } /* { dg-warning "(deprecated initialization)|(near initialization)" "" } */
  };
--- 22,27 ----
  {
    "BookName",
    {
!     { 1, "PName0" }, /* { dg-warning "(excess elements)|(near initialization)" "" } */
!   }
  };
Index: testsuite/gcc.dg/array-2.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/testsuite/gcc.dg/array-2.c,v
retrieving revision 1.2
diff -p -3 -r1.2 array-2.c
*** array-2.c	2001/01/05 05:56:00	1.2
--- array-2.c	2001/09/20 00:59:54
***************
*** 1,5 ****
  /* { dg-do compile } */
! /* { dg-options "-w" } */
  
  /* Verify that we can't do things to get ourselves in trouble
     with GCC's initialized flexible array member extension.  */
--- 1,5 ----
  /* { dg-do compile } */
! /* { dg-options "" } */
  
  /* Verify that we can't do things to get ourselves in trouble
     with GCC's initialized flexible array member extension.  */
*************** struct g g1 = { { 0, { } } };
*** 10,13 ****
  struct g g2 = { { 0, { 1 } } }; /* { dg-error "(nested context)|(near initialization)" "nested" } */
  
  struct h { int x[0]; int y; };
! struct h h1 = { { 0 }, 1 }; /* { dg-error "(before end)|(near initialization)" "before end" } */
--- 10,13 ----
  struct g g2 = { { 0, { 1 } } }; /* { dg-error "(nested context)|(near initialization)" "nested" } */
  
  struct h { int x[0]; int y; };
! struct h h1 = { { 0 }, 1 }; /* { dg-error "(excess elements)|(near initialization)" "before end" } */
Index: testsuite/gcc.dg/array-4.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/testsuite/gcc.dg/array-4.c,v
retrieving revision 1.2
diff -p -3 -r1.2 array-4.c
*** array-4.c	2001/01/05 05:56:00	1.2
--- array-4.c	2001/09/20 00:59:54
*************** struct g { int w; int x[0]; };
*** 12,18 ****
  
  static struct f f = { 4, { 0, 1, 2, 3 } };
  static int junk1[] = { -1, -1, -1, -1 };
! static struct g g = { 4, { 0, 1, 2, 3 } }; /* { dg-warning "(deprecated initialization)|(near initialization)" "" } */
  static int junk2[] = { -1, -1, -1, -1 };
  
  int main()
--- 12,18 ----
  
  static struct f f = { 4, { 0, 1, 2, 3 } };
  static int junk1[] = { -1, -1, -1, -1 };
! static struct g g = { 4, { 0, 1, 2, 3 } }; /* { dg-warning "(excess elements)|(near initialization)" "" } */
  static int junk2[] = { -1, -1, -1, -1 };
  
  int main()
*************** int main()
*** 21,28 ****
--- 21,30 ----
    for (i = 0; i < f.w; ++i)
      if (f.x[i] != i)
        abort ();
+   /* zero length arrays are no longer initialized to non-zero length.
    for (i = 0; i < g.w; ++i)
      if (g.x[i] != i)
        abort ();
+   */
    exit(0);
  }

Re: host_integerp vs [] decls

[Franz Sirl]

At 03:10 20.09.2001, DJ Delorie wrote:

> > However, please follow the directions of the comment and remove the
> > special case from pop_level_1.  Also update the documentation such
> > that "deprecated" is now "illegal".
>
>It took a while to get the right warnings for flexible vs zero-length
>arrays, and I had to adjust some of the test cases to detect the right
>warnings, but here it all is.  No regressions on x86 linux.
>
>2001-09-19  DJ Delorie  <dj@redhat.com>
>
>         * c-typeck.c (really_start_incremental_init): Discriminate
>         between zero-length arrays and flexible arrays.
>         (push_init_level): Detect zero-length arrays and handle them
>         like fixed-sized arrays.
>         * expr.c (store_constructor): Handle zero-length arrays and
>         flexible arrays correctly.
>         * doc/extend.texi: Update zero-length array notes.
>
>2001-09-19  DJ Delorie  <dj@redhat.com>
>
>         * gcc.dg/20000926-1.c: Update expected warning messages.
>         * gcc.dg/array-2.c: Likewise, and test for warnings too.
>         * gcc.dg/array-4.c: Likewise, and don't verify the zero-length
>         array.

What about the XFAIL in gcc.dg/array-5.c?

Franz.

Re: host_integerp vs [] decls

[DJ Delorie]

> What about the XFAIL in gcc.dg/array-5.c?

It still xfails.

Re: host_integerp vs [] decls

[Richard Henderson]

On Wed, Sep 19, 2001 at 09:10:02PM -0400, DJ Delorie wrote:
> 	* c-typeck.c (really_start_incremental_init): Discriminate
> 	between zero-length arrays and flexible arrays.
> 	(push_init_level): Detect zero-length arrays and handle them
> 	like fixed-sized arrays.
> 	* expr.c (store_constructor): Handle zero-length arrays and
> 	flexible arrays correctly.
> 	* doc/extend.texi: Update zero-length array notes.

Ok, except, 

> 	* gcc.dg/array-4.c: Likewise, and don't verify the zero-length
> 	array.

Just delete the zero-length bits here.


r~

Re: host_integerp vs [] decls

[DJ Delorie]

> On Wed, Sep 19, 2001 at 09:10:02PM -0400, DJ Delorie wrote:
> > 	* c-typeck.c (really_start_incremental_init): Discriminate
> > 	between zero-length arrays and flexible arrays.
> > 	(push_init_level): Detect zero-length arrays and handle them
> > 	like fixed-sized arrays.
> > 	* expr.c (store_constructor): Handle zero-length arrays and
> > 	flexible arrays correctly.
> > 	* doc/extend.texi: Update zero-length array notes.
> 
> Ok, except, 
> 
> > 	* gcc.dg/array-4.c: Likewise, and don't verify the zero-length
> > 	array.
> 
> Just delete the zero-length bits here.

Ok.  Done.  Thanks!

Re: host_integerp vs [] decls

[Zack Weinberg]

On Wed, Sep 19, 2001 at 01:36:11PM -0700, Richard Henderson wrote:
> Also update the documentation such that "deprecated" is now
> "illegal".

Didn't we decide that "invalid" was preferred to "illegal"?

zw

Re: host_integerp vs [] decls

[DJ Delorie]

> Didn't we decide that "invalid" was preferred to "illegal"?

Neither ended up in the docs.  The new wording is this:

  Non-empty initialization of zero-length arrays is now treated like
  any case where there are more initializer elements than the array
  holds, in that a suitable warning about "excess elements in array"
  is given, and the excess elements (all of them, in this case) are
  ignored.

Re: host_integerp vs [] decls

[Richard Kenner]

    Another `obvious' fix is to have host_integerp return false when given
    NULL.  Not sure if that would fix or hide other problems ;-)

I think it would hide other problems.