Bug 21123 - [4.0/4.1 regression] ICE in cp_expr_size, at cp/cp-objcp-common.c:101
Summary: [4.0/4.1 regression] ICE in cp_expr_size, at cp/cp-objcp-common.c:101
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 4.0.0
: P1 critical
Target Milestone: 4.0.3
Assignee: Jason Merrill
URL:
Keywords: ice-on-valid-code
Depends on:
Blocks:
 
Reported: 2005-04-20 14:27 UTC by b.gunreben
Modified: 2005-11-30 22:12 UTC (History)
9 users (show)

See Also:
Host:
Target: hppa-*-linux-gnu, arm-elf
Build:
Known to work: 3.4.4 4.2.0
Known to fail: 4.0.0 4.0.3 4.1.0
Last reconfirmed: 2005-11-07 18:10:08


Attachments
testcase (723 bytes, application/x-bzip2)
2005-04-20 14:28 UTC, b.gunreben
Details
preprocessed source (157.59 KB, application/x-bzip)
2005-11-23 11:47 UTC, Debian GCC Maintainers
Details

Note You need to log in before you can comment on or make changes to this bug.
Description b.gunreben 2005-04-20 14:27:15 UTC
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
Comment 1 b.gunreben 2005-04-20 14:28:01 UTC
Created attachment 8689 [details]
testcase
Comment 2 Andrew Pinski 2005-04-20 15:10:15 UTC
This works on the mainline.
Comment 3 b.gunreben 2005-04-22 08:01:35 UTC
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. 
Comment 4 Serge Belyshev 2005-04-29 13:12:21 UTC
// 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;
}
Comment 5 trauscher 2005-05-25 09:35:07 UTC
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;
}
Comment 6 mki 2005-07-15 16:52:22 UTC
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.)
Comment 7 dave 2005-07-15 17:28:06 UTC
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
Comment 8 mki 2005-07-15 19:11:16 UTC
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.
Comment 9 dave 2005-07-15 20:24:46 UTC
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
Comment 10 Steve Ellcey 2005-07-15 22:08:46 UTC
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.
Comment 11 dave 2005-07-15 22:35:07 UTC
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
Comment 12 Steve Ellcey 2005-07-15 23:27:48 UTC
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)
Comment 13 dave 2005-07-15 23:37:38 UTC
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
Comment 14 b.gunreben 2005-07-19 16:50:29 UTC
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 
 
Comment 15 mki 2005-07-27 16:30:51 UTC
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
Comment 16 dave 2005-07-27 17:20:56 UTC
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
Comment 17 dave 2005-07-27 20:17:45 UTC
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
Comment 18 John David Anglin 2005-07-27 21:41:15 UTC
This bug seems related to PR c++/18793.
Comment 19 Debian GCC Maintainers 2005-08-29 09:20:53 UTC
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
Comment 20 Romain Beauxis 2005-09-05 17:29:23 UTC
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 
Comment 21 Andrew Pinski 2005-10-31 01:40:47 UTC
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.
Comment 22 Richard Biener 2005-11-01 22:00:44 UTC
Seems to happen a lot on hppa-linux here.  19 packages fail to build due to this.  Do you need another testcase?
Comment 23 Mark Mitchell 2005-11-03 06:36:43 UTC
Showstopper: popular packages not building on primary target.
Comment 24 Jason Merrill 2005-11-07 19:35:13 UTC
This is a bug in the generic thunk support; it doesn't show up on x86 because it uses asm thunks.  Continuing to investigate.
Comment 25 Jason Merrill 2005-11-08 08:32:32 UTC
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

Comment 26 Andrew Pinski 2005-11-08 12:54:06 UTC
Fixed at least on the mainline.
Comment 27 Jason Merrill 2005-11-09 16:58:59 UTC
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

Comment 28 Andrew Pinski 2005-11-09 17:04:05 UTC
Fixed in 4.0.3.
Comment 29 Debian GCC Maintainers 2005-11-23 11:47:15 UTC
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
Comment 30 Richard Biener 2005-11-23 11:55:04 UTC
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.
Comment 31 Debian GCC Maintainers 2005-11-23 11:57:58 UTC
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.
Comment 32 Jason Merrill 2005-11-23 23:56:58 UTC
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;
}
Comment 33 Jason Merrill 2005-11-30 20:58:31 UTC
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

Comment 34 Jason Merrill 2005-11-30 21:08:43 UTC
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

Comment 35 Jason Merrill 2005-11-30 21:40:15 UTC
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

Comment 36 Richard Biener 2005-11-30 22:12:00 UTC
Fixed again.