The following invalid code snippet triggers an ICE on mainline: ================================================= template<typename T, int = T()[0]> struct A { typedef A<T> B; }; ================================================= bug.cc:3: internal compiler error: Segmentation fault Please submit a full bug report, [etc.] The code is accepted by GCC 4.2.x and older.
I don't get an ICE with the trunk as of today: Sat Dec 8 19:47:21 UTC 2007 (revision 130710)
If I add: A<int> a; The code is rejected: t.cc:7: error: subscripted value is neither array nor pointer t.cc:7: error: template argument 2 is invalid t.cc:7: error: invalid type in declaration before ';' token
Well, I'm using the version from 2007-12-06, and since then nothing C++ related has been checked in.
What target is this on?
> What target is this on? i686-pc-linux-gnu. I can see the ICE since at least 2007-05-13 on mainline (I don't have any older mainline versions around).
Also crashes on x86_64-unknown-linux-gnu.
It works for me on "i386-apple-darwin8.10.1" with: GNU C++ (GCC) version 4.3.0 20071209 (experimental) [trunk revision 130717] (i386-apple-darwin8.10.1)
It also works for me with: GNU C++ (GCC) version 4.3.0 20071205 (experimental) [trunk revision 130629] (spu-elf) Are you sure you don't have a modified compiler?
> Are you sure you don't have a modified compiler? Pretty sure. I bootstrapped a really clean one ("svn diff --no-ignore" showed nothing) last night on i686-pc-linux-gnu. It still shows the segfault. The x86_64-unknown-linux-gnu compiler was bootstrapped without modifications from a snapshot. It's a little older, though (2007-11-16).
I still cannot reproduce this.
Can confirm on i686 linux: [~]> g++ test.cpp test.cpp:3: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <http://bugs.pardus.org.tr> for instructions. [~]> g++ -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc/4.3.0 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.3.0/include --datadir=/usr/share/gcc/i686-pc-linux-gnu/4.3.0 --mandir=/usr/share/gcc/i686-pc-linux-gnu/4.3.0/man --infodir=/usr/share/gcc/i686-pc-linux-gnu/4.3.0/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.3.0/include/g++-v3 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-libgcj --disable-libssp --disable-multilib --disable-nls --disable-werror --disable-mudflap --disable-libmudflap --enable-checking=release --enable-clocale=gnu --enable-__cxa_atexit --enable-languages=c,c++,fortran,objc --enable-libstdcxx-allocator=new --enable-shared --enable-ssp --enable-threads=posix --enable-version-specific-runtime-libs --without-included-gettext --without-system-libunwind --with-system-zlib --with-pkgversion='Pardus Linux' --with-bugurl=http://bugs.pardus.org.tr Thread model: posix gcc version 4.3.0 20071225 [trunk revision 131170] (Pardus Linux)
Also confirmed on x86_64-pc-linux-gnu: Program received signal SIGSEGV, Segmentation fault. find_parameter_packs_r (tp=0x2aaaadfef5e0, walk_subtrees=0x7fff62fefdec, data=0x7fff62ff0050) at ../../gcc-svn/trunk/gcc/cp/pt.c:2460 2460 switch (TREE_CODE (t)) (gdb) bt #0 find_parameter_packs_r (tp=0x2aaaadfef5e0, walk_subtrees=0x7fff62fefdec, data=0x7fff62ff0050) at ../../gcc-svn/trunk/gcc/cp/pt.c:2460 #1 0x00000000009b140d in walk_tree_1 (tp=0x2aaaadfef5e0, func=0x4459c0 <find_parameter_packs_r>, data=0x7fff62ff0050, pset=0x0, lh=0x52d8d0 <cp_walk_subtrees>) at ../../gcc-svn/trunk/gcc/tree.c:8376 #2 0x00000000009b154f in walk_tree_1 (tp=0x2aaaae129c30, func=0x4459c0 <find_parameter_packs_r>, data=0x7fff62ff0050, pset=0x0, lh=0x52d8d0 <cp_walk_subtrees>) at ../../gcc-svn/trunk/gcc/tree.c:8615 #3 0x00000000009b1664 in walk_tree_1 (tp=0x2aaaae12ed48, func=0x4459c0 <find_parameter_packs_r>, data=0x7fff62ff0050, pset=0x0, lh=0x52d8d0 <cp_walk_subtrees>) at ../../gcc-svn/trunk/gcc/tree.c:8436 #4 0x0000000000445ac9 in find_parameter_packs_r (tp=0x2aaaae138a98, walk_subtrees=0x7fff62ff000c, data=0x7fff62ff0050) at ../../gcc-svn/trunk/gcc/cp/pt.c:2575 #5 0x00000000009b140d in walk_tree_1 (tp=0x2aaaae138a98, func=0x4459c0 <find_parameter_packs_r>, data=0x7fff62ff0050, pset=0x0, lh=0x52d8d0 <cp_walk_subtrees>) at ../../gcc-svn/trunk/gcc/tree.c:8376 #6 0x00000000004450ff in check_for_bare_parameter_packs (t=0x2aaaae138a98) at ../../gcc-svn/trunk/gcc/cp/pt.c:2751 #7 0x000000000044eda8 in push_template_decl_real (decl=0x2aaaae138a80, is_friend=0 '\0') at ../../gcc-svn/trunk/gcc/cp/pt.c:3885 #8 0x00000000004aa265 in grokfield (declarator=<value optimized out>, declspecs=<value optimized out>, init=<value optimized out>, (gdb) print t $1 = (tree) 0x41 Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc-svn/trunk/configure --enable-languages=c,c++,fortran --enable-checking Thread model: posix gcc version 4.3.0 20071222 (experimental) [trunk revision 131134] (GCC)
For some reason it works correctly on i386-apple-darwin and powerpc-linux-gnu. I wonder if something is not miscompiling the C++ front-end.
(In reply to comment #13) > For some reason it works correctly on i386-apple-darwin and powerpc-linux-gnu. > I wonder if something is not miscompiling the C++ front-end. No, I have build non-bootstrapped gcc with gcc-4.1 and it still shows the same problem. Adding a "debug_tree (t)" at the top of find_parameter_packs_r() in cp/pt.c results in: <array_ref 0x2aaaadfef5a0 arg 0 <cast_expr 0x2aaaae129c40 type <template_type_parm 0x2aaaae1383c0 T type_0 type_6 VOID align 8 symtab 0 alias set -1 canonical type 0x2aaaae1383c0 index 0 level 1 orig_level 1 chain <type_decl 0x2aaaae138480 T>> side-effects> arg 1 <integer_cst 0x2aaaae00b480 type <integer_type 0x2aaaadffd540 int> constant invariant 0> arg 2 <integer_cst 0x2aaaae00b480 0>pr34397.cpp:3: internal compiler error: Segmentation fault <...> The segfault now points to: Program received signal SIGSEGV, Segmentation fault. print_node (file=0x30d1948860, prefix=0x7fffc27c5510 "arg 3", node=0x17, indent=4) at ../../gcc-svn/trunk/gcc/print-tree.c:197 197 code = TREE_CODE (node); So, we can conclude that something is wrong with arg 3 of ARRAY_REF expr. Perhaps it is left uninitialized?
(In reply to comment #14) > So, we can conclude that something is wrong with arg 3 of ARRAY_REF expr. > Perhaps it is left uninitialized? Probably it is not OK to build ARRAY_REF expr using build_x_binary_op(). Could a c++ expert check this usage in cp/pt.c, around line 10823?
Then this has been a bug since 4.0.0 when array ref was changed to be a 4 operand expression.
I would expect pt.c to call grok_array_decl (which is the same function called by the parser), not build_x_binary_op.
Closing 4.1 branch.
Indeed, in my experiments the problem seems due to build_min_nt not passing NULL_TREEs as called by build_x_binary_op. The patch I'm going to attach then works, in the sense that the testcase compiles (and then an error is emitted in case of instantiation). I also tried calling directly grok_array_decl from tsubst_copy_and_build, and indeed that largely works (but note that, for some reason, the grok_* functions, called by the parser, are not called often in pt.c, many build_x_* functions instead), but there are subtle issues, like sfinae7.C failing...
Created attachment 17246 [details] draft, showing that the missing NULL_TREEs are indeed an issue
Paolo -- My earlier suggestion to try grok_array_decl may indeed have been misguided. Some of the grok_* functions do more parser-style analysis than we want when processing templates. In theory, the way this ought to work is that we parse for a while, until we know what the user meant, and then call a function that actually generates code. When processing a template, we call that same underlying function after substitution. But, in practice, we may not always have organized things that tidily. In that case, the best fix is to factor out syntactic dismabiguation bits from grok_array_decl, and make a new underlying function that is called from both the parser and the template machinery. -- Mark
Many thanks Mark for your detailed feedback on this PR and the other one. I'll try to work along the lines you suggested.
Mark, can you have a closer look to the draft patch? I'm still looking but I don't think we can extract and commonize much code from grok_array_decl, unless we accept to pass from the callers an in_parser flag, or use a function pointer, I can see only such rather ugly solutions...
Subject: Re: [4.2/4.3/4.4 regression] ICE on invalid default template parameter paolo dot carlini at oracle dot com wrote: > Mark, can you have a closer look to the draft patch? I'm still looking but I > don't think we can extract and commonize much code from grok_array_decl, unless > we accept to pass from the callers an in_parser flag, or use a function > pointer, I can see only such rather ugly solutions... You may well be right. Your draft patch looks plausible. Thanks,
Thanks. I'll try to submit something more polished along these lines...
Subject: Bug 34397 Author: paolo Date: Tue Feb 10 21:47:12 2009 New Revision: 144083 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144083 Log: /cp 2009-02-10 Paolo Carlini <paolo.carlini@oracle.com> PR c++/34397 * typeck.c (build_x_array_ref): New. * cp-tree.h: Declare it. * pt.c (tsubst_copy_and_build): Use it for case ARRAY_REF. /testsuite 2009-02-10 Paolo Carlini <paolo.carlini@oracle.com> PR c++/34397 * g++.dg/template/crash88.C: New. * g++.dg/template/crash89.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/template/crash88.C trunk/gcc/testsuite/g++.dg/template/crash89.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/pt.c trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog
Fixed for 4.4.0.
Closing 4.2 branch.
WONTFIX for 4.3.