Displaying 9 results from an estimated 9 matches for "straup".
Did you mean:
strdup
2010 Feb 01
2
[LLVMdev] llvm interpreter cannot execute llvm-gcc generated bitcode
...code is crashing on jit too and
when using the interpreter it is much easier to iron out the problems.
Although as it seems at the current state the interpreter is quite
unreliable.
Thank you,
Kristaps.
On Thu, Jan 28, 2010 at 8:04 PM, Nick Lewycky <nicholas at mxc.ca> wrote:
> Kristaps Straupe wrote:
>>
>> Hi!
>>
>> We are compiling a very large C project in llvm and trying to execute
>> it in interpreter. There is a problem with executing the generated
>> bitcode.
>
> The interpreter is under-maintained in general, but this bug in particular
&g...
2010 Feb 01
0
[LLVMdev] llvm interpreter cannot execute llvm-gcc generated bitcode
On 02/01/2010 01:13 PM, Kristaps Straupe wrote:
> Hello again!
>
> We have fetched the latest llvm sources from repository and the
> original problem has went away. Though now we are facing a new problem
> with interpreter on the following c code:
>
> --------------
> #include <stdarg.h>
> #include <st...
2010 Jan 28
0
[LLVMdev] llvm interpreter cannot execute llvm-gcc generated bitcode
Kristaps Straupe wrote:
> Hi!
>
> We are compiling a very large C project in llvm and trying to execute
> it in interpreter. There is a problem with executing the generated
> bitcode.
The interpreter is under-maintained in general, but this bug in
particular is fixed SVN as-of r86428. Are you on a...
2010 Jan 28
3
[LLVMdev] llvm interpreter cannot execute llvm-gcc generated bitcode
Hi!
We are compiling a very large C project in llvm and trying to execute
it in interpreter. There is a problem with executing the generated
bitcode.
We are using lli.exe and llvm-gcc.exe from official 2.6 LLVM release.
We have localized the problem to following c code:
--------------------
int f(unsigned char x) __attribute__((noinline));
int f(unsigned char x)
{
return x - 1;
}
int main()
2010 Feb 02
1
[LLVMdev] __fixunsdfdi and etc with Visual Studio JIT?
Hello!
We are running bitcode with JIT on visual studio project and we get
strange external function call problems (jit generates jump to
00000000 address as can be seen in debugger) for libgcc functions like
__fixunsdfdi, __divdi3 etc. Currently we have attached our own
implementations of these functions to overcome this problem. What
would be the correct way to do this on Visual Studio? Why
2010 Feb 03
0
[LLVMdev] jit X86 target compilation callback bug
On 02/03/2010 01:08 PM, Kristaps Straupe wrote:
> Hello again.
>
> I still think that you are wrong. Realignement with and esp,-16 not
> always changes stack poiner. If esp is already aligned to 16 byte
> boundary, it will not change! Take a look at following example.
> Assume esp has value 0x000001000 at start of X86Co...
2010 Feb 03
2
[LLVMdev] jit X86 target compilation callback bug
Hello again.
I still think that you are wrong. Realignement with and esp,-16 not
always changes stack poiner. If esp is already aligned to 16 byte
boundary, it will not change! Take a look at following example.
Assume esp has value 0x000001000 at start of X86CompilationCallback
function. Then execution of it will yield following esp values:
0x000000FFC - after push ebp
0x000000FFC - after mov
2010 Feb 26
0
[LLVMdev] ARM (JIT) jump table bug
Hello!
We are experiencing a problem with jit generated instructions for arm
target (we have built llvm gcc for arm arch using the llvm sources
fetched from llvm svn a few days ago).
It triggers assert in MachineOperand::getImm method (isImm() && "Wrong
MachineOperand accessor") when the bitcode from the testcase (c code
below in this email) is being run. We have found out that
2010 Feb 02
3
[LLVMdev] jit X86 target compilation callback bug
Hi!
We are running llvm jit x86 on MS Visual Studio 2005. It seems there
is a bug in asm code in function X86CompilationCallback in file
X86JITInfo.cpp. Current code sets stack pointer to invalid value in
instruction "and esp, 16". Depending on current stack pointer value
it sometimes overwrites ecx and edx registers with next three lines.
We have fixed this problem by changing this