search for: l_fixarray_array3

...Nick Lewycky wrote: > Eric van Riet Paap wrote: >> *testme.cbe.c:106: error: array type has incomplete element type* > > The problem code boils down to: > > /* Structure forward decls */ > struct l_structtype_s; > > /* Typedefs */ > typedef struct l_structtype_s l_fixarray_array3[3]; > > which is illegal C, but perfectly valid C++, and g++ accepts it. > > The structure contents are defined right afterwards, but I assume that > the typedefs are used when emitting the structure contents? We may have > to put fully defined structures first and typedefs second...

The C backend can currently (recent head) produce code with such patterns: /* Global Declarations */ /* Structure forward decls */ struct l_structtype_s; /* Typedefs */ typedef struct l_structtype_s l_fixarray_array3[3]; /* problematic declaration */ typedef struct l_structtype_s l_structtype_s; /* Structure contents */ struct l_structtype_s { int field0; }; gcc 4.0.1 will reject this with example.c:7: error: array type has incomplete element type this kind of code was accepted by previous versions of gc...

Eric van Riet Paap wrote: > *testme.cbe.c:106: error: array type has incomplete element type* The problem code boils down to: /* Structure forward decls */ struct l_structtype_s; /* Typedefs */ typedef struct l_structtype_s l_fixarray_array3[3]; which is illegal C, but perfectly valid C++, and g++ accepts it. The structure contents are defined right afterwards, but I assume that the typedefs are used when emitting the structure contents? We may have to put fully defined structures first and typedefs second. Nick Lewycky

On Tue, 16 Jan 2007, Gordon Henriksen wrote: > The simplest solution is to avoid typedefs for array types. With > names of array types removed from the symbol table, llc will simply > output (for instance) 'l_structtype_s[3]' instead of the equivalent > 'l_fixarray_array3'. Very nice catch and approach. > A more ambitious fix would be to merge the "typedef" and "structure > contents" loops into a single, substantially more complex dependency- > ordered traversal. This would preserve type names from the bytecode > file—but to wha...

...something like [2 x { [2 x {int}] }]; these two stages must be interleaved. The simplest solution is to avoid typedefs for array types. With names of array types removed from the symbol table, llc will simply output (for instance) 'l_structtype_s[3]' instead of the equivalent 'l_fixarray_array3'. A more ambitious fix would be to merge the "typedef" and "structure contents" loops into a single, substantially more complex dependency- ordered traversal. This would preserve type names from the bytecode file—but to what end? Here's the patch and test: http://...

Hello, I would like to ask the llvm developers to have a look at http:// llvm.org/bugs/show_bug.cgi?id=918 . This bug has been reported 4 month ago but is none the less a somewhat serious one. Below I have pasted the test case and output of the issue running on my ppc machine. thank you Eric pb:~ eric$ cat testme.ll;llvm-as -f testme.ll;llc -march=c -f testme.bc;gcc -c testme.cbe.c

...20/06, Samuele Pedroni <pedronis at strakt.com> wrote: > The C backend can currently (recent head) produce code with such patterns: > > /* Global Declarations */ > /* Structure forward decls */ > struct l_structtype_s; > > /* Typedefs */ > typedef struct l_structtype_s l_fixarray_array3[3]; /* problematic > declaration */ > typedef struct l_structtype_s l_structtype_s; > > /* Structure contents */ > struct l_structtype_s { > int field0; > }; > > gcc 4.0.1 will reject this with > > example.c:7: error: array type has incomplete element type > &g...