User account creation filtered due to spam.

Bug 55245 - [4.6 Regression] Compiler segfault when compiling a small test case
Summary: [4.6 Regression] Compiler segfault when compiling a small test case
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 4.8.0
: P2 normal
Target Milestone: 4.6.4
Assignee: Jason Merrill
URL:
Keywords: ice-on-valid-code
Depends on:
Blocks:
 
Reported: 2012-11-09 00:22 UTC by davidxl
Modified: 2013-01-02 19:04 UTC (History)
5 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2012-11-09 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description davidxl 2012-11-09 00:22:18 UTC
Compiling the following program without any option, gcc segfaults:

get.cc: In member function 'virtual void Test2::TestBody()':
get.cc:22:27: internal compiler error: Segmentation fault


The problem is that one array type Vector2_f[2]'s size field is reset to zero during gimplify_type_sizes by one of its variant (which has null size).

The problem does not show up in trunk compiler.  Was this fixed explicitly in trunk or it happens to work by luck?

David



template <typename VType> class Vector2 { };
typedef Vector2<float> Vector2_f;

void GetR( const Vector2_f mosaic_position[3]);

class Test1 {
 private: virtual void TestBody();
};

void Test1::TestBody() {
  Vector2_f mosaic_position[2][1];   // (1)
}

class Test2 {
 private: virtual void TestBody();
};

int tri;
void Test2::TestBody() {
  Vector2_f mosaic_position[2][3] = { };
  GetR(mosaic_position[tri]);
}
Comment 1 davidxl 2012-11-09 00:42:55 UTC
The problem actually exists in main line compiler too.
Comment 2 davidxl 2012-11-09 06:05:43 UTC
(In reply to comment #1)
> The problem actually exists in main line compiler too.


This is another test case.

Segfaults without option, but builds ok with -DOK.

The problem seems to be that the main variant of the array type Vector2<float>[2] does not have size, while the variant Vector2_f[2] has. The variant's size later gets reset to 0 (from main variant).

David

template <typename VType> class Vector2 {
 public:
  Vector2();
  VType x() const;
};
typedef Vector2<float> Vector2_f;
void GetR(const Vector2_f mosaic_position[3]);
template <class C> struct DefaultDeleter {
   float  GetColorTexCoord(Vector2_f &tex_coord) const  {
    return tex_coord.x();
  }
};

class GetT { private: virtual void TestBody(); };

void GetT::TestBody() {
#ifdef OK
  Vector2<float> mosaic_position[2][3] = { };
#else
  Vector2_f mosaic_position[2][3] = { };
#endif
}
Comment 3 Jakub Jelinek 2012-11-09 09:06:25 UTC
Started with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170853 aka PR48029 fix.
Comment 4 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.
Comment 5 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
Comment 6 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.
Comment 7 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  <dnovillo@google.com>

	* 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
Comment 8 Jason Merrill 2012-12-06 22:18:18 UTC
Fixed for 4.7 and 4.8 by patch for bug 55032.
Comment 9 Jason Merrill 2012-12-07 04:54:23 UTC
Author: jason
Date: Fri Dec  7 04:54:12 2012
New Revision: 194283

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194283
Log:
add PR 55245 marker

Modified:
    trunk/gcc/ChangeLog
Comment 10 Jason Merrill 2012-12-07 05:14:34 UTC
Fix applied for 4.6.4 as well.
Comment 11 Jason Merrill 2013-01-02 19:03:17 UTC
Author: jason
Date: Wed Jan  2 19:03:04 2013
New Revision: 194811

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194811
Log:
	PR c++/55804
	PR c++/55032
	PR c++/55245
	* tree.c (build_array_type_1): Revert earlier change.
	* cp/tree.c (build_cplus_array_type): Copy layout information
	to main variant if necessary.

Added:
    trunk/gcc/testsuite/g++.dg/init/array33.C
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/tree.c
    trunk/gcc/tree.c
Comment 12 Jason Merrill 2013-01-02 19:03:55 UTC
Author: jason
Date: Wed Jan  2 19:03:37 2013
New Revision: 194812

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194812
Log:
	PR c++/55804
	PR c++/55032
	PR c++/55245
	* tree.c (build_array_type_1): Revert earlier change.
	* cp/tree.c (build_cplus_array_type): Copy layout information
	to main variant if necessary.

Added:
    branches/gcc-4_7-branch/gcc/testsuite/g++.dg/init/array33.C
Modified:
    branches/gcc-4_7-branch/gcc/ChangeLog
    branches/gcc-4_7-branch/gcc/cp/ChangeLog
    branches/gcc-4_7-branch/gcc/cp/tree.c
    branches/gcc-4_7-branch/gcc/tree.c
Comment 13 Jason Merrill 2013-01-02 19:04:07 UTC
Author: jason
Date: Wed Jan  2 19:03:46 2013
New Revision: 194813

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194813
Log:
	PR c++/55804
	PR c++/55032
	PR c++/55245
	* tree.c (build_array_type_1): Revert earlier change.
	* cp/tree.c (build_cplus_array_type): Copy layout information
	to main variant if necessary.

Added:
    branches/gcc-4_6-branch/gcc/testsuite/g++.dg/init/array33.C
Modified:
    branches/gcc-4_6-branch/gcc/ChangeLog
    branches/gcc-4_6-branch/gcc/cp/ChangeLog
    branches/gcc-4_6-branch/gcc/cp/tree.c
    branches/gcc-4_6-branch/gcc/tree.c