this code is from the package arts, preprocessed and reduced. The bug may be reproduced with # g++ -c mcop.ii mcop.ii: In member function 'std::vector<std::string, std::allocator<std::string> > Arts::InterfaceRepo_base::_ZTv0_n12_NK4Arts18InterfaceRepo_base15_defaultPortsInEv() const': mcop.ii:134: internal compiler error: in cp_expr_size, at cp/cp-objcp-common.c:101
Created attachment 8689 [details] testcase
This works on the mainline.
I just tested on a compiler without additional patches at all. The version is g++ (GCC) 4.0.0 20050415, means CVS from april 15th. I still get the same bug.
// Confirmed, smaller testcase: struct U { U (); U (const U&); }; struct T { U u; }; struct V : T { int operator= (V &__x); }; struct A { virtual V foo() const; }; struct B : virtual public A { virtual V foo() const; }; V B::foo() const { V ret; return ret; }
Another small testcase (failed on arm-elf, 4.0.0) struct A { A( const A &a); const A& operator=( const A& a); }; struct B { virtual A f(); }; struct C : virtual B { virtual A f(); A a; }; A C::f() { return a; }
Meetoo :-( Note that the bug is on hppa2.0w-hp-hpux11.11 but not on i686-pc-linux-gnu. (And on HP 3.4.3 works but 4.0.1 doesn't.)
Subject: Re: [4.0 regression] ICE in cp_expr_size, at cp/cp-objcp-common.c:101 > ------- Additional Comments From mki at maconomy dot dk 2005-07-15 = > 16:52 ------- > Meetoo :-( > > Note that the bug is on hppa2.0w-hp-hpux11.11 but not on = > i686-pc-linux-gnu. (And > on HP 3.4.3 works but 4.0.1 doesn't.) I can't duplicate this problem using either the original mcop testcase or the reduced testcase. Are you possibly trying to use the HP assembler? If so, I suggest using gas. Also, make sure that you have a recent linker patch installed. You will get segementation faults linking if the linker isn't updated. There will also be problems with constructors. The HP assembler doesn't have weak support. Dave
I'm using gas from binutils-2.16. But the ICE seems to appear before as is run at all (If the cc1plus command succeeds it will be followed by "/usr/local/binutils-2.16/bin/as -o trauscher.o trauscher.s"). The linker can thus not have any influence either. IMHO ;-) When I'm testing trauscher's example I get the following output, which says "something" about my setup. (11.11 with PHSS_30970 installed). Dave, how does your working configuration look like? -bash-3.00$ /usr/local/gcc-4.0.1/bin/g++ -v -save-temps -c trauscher.cpp Using built-in specs. Target: hppa2.0w-hp-hpux11.11 Configured with: /data/develop/src/gcc-4.0.1/o/../configure --enable-languages=c,c++ --with-gnu-as --without-gnu-ld --with-as=/usr/local/binutils-2.16/bin/as --prefix=/usr/local/gcc-4.0.1 Thread model: single gcc version 4.0.1 /usr/local/gcc-4.0.1/libexec/gcc/hppa2.0w-hp-hpux11.11/4.0.1/cc1plus -E -quiet -v trauscher.cpp -fpch-preprocess -o trauscher.ii ignoring nonexistent directory "/usr/local/gcc-4.0.1/hppa2.0w-hp-hpux11.11/include" #include "..." search starts here: #include <...> search starts here: /usr/local/gcc-4.0.1/include/c++/4.0.1 /usr/local/gcc-4.0.1/include/c++/4.0.1/hppa2.0w-hp-hpux11.11 /usr/local/gcc-4.0.1/include/c++/4.0.1/backward /usr/local/include /usr/local/gcc-4.0.1/include /usr/local/gcc-4.0.1/lib/gcc/hppa2.0w-hp-hpux11.11/4.0.1/include /usr/include End of search list. /usr/local/gcc-4.0.1/libexec/gcc/hppa2.0w-hp-hpux11.11/4.0.1/cc1plus -fpreprocessed trauscher.ii -quiet -dumpbase trauscher.cpp -auxbase trauscher -version -o trauscher.s GNU C++ version 4.0.1 (hppa2.0w-hp-hpux11.11) compiled by GNU C version 4.0.1. GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=130816 trauscher.cpp: In member function 'A C::_ZTv0_n12_N1C1fEv()': trauscher.cpp:20: internal compiler error: in cp_expr_size, at cp/cp-objcp-common.c:101 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions.
Subject: Re: [4.0 regression] ICE in cp_expr_size, at cp/cp-objcp-common.c:101 > I'm using gas from binutils-2.16. But the ICE seems to appear before as = > is run > at all (If the cc1plus command succeeds it will be followed by > "/usr/local/binutils-2.16/bin/as -o trauscher.o trauscher.s"). The = > linker can > thus not have any influence either. IMHO ;-) I wasn't implying that either the linker or the assembler are directly involved. The choice of assembler when GCC is configured affects the defaults for code generation. In particular, when gas is used, there is support for one-only in C++. > When I'm testing trauscher's example I get the following output, which = > says > "something" about my setup. (11.11 with PHSS_30970 installed). > Dave, how does your working configuration look like? > > -bash-3.00$ /usr/local/gcc-4.0.1/bin/g++ -v -save-temps -c trauscher.cpp > Using built-in specs. > Target: hppa2.0w-hp-hpux11.11 > Configured with: /data/develop/src/gcc-4.0.1/o/../configure > --enable-languages=3Dc,c++ --with-gnu-as --without-gnu-ld > --with-as=3D/usr/local/binutils-2.16/bin/as = > --prefix=3D/usr/local/gcc-4.0.1 The setup appears fine. I've enclosed mine below. > Thread model: single I've enabled posix threads. > gcc version 4.0.1 > /usr/local/gcc-4.0.1/libexec/gcc/hppa2.0w-hp-hpux11.11/4.0.1/cc1plus -E = > -quiet > -v trauscher.cpp -fpch-preprocess -o trauscher.ii I wonder if this is a pch problem. Dave -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) Using built-in specs. Target: hppa2.0w-hp-hpux11.11 Configured with: ../gcc/configure --with-gnu-as --with-as=/opt/gnu/bin/as --enable-shared --disable-nls --with-local-prefix=/opt/gnu --prefix=/opt/gnu/gcc/gcc-4.0.1 --enable-debug=no --enable-threads=posix --with-gmp=/opt/gnu/gcc/gcc-4.0.1 --disable-libmudflap --enable-languages=c,c++,objc,f95,java,ada --disable-checking Thread model: posix gcc version 4.0.1 /opt/gnu/gcc/gcc-4.0.1/libexec/gcc/hppa2.0w-hp-hpux11.11/4.0.1/cc1plus -fpreprocessed mcop.ii -quiet -dumpbase mcop.ii -auxbase mcop -version -o /var/tmp//ccGHSXib.s GNU C++ version 4.0.1 (hppa2.0w-hp-hpux11.11) compiled by GNU C version 4.0.1. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 /opt/gnu/bin/as -o mcop.o /var/tmp//ccGHSXib.s
This might be a second-order code generation bug, when I build bootstrap on PA HP-UX I get a GCC that has this problem but when I build all-gcc with GCC 3.4.2 and the -g option I do not see the bug.
Subject: Re: [4.0 regression] ICE in cp_expr_size, at cp/cp-objcp-common.c:101 > This might be a second-order code generation bug, when I build bootstrap = > on PA > HP-UX I get a GCC that has this problem but when I build all-gcc with = > GCC 3.4.2 > and the -g option I do not see the bug. Can you be more specific about the starting compiler when you see the problem? Dave
My starting compiler, both for the all-gcc build which did not have the problem and for the bootstrap build that did have the problem is here: Reading specs from /extra4/be/lib/gcc/hppa1.1-hp-hpux11.00/3.4.2/specs Configured with: /home/sje/be/gcc-3.4.2/configure --host=hppa1.1-hp-hpux11.00 -- target=hppa1.1-hp-hpux11.00 --build=hppa1.1-hp-hpux11.00 --prefix=/extra4/be -- with-gnu-as --with-included-gettext --disable-libmudflap --enable-libunwind- exceptions --with-ld=/usr/ccs/bin/ld --enable-languages=c --disable-shared Thread model: single gcc version 3.4.2 The sources that I was building, in both cases, was of ToT: Using built-in specs. Target: hppa1.1-hp-hpux11.00 Configured with: /extra3/sje/builddir_patch_pa32/gcc/configure --host=hppa1.1- hp-hpux11.00 --target=hppa1.1-hp-hpux11.00 --build=hppa1.1-hp-hpux11.00 -- prefix=/extra3/sje/gcc_patch_pa32 --with-gnu-as --with-included-gettext --with- ld=/usr/ccs/bin/ld --with-gmp=/extra4/be --with-mpfr=/extra4/be Thread model: single gcc version 4.1.0 20050713 (experimental)
Subject: Re: [4.0 regression] ICE in cp_expr_size, at cp/cp-objcp-common.c:101 > My starting compiler, both for the all-gcc build which did not have the = > problem=20 > and for the bootstrap build that did have the problem is here: Not very enlightening. I think the actual fault needs debugging on a system that can reproduce it. Dave
I did some more tests and it looks like --disable-checking also disables the bug. At least --enable-checking was enough to reproduce it. My latest configuration with this bug was Configured with: ../configure --enable-languages=c,c++ --enable-checking Thread model: posix
Hi, Dave, you mentioned that it "needs debugging on a system that can reproduce it". Is there anything I can do to debug it? It seems like you know what to look for... Something like building gcc with -save-temps, once with --disable-checking and once with --enable-checking, and find the difference in .ii and .s files? What is the right way to do that? I can't provide access to machine where it can be tested. Perhaps Steve@HP can? /Mads
Subject: Re: [4.0 regression] ICE in cp_expr_size, at cp/cp-objcp-common.c:101 > Dave, you mentioned that it "needs debugging on a system that can reproduce it". I was just able to reproduce it using a cvs head build done yesterday. It had checking enabled. The release builds that I had tried previously had checking disabled. Thus, it looks as if the ICE is caused by a tree check failure in the assert at cp/cp-objcp-common.c:101, rather than the assert itself. Dave
Subject: Re: [4.0 regression] ICE in cp_expr_size, at cp/cp-objcp-common.c:101 > Thus, it looks as if the ICE is caused by a > tree check failure in the assert at cp/cp-objcp-common.c:101, rather > than the assert itself. Actually, it's the enabling of assert checking that catches this problem. The problem can be duplicated with an x86 cross to hppa-unknown-linux-gnu. Here is some debug output: Breakpoint 1, fancy_abort ( file=0x84d9e38 "../../gcc/gcc/cp/cp-objcp-common.c", line=101, function=0x84d9de5 "cp_expr_size") at ../../gcc/gcc/diagnostic.c:590 590 internal_error ("in %s, at %s:%d", function, trim_filename (file), line); (gdb) bt #0 fancy_abort (file=0x84d9e38 "../../gcc/gcc/cp/cp-objcp-common.c", line=101, function=0x84d9de5 "cp_expr_size") at ../../gcc/gcc/diagnostic.c:590 During symbol reading, Incomplete CFI data; unspecified registers at 0x0826776d. During symbol reading, Incomplete CFI data; unspecified registers at 0x0826776d. During symbol reading, Incomplete CFI data; unspecified registers at 0x0826776d. During symbol reading, Incomplete CFI data; unspecified registers at 0x0826776d. During symbol reading, Incomplete CFI data; unspecified registers at 0x0826776d. During symbol reading, Incomplete CFI data; unspecified registers at 0x0826776d. During symbol reading, Incomplete CFI data; unspecified registers at 0x0826776d. #1 0x0812c516 in cp_expr_size (exp=0x4021f820) at ../../gcc/gcc/cp/cp-objcp-common.c:85 During symbol reading, Incomplete CFI data; unspecified registers at 0x0812c584. During symbol reading, Incomplete CFI data; unspecified registers at 0x0812c584. During symbol reading, Incomplete CFI data; unspecified registers at 0x0812c584. During symbol reading, Incomplete CFI data; unspecified registers at 0x0812c584. During symbol reading, Incomplete CFI data; unspecified registers at 0x0812c584. During symbol reading, Incomplete CFI data; unspecified registers at 0x0812c584. #2 0x082907f2 in expr_size (exp=0x4021f820) at ../../gcc/gcc/explow.c:246 During symbol reading, Incomplete CFI data; unspecified registers at 0x08290840. During symbol reading, Incomplete CFI data; unspecified registers at 0x08290840. During symbol reading, Incomplete CFI data; unspecified registers at 0x08290840. During symbol reading, Incomplete CFI data; unspecified registers at 0x08290840. During symbol reading, Incomplete CFI data; unspecified registers at 0x08290840. During symbol reading, Incomplete CFI data; unspecified registers at 0x08290840. #3 0x082a4c7a in store_expr (exp=0x4021f820, target=0x40223fc0, call_param_p=0) at ../../gcc/gcc/expr.c:4267 During symbol reading, Incomplete CFI data; unspecified registers at 0x082a4d74. #4 0x082a44e9 in expand_assignment (to=0x4022b9c0, from=0x4021f820) at ../../gcc/gcc/expr.c:4099 #5 0x082b4017 in expand_expr_real_1 (exp=0x4022d240, target=0x0, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at ../../gcc/gcc/expr.c:8279 #6 0x082aa838 in expand_expr_real (exp=0x4022d240, target=0x4014f210, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at ../../gcc/gcc/expr.c:6456 #7 0x0838a099 in expand_expr_stmt (exp=0x4022d240) at expr.h:492 #8 0x083c97ac in expand_gimple_basic_block (bb=0x40226e10, dump_file=0x0) at ../../gcc/gcc/cfgexpand.c:1326 #9 0x083c9ef4 in tree_expand_cfg () at ../../gcc/gcc/cfgexpand.c:1521 #10 0x083c6206 in execute_one_pass (pass=0x8559fe0) at ../../gcc/gcc/passes.c:790 #11 0x083c62af in execute_pass_list (pass=0x8559fe0) ---Type <return> to continue, or q <return> to quit--- at ../../gcc/gcc/passes.c:822 #12 0x0818ea05 in tree_rest_of_compilation (fndecl=0x401f0d80) at ../../gcc/gcc/tree-optimize.c:419 #13 0x0811469d in expand_body (fn=0x401f0d80) at ../../gcc/gcc/cp/semantics.c:3008 #14 0x081060ab in use_thunk (thunk_fndecl=0x401f0d80, emit_p=1 '\001') at ../../gcc/gcc/cp/method.c:520 #15 0x081144ec in emit_associated_thunks (fn=0x4021f820) at ../../gcc/gcc/cp/semantics.c:2961 #16 0x08114671 in expand_body (fn=0x401d0280) at ../../gcc/gcc/cp/semantics.c:3001 #17 0x083f7579 in cgraph_expand_function (node=0x402032d8) at ../../gcc/gcc/cgraphunit.c:1033 #18 0x083f7707 in cgraph_expand_all_functions () at ../../gcc/gcc/cgraphunit.c:1099 #19 0x083f7c0e in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1256 #20 0x080c2ced in cp_finish_file () at ../../gcc/gcc/cp/decl2.c:3094 #21 0x08049afa in finish_file () at ../../gcc/gcc/cp/cp-lang.c:149 #22 0x08166cb8 in c_common_parse_file (set_yydebug=1075792704) at ../../gcc/gcc/c-opts.c:1117 #23 0x08396cfe in compile_file () at ../../gcc/gcc/toplev.c:971 #24 0x0839813f in do_compile () at ../../gcc/gcc/toplev.c:1937 #25 0x08398197 in toplev_main (argc=10, argv=0xbffff484) at ../../gcc/gcc/toplev.c:1969 #26 0x0816fec3 in main (argc=10, argv=0xbffff484) at ../../gcc/gcc/main.c:35 (gdb) frame 1 #1 0x0812c516 in cp_expr_size (exp=0x4021f820) at ../../gcc/gcc/cp/cp-objcp-common.c:85 85 gcc_assert (!TYPE_HAS_COMPLEX_INIT_REF (type) (gdb) p debug_tree (exp) <call_expr 0x4021f820 type <record_type 0x401fa508 vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >,std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > sizes-gimplified addressable needs-constructing type_1 type_4 type_5 BLK size <integer_cst 0x4014b0d8 constant invariant 8> unit size <integer_cst 0x4014b0f0 constant invariant 1> align 8 symtab 0 alias set -1 fields <field_decl 0x40204958 D.1916 type <record_type 0x401fd450 _Vector_base<std::basic_string<char, std::char_traits<char>, std::allocator<char> >,std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >> ignored decl_6 BLK file mcop.ii line 94 size <integer_cst 0x4014b0d8 8> unit size <integer_cst 0x4014b0f0 1> align 8 offset_align 64 offset <integer_cst 0x4014b078 constant invariant 0> bit offset <integer_cst 0x4014b810 constant invariant 0> context <record_type 0x401fa508 vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >,std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >> chain <type_decl 0x401f55b0 vector>> context <namespace_decl 0x40162068 std> needs-constructor needs-destructor X() X(constX&) this=(X&) n_parents=1 use_template=1 interface-unknown pointer_to_this <pointer_type 0x401fdebc> reference_to_this <reference_type 0x402040b8> chain <type_decl 0x401f5d68 vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >,std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >>> side-effects protected arg 0 <addr_expr 0x40222e40 type <pointer_type 0x40208c94 type <method_type 0x401faf74> unsigned SI size <integer_cst 0x4014b2d0 constant invariant 32> unit size <integer_cst 0x4014b060 constant invariant 4> align 32 symtab 0 alias set -1> constant invariant arg 0 <function_decl 0x40229200 *.LTHUNK0 type <method_type 0x401faf74> addressable used no-static-chain decl_5 decl_6 SI file mcop.ii line 134 initial <error_mark 0x40150d00> (mem:SI (symbol_ref/v:SI ("@*.LTHUNK0") [flags 0x3] <function_decl 0x40229200 *.LTHUNK0>) [0 S4 A32])>> arg 1 <tree_list 0x4021c948 value <var_decl 0x4022f108 D.2077 type <pointer_type 0x401fd05c> used unsigned ignored SI file mcop.ii line 134 size <integer_cst 0x4014b2d0 32> unit size <integer_cst 0x4014b060 4> align 32 context <function_decl 0x401f0d80 _ZTv0_n12_NK4Arts18InterfaceRepo_base15_defaultPortsInEv> (reg:SI 94 [ D.2077 ])>> mcop.ii:134> $1 = void (gdb) p debug_tree (type) <record_type 0x401fa508 vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >,std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > sizes-gimplified addressable needs-constructing type_1 type_4 type_5 BLK size <integer_cst 0x4014b0d8 type <integer_type 0x4015b05c bit_size_type> constant invariant 8> unit size <integer_cst 0x4014b0f0 type <integer_type 0x4015b000 unsigned int> constant invariant 1> align 8 symtab 0 alias set -1 fields <field_decl 0x40204958 D.1916 type <record_type 0x401fd450 _Vector_base<std::basic_string<char, std::char_traits<char>, std::allocator<char> >,std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > sizes-gimplified addressable needs-constructing type_1 type_4 type_5 type_6 BLK size <integer_cst 0x4014b0d8 8> unit size <integer_cst 0x4014b0f0 1> align 8 symtab 0 alias set -1 fields <field_decl 0x401fd7e8 _M_impl> context <namespace_decl 0x40162068 std> needs-constructor needs-destructor X(constX&) this=(X&) n_parents=0 use_template=1 interface-unknown pointer_to_this <pointer_type 0x401fd508> reference_to_this <reference_type 0x40204170> chain <type_decl 0x401f5f70 _Vector_base<std::basic_string<char, std::char_traits<char>, std::allocator<char> >,std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >>> ignored decl_6 BLK file mcop.ii line 94 size <integer_cst 0x4014b0d8 8> unit size <integer_cst 0x4014b0f0 1> align 8 offset_align 64 offset <integer_cst 0x4014b078 constant invariant 0> bit offset <integer_cst 0x4014b810 constant invariant 0> context <record_type 0x401fa508 vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >,std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >> chain <type_decl 0x401f55b0 vector type <record_type 0x401fa508 vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >,std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >> external nonlocal suppress-debug decl_4 VOID file mcop.ii line 94 align 8 context <record_type 0x401fa508 vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >,std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >> chain <type_decl 0x402030d0 _Base>>> context <namespace_decl 0x40162068 std> needs-constructor needs-destructor X() X(constX&) this=(X&) n_parents=1 use_template=1 interface-unknown pointer_to_this <pointer_type 0x401fdebc> reference_to_this <reference_type 0x402040b8> chain <type_decl 0x401f5d68 vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >,std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >>> $2 = void "type" is record_type but CLASSTYPE_NON_AGGREGATE (type) is true, so CP_AGGREGATE_TYPE_P is false. It would appear that cp_expr_size shouldn't be called in this situation... The problem occurs on hppa-unknown-linux-gnu as well as hppa*-*-hpux*. Dave
This bug seems related to PR c++/18793.
seen on arm-linux as well, building kdelibs-3.4, according to http://buildd.debian.org/fetch.php?&pkg=kdelibs&ver=4%3A3.4.2-2&arch=arm&stamp=1124910639&file=log&as=raw
Seen also for another KDE related build: http://buildd.debian.org/fetch.php?&pkg=kshutdown&ver=0.6.0-3&arch=m68k&stamp=1125936989&file=log&as=raw
Reproduced on the mainline on arm-elf using the testcase in comment #4 also so changing Priority to P3 so that Mark knows that he has to recide this bug as arm-elf is a primary/secondary target.
Seems to happen a lot on hppa-linux here. 19 packages fail to build due to this. Do you need another testcase?
Showstopper: popular packages not building on primary target.
This is a bug in the generic thunk support; it doesn't show up on x86 because it uses asm thunks. Continuing to investigate.
Subject: Bug 21123 Author: jason Date: Tue Nov 8 08:32:26 2005 New Revision: 106634 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106634 Log: PR c++/21123 * cp/method.c (use_thunk): Use build_cplus_new instead of force_target_expr. * tree.h (CALL_FROM_THUNK_P): Add CALL_EXPR_CHECK. Added: trunk/gcc/testsuite/g++.dg/inherit/thunk4.C Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/method.c trunk/gcc/tree.h
Fixed at least on the mainline.
Subject: Bug 21123 Author: jason Date: Wed Nov 9 16:58:52 2005 New Revision: 106698 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106698 Log: PR c++/21123 * method.c (use_thunk): Use build_cplus_new instead of force_target_expr. Added: branches/gcc-4_0-branch/gcc/testsuite/g++.dg/inherit/thunk4.C Modified: branches/gcc-4_0-branch/gcc/cp/ChangeLog branches/gcc-4_0-branch/gcc/cp/method.c
Fixed in 4.0.3.
Created attachment 10322 [details] preprocessed source The original file still fails on at least hppa-linux, both on 4.0 20051111 and 4.1 20051112, works with 3.4
I also still see these problems: gcc-4.1.0_20051116-4 armv4l 10 ICEs 5 Segmentation fault 1 in insert_save, at caller-save.c:719 4 in cp_expr_size, at cp/cp-objcp-common.c:101 hppa 10 ICEs 9 verify_flow_info failed 1 in cp_expr_size, at cp/cp-objcp-common.c:101 /work/built/info/failed/armv4l/kvim: gui_kde_widget.cc:1431: internal compiler error: in cp_expr_size, at cp/cp-objcp-common.c:101 /work/built/info/failed/armv4l/katalog: /usr/src/packages/BUILD/katalog-0.3/katalogdcop/katalogdcop.moc:106: internal compiler error: in cp_expr_size, at cp/cp-objcp-common.c:101 /work/built/info/failed/armv4l/konversation: /usr/src/packages/BUILD/konversation-0.18/konversation/src/konvdcop.moc:469: internal compiler error: in cp_expr_size, at cp/cp-objcp-common.c:101 /work/built/info/failed/armv4l/TeXmacs: ./Edit/Modify/edit_dynamic.cpp:614: internal compiler error: in cp_expr_size, at cp/cp-objcp-common.c:101 /work/built/info/failed/hppa/arts: dynamicskeleton.cc:205: internal compiler error: in cp_expr_size, at cp/cp-objcp-common.c:101 re-opening. Tell me, if you need another testcase for this.
The original file still fails on at least hppa-linux, both on 4.0 20051111 and 4.1 20051112, works with 3.4. no results for arm and m68k yet. Matthias g++ -c -fpreprocessed libmcop_la.all_cc.ii -g -O2 -fno-exceptions -fno-check-new -fno-common -ftemplate-depth-99 -fPIC /scratch/packages/tmp/arts-1.4.3/./mcop/dynamicskeleton.cc: In member function 'std::string Arts::Object_skel::_ZTv0_n104_N4Arts11Object_skel9_addChildENS_6ObjectERKSs(Arts::Object, const std::string&)': /scratch/packages/tmp/arts-1.4.3/./mcop/dynamicskeleton.cc:205: internal compiler error: in cp_expr_size, at cp/cp-objcp-common.c:101 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions.
My earlier patch fixed all the reduced testcases, but not the unreduced one. Here's a reduced testcase that still fails (adding a by-value parm to the virtual function): struct A { A(const A &a); const A& operator=(const A& a); }; struct B { virtual A f(A); }; struct C : virtual B { virtual A f(A); }; A C::f(A a) { return a; }
Subject: Bug 21123 Author: jason Date: Wed Nov 30 20:58:27 2005 New Revision: 107738 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107738 Log: PR c++/21123 * cp-gimplify.c (cp_genericize_r): Don't dereference invisible reference parms in a thunk. Added: trunk/gcc/testsuite/g++.dg/inherit/thunk5.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-gimplify.c
Subject: Bug 21123 Author: jason Date: Wed Nov 30 21:08:39 2005 New Revision: 107740 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107740 Log: PR c++/21123 * cp-gimplify.c (cp_genericize_r): Don't dereference invisible reference parms in a thunk. Added: branches/gcc-4_0-branch/gcc/testsuite/g++.dg/inherit/thunk5.C - copied unchanged from r107738, trunk/gcc/testsuite/g++.dg/inherit/thunk5.C Modified: branches/gcc-4_0-branch/gcc/cp/ChangeLog branches/gcc-4_0-branch/gcc/cp/cp-gimplify.c
Subject: Bug 21123 Author: jason Date: Wed Nov 30 21:40:12 2005 New Revision: 107742 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107742 Log: PR c++/21123 * cp-gimplify.c (cp_genericize_r): Don't dereference invisible reference parms in a thunk. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/inherit/thunk5.C - copied unchanged from r107738, trunk/gcc/testsuite/g++.dg/inherit/thunk5.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/cp-gimplify.c
Fixed again.