This didn't happen with 4.2 20061015. It happens with mainline but I cannot check the 4.2 branch right now. (sid)978:tbm@coconut: ~] /usr/lib/gcc-snapshot/bin/gcc -c pasmo-asm.cc pasmo-asm.cc:77: warning: 'Asm::In' has a field 'Asm::In::nullout' whose type uses the anonymous namespace (sid)979:tbm@coconut: ~] /usr/lib/gcc-snapshot/bin/gcc -c -O pasmo-asm.cc pasmo-asm.cc:77: warning: 'Asm::In' has a field 'Asm::In::nullout' whose type uses the anonymous namespace pasmo-asm.cc: In constructor '<unnamed>::Nullostream::Nullostream()': pasmo-asm.cc:64: internal compiler error: tree check: expected ssa_name, have var_decl in is_old_name, at tree-into-ssa.c:558 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions.
Created attachment 12487 [details] testcase
Here is a more reduced (and cleaned up) testcase: class ios_base{}; struct basic_ostream : virtual ios_base{}; namespace { struct Nullostream : basic_ostream{}; } class In { In (); Nullostream nullout; }; In::In (){} This is an interaction between aliasing and anonymous namespaces.
Confirmed.
_ZTCN33_GLOBAL__N_t.cc_00000000_2292CFAC11NullostreamE0_13basic_ostream # _ZTI13basic_ostream = V_MAY_DEF <_ZTI13basic_ostream_16>; # _ZTIN33_GLOBAL__N_t.cc_00000000_2292CFAC11NullostreamE = V_MAY_DEF <_ZTIN33_GLOBAL__N_t.cc_00000000_2292CFAC11NullostreamE_17>; # _ZTCN33_GLOBAL__N_t.cc_00000000_2292CFAC11NullostreamE0_13basic_ostream = V_MAY_DEF <_ZTCN33_GLOBAL__N_t.cc_00000000_2292CFAC11NullostreamE0_13basic_ostream>; # _ZTSN33_GLOBAL__N_t.cc_00000000_2292CFAC11NullostreamE = V_MAY_DEF <_ZTSN33_GLOBAL__N_t.cc_00000000_2292CFAC11NullostreamE>; # _ZTVN10__cxxabiv120__si_class_type_infoE = V_MAY_DEF <_ZTVN10__cxxabiv120__si_class_type_infoE>; # _ZTI8ios_base = V_MAY_DEF <_ZTI8ios_base>; # _ZTS13basic_ostream = V_MAY_DEF <_ZTS13basic_ostream>; # _ZTVN10__cxxabiv121__vmi_class_type_infoE = V_MAY_DEF <_ZTVN10__cxxabiv121__vmi_class_type_infoE>; # _ZTS8ios_base = V_MAY_DEF <_ZTS8ios_base>; # _ZTVN10__cxxabiv117__class_type_infoE = V_MAY_DEF <_ZTVN10__cxxabiv117__class_type_infoE>; # SFT.5 = V_MAY_DEF <SFT.5>; # SFT.6 = V_MAY_DEF <SFT.6>; # SFT.7 = V_MAY_DEF <SFT.7>; # SFT.8 = V_MAY_DEF <SFT.8>; # SFT.9 = V_MAY_DEF <SFT.9>; # NONLOCAL.15 = V_MAY_DEF <NONLOCAL.15>; this_9->_vptr.basic_ostream = iftmp.1_13;
Subject: Re: [4.2/4.3 Regression] tree check: expected ssa_name, have var_decl in is_old_name, at tree-into-ssa.c:558 On 25 Oct 2006 05:23:00 -0000, pinskia at gcc dot gnu dot org <gcc-bugzilla@gcc.gnu.org> wrote: > > > ------- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-25 05:22 ------- > _ZTCN33_GLOBAL__N_t.cc_00000000_2292CFAC11NullostreamE0_13basic_ostream > > # _ZTI13basic_ostream = V_MAY_DEF <_ZTI13basic_ostream_16>; > # _ZTIN33_GLOBAL__N_t.cc_00000000_2292CFAC11NullostreamE = V_MAY_DEF > <_ZTIN33_GLOBAL__N_t.cc_00000000_2292CFAC11NullostreamE_17>; > # _ZTCN33_GLOBAL__N_t.cc_00000000_2292CFAC11NullostreamE0_13basic_ostream = > V_MAY_DEF > <_ZTCN33_GLOBAL__N_t.cc_00000000_2292CFAC11NullostreamE0_13basic_ostream>; > # _ZTSN33_GLOBAL__N_t.cc_00000000_2292CFAC11NullostreamE = V_MAY_DEF > <_ZTSN33_GLOBAL__N_t.cc_00000000_2292CFAC11NullostreamE>; > # _ZTVN10__cxxabiv120__si_class_type_infoE = V_MAY_DEF > <_ZTVN10__cxxabiv120__si_class_type_infoE>; > # _ZTI8ios_base = V_MAY_DEF <_ZTI8ios_base>; > # _ZTS13basic_ostream = V_MAY_DEF <_ZTS13basic_ostream>; > # _ZTVN10__cxxabiv121__vmi_class_type_infoE = V_MAY_DEF > <_ZTVN10__cxxabiv121__vmi_class_type_infoE>; > # _ZTS8ios_base = V_MAY_DEF <_ZTS8ios_base>; > # _ZTVN10__cxxabiv117__class_type_infoE = V_MAY_DEF > <_ZTVN10__cxxabiv117__class_type_infoE>; > # SFT.5 = V_MAY_DEF <SFT.5>; > # SFT.6 = V_MAY_DEF <SFT.6>; > # SFT.7 = V_MAY_DEF <SFT.7>; > # SFT.8 = V_MAY_DEF <SFT.8>; > # SFT.9 = V_MAY_DEF <SFT.9>; > # NONLOCAL.15 = V_MAY_DEF <NONLOCAL.15>; > this_9->_vptr.basic_ostream = iftmp.1_13; > > Uh, this is pretty weird. *all* of these should have been marked for renaming, not just NONLOCAL.
*** Bug 29908 has been marked as a duplicate of this bug. ***
Here is another reduced testcase: struct iunknown { virtual ~iunknown() {} }; class ifile_format : virtual iunknown{}; namespace { struct imagemagick_reader : ifile_format{}; } void imagemagick_reader_factory() { imagemagick_reader a; }
symbol_marked_for_renaming is returning false. Symbols to be put in SSA form _ZTI13basic_ostream _ZTIN12_GLOBAL__N_111NullostreamE _ZTSN12_GLOBAL__N_111NullostreamE _ZTVN10__cxxabiv120__si_class_type_infoE _ZTI8ios_base _ZTS13basic_ostream _ZTVN10__cxxabiv121__vmi_class_type_infoE _ZTS8ios_base _ZTVN10__cxxabiv117__class_type_infoE SFT.5 SFT.6 SFT.7 SFT.8 SFT.9 NONLOCAL.15 SMT.16 NMT.17 NMT.18 (gdb) p debug_generic_expr (name) _ZTCN12_GLOBAL__N_111NullostreamE0_13basic_ostreamD.2726 I think the loop in setup_pointers_and_addressables is where the problem is. Still looking into it some more.
*** Bug 30316 has been marked as a duplicate of this bug. ***
The testcase in comment #2 works for me on the 4.2 branch now, but the one in comment #7 fails with > ./cc1plus -quiet t.ii -O t.ii: In destructor 'virtual<unnamed>::imagemagick_reader::~imagemagick_reader()': t.ii:7: internal compiler error: in set_lattice_value, at tree-ssa-ccp.c:434 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions.
(In reply to comment #10) > The testcase in comment #2 works for me on the 4.2 branch now, but the one in > comment #7 fails with > > t.ii:7: internal compiler error: in set_lattice_value, at tree-ssa-ccp.c:434 Yeah, I mentioned this problem in PR29908 already and Pinski closed it as a duplicate of this bug. PR29908 has another testcase from Andrew and some comments.
This is similar to PR30840 on the mainline - evaluate_stmt does not care about us possibly going up the lattice (in this case from VARYING to CONSTANT).
I can't reproduce this on mainline anymore. It does fail on the 4.2 branch.
Subject: Bug 29585 Author: dnovillo Date: Sat Mar 31 19:21:46 2007 New Revision: 123386 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123386 Log: 2007-03-31 Diego Novillo <dnovillo@redhat.com> Mark Mitchell <mark@codesourcery.com> PR 29585 * class.c (dfs_accumulate_vtbl_inits): Use build_address to build the vtbl entry. testsuite/ChangeLog PR 29585 * g++.dg/tree-ssa/pr29585.C: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/tree-ssa/pr29585.C Modified: branches/gcc-4_2-branch/gcc/cp/ChangeLog branches/gcc-4_2-branch/gcc/cp/class.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog
Fixed. http://gcc.gnu.org/ml/gcc-patches/2007-03/msg02059.html
I think this patch breaks: FAIL: g++.old-deja/g++.mike/p4736b.C (internal compiler error) FAIL: g++.old-deja/g++.mike/p4736b.C (test for excess errors) on powerpc-apple-darwin: /Volumes/mrs3/net/gcc-4.2-fsf/gcc/gcc/testsuite/g++.old-deja/g++.mike/p4736b.C: In function 'i nt main()': /Volumes/mrs3/net/gcc-4.2-fsf/gcc/gcc/testsuite/g++.old-deja/g++.mike/p4736b.C:41: internal co mpiler error: in convert_memory_address, at explow.c:319 :-( radr://5107167
The followup problem has now been fixed in 4.2.