[Bug c++/11228] New: ICE on new-expression using array operator new and default-initialization

["austern at apple dot com" <gcc-bugzilla@gcc.gnu.org>]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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

           Summary: ICE on new-expression using array operator new and
                    default-initialization
           Product: gcc
           Version: 3.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: austern@apple.com
                CC: gcc-bugs@gcc.gnu.org
 GCC build triplet: i686-pc-linux-gnu/
  GCC host triplet: i686-pc-linux-gnu/
GCC target triplet: i686-pc-linux-gnu/

Compile the following translation unit with 3.3:
struct MDSWeight { };

void foo(int numWeights)
{
  new MDSWeight[numWeights]();
}

If the compiler is configured with --enable-checking, this causes an internal compiler error:
foo.cc:5: internal compiler error: tree check: expected integer_cst, have 
   non_lvalue_expr in tree_int_cst_lt, at tree.c:3180

If the compiler is configured without checking the behavior is even less friendly: an infinite loop, 
with the compiler allocating more and more memory.

I believe that the code above is legal.  (Although admittedly it would be more natural not to write 
the parentheses.)  The syntax of a new-expression is given in clause 5.3.4, paragraph 1.  
"MDSWeight[numWeights]" is a new-type-id ("MDSWeight" is a type-specifier-seq and 
"[numWeights]" is a direct-new-declarator.  "()" is a valid new-initializer.  Clause 5.3.4, paragraph 
15, describes the semantics of the new-initializer, referring to clause 8.5.  Nothing in 5.3.4/15 or 
8.5 suggests that it's illegal to explicitly request default initialization when using array operator 
new.

Note that the ICE is a regression from 2.95 (which accepts this construct) and from 3.1/3.2 (which 
reject it with an error).