Bug 42387 - [4.4/4.5 Regression] ICE with new expression in class template
Summary: [4.4/4.5 Regression] ICE with new expression in class template
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 4.2.2
: P2 normal
Target Milestone: 4.4.3
Assignee: Jason Merrill
URL:
Keywords: ice-on-valid-code
Depends on:
Blocks:
 
Reported: 2009-12-16 00:02 UTC by Parviz Fariborz
Modified: 2009-12-16 18:03 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work: 4.3.4
Known to fail: 4.4.1 4.4.2 4.5.0
Last reconfirmed: 2009-12-16 14:13:46


Attachments
The output of -save-temps gcc switch (7.59 KB, text/plain)
2009-12-16 00:05 UTC, Parviz Fariborz
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Parviz Fariborz 2009-12-16 00:02:56 UTC
Version :

cape1:/home/parvizf/tmp=> /tools/linux64/gcc-4.4.2/bin/gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu

Compile command line output :

cape1:/home/parvizf/tmp/gcc_buf> /tools/linux64/gcc-4.4.2/bin/gcc -o test -Wall -save-temps test.cc
test.cc: In constructor ‘AvlTreeIter<PF>::AvlTreeIter(const AvlTree<PF>*)’:
test.cc:48: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
Comment 1 Parviz Fariborz 2009-12-16 00:05:33 UTC
Created attachment 19315 [details]
The output of -save-temps gcc switch
Comment 2 Paolo Carlini 2009-12-16 00:53:43 UTC
Gosh, this is enough. The ICE disappears if AvlTreeIter isn't a template:

template<class PF>
struct AvlTreeIter
{
  int Num();

  AvlTreeIter()
  {
    new (void* [Num()]);
  }
};
Comment 3 Paolo Carlini 2009-12-16 01:10:49 UTC
In mainline the ICE happens like this:

#0  0x00000000007613e0 in fold_convert_loc (loc=0, type=0x7ffff7e9f000, arg=0x7ffff7e8d9f0) at ../../trunk/gcc/fold-const.c:2629
#1  0x000000000075aa5f in associate_trees (loc=0, t1=0x7ffff7e8d9f0, t2=0x7ffff7e8a690, code=PLUS_EXPR, type=0x7ffff7e9f000) at ../../trunk/gcc/fold-const.c:1598
#2  0x00000000007aa3f0 in fold_binary_loc (loc=0, code=PLUS_EXPR, type=0x7ffff7e9f000, op0=0x7ffff7fc10a8, op1=0x7ffff7e8a758) at ../../trunk/gcc/fold-const.c:10678
#3  0x00000000007e6b97 in fold_build2_stat_loc (loc=0, code=PLUS_EXPR, type=0x7ffff7e9f000, op0=0x7ffff7fc10a8, op1=0x7ffff7e8a758) at ../../trunk/gcc/fold-const.c:14460
#4  0x00000000007a34e1 in fold_binary_loc (loc=0, code=PLUS_EXPR, type=0x7ffff7e9f000, op0=0x7ffff7e8a758, op1=0x7ffff7fc10a8) at ../../trunk/gcc/fold-const.c:10095
#5  0x00000000007e6b97 in fold_build2_stat_loc (loc=0, code=PLUS_EXPR, type=0x7ffff7e9f000, op0=0x7ffff7e8a758, op1=0x7ffff7fc10a8) at ../../trunk/gcc/fold-const.c:14460
#6  0x000000000075d6e1 in size_binop_loc (loc=0, code=PLUS_EXPR, arg0=0x7ffff7e8a758, arg1=0x7ffff7fc10a8) at ../../trunk/gcc/fold-const.c:2183
#7  0x000000000093f329 in layout_type (type=0x7ffff5b38498) at ../../trunk/gcc/stor-layout.c:1975
#8  0x0000000000591b88 in complete_type (type=0x7ffff5b38498) at ../../trunk/gcc/cp/typeck.c:118
#9  0x0000000000591e69 in complete_type_or_else (type=0x0, value=0x7ffff7e9f000) at ../../trunk/gcc/cp/typeck.c:142
#10 0x00000000005afc6a in build_new (placement=0x7fffffffd440, type=0x7ffff5b38498, nelts=0x0, init=0x7fffffffd438, use_global_new=-135663616, complain=3) at ../../trunk/gcc/cp/init.c:2389
#11 0x00000000005707c6 in cp_parser_new_expression (parser=0x7ffff5b37000) at ../../trunk/gcc/cp/parser.c:5783
...
Comment 4 Jakub Jelinek 2009-12-16 10:10:51 UTC
Caused by PR28879 fix:
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144988
Comment 5 Jakub Jelinek 2009-12-16 10:44:52 UTC
This exact spot of ICE can be fixed with e.g.:
--- init.c.jj 2009-12-02 09:37:36.000000000 +0100
+++ init.c 2009-12-16 11:32:52.000000000 +0100
@@ -2386,7 +2386,16 @@ build_new (VEC(tree,gc) **placement, tre
   /* The type allocated must be complete.  If the new-type-id was
      "T[N]" then we are just checking that "T" is complete here, but
      that is equivalent, since the value of "N" doesn't matter.  */
-  if (!complete_type_or_else (type, NULL_TREE))
+  if (processing_template_decl
+      && TREE_CODE (type) == ARRAY_TYPE
+      && TYPE_DOMAIN (type)
+      && TYPE_MAX_VALUE (TYPE_DOMAIN (type))
+      && TREE_SIDE_EFFECTS (TYPE_MAX_VALUE (TYPE_DOMAIN (type))))
+    {
+      if (!complete_type_or_else (TREE_TYPE (type), NULL_TREE))
+        return error_mark_node;
+    }
+  else if (!complete_type_or_else (type, NULL_TREE))
     return error_mark_node;
 
   rval = build_new_1 (placement, type, nelts, init, use_global_new, complain);

but then we ICE in array_type_nelts_top called from build_new_1.  So, either when processing_template_decl and TYPE_MAX_VALUE of ARRAY_TYPE's TYPE_DOMAIN has side-effects we just shouldn't call build_new_1, or build_new_1 will need to be prepared for it.
Comment 6 Jason Merrill 2009-12-16 17:36:20 UTC
Subject: Bug 42387

Author: jason
Date: Wed Dec 16 17:36:05 2009
New Revision: 155292

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155292
Log:
	PR c++/42387
	* decl.c (compute_array_index_type): Mark a VLA as dependent.

Added:
    trunk/gcc/testsuite/g++.dg/ext/vla8.C
Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/decl.c
    trunk/gcc/testsuite/ChangeLog

Comment 7 Jason Merrill 2009-12-16 18:02:58 UTC
Subject: Bug 42387

Author: jason
Date: Wed Dec 16 18:02:38 2009
New Revision: 155293

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155293
Log:
	PR c++/42387
	* decl.c (compute_array_index_type): Mark a VLA as dependent.

Added:
    branches/gcc-4_4-branch/gcc/testsuite/g++.dg/ext/vla8.C
Modified:
    branches/gcc-4_4-branch/gcc/cp/ChangeLog
    branches/gcc-4_4-branch/gcc/cp/decl.c
    branches/gcc-4_4-branch/gcc/testsuite/ChangeLog

Comment 8 Jason Merrill 2009-12-16 18:03:20 UTC
Fixed.