PR 12207: sign extension of parameters and return values on x86-64

Hi,

I recently spent a bit of time looking into
http://llvm.org/bugs/show_bug.cgi?id=12207. After talking to a bunch
of different projects (including libffi and python, which is where I
actually ran into issues), I found out that it seems that LLVM is in
the wrong here after all. I noted such on the issue, but haven't
gotten a response.

There's a recent relevant thread in
http://gcc.gnu.org/ml/gcc/2013-01/msg00447.html which discusses the
issues here, which seems to come to the conclusion that LLVM's
behavior is incorrect. Does the current lack of response on the bug
signal disagreement with that diagnosis, or just disinterest?

Since this affects stuff like Python (or really lots of software using
libffi to make calls), it would be great to get this fixed.

Cheers,

Dirkjan

Hi Dirkjan,

> I recently spent a bit of time looking into

http://llvm.org/bugs/show_bug.cgi?id=12207. After talking to a bunch
of different projects (including libffi and python, which is where I
actually ran into issues), I found out that it seems that LLVM is in
the wrong here after all. I noted such on the issue, but haven't
gotten a response.

There's a recent relevant thread in
http://gcc.gnu.org/ml/gcc/2013-01/msg00447.html which discusses the
issues here, which seems to come to the conclusion that LLVM's
behavior is incorrect. Does the current lack of response on the bug
signal disagreement with that diagnosis, or just disinterest?

Since this affects stuff like Python (or really lots of software using
libffi to make calls), it would be great to get this fixed.

I think the reason for the lack of action is that there is a plan to get
rid of zext/sext parameter- and return-value-attributes altogether. See
http://nondot.org/sabre/LLVMNotes/ExtendedIntegerResults.txt
However in order to implement this scheme, parameter attributes need to
be made more powerful (so you can say things like "sexted from iN" where
N may be 1, 8, 16, ... or even 33). Maybe they now are powerful enough thanks
to Bill's recent work (hopefully Bill will chime in here).

Ciao, Duncan.