[LLVMdev] struct returns

[Dan Gohman]

On Sep 20, 2009, at 11:36 AM, Kenneth Uildriks wrote:

> I wish to assure you that I have not forgotten this task, nor failed
> to start on it, but I cannot give even a rough estimate on when it
> will be completed.

Ok, that's fine. Thanks for keeping me up to date.

> 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.

LLVM can't always see what the operand may have been bitcasted from,
so it just has to trust the user. If the dynamic callee's type doesn't
match the static operand type on the call, it's undefined behavior.

> 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.

Dan