I'm fine with using JIT, but I'm trying to understand this problem:
1. My LLVM program does not produce correct results
2. Using llvm-dis, I disassemble the bytecode to C
3. I recompile using GCC and the program _works correctly_.
The only odd thing is when I recompile with GCC, I see these messages:
pal3.c:195: warning: conflicting types for built-in function `strcmp'
pal3.c:200: warning: conflicting types for built-in function `memcpy'
pal3.c:202: warning: conflicting types for built-in function `strncpy'
The lines referenced are:
int strcmp(signed char *, signed char *);
signed char *memcpy(signed char *, signed char *, unsigned );
signed char *strncpy(signed char *, signed char *, unsigned );
Do you have any insight into what's happening? Thanks,
-Eric
----- Forwarded message from Chris Lattner <sabre@nondot.org> -----
The only thing I can think of is that string.h is being #included and
has different signatures for memcpy and strncpy. Possibly "char" is not
signed on your machine (very unusual) or some of the parameters are
declared as "const".
I'm fine with using JIT, but I'm trying to understand this problem:
1. My LLVM program does not produce correct results
How are you running it when it does not produce correct results? The
interpreter (lli -force-interpreter) will not work with strncpy.
2. Using llvm-dis, I disassemble the bytecode to C
3. I recompile using GCC and the program _works correctly_.
So it works with the C backend, but not with which code generator?
The only odd thing is when I recompile with GCC, I see these messages:
pal3.c:195: warning: conflicting types for built-in function `strcmp'
pal3.c:200: warning: conflicting types for built-in function `memcpy'
pal3.c:202: warning: conflicting types for built-in function `strncpy'
Do you have any insight into what's happening? Thanks,
These warnings can be ignored. I don't know of any way to make GCC be
quiet about them.
The only thing I can think of is that string.h is being #included and
has different signatures for memcpy and strncpy. Possibly "char" is not
signed on your machine (very unusual) or some of the parameters are
declared as "const".
The problem is that the code generated by the C backend cannot include any
system headers. If the system header were to have a #define (not a rare
occurance) the header could arbitrarily change the CBE code in BAAD ways.
There is no reason for GCC to emit this warning. Basically it is
expecting slightly different, but compatible, types in the prototype. I
don't think there is any clean way to work around this, but I'm certainly
open to suggestions.
-Chris
Reid.
> Chris,
>
> I'm fine with using JIT, but I'm trying to understand this problem:
> 1. My LLVM program does not produce correct results
> 2. Using llvm-dis, I disassemble the bytecode to C
> 3. I recompile using GCC and the program _works correctly_.
>
> The only odd thing is when I recompile with GCC, I see these messages:
>
> pal3.c:195: warning: conflicting types for built-in function `strcmp'
> pal3.c:200: warning: conflicting types for built-in function `memcpy'
> pal3.c:202: warning: conflicting types for built-in function `strncpy'
>
> The lines referenced are:
> int strcmp(signed char *, signed char *);
> signed char *memcpy(signed char *, signed char *, unsigned );
> signed char *strncpy(signed char *, signed char *, unsigned );
>
> Do you have any insight into what's happening? Thanks,
> -Eric
>
> ----- Forwarded message from Chris Lattner <sabre@nondot.org> -----
>
> Date: Wed, 14 Apr 2004 19:25:45 -0500 (CDT)
> From: Chris Lattner <sabre@nondot.org>
> To: llvmdev@cs.uiuc.edu
> Subject: Re: [LLVMdev] Linking strncpy
> Reply-To: llvmdev@cs.uiuc.edu
>
> > I'm working on a CS326 compiler project, and I'm having some problems
> > using string functions. Some LLVM programs produced are either
> > aborting or giving incorrect results; however, if I disassemble the
> > LLVM bytecode and recompile with GCC, everything works fine.
> >
> > I encountered the following error when running lli with
> > '-force-interpreter' option:
> > "Tried to execute an unknown external function: sbyte * (sbyte
> > *, sbyte *, uint) * strncpy"
>
> This is one of the "features" of the interpreter: it only supports
> external functions that it "knows" about. Why not use the JIT, without
> -force-interpreter? Are you on a machine that we don't support? If so,
> you can either add support for strncpy (to
> lib/ExecutionEngine/Interpreter/ExternalFunctions.cpp) or use the C
> backend.
>
> -Chris
>
>
> > Strncpy is used as part of my compiler's run-time library, and it was
> > compiled with the C-frontend for LLVM. Looking at the assembly, the
> > function is declared at the top of the file;
> >
> > declare sbyte* %strncpy(sbyte*,sbyte*,uint) ;; __builtin_strncpy
> >
> > And it is called like this:
> > %tmp.12 = call sbyte* (sbyte*, sbyte*, uint)* %strncpy(sbyte*
> > %tmp.15, sbyte* %tmp.23, uint %tmp.27)
> >
> > What am I forgetting to do? What is the right way to link to the
> > string functions? Thanks,
> >
> > -Eric Zimmerman
> >
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev@cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev
_______________________
Reid Spencer
President & CTO
eXtensible Systems, Inc.
rspencer@x10sys.com
You don't need to do this to get those annoying GCC warnings. They come
out whenever you compile a C program produced by the LLVM CBE that uses
certain GCC "builtins", like memcpy...
You don't need to do this to get those annoying GCC warnings. They come
out whenever you compile a C program produced by the LLVM CBE that uses
certain GCC "builtins", like memcpy...
-Chris
That's weird. Perhaps GCC knows about its own builtin functions and the
prototypes for them so that if you declare a similar function with the
wrong prototype you get the warning?
I would suspect (and this is only a guess) that GCC would warn on
builtins that it doesn't actually generate a function for.
memcpy/memmove fall into this category on processors like i86 because
there are simple instructions to essentially do the copy/move. Even
though the function may be declared and even implemented somewhere in a
header file, it probably singles a few of them out for direct code
implementation rather than function call?
I'm fine with using JIT, but I'm trying to understand this problem:
1. My LLVM program does not produce correct results
2. Using llvm-dis, I disassemble the bytecode to C
3. I recompile using GCC and the program _works correctly_.
The only odd thing is when I recompile with GCC, I see these messages:
pal3.c:195: warning: conflicting types for built-in function `strcmp'
pal3.c:200: warning: conflicting types for built-in function `memcpy'
pal3.c:202: warning: conflicting types for built-in function `strncpy'
The lines referenced are:
int strcmp(signed char *, signed char *);
signed char *memcpy(signed char *, signed char *, unsigned );
signed char *strncpy(signed char *, signed char *, unsigned );
Do you have any insight into what's happening? Thanks,
These warnings seem to happen and, as far as I can tell, can be safely ignored.
If you're on x86, it's possible that your code works incorrectly due to bugs in our code generator that have been fixed since I created the LLVM source tarball for your class. I know at least one codegen bug has been found since I made the tarball.
If you could post the snippet of LLVM assembly code that is miscompiled, that will help us figure out if LLVM was/is miscompiling your program. Also, you can check the following URL for X86 Backend bugs to see if your code could be triggering the following bugs:
Thanks for the explanation of the GCC warnings. The source of my
problem was apparently on my end since I haven't been able to
reproduce the bug since yesterday. Again, thanks to all for your
help.
