Chris Lattner
2007-Jan-15 16:48 UTC
[LLVMdev] llc c backend can produce code that doesn't compile on gcc 4.x
On Mon, 15 Jan 2007, 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.Looks like it. It sounds like the CBE should build an ordering of types, based on their nesting properties, then emit them in nesting order. Because all recursive types have to go through a pointer in C, we should get a dag of types, which is easy to emit. Anyone want to take a crack at it? -Chris -- http://nondot.org/sabre/ http://llvm.org/
Gordon Henriksen
2007-Jan-16 06:53 UTC
[LLVMdev] llc c backend can produce code that doesn't compile on gcc 4.x
On 2007-01-15, at 11:48, Chris Lattner wrote:> On Mon, 15 Jan 2007, Nick Lewycky wrote: > >> 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. > > Looks like it. It sounds like the CBE should build an ordering of > types, based on their nesting properties, then emit them in nesting > order. Because all recursive types have to go through a pointer in > C, we should get a dag of types, which is easy to emit.A DAG traversal is already performed, but only for struct types. It is implemented in CWriter::printContainedStructs (lib/Target/CBackend/ CBackend.cpp:1722). The bug is in the calling function, printModuleTypes, which prints typedefs for all named types before performing the dependency- sensitive traversal. For array typedefs, this ordering is incorrect; the element type must be defined first. But consider 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://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of- Mon-20070115/042760.html A workaround for this bug was to avoid naming array types in .ll files. — Gordon
Chris Lattner
2007-Jan-16 07:47 UTC
[LLVMdev] llc c backend can produce code that doesn't compile on gcc 4.x
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 what end?Good question, I can't think of a reason! I applied your patch but generalized it slightly. The CBE now strips off any non-struct type names, to avoid issues with vectors (if the CBE starts supporting them in the future). Thanks Gordon! -Chris -- http://nondot.org/sabre/ http://llvm.org/
Maybe Matching Threads
- [LLVMdev] llc c backend can produce code that doesn't compile on gcc 4.x
- [LLVMdev] llc c backend can produce code that doesn't compile on gcc 4.x
- [LLVMdev] llc c backend can produce code that doesn't compile on gcc 4.x
- [LLVMdev] bug? c backend produces code rejected by gcc4.0.1: array type has incomplete element type
- [LLVMdev] bug? c backend produces code rejected by gcc4.0.1: array type has incomplete element type