[LLVMdev] PointerIntPair causing trouble

[OvermindDL1]

On Mon, May 4, 2009 at 12:02 PM, Stefanus Du Toit
<stefanus.dutoit at rapidmind.com> wrote:
> /* snip PointerIntPair bug */

I had made a toy language a month ago to catch back up to the latest
svn LLVM api and for some reason anytime I used a compare operator (<,
=, or > are all this toy language has) that was inside a function
definition (a prime example is this code "(begin (define (fib n) (if
(< n 3) 1 (+ (fib (- n 1)) (fib (- n 2))))) (fib (+ 1 3)))" of the toy
language, even if reduced so all it does is return the (< n 3) part),
then anytime I JITed the function and called it, when the JIT compiled
it, it always crashed.  I ran out of time to mess with it due to RL
issues, but I tried to debug that one section of code for 3 days
straight, tried every combination I could think of and so forth.  When
I debug into the JIT compiler and followed it, it always crashed when
it got the Uses of the instruction that used the compare (which was
always a zero-extend to 32-bit integer since every variable in this
toy language is a 32-bit integer, but it also did it if I removed that
instruction, changed it to something else, etc...) it went into the
function, and ended up going through about 8 or so other functions
that did not look like they did anything but route to other
instructions (testing class type, removing references if necessary, so
on and so forth, would not std::tr1::type_traits be *much* better for
this stuff, just including Boost.Type_Traits would make it work on
other platforms, and less code in your base to deal with), and the
final instruction call returned a pointer to what should have been the
compare, but it was always in some other random (non-allocated)
memory.  Although I cannot check right now (still real-life issues in
the way, I could check in two weeks, maybe sooner if I get a free
moment while at home), but from what I remember of the pointer value,
I would bet real money that the bit pattern got shifted from what the
Compare instruction pointer value was supposed to be.

Hence, I bet the issue I was seeing and tried to fix for a couple of
days before I ran out of time is this exact issue, and yes, I am using
Visual Studio 2005.  I have the toy language at my local home svn, if
anyone wants access I can give you all the link so you can download
and try it out (built with LLVM trunk SVN about a month or two ago,
and Boost 1.40, hence, Boost trunk SVN) to confirm that this is the
issue, or if you fix this issue in LLVM trunk, then I can resync and
rebuild LLVM and see if that fixes the problem I have, the toy
language code "(begin (define (tes n) (< n 1)))" reliably causes the
bug I had been experiencing (as does the full Fibonacci function
above).

Actually, I am *very* curious if this is the bug.  I can try to see if
it is now that I know what to look for (or if you fix it in SVN then I
will first make sure the bug still exists in mine, when it does then I
will update LLVM to the latest trunk and test again, if it was fixed
that I will be giving many thanks), but the earliest that I might be
able to check will be this coming Thursday night.