[LLVMdev] struct returns

[Kenneth Uildriks]

>> It occurs to me that all declarations of a function pointer, and all
>> bitcasts to a function pointer, could possibly refer to a function
>> whose signature must be altered by this fix.  Is the function
>> signature relevant to the SelectionDAG representation of said function
>> pointers, or can it be safely ignored when lowering loads, stores, and
>> bitcasts involving such pointers?
>
> No. Fortunately, you don't have to worry about complicated bitcast
> situations here. There are only two constructs which are affected:
> function definitions and function calls. And in the case of calls,
> the only thing that matters is the type of the call operand itself,
> not what the operand might have been bitcasted from.

What about the type of the ptr-to-function-ptr that the call operand
was *loaded* from?  This will come up whenever a function pointer is
stored in callback situations.  If I change the call operand, it won't
match the element type of the pointer it was loaded from.  Does this
matter in a SelectionDAG?

>> Also, I cannot build the test suite: the option "-disable-llvm-optzns"
>> passed to llvm-gcc produces several warnings (cc1 seems to think every
>> letter after 'd' is an individual option), and the option "-m32"
>> passed to llvm-gcc produces an "unknown command line argument" error
>> from "cc1".  I have been using llvm-gcc extensively to build my own
>> front-end project, and have not had a problem with it.  I am reluctant
>> to make further changes to the source without being able to run the
>> test suite and satisfy myself that I have not broken something.  I am
>> running version 4.2.1 of llvm-gcc from the 2.5 release... should I
>> take a later development snapshot of llvm-gcc?
>
> The -disable-llvm-optzns is preceded by a -mllvm, but it's likely
> that that didn't work in 2.5 llvm-gcc. If you don't want to live on
> the latest snapshot, the 2.6 pre-release (and the 2.6 release, once
> it exists) should work here. As a temporary workaround, you might
> also be able to replace "-mllvm -disable-llvm-optzns" with "-O0",
> which isn't exactly the same, but basically works.
>
> I'm not as familiar with what might be going on with -m32 option.
> What host are you on, and what targets is your llvm-gcc configured
> for? Does it include 64-bit support? It may be that an llvm-gcc
> configured for 32-bit only doesn't recognize -m32. I'm not sure
> what to suggest there. Perhaps the Makefile needs to be smarter.

I am on linux x86 32 bit... no 64 bit support at all.  llvm-gcc is
configured for C and C++... I didn't add any other languages or
targets onto the defaults for LLVM or llvm-gcc.  I was hoping not to
install another version of llvm-gcc, since it is quite a beast and I
don't want to break the one I already have running.  (Giving it a new
prefix should be safe, right?)  I pretty much have to live on the
snapshot for the folder that I'm working on LLVM code in, so I'll just
have to bite the bullet and make it work.