This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/18793] [4.0 regression] ICE in cp_expr_size
- From: "mmitchel at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 14 Dec 2004 07:24:30 -0000
- Subject: [Bug c++/18793] [4.0 regression] ICE in cp_expr_size
- References: <20041202195715.18793.bangerth@dealii.org>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From mmitchel at gcc dot gnu dot org 2004-12-14 07:24 -------
I'm not sure how to fix this yet.
The C++ front end is generating what looks to me to perfectly reasonable code.
Then, gimplify_init_constructor decides that it wants to create a temporary
variable of type X. It's never, ever correct for the middle end to create a
variable of type with a copy constructor, and the assert catches this error later.
The middle end is transforming:
x = { 0 }
into:
static const X temp = { 0 };
x = temp;
That's wrong, if X has a constructor or destructor.
One solution would be to say that an object of a type for which this is invalid
cannot be initialized with a CONSTRUCTOR, and have the front end lower away the
CONSTRUCTOR. But, that would be a change from longstanding precedent, and a
CONSTRUCTOR seems the right way to represent this.
Then again, my change, to split out nonconstant inits, might result in
initializations taking place in an order not allowed by the standard. So, more
thought is required.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18793