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 at nondot.org> ----- Date: Wed, 14 Apr 2004 19:25:45 -0500 (CDT) From: Chris Lattner <sabre at nondot.org> To: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Linking strncpy Reply-To: llvmdev at cs.uiuc.edu On Wed, 14 Apr 2004, Eric Zimmerman wrote:> 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 >
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". Reid. On Wed, 2004-04-14 at 18:19, Eric Zimmerman wrote:> 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 at nondot.org> ----- > > Date: Wed, 14 Apr 2004 19:25:45 -0500 (CDT) > From: Chris Lattner <sabre at nondot.org> > To: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] Linking strncpy > Reply-To: llvmdev at cs.uiuc.edu > > On Wed, 14 Apr 2004, Eric Zimmerman wrote: > > 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 at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev_______________________ Reid Spencer President & CTO eXtensible Systems, Inc. rspencer at x10sys.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20040414/a1eef674/attachment.sig>
On Wed, 14 Apr 2004, Eric Zimmerman wrote:> Chris, > > I'm fine with using JIT, but I'm trying to understand this problem: > 1. My LLVM program does not produce correct resultsHow 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. :) -Chris -- http://llvm.cs.uiuc.edu/ http://www.nondot.org/~sabre/Projects/
On Wed, 14 Apr 2004, Reid Spencer wrote:> 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. > > On Wed, 2004-04-14 at 18:19, Eric Zimmerman wrote: > > 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 at nondot.org> ----- > > > > Date: Wed, 14 Apr 2004 19:25:45 -0500 (CDT) > > From: Chris Lattner <sabre at nondot.org> > > To: llvmdev at cs.uiuc.edu > > Subject: Re: [LLVMdev] Linking strncpy > > Reply-To: llvmdev at cs.uiuc.edu > > > > On Wed, 14 Apr 2004, Eric Zimmerman wrote: > > > 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 at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev > > > _______________________ > Reid Spencer > President & CTO > eXtensible Systems, Inc. > rspencer at x10sys.com >-Chris -- http://llvm.cs.uiuc.edu/ http://www.nondot.org/~sabre/Projects/
Eric Zimmerman wrote:> 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,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: http://llvm.cs.uiuc.edu/bugs/buglist.cgi?short_desc_type=allwordssubstr&short_desc=&component=X86+Backend&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=RESOLVED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&changedin=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&namedcmd=All&newqueryname=&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0 Regards, -- John T.> -Eric > > ----- Forwarded message from Chris Lattner <sabre at nondot.org> ----- > > Date: Wed, 14 Apr 2004 19:25:45 -0500 (CDT) > From: Chris Lattner <sabre at nondot.org> > To: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] Linking strncpy > Reply-To: llvmdev at cs.uiuc.edu > > On Wed, 14 Apr 2004, Eric Zimmerman wrote: > >>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 at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev-- ********************************************************************* * John T. Criswell Email: criswell at uiuc.edu * * Research Programmer * * University of Illinois at Urbana-Champaign * * * * "It's today!" said Piglet. "My favorite day," said Pooh. * *********************************************************************
On Thu, Apr 15, 2004 at 08:32:44AM -0500, John Criswell wrote:> > > >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: > > http://llvm.cs.uiuc.edu/bugs/buglist.cgi?short_desc_type=allwordssubstr&short_desc=&component=X86+Backend&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=RESOLVED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&changedin=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&namedcmd=All&newqueryname=&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0> > Regards, > > -- John T. >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. -Eric