Duncan Sands <baldrick at free.fr> writes:>> But you put me on the right track. The problem is that the class is >> returned on the stack.Correction: The class is returned on the FP stack:>> 0x6e08b5b5 <_ZN3Foo6GetFooEv+17>: fldl -0x8(%ebp) >> 0x6e08b5b8 <_ZN3Foo6GetFooEv+20>: leave >> 0x6e08b5b9 <_ZN3Foo6GetFooEv+21>: ret >> End of assembler dump. >> >> I guess that g++ exploits its knowledge of Foo's internals for deciding >> how to return the class. > > How Foo is returned is specified by the platform ABI. It is not really a > feature of g++.This is C++ land, so there is no "platform ABI", although static methods usually follow C calling convention. I've checked that wrapping the class definition with extern "C" changes nothing, so maybe it is following the platform ABI, after all. BTW, -fpcc-struct-return solves the case that motivated this thread.>> But my compiler knows nothing about Foo, so I >> must disable this "feature" of g++. Suggestions welcome. > > It is not possible to correctly codegen parameter passing/result returning > without knowing the type (though not all details of the type are relevant). > Your compiler needs to know something about Foo.I'm afraid you are right. Current available information includes the specific type (if it is fundamental), and type size (if it is derived). It also knows the default constructor, copier and destructor of each type. I hope that this, together with -fpcc-struct-return, is enough to complete my C++ <-> LLVM interface, which only has to deal with static methods. -- Oscar
Óscar Fuentes <ofv at wanadoo.es> writes:> BTW, -fpcc-struct-return solves the case that motivated this thread.-fpcc-struct-return is an ABI change, hence it requires "compiling the world". Not acceptable. I'll be interested on hearing ideas about how to determine how a function returns a small struct, without knowing the internals of the struct. -- Oscar
Óscar Fuentes <ofv at wanadoo.es> writes:> BTW, -fpcc-struct-return solves the case that motivated this thread.-fpcc-struct-return is an ABI change, hence it requires "compiling the world". Not acceptable. I'll be interested on hearing ideas about how to determine how a function returns a small struct, without knowing the internals of the struct. -- Oscar
On Mar 26, 2008, at 1:31 PM, Óscar Fuentes wrote:> Óscar Fuentes <ofv at wanadoo.es> writes: > >> BTW, -fpcc-struct-return solves the case that motivated this thread. > > -fpcc-struct-return is an ABI change, hence it requires "compiling the > world". Not acceptable. > > I'll be interested on hearing ideas about how to determine how a > function returns a small struct, without knowing the internals of the > struct.You need to know _something_ about the internals. GCC approximately implements the IA-64 C++ ABI; which is fairly conventional in this particular aspect of a C++ ABI. See http://www.codesourcery.com/cxx-abi/abi.html#calls In that ABI, if there is a "nontrivial" (that's a precise term) copy- constructor or destructor, the caller is responsible for allocation. Daveed
Take a look at llvm-gcc. Look for HandleAggregateShadowArgument. Evan On Mar 26, 2008, at 10:31 AM, Óscar Fuentes wrote:> Óscar Fuentes <ofv at wanadoo.es> writes: > >> BTW, -fpcc-struct-return solves the case that motivated this thread. > > -fpcc-struct-return is an ABI change, hence it requires "compiling the > world". Not acceptable. > > I'll be interested on hearing ideas about how to determine how a > function returns a small struct, without knowing the internals of the > struct. > > -- > Oscar > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev