🚀 go-pugleaf

The following bug exists in both gcc v2.3.1, as well as in snapshot 921106, on  
a 68040 NeXT running NeXTSTEP v3.0.  Both versions of gcc [v2.3.1 and ss921106]  
were built with gcc v2.3.1 with optimization level 2, but in no other way  
deviated from the standard installation process:

monolith[NeXT]% cat test.c
enum { NUM = 5 };

int bad_array[] = { [NUM] 9 };
int good_array[] = { [5] 9 };
int another_good_array[] = { [4 + 1] 9 };

monolith[NeXT]% gcc -c test.c
test.c:3: non-constant array index in initializer

[NOTE: this bug had been previously reported by mjhostet@athena.mit.edu in 

[message <9211022214.AA05706@slayer.MIT.EDU>.

the following diff [made from the ss921106 source.  this code has not changed  
since 2.3.1 release, so the diff would be the same minus date modification  
times].

monolith[NeXT]# diff -c c-typeck.c c-typeck.c.orig 

*** c-typeck.c  Sat Nov  7 15:56:55 1992
--- c-typeck.c.orig     Sat Nov  7 15:56:36 1992
***************
*** 4970,4976 ****
              int win = 0;
              tree index = TREE_PURPOSE (tail);
  

!             if (index && (TREE_CODE (index) == NON_LVALUE_EXPR || TREE_CODE  
(index) == NOP_EXPR))
                index = TREE_OPERAND (index, 0);
  

              /* Begin a range.  */
--- 4970,4976 ----
              int win = 0;
              tree index = TREE_PURPOSE (tail);
  

!             if (index && TREE_CODE (index) == NON_LVALUE_EXPR)
                index = TREE_OPERAND (index, 0);
  

              /* Begin a range.  */

in the case of ENUMS, the tree code is NON_EXPR, so this code merely exposes  
the constant residing in the operand portion of the index tree node.

NOTE: this does not deal with problems in the range array initialization,  
including its failure to handle enums in the ranges.