[Bug c++/55245] [4.6/4.7/4.8 Regression] Compiler segfault when compiling a small test case

2012-12-06 Thread rguenth at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55245



Richard Biener  changed:



   What|Removed |Added



   Keywords||ice-on-valid-code

   Priority|P3  |P2


[Bug c++/55245] [4.6/4.7/4.8 Regression] Compiler segfault when compiling a small test case

2012-11-26 Thread dnovillo at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55245



--- Comment #7 from Diego Novillo  2012-11-26 
18:35:43 UTC ---

Author: dnovillo

Date: Mon Nov 26 18:35:38 2012

New Revision: 193825



URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193825

Log:

Google ref b/7500842.



2012-11-26  Diego Novillo  



* gimplify.c: Work around for PR 55245.



testsuite/ChangeLog.google-integration

* g++.dg/pr55245.C: New.







Added:

branches/google/gcc-4_7/gcc/testsuite/g++.dg/pr55245.C

Modified:

branches/google/gcc-4_7/gcc/ChangeLog.google-4_7

branches/google/gcc-4_7/gcc/gimplify.c

branches/google/gcc-4_7/gcc/testsuite/ChangeLog.google-4_7


[Bug c++/55245] [4.6/4.7/4.8 Regression] Compiler segfault when compiling a small test case

2012-11-26 Thread jakub at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55245



--- Comment #6 from Jakub Jelinek  2012-11-26 
09:49:23 UTC ---

I'd say it should be the FE's responsibility to layout all needed types, so it

should be done either somewhere when the type ARRAY_REF is created or

finalized, or in cp-gimplify.c at latest.


[Bug c++/55245] [4.6/4.7/4.8 Regression] Compiler segfault when compiling a small test case

2012-11-21 Thread xinliangli at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55245



--- Comment #5 from davidxl  2012-11-21 16:17:27 
UTC ---

Should the main variant types gets laid out in gimplify_type_sizes, when the

variant's type has size, but the main variant is incomplete? 



David


[Bug c++/55245] [4.6/4.7/4.8 Regression] Compiler segfault when compiling a small test case

2012-11-20 Thread dnovillo at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55245



Diego Novillo  changed:



   What|Removed |Added



 CC||dnovillo at gcc dot gnu.org



--- Comment #4 from Diego Novillo  2012-11-21 
00:52:57 UTC ---

David's analysis is correct.  The type of the element at the point of the

failure is not a complete type.



At this point, I think all the types should've been completed, so I'm not sure

why this one still isn't.  Jason, this patchlet (which is very likely papering

over the issue) allows the file to build.



Index: gimplify.c

===

--- gimplify.c  (revision 193508)

+++ gimplify.c  (working copy)

@@ -2123,6 +2123,8 @@

  if (TREE_OPERAND (t, 3) == NULL_TREE)

{ 

  tree elmt_type = TREE_TYPE (TREE_TYPE (TREE_OPERAND (t, 0)));

+ if (!COMPLETE_TYPE_P (elmt_type))

+   layout_type (elmt_type);

  tree elmt_size = unshare_expr (array_ref_element_size (t));

  tree factor = size_int (TYPE_ALIGN_UNIT (elmt_type));



In this case, we have



t ==> mosaic_position[tri]

elmt_type ==> struct Vector2_f[3], but we cannot compute its element size

because it has not yet been laid out.



Jason, what would be a better place to make sure the type is laid out?





Thanks.  Diego.