similar to: [LLVMdev] LLVM & Large memory 64-bit systems

On Thu, 16 Dec 2004, Markus F.X.J. Oberhumer wrote: > On Thursday 16 December 2004 06:22, Chris Lattner wrote: >> On Thu, 16 Dec 2004, Markus F.X.J. Oberhumer wrote: >>> More problematic is the use of unsigned instead of size_t in many llvm >>> places - how does the the following file big_array.c compile on your >>> current 64-bit targets: >> >>

I commented this line and it is compiling now: extern void *malloc ARGS((unsigned)); I hope that will not cause a different kind of problem. What it is zalloc used for? Thanks --- Chris Lattner <sabre at nondot.org> wrote: > On Sat, 12 Mar 2005, xavier wrote: > > > It seems that this happened before but I do not know the details: > >

This patch (apologies for the size) updates zlib/* to the files that ship with zlib 1.1.3. Index: zlib/ChangeLog =================================================================== RCS file: /cvsroot/rsync/zlib/ChangeLog,v retrieving revision 1.1 diff -u -r1.1 ChangeLog --- zlib/ChangeLog 7 May 1998 06:19:41 -0000 1.1 +++ zlib/ChangeLog 30 Jan 2002 01:12:41 -0000 @@ -1,6 +1,54 @@ ChangeLog

Yes, sorry for not mentioning it. I added that header also Although I suppose that if I am not using Sparc there will be no problem (it's an Itanium 2 machine) Thanks --- Chris Lattner <sabre at nondot.org> wrote: > On Sat, 12 Mar 2005, xavier wrote: > > > I commented this line and it is compiling now: > > > > extern void *malloc ARGS((unsigned)); > >

It seems that this happened before but I do not know the details: http://llvm.cs.uiuc.edu/testresults/SparcV9/2004-12-07.html Thanks --- Chris Lattner <sabre at nondot.org> wrote: > On Sat, 12 Mar 2005, xavier wrote: > > llvm[2]: Compiling zalloc.c for Release build > > /homes/myuser/LLVM/llvmobj/../llvmsrc/utils/Burg/zalloc.c:9: error: conflictin > > g types for

Hi All, Here are answers to the questions / comments that were raised so far during the SPIR discussions. **** A general clarification regarding sizeof **** In SPIR, sizeof in an integer constant expression is illegal. The reason behind it is that once the device is no longer known, the width of the unsigned integer that represents the size_t type is no longer known. The C spec states in

Volodya, I think you may need to update your CFE and rebuild. I compiled the test using my local build and I didn't get the results you see below. I'm also very surprised to see this output. The first %tmp.11 should have been %tmp.1 .. not sure how it got corrupted. In any event, the attachment is obviously generated by code that runs quite differently because the virtual register names

Okay, let me test with exactly your options and I'll let you know what I get. Reid. On Wed, 7 Jul 2004 19:53:15 +0400 Vladimir Prus <ghost at cs.msu.su> wrote: > Reid Spencer wrote: >> Volodya, >> >> I think you may need to update your CFE and rebuild. I compiled the test >> using my local build and I didn't get the results you see below. I'm

Reid Spencer wrote: > Volodya, > > I think you may need to update your CFE and rebuild. I compiled the test > using my local build and I didn't get the results you see below. I'm > also very surprised to see this output. The first %tmp.11 should have > been %tmp.1 .. not sure how it got corrupted. In any event, the > attachment is obviously generated by code that runs

Ouriel, Boaz wrote: ... *** Richard Smith, Eli Friedman & Nadav Rotem: Portability Issues *** *****comment 1: int does_this_compile[sizeof(void*) - 3]; Answer: We are discussing this internally and will provide an answer soon. ****comment 2: struct how_do_you_represent_this_in_IR {

Okay, I've replicated your results, but I don't think there's an error here, its just not nice output from the disassembler. The first %tmp.ll is of type long. The second one is of type short. I think that's valid for LLVM. That is, the SSA form depends on both the type and name of the virtual register. In any event, llvm-as seems to compile the llvm-dis output just fine. Make

hi, when i build hello.cpp, it show following conflict: ----------------------------------------------------------- [yue at RH9 Shootout-C++]$ llvmg++ hello.cpp -o hello WARNING: Type conflict between types named 'struct._Unwind_Exception'. Src='{ ulong, void (uint, \4 *) *, uint, uint }'. Dest='{ ulong, void (ubyte, \4 *) *, uint, uint }' gccld: error linking in

Hello, when I'm compiling test/Programs/SingleSource/UnitTests/2003-05-26-Shorts.c I get LLVM assembler which looks like: int %main(int %argc, sbyte** %argv) { entry: call void %__main( ) %tmp.11 = call ulong %getL( ) ; <ulong> [#uses=16] %tmp.3 = cast ulong %tmp.11 to long ; <long> [#uses= %tmp.5 = cast ulong %tmp.11 to

Chris, Thanks for your answer Here is the verbose output: =========================== gmake tools-only VERBOSE=1 TOOL_VERBOSE=1 for dir in lib/System lib/Support utils lib tools ; do \ if [ ! -f $dir/Makefile ]; then \ /home/myuser/LLVM/objdir/../srcdir/autoconf/mkinstalldirs $dir; \ cp /home/myuser/LLVM/objdir/../srcdir//$dir/Makefile $dir/Makefile; \ fi; \ (gmake -C $dir all )

Hi These are: ======================== llvm[2]: Linking Release Object Library LLVMbzip2.o gmake[2]: Leaving directory `/homes/myuser/LLVM/llvmobj/lib/Support/bzip2' gmake[1]: Leaving directory `/homes/myuser/LLVM/llvmobj/lib/Support' gmake[1]: Entering directory `/homes/myuser/LLVM/llvmobj/utils' gmake[2]: Entering directory `/homes/myuser/LLVM/llvmobj/utils/Burg' llvm[2]:

Hi! Hmm, ok. I'm using the 1.2 release. Found out that it worked when using long to index getelementptr, but not when using uint, int or ulong. But then I'll try with the CVS code instead. Thank you. , Tobias On Sat, 12 Jun 2004, Reid Spencer wrote: > Hi Tobias, > > I tried your test program on the latest CVS code. Everything worked > fine. > > Can you tell me which

On Fri, 11 Mar 2005, Markus F.X.J. Oberhumer wrote: > Is there an optimization pass that eliminates redundant pointer > arithmethics ? In the example below llvm is only able to optimize > away the subtraction in test1, but not in test2/3. Nope, there isn't anything yet. This should be handled by the instruction combiner. I'll file an enhancement PR for this, and sometime when

On 11/24/2013 03:29 AM, Gene Cumm wrote: >> >> (Sorry for the top posting.) > > I just started examining this and find it odd that the core_udp_recv() > doesn't zalloc() its token while core_udp_send()/core_udp_sendto() do. > All three are a part of commit fe283b78 by Matt Fleming. Should this > be made into a zalloc() rather than pushing it into the stack?

On Wed, Sep 19, 2012 at 5:43 AM, Benyei, Guy <guy.benyei at intel.com> wrote: > Ouriel, Boaz wrote: > > > ... > > > *** Richard Smith, Eli Friedman & Nadav Rotem: Portability Issues *** > > *****comment 1: int does_this_compile[sizeof(void*) - 3]; > Answer: We are discussing this internally and will provide an answer soon. >

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> I have looked in the GetElementPtr FAQ but could not find the answer to this.<br> <br> I have