[llvm-gcc] Crash on structure with variable length array member

[llvmbot]

Bugzilla Link	199
Resolution	FIXED
Resolved on	Feb 22, 2010 12:54
Version	1.1
OS	All
Depends On	#534
Attachments	Preprocessed C code that reproduces the problem., Reduced test case, Proposed fix
Reporter	LLVM Bugzilla Contributor
CC	@lattner

Extended Description

The llvm-gcc program crashes when it tries to compile the attached pre-processed
code. It occurs because we have an FIELD_DECL tree whose DECL_SIZE returns a
NULL_TREE. We deference this NULL_TREE with TREE_INT_CST_LOW, causing the error:

C-ctype.c:685: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://llvm.cs.uiuc.edu for instructions.

The source file comes from glibc.

I'm assigning it to myself for now since I've figured what is causing it, have
devised a hack to work around it, and am now looking at how to fix it correctly.

[llvmbot]

assigned to @lattner

[lattner]

Hrm, interesting testcase. What exactly does this cause the compiler to compile
it into?

-Chris

[llvmbot]

llvm-gcc compiles it into the following:

target endian = little
target pointersize = 32
%struct.one = type { int, [0 x int] }
%hobbit = global %struct.one { int 5, [0 x int] [ ] } ; <%struct.one*> [#uses=0]

implementation ; Functions:

It compiles, but the code is incorrect.
Well, that's the second regression test of the year...
:)

[lattner]

I suspected as much. I would rather keep this as a compile-fail bug than as a
miscompilation. When I finally get around to working on fixing the Bug 162
family of problems, I will also look at this. Basically the C front-end should
generate a global of type { int, [3 x int] }, instead of { int, [0 x int] }.
Doing this requires looking at the initializer before looking at the global
variable though, and will be tricky to get right.

If you are feeling in a "hacking on the C/C++ front-end" kind of mood, you could
try synching it up with a more current version of the CVS tree... :)

-Chris

[lattner]

Here's another expanded testcase that should be compiled correctly by any fix
for this bug:

---

struct one {
int a;
int values [];
};

extern struct one hobbit;
void *foo() { return &hobbit; }
struct one hobbit = {5, {1, 2, 3}};

---

In other words, the CFE has to be able to adjust the type of an
already-emitted-and-potentially-used global as needed.

-Chris

[lattner]

Here's an execution test for the problem. Once this is fixed, it should be
checked into the testsuite. Until then it is causing it to stop early, so I'm
removing it.

-Chris

---

/*

• This regression test ensures that the C front end can compile initializers
• correctly when their size is not static.
  */
  struct one {
  int a;
  int values [];
  };

struct one hobbit = {5, {1, 2, 3}};

int main () {
int index;
for (index=0; index < 3; index++)
printf ("%d\n", hobbit.values[index]);
return 0;
}

[lattner]

John, I think you checked in your proposed fix for this bug, which changes it
from a compile-fail to a miscompilation. Should this be reverted?

-Chris

[llvmbot]

No reversion is necessary. This code still compile-fails under the current
llvm-gcc.

[lattner]

*** Bug llvm/llvm-bugzilla-archive#431 has been marked as a duplicate of this bug. ***

[lattner]

*** Bug llvm/llvm-bugzilla-archive#654 has been marked as a duplicate of this bug. ***

[lattner]

*** Bug llvm/llvm-bugzilla-archive#648 has been marked as a duplicate of this bug. ***

[lattner]

*** Bug llvm/llvm-bugzilla-archive#649 has been marked as a duplicate of this bug. ***

[lattner]

When working on this bug, please make sure that all of the marked duplicates are fixed before this one is
closed.

-Chris

[lattner]

llvm/llvm-bugzilla-archive#648 was reopened, it was actually a different bug.

[lattner]

Testcase here: llvm-test/SingleSource/UnitTests/2006-01-23-UnionInit.c
This is fixed by the new frontend and will be closed when it is the default.

-Chris

[lattner]

This is fixed in llvmgcc4.

[lattner]

mentioned in issue llvm/llvm-bugzilla-archive#200