This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/54038] [4.7/4.8 Regression] finalize_type_size enters infinite loop becasue TYPE_NEXT_VARIANT (variant) == variant
- From: "jakub at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Fri, 20 Jul 2012 11:08:49 +0000
- Subject: [Bug c++/54038] [4.7/4.8 Regression] finalize_type_size enters infinite loop becasue TYPE_NEXT_VARIANT (variant) == variant
- Auto-submitted: auto-generated
- References: <bug-54038-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54038
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-07-20 11:08:49 UTC ---
Created attachment 27844
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27844
gcc48-pr54038.patch
Untested fix. On array23.C testcase, we have Foo as main variant of Foo2 and
we have:
t: const Foo2 []
c: const Foo []
m: Foo []
and in that case we want to change c's TYPE_MAIN_VARIANT to m. On this new
testcase we have char as TYPE_MAIN_VARIANT of gchar, and have:
t: const gchar *const []
c: const char *const []
m: const gchar * []
and trying to change TYPE_MAIN_VARIANT of c in that case (whose
TYPE_MAIN_VARIANT is const char * [] at that point) is fatal. I believe the
important difference between the two is that in array23.C TYPE_MAIN_VARIANT
(TREE_TYPE (c)) is the same as TREE_TYPE (m) (aka TYPE_MAIN_VARIANT
(elt_type)),
but on this PR it is different and as the element type's of c vs. m + t aren't
variants of the same type, neither should the array types be variants of one
another.