Created attachment 28533 [details] preprocessed source attached source produces an ICE with gcc-4.7, but not with gcc-4.6: home/tim/workspace/supercollider/server/supernova/./audio_backend/upsampled_audio_backend.hpp: In lambda function: /home/tim/workspace/supercollider/server/supernova/./audio_backend/upsampled_audio_backend.hpp:59:67: internal compiler error: Segmentation fault gcc -v Using built-in specs. COLLECT_GCC=/usr/bin/gcc-4.7.real COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.7.2-2ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.7.2 (Ubuntu/Linaro 4.7.2-2ubuntu1)
Please reduce the testcase to a manageable size: we have open quite a few issues about lambdas and most likely this is a duplicate, but it's unnecessarily hard to tell with a 600+ KB attachment.
Testcase was over 7.1 Mbyte, but parallel creduce is quick. markus@x4 tmp % cat test.ii void src_new (int); template < bool > struct A { void prepare () { ([=] { src_new (con); }); } int con; }; markus@x4 tmp % g++ -std=c++11 -c test.ii test.ii: In lambda function: test.ii:6:28: internal compiler error: Segmentation fault ([=] { src_new (con); }); ^
Indeed. Thanks Markus! Next, whether it's actually a (more or less manifest) dup.
Valgrind says: markus@x4 tmp % /var/tmp/gcc_valgrind/usr/local/bin/g++ -std=c++11 -c test.ii ==10632== Invalid read of size 2 ==10632== at 0x668622: lvalue_kind(tree_node const*) (tree.c:148) ==10632== by 0x668803: lvalue_kind(tree_node const*) (tree.c:103) ==10632== by 0x6691C8: lvalue_p(tree_node const*) (tree.c:269) ==10632== by 0x4CF7EC: standard_conversion(tree_node*, tree_node*, tree_node*, bool, int) (call.c:1104) ==10632== by 0x4D5629: implicit_conversion(tree_node*, tree_node*, tree_node*, bool, int, int) (call.c:1696) ==10632== by 0x4D7702: add_function_candidate(z_candidate**, tree_node*, tree_node*, tree_node*, vec_t<tree_node*> const*, tree_node*, tree_node*, int, int) (call.c:1987) ==10632== by 0x4D3EEE: add_candidates(tree_node*, tree_node*, vec_t<tree_node*> const*, tree_node*, tree_node*, bool, tree_node*, tree_node*, int, z_candidate**, int) (call.c:4954) ==10632== by 0x4DA7B0: perform_overload_resolution(tree_node*, vec_t<tree_node*> const*, z_candidate**, bool*, int) (call.c:3807) ==10632== by 0x4E0D5C: build_new_function_call(tree_node*, vec_t<tree_node*>**, bool, int) (call.c:3884) ==10632== by 0x656EEA: finish_call_expr(tree_node*, vec_t<tree_node*>**, bool, bool, int) (semantics.c:2190) ==10632== by 0x5CEA2E: cp_parser_postfix_expression(cp_parser*, bool, bool, bool, cp_id_kind*) (parser.c:5814) ==10632== by 0x5D9D32: cp_parser_unary_expression(cp_parser*, bool, bool, cp_id_kind*) (parser.c:6682) ==10632== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==10632==
probably bug 54403
(In reply to comment #5) > probably bug 54403 Yes. Valgrind backtrace is the same.
What about the following naïve patch? At least it fixes the problem and causes no new test suite regressions. diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c index 8d555c2..0f1a75d 100644 --- a/gcc/cp/tree.c +++ b/gcc/cp/tree.c @@ -145,7 +145,7 @@ lvalue_kind (const_tree ref) case ARRAY_REF: case PARM_DECL: case RESULT_DECL: - if (TREE_CODE (TREE_TYPE (ref)) != METHOD_TYPE) + if (TREE_TYPE (ref) && TREE_CODE (TREE_TYPE (ref)) != METHOD_TYPE) return clk_ordinary; break;
I think that at some point I had the same trick in my local tree too, then I don't remember sending it to the mailing list, not even as a RFC. I think you should, CC Jason, and ask whether is it possible that at that point TREE_TYPE is not set or the check would just paper over the real issue.
Fixed mainline and 4.7.3. *** This bug has been marked as a duplicate of bug 54122 ***