http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56403
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org,
| |jason at gcc dot gnu.org
Target Milestone|--- |4.6.4
Summary|internal compiler error: in |[4.6/4.7/4.8 Regression]
|build_zero_init_1, at |internal compiler error: in
|cp/init.c:279 |build_zero_init_1, at
| |cp/init.c:279
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-02-20
07:05:27 UTC ---
My guess is this started with
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126399
but haven't verified (all I know is that r126000 didn't ICE, r127000 does).
I think the problem is that (*lang_hooks.types.make_type) (RECORD_TYPE)
doesn't create CLASS_TYPE_P, which is what I think is generally desirable at
least for the middle-end va_list aggregates (and supposedly other records too,
though they likely can't appear in user code).
One way would be just during the initialization of C++ FE to fix up the
RECORD_TYPE embedded in va_list, but that wouldn't work well on i?86 which
creates several va_list records for the different ABIs.
We have cxx_make_type which doesn't create CLASS_TYPE_P, and make_class_type
which does, but only handles RECORD_TYPE and UNION_TYPE.
So, perhaps the lang hook make_type should be some other function, that for
code == RECORD_TYPE || code == UNION_TYPE calls make_class_type, otherwise
calls cxx_make_type?
